Re: [TLS] New version of Multiple OCSP mode of Certificate Status extension

["Yngve Nysaeter Pettersen" <[e-mail]>]

On Tue, 03 Aug 2010 18:51:04 +0200, Peter Gutmann  
<[e-mail]> wrote:

> "Yngve Nysaeter Pettersen" <[e-mail]> writes:
>
>> AFAIK, currently all the major browsers check for OCSP for the site
>> certificates (IE for Vista and later, XP requires a preference change  
>> IIRC),
>> I am not quite sure about CRLs, but checking intermediates is a  
>> requirement
>> for Extended Validation verification. I didn't see any need to  
>> distinguish
>> the cases, so we check CRLs for all certificates that identify them  
>> (and if
>> one certificate have a CRL defined, we require them for all certificates
>> below the Root, except the ones we check OCSP for, or we remove the  
>> padlock)
>
> How does this impact availability?  This would make the effective  
> availability
> of a site the same as that of the least reliable CRL/OCSP server in the  
> chain.
> Do you block on all the certs checking out, or perform it in a background
> thread?  Again, blocking would make the response time of the site the  
> same as
> that of the slowest-responding CRL/OCSP server in the chain.

Opera has a 15-20 second timeout for such operations, as well as AIA  
intermediate CA cert retrieval, and if the timeout is triggers the URL is  
marked as "don't use" for a few hours, so the delay will be on the first  
request only.

There are requirements in the Extended Validation guidelines for being  
able to download revocation responses within a few seconds even for low  
bandwidths.

The cases where we have run into trouble have been caused by OCSP/CRL  
responders that have been specified with HTTPS URLs (rather than HTTP) and  
where the TLS certificate of the responder referenced the same revocation  
resource (an example of this have been CAcert.org), which causes a bit of  
a trouble when you suspend all other connections to that specific server  
while negotiating a session (to avoid negotiating multiple sessions for  
the same server). We have currently "solved" this problem by immediately  
failing such loops (which does not affect the revocation request)

>> The optimization benefits for my proposals, is that the client need to  
>> check
>> fewer online revocation resources than before, and they will preferably  
>> be
>> more up to date, in the best case it does not have to check any online
>> resources since the server provided them all.
>
> What about having public CA certs contains a special indicator in them  
> to tell
> apps that they're revocation-proof and there's no need to check CRLs and
> whatnot, since they'll never be revoked?  That would speed up checking  
> quite a
> bit.

That would cause problems if the key is compromised

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************