Re: [pkix] Deployment Clarifications about RFC6960 - Section 2.2 and 4.4.8

[Gervase Markham <[e-mail]>]

I wasn't involved in writing RFC 6960, but:

On 13/11/14 22:18, Dr. Massimiliano Pala wrote:
> In particular, by extending the responsibilities of the OCSP responders
> to provide also information about the issuing status (instead of just
> the revocation information) we might have potential deployment issues -
> that is, for pre-computed responses, it seems difficult to make any
> useful use of the Extender Revoked extension. This also applies for
> other transport protocols that could be defined to make the OCSP
> responses easily accessible (e.g., OCSP over DNS or OCSP over LDAP - not
> currently standardized, but, I think, useful). 

As far as the web is concerned, HTTP (and stapling) is the way to go.
CRL retrieval over LDAP (for example) is no longer supported by Firefox,
if it ever was.

> Also, I think there are some security considerations. The first one is
> about protecting against certificate enumeration. 

Is that a security consideration, or a "protect a CA's business secrets"
consideration? Regardless, CT means CAs in the Web PKI need to disclose
everything anyway. Serial numbers remain random because randomness in
certificate contents is a good "belt and braces" defence against various
types of attack.

> Historically, CRLs were the source of revocation information for the
> OCSP.

Yep. That's no longer possible, for the reasons you give. An OCSP
responder is more than just a CRL-fragment-responder.

> Unfortunately there is no standard for a signed "white" list - this
> would be huge for many CAs. If CRLs are bad for sizes and they usually
> are 10% of the overall population of certificates, the list of valid
> certificates is quite huge and should be updated (and synchronized
> throughout all the OCSP server cloud) each time a new certificate is
> issued. This would mean that a CA has now to make 2 signatures each time
> a certificate is issued - one of which over a huge file (the white list
> itself).

Why not just send a copy of the certificate itself? It's signed by the
CA's key, and it is small.

> As it is now, I would not implement the feature as I think it reduces
> the overall security of the OCSP infrastructure.

If your OCSP responder does not implement this feature, it will not be
possible for any hierarchy which wishes to be CAB Forum BR-compliant to
use your software. (I don't know whether this is a matter of concern for
you or not.)

Gerv