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

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

On Mon, 02 Aug 2010 18:26:31 +0200, Peter Gutmann  
<[e-mail]> wrote:

> "Yngve Nysaeter Pettersen" <[e-mail]> writes:
>
>> This issue will not be any different from the current situation; When  
>> they
>> check OCSP, clients only check the site certificate. If they check  
>> revocation
>> for intermediates they use CRLs. In fact, for Opera's part, we retrieve  
>> CRLs
>> while verifying the certificate, OCSP after the certificate has been  
>> checked,
>> so CRLs are more "dangerous" from that perspective.
>
> Just out of interest, is this a pure performance optimisation, or a tacit
> recognition of the fact that no public CA cert has ever been revoked no  
> matter
> how negligently the CA has behaved [0] (and it's unlikely that one ever  
> will
> because the collateral damage incurred makes it politically untenable),
> therefore there's no need to spend too much time on revocation checks?
>
> What do other implementations do?  Does anyone check CA certs for  
> revocation
> when they process a cert chain?

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)

Previously, intermediate CA roots were usually issued just to the CA that  
owned the Root, now I am seeing a tendency to issue intermediate CA  
certificates to larger companies, for example. Worst case, it might be  
that it is only a question of time before an intermediate CA have to be  
revoked (That is different from revoking a Root, where the collateral  
damage will be huge if it ever happens, but in such a case the Root key  
has probably been compromised).

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. For the CA, there  
will ultimately be less traffic to the server, and it will depend less on  
the number of users, and more on the number of customers.


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