Subject: [pkix] PKIX and Revocation - Time to move forward!

From: "Dr. Pala" <[email-masked]>
Date: Mon, 20 Nov 2017 12:20:31 -0500

Hi all,

although it seems that in the SEC area there is little interest in 
addressing the issue of revocation, we think it is still important to 
address it. Unfortunately, since the PKIX WG was closed, this type of 
work has no house and, as a consequence, there has been NO improvement 
on PKIX in AGES!

We are currently working on a couple of proposals that we are going to 
deploy (independently from IETF's interest in it) in several industry 
segments and related organizations. In particular, we have two different 
proposals. The first is the OCSP over DNS that aims at providing an 
additional transport protocol for OCSP responses (i.e., it is an 
alternative to OCSP over HTTP and not, as some people wrongly focused 
on, as a replacement of OCSP stapling). The draft is currently available 
here:

  * https://datatracker.ietf.org/doc/draft-pala-odin/

For the second proposal, we are not ready to disclose it but it is 
related to improve and simplify revocation information checking.

In order to make a good case around the new design, I wanted to ask the 
PKIX WG few questions that would help confirming or rejecting our 
assumptions related to some PKIX ops (from a CA perspective).

These are my questions:

  * *Does anyone remember why the use of non-sequential random serial
    number for certificates was introduced ?* Initially, I think, it was
    an attempt at masking the number of issued certificates from a CA.
    Then, there was some kind of argument about the "randomness" of data
    within certificates (that did not make sense to me, really, since
    the public key provides plenty of randomness) - maybe this was
    combined with the fear of having "weak" hash algorithms for signing
    certificates ? I.e., SHA-1 ? If that is correct, would the use of
    SHA2 family (or next gen ones) solve the issue and remove the
    alleged need for random serial numbers ?

  * *Why the OCSP protocol behavior was shifted from revocation checking
    to validity checking ?* When the OCSP protocol was first
    standardized, it was meant to provide revocation information (an
    alternative to CRLs) - in particular when no revocation information
    existed related to a requested serial number, the response would
    carry the "valid" response. Following some compromises of CAs, the
    CAB forum (???) decided to mandate for a different interpretation of
    the OCSP: instead of a revocation checking mechanism, they wanted to
    use it as a validation mechanism in the sense that "valid" responses
    were to be returned only for serial numbers of ISSUED certificates
    and not for serial numbers for which no revocation information
    existed (i.e., even if a certificate with the requested serial
    number was never issued). If I am not mistaken, this was an attempt
    at certificate transparency - for which now we have a whole set of
    (overly complicated, IMHO) infrastructure :-( If that is true,
    wouldn't be the original intended usage of OCSP be more appropriate
    today ?

Since in the recent years we developed lots of experience when it comes 
to what and how is actually used for revocation checking, I think we can 
easily provide simpler designs with lower operational costs and, 
consequently, better (more frequent) updates [*] for revocation 
information that take all these considerations into account (in 
particular, the requirements related to the 2nd question above have 
pushed the costs of providing revocation information - probably an 
not-intended consequence/side effect).

Thanks everybody in advance for all your feedback/insights, and please 
let me know if you are interested in collaborating and in which capacity.

Cheers,
Max

[*] Because of this shift in OCSP behavior, CAs now issue OCSP responses 
that have validity of up to 7 days, which is definitely not what OCSP 
was intended for (usually few minutes, hours or maybe one day max was 
initially view

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 20 Nov 2017 18:27:37 -0500

Hi Ryan,

thanks for the reply! Some comments inline...

On 11/20/2017 02:06 PM, Ryan Sleevi wrote:
> [...]
> I don't think it's fair to suggest that a lack of interest in 
> addressing the issue as you've framed it supports a conclusion that 
> there's been no improvements. I think there's been substantial 
> improvements within the relatively focused communities - as both LAMPS 
> and TRANS show - but it may be that you simply disagree on whether 
> they're improvements.
Don't get me wrong, there's been work in many directions - but none 
really focused on improving the access/scalability/availability of 
revocation information (to a certain extent). Good work, but I see it 
more as patches rather than tackling the main issue. In my personal 
experience, when we tried to tackle revocation issues directly, the 
answer from WG Chairs or SEC AD was "we are not interested" or "it does 
not belong here", even when interest was expressed on the mailing 
list(s). As I say, regrettably, this is my direct personal experience. :-(
>
>     [...]
>
>       * *Does anyone remember why the use of non-sequential random
>         serial number for certificates was introduced ?* Initially, I
>         think, it was an attempt at masking the number of issued
>         certificates from a CA. Then, there was some kind of argument
>         about the "randomness" of data within certificates (that did
>         not make sense to me, really, since the public key provides
>         plenty of randomness) - maybe this was combined with the fear
>         of having "weak" hash algorithms for signing certificates ?
>         I.e., SHA-1 ? If that is correct, would the use of SHA2 family
>         (or next gen ones) solve the issue and remove the alleged need
>         for random serial numbers ?
>
> This is not a requirement of any IETF documents.
>
> It is a requirement of various industries - for example, the 
> CA/Browser Forum's Baseline Requirements - and itself was predated by 
> various root program requirements that trace their history back to the 
> MD5 collisions on 'live' CAs ~2006.
>
> Much in the same way that some CAs (incorrectly) argued that the 
> entropy added for MD5 was unnecessary for SHA-1, it seems premature to 
> suggest that the entropy is yet again unneeded for SHA-2 (given the 
> construction similarities). In either event, this represents one of 
> the few unpredictable fields that cannot be controlled by an attacker 
> under an adversarial issuance model, and in the world in which all 
> (Web) issuance should be fully automatic, that is worth considering.

Sorry if it was not clear, I was not suggesting that this was a 
requirement, rather I wanted to verify the story here. Thanks for the 
clarifications.

> [...]
> As part of this, the industry's adopted requirements require CAs to 
> regularly monitor their OCSP systems for such requests as yet another 
> signal of possible compromise.
Maybe I do not fully understand your point, but I think that you just 
confirmed what I wrote, in some sense... ? The switch in the semantics 
of the OCSP protocol was/is related to certificate transparency and 
certificate usage monitoring (i.e., if bad "serial number" are detected, 
there might be something weird going on). I guess, but correct me if I 
am wrong, that what you are saying is that this switch is complementary 
to CT rather than an initial attempt at CT... ?
>
>     Since in the recent years we developed lots of experience when it
>     comes to what and how is actually used for revocation checking, I
>     think we can easily provide simpler designs with lower operational
>     costs and, consequently, better (more frequent) updates [*] for
>     revocation information that take all these considerations into
>     account (in particular, the requirements related to the 2nd
>     question above have pushed the costs of providing revocation
>     information - probably an not-intended consequence/side effect).
>
> I don't think the argument that it's increased the costs is well 
> supported, and certainly not with respect to the holistic costs of 
> maintaining "keys to the Internet".
Let's put it this way - what if we have a system that does not have to 
provide signed "tokens" (OCSP responses) for each issued certificates 
but optimizes for the "valid" case ? In this case, if you run a PKI 
with, let's say, 100M valid certs of which you have 300K revoked, if you 
only have to provide 600K signatures overall, this definitely might 
change the order of magnitude of the incurred costs in terms of 
"capacity" (e.g., networking, signing, etc.).

I am trying to gather some information from major CAs around this point 
to understand what the real situation is today :D When / If I manage to 
get some data around this (if anybody is actually interested), I would 
be happy to share it with the community.

Do you (or anybody on the list) happen to have worked / have experience 
running large revocation infrastructure ? If so, would you mind sharing 
your experience (e.g., costs per-certificate for rev info provisioning - 
comprising the costs incurred for running or outsourcing the required 
infrastructure) ? I think it would be useful...

> In either event, it's worth noting that significant areas of 
> performance, privacy, and correctness have been glossed over, and from 
> industry, we know these are all substantial concerns that exist with 
> the revocation infrastructure today.
+1
>
> [...]
> This is all predicated on an assumption of server certificates, 
> although admittedly, there are many other deployments that exist. 
> However, it is useful to frame the problem in the intended communities 
> - whether server certs, client certs, S/MIME, whether closed intranets 
> or public Internet, etc - so that the constraints can be understood 
> and the potential implementors can be determined.
>
>     [...]
>
You make very good points here, and I do not disagree :D I am also 
thinking about other environments where milliseconds are not the issue 
(IoT) and scalability might be the dominant design requirement.
>
>     [*] Because of this shift in OCSP behavior, CAs now issue OCSP
>     responses that have validity of up to 7 days, which is definitely
>     not what OCSP was intended for (usually few minutes, hours or
>     maybe one day max was initially view
>
> The industry has long accepted 8 hours as the absolute minimum for 
> such responses. I also don't think the historic discussion supports 
> that paranthetical - given that OCSP and CRLs were intended with an 
> equivalency and CRL publication itself was measured in much longer 
> timescales.

I think that 8 hours is not the same as 7 days :D Big difference there. 
Also, I would say that CRLs and OCSP responses have very different 
"implemented semantics" when it comes to the validity period - it is 
well understood that CRLs should still be checked for updates (as 
information can become available at any time and certainly within the 
nextUpdate) while OCSP responses validity are today treated as 
"cachable" for tor the entire validity period (which, if I read the RFCs 
correctly, is not the correct behavior). Unfortunately, the semantics 
that would "enforce" the correct behavior (omit the nextUpdate in OCSP 
responses) is not really implemented by today's (Internet) CAs as this 
might break the (limited) HTTP caching mechanism.

Ryan, again, thanks! I really appreciated your good points and the 
discussion :D

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo