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

[Peter Gutmann <[e-mail]>]

"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.

(Feel free to reply off-list if you prefer, I'm interested in the practical
aspects of this since it availability issues are something that's never really
considered when coming up with the PKI protocols themselves.  If anyone else
has any experience with this I'd be interested in your comments as well).

>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

Oh, I know of cases where private-label (i.e. signed by public CAs but not
public CAs themselves) CA certs have been revoked, at the request of the
private-label CA, e.g. due to a change of business.  They then found out that
they could still issue certs because nothing seemed to pay attention to the
revocation :-).

>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.

Peter.