Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt)

[Geoffrey Keating <[e-mail]>]

Jean-Marc Desperrier <[e-mail]> writes:

> On 04/06/2012 06:31, Yngve N. Pettersen (Developer Opera Software ASA)
> wrote:
> > Like Martin Rex, I am concerned that this would significantly
> > increase the complexity of the system:
> >  - The servers would have to download both, and then decide which to use.
> Not necessarily, the extension is still very useful if the servers
> systematically downloads the OCSP where available, and CRL when the
> intermediate CA have no OCSP. Or has been initially configured to do
> only one of the two.
> 
> The biggest problem with the OCSP only mode is that in many cases
> intermediate CA do not have OCSP responders, so that in practice,
> either the client doesn't check intermediate levels, or it will still
> have to do several network requests when using multi.

Although most intermediate CAs don't have OCSP responders, the
intermediate certificates most commonly used on the Internet do.

That is to say, when I look at intermediate certificates visible on
the Internet, unexpired and signed by the CAs recognised by OS X, I
see only about 25% have OCSP responders named (321 out of 1256).  But,
when counting them by the number of IP addresses which send the
certificate, the numbers reverse and 74% of the certificates sent
(2071453 out of 2813712) have OCSP responders named.

These numbers should only improve in the future, as the CABforum
baseline requirements require new intermediate CAs to have OCSP
responders.

So, I wouldn't put a lot of effort into making CRLs more efficient in
situations where OCSP can be used instead.