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

[Eric Rescorla <[e-mail]>]

On Fri, Jun 1, 2012 at 8:08 AM, Martin Rex <[e-mail]> wrote:
> Rob Stradling wrote:
>>
>> IIRC, when Opera does an online revocation check, it currently checks
>> CRLs for intermediate CA certificates and OCSP for end-entity
>> certificates.  This makes sense because:
>>    - CRLs covering intermediate CA certificates tend to be roughly the
>> same size (sometimes smaller!) as the equivalent OCSP Responses (since
>> it's quite rare for intermediate CA certificates to be revoked).
>>    - Possessing a current CRL means you won't have to do an online
>> revocation check if you encounter another certificate issued by the same
>> issuer.
>>
>>   [...]
>>
>> How about changing the scope of the multi-stapling I-D so that it *only*
>> covers the intermediate CA certificate(s) in the chain?
>
> This would significantly increase the complexity without adding value.
> OCSP responses can be cached just as long as the CRLs on which they're
> based.
>
>>
>> With this approach, an end-entity OCSP Response could be stapled using
>> the RFC6066 TLS extension, and the intermediate CRL(s) could be stapled
>> using the new multi-stapling TLS extension.
>
> This would require the complexity of two TLS extensions where a single
> TLS extension is perfectly sufficient (i.e. a lot more code and a lot
> more bugs).
>
>
> While I might eventually look into implementing the multi-stapling
> TLS extension, I will never consider doing the rfc6066 single OCSP
> extension.

FWIW, Chrome already supports RFC 6066 and it's in process
for Firefox.

-Ekr