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

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 11 Apr 2012 19:36:39 +0200

On Wed, 11 Apr 2012 18:54:10 +0200, Jim Schaad <[email-masked]>  
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: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 11 Apr 2012 21:15:48 +0200

On Wed, 11 Apr 2012 20:19:52 +0200, Jim Schaad <[email-masked]>  
wrote:

>
>
>> -----Original Message-----
>> From: Yngve N. Pettersen (Developer Opera Software ASA)
>> [mailto:[email-masked]]
>> Sent: Wednesday, April 11, 2012 10:37 AM
>> To: [email-masked]; Jim Schaad
>> Cc: [email-masked]
>> Subject: Re: draft-pettersen-tls-ext-multiple-ocsp questions
>>
>> > 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.
>> > issues (thus they replace direct CRLs) 3.  The CA issues a certificate
>> > to the OCSP responder (thus they replace indirect CRLs).
>> >
>> > 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.
>>
> 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.

A designated/delegated OCSP responder certificate MUST be issued directly  
 from the CA that issued the certificate that is being validated, and the  
certificate must be included in the response. See RFC 2560 sec. 2.6 and  
4.2.2.2

Since we are assuming that the client is able to build a complete  
certificate chain based on the certificates sent by the server, if  
necessary by providing certificates from its own repository or retrieving  
intermediate CA certs remotely using the AIA Issuer URL in the received  
certificates, there will be no certificates missing from the chain needed  
to verify the OCSP response, since the OCSP response is either signed  
directly by the in-chain CA that issued the certificate, or by a responder  
using a delegation certificate which was issued by that CA, and which must  
be included in the response.

The only cases for which the validation chain will be broken is if the  
server's certificate chain cannot be completed, which is a server  
configuration issue, or if the the delegation certificate either was not  
included, or was not issued by the CA that issued the certificate, which  
is a spec violation, and in such a case the client should fail the  
validation (at least of the response).

The OCSP response for a certificate forwarded by the server will (if  
valid) contain either just the signed response (signed by issuer), or the  
signed response in combination with the certificate of the  responder,  
which was issued by the CA that issued the certificate. Therefore, all  
information necessary to check the signature of the response is already  
available to the client.

At present I doubt that any client checks the revocation status of the  
delegated responder, it is presumed valid and unrevoked (the topic is  
discussed in RFC 2560 sec. 4.2.2.2.1) . This may or may not be desirable  
 from a security POV, but if so, it is something that the PKIX group should  
maybe consider as part of the 2560bis work, or perhaps a 5019 successor,  
not something that should be part of the stapling discussion, since the  
same issue would be experienced by a client retrieving the responses  
directly.

It is worth noting that (as mentioned) RFC 5019 (which is a light weight  
profile, meaning that minimum processing overhead is desired) recommends  
not providing any revocation information in the delegation certificate,  
but the decision for adding the information is the CA's, and it is the  
client's decision whether or not to check the revocation information if it  
is present (which might mean retrieving the CRL or an OCSP response). The  
server doing the stapling is not involved, and IMO it shouldn't be (if it  
was, it would have to request that information and then forward it as part  
of the stapling, which would complicate the protocol structure, as well as  
the server's control paths).

> to be
>> configured to download it from a specific responder (or responders)
> 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.

Whether OCSP or CRL is specified for the delegation certificate, and the  
client want to check it, obtaining that information is IMO outside the  
scope of this draft as currently envisioned.

If desirable, stapling such information should IMO be done by the  
responder, inside the OCSP response.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 11 Apr 2012 11:19:52 -0700

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.

to be
validation,
also
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

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