Re: [TLS] draft-pettersen-tls-ext-multiple-ocsp questions

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

On Wed, 11 Apr 2012 18:54:10 +0200, Jim Schaad <[e-mail]>  
wrote:

> There are three models for doing OCSP, as near as I can tell this draft  
> only
> addresses two of those models.
>
> 1.  The RP uses a single OCSP server that will issue the OCSP responses  
> for
> all of the certificates in a chain.
> 2.  The CA directly issues OCSP responses for the certificates that it
> issues (thus they replace direct CRLs)
> 3.  The CA issues a certificate to the OCSP responder (thus they replace
> indirect CRLs).
>
> The first two are covered as only the certificates in the CA chain and  
> the
> OCSP responses are needed, however the last model would require that
> additional certificates and potentially CRLs be transported so that the
> indirect certificate can be validated as part of processing the OCSP
> responses.

How the OCSP responses are retrieved by the server is decided by the  
server design, and is governed by RFCs 2560 and 5019, and is not really in  
scope for the document.

The most common model will be that the server retrieves them based on the  
AIA OCSP URL in the certificates, but it is also possible for the server  
to be configured to download it from a specific responder (or responders)  
different from what is stated in the certificates.

Whether the CA signs the OCSP responses directly, or uses a designated  
certificate to sign the response (this is handled by the response  
validation, same as for normal OCSP retrieval) is also IMO out of scope,  
and it is also governed by RFCs 2560 and 5019. AFAIK revocation is not  
checked on the designated issuer certificate and there is a recommendation  
in RFC 5019 about using an extension to disable OCSP checking for that  
certificate, and not including the CRL or OCSP URLs.

While most of that is IMO out of scope, what might be in scope is a  
recommendation to CAs about whether or not to use designated issuer to  
sign the responses (although I am inclined to say that this is out of  
scope, too). At least one major website operator have expressed concern  
about the responsiveness (from the user experience point of view) of their  
site if designated issuers are used, since those responses will be much  
larger than non-designated responses, which might make the handshake hit  
network limits, requiring an extra delay before the handshake can be  
completed. While this may be a concern during the first handshake of a  
session, a well-configured server should be able to keep a session alive  
for hours or maybe 24 hours, meaning that the extra delay will be rather  
infrequent (if the session are renegotiated frequently the UX impact might  
be greater).

The present document is about how the client negotiates that the server  
collects (in a manner not specified) the OCSP responses relevant to the  
certificates presented by the server, and how they are transferred from  
the server to the client. Validation of the responses are then handled  
according to RFC 2560 and RFC 5019,as part of the certificate validation  
process. It is not different from RFC 6066 in this aspect.

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