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

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: Yngve N. Pettersen (Developer Opera Software ASA)
> [mailto:[e-mail]]
> Sent: Wednesday, April 11, 2012 10:37 AM
> To: [e-mail]; Jim Schaad
> Cc: [e-mail]
> Subject: Re: draft-pettersen-tls-ext-multiple-ocsp questions
> 
> 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.

I am afraid you have missed my point.  What I am looking at is strictly the
information that needs to be conveyed to the client.

If a CA setups with an indirect signing certificate then that certificate is
REQUIRED by the client as part of the OCSP validation information chunk.
Otherwise it would need to do a retrieval on the web for that certificate in
order to validate the signature on the OCSP response.  I suggested that a
CRL MIGHT be needed for the certificate that did the OCSP signing
specifically because I would expect that such a certificate would be
excluded from the OCSP signing and thus a different way of doing the
validation would be required.  I would expect a CA to have a CRL that
consisted of JUST OCSP signers as its contents and thus the CRL itself
should be very small.

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

Which is a recommendation, but is not a requirement.  Thus one could use a
CRL for OCSP responders (using an OCSP responder for OCSP responders would
be recursive) and the model does need to be supported by this document.

Jim

> 
> 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]
> **********************************************************
> **********