[TLS] rfc4366-bis: Certificate Status for intermediate CA certificates

["Yngve N. Pettersen (Developer Opera Software ASA)" <yngve at opera.com>]

Hi,

The current Certificate Status request and response is currently only able  
to handle a single OCSP respose, for the site certificate.

A number of CAs have started to put OCSP URLs in their intermediate  
certificates, and using these URLs would help provide a more timely  
revocation information for Intermediate CA certificates too (not that it  
should normally be needed for CA certificates), not just for site  
certificates.

However, CAs have already been concerned about the network traffic  
generated by clients just performing OCSP checks directly, not via the  
Certificate Status request, and I am aware of at least one case were the  
number of such requests caused serious problems for a CA. Adding direct  
retrieval of OCSP for the intermediates, and therefore significantly  
increasing the network traffic (particularly after the Certificate Status  
extension starts handling the majority of responses) is therefore not  
recommended.

The problem with OCSP traffic for intermediates could be solved if the  
client could get the responses via the TLS server, similar to what the  
Certificate Status extension already do for site certificates.

But given the definition of the Certificate Status extension it cannot be  
used to provide OCSP information for intermediates, so a new extension  
will be needed.

My suggestion would be to add an extension to indicate support for  
multiple Certificate Status responses, e.g. "Certificate Chain Status",  
which the server have to use in the Server Hello extension list, followed  
either by a new Certificate Chain Status handshake record containing an  
array of status responses, or multiple Certificate Status messages.

Whichever record method is chose, in either case the list of responses  
must either be in the sequence the certificates are placed in the chain,  
or the responses have to be matched with the certificate somehow. An issue  
with following the sequence is that some CAs are using cross-signed  
certificates linking to multiple roots, e.g. to allow EV chains (which in  
many cases chain to new Roots) to be validated by legacy clients, or new  
CAs have their certificate signed by a CA already in most Rootstores to be  
able to enter the market.

Based on this I would suggest a new record, at least for the  
intermediates, in which each entry in the list identifies the Certificate  
it is the OCSP response for. This might be the same key used to request  
the OCSP response from the server, or some other way to identify the  
certificate (name, serialnumber, pubkeyhash, etc.)

Thoughts?



--
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: yngve at opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************