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

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

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

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

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

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

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.

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