PKIX and Revocation - Time to move forward!

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

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix