Subject: [pkix] Comments on draft-ietf-pkix-ocspagility-09 (second resent with an ASN.1 error corrected)

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 14 Sep 2010 10:46:51 +0200

Dave draw my attention on this draft since some comments made of RFC2560bis was on text imported from ocspagility. 

Let us start by these comments and then, since I reviewed the whole document, I have further comments. 

The security consideration section has two related problems. 

There are two sentences that indicate that an OCSP responder is able to provide status information at a time in the past, 
which is wrong. 

I provide both the current text (marked OLD) and a proposal replacement to fix the text (marked NEW). See page 7: 

OLD: 

   In most applications it is sufficient for the signing algorithm to be 
   at least as secure as the signing algorithm used to sign the original 
   certificate whose status is being queried. This criteria may not 
   hold in long term archival applications however in which the status 
   of a certificate is being queried for a date in the distant past, 
   long after the signing algorithm has ceased being considered 
   trustworthy. 

NEW: 

   In most applications it is sufficient for the signing algorithm to be 
   at least as secure as the signing algorithm used to sign the original 
   certificate whose status is being queried. This criteria may not 
   hold in long term archival applications however in which the status 
   of a certificate is being used for a date in the distant past, 
   long after the signing algorithm has ceased being considered 
   trustworthy. 

OLD: 

   In archival applications it is quite possible that an OCSP responder 
   might be asked to report the validity of a certificate on a date in 
   the distant past. 

NEW: 

   In archival applications it is quite possible that an OCSP response 
   is used to report the validity of a certificate on a date in 
   the distant past. 

Now, let us come to the other comments and start with an easy one: 
a typo left intentionally by the editor to check whether someone read the draft. 

On page 3, the text is: 

   Since algorithms other than the mandatory to implement algorithms are 
   Allowed, and since a client currently has no mechanism to indicate 
   it's algorithm preferences, there is always a risk that a server 
   choosing a non-mandatory algorithm, will generate a response that the 
   client may not support. 

On the second line the capital A is incorrect. The text should be changed into: 

   Since algorithms other than the mandatory to implement algorithms are 
   allowed, and since a client currently has no mechanism to indicate 
   it's algorithm preferences, there is always a risk that a server 
   choosing a non-mandatory algorithm, will generate a response that the 
   client may not support. 

Now, let us come to comments which require text changes/additions. 

On page 5, the explanations about the meaning of the fields sigIdentifier 
is not crystal clear. 

OLD: 

   sigIdentifier specifies the signature algorithm the client prefers, 
   e.g. algorithm=ecdsa-with-sha256. Parameters are absent for most 
   common signature algorithms. 

NEW: 

   sigIdentifier specifies the signature algorithm the client prefers, 
   for the OCSP responder to sign the OCSP response, e.g. 
   algorithm=ecdsa-with-sha256. Parameters are absent for most common 
   signature algorithms. 

Finally, let us come to a more substantial comment: 

If the client indicates a sigIdentifier parameter, this means that the OCSP 
responder has more than one certificate. Since the OCSP response has a certs field in Signature, 
the OCSP responder may place certificates in it. I do not believe that the field PreferredSignatureAlgorithm 
as defined is the best approach. 

I would propose the following: 

     PreferredSignatureAlgorithm ::= SEQUENCE { 
        sigIdentifier AlgorithmIdentifier, 
        certs BOOLEAN DEFAULT FALSE 
        } 

along with the following explanations: 

If the certs field is present or set to TRUE, then the OCSP responder SHALL return in the certs field from the Signature 
all the OCSP certificates issued by the CAs known by the OCSP responder which guaranty the OCSP signing key 
with the algorithm chosen by the OCSP responder. 

If the certs field is missing or set to FALSE, then the OCSP responder SHALL NOTinclude any OCSP certificate 
in the certs field from the Signature. 

In the first exchange, OCSP certificates are requested, in subsequent exchanges the certs field is no more present 
and thus OCSP certificates are no more requested. This saves the bandwidth. This also simplifies the client’s code 
and reduces the number of errors on the content of the certIdentifier field, as currently defined. 

Denis

PS. Sorry about sending this message three times, due to odd copy and paste problems.

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 17 Sep 2010 11:48:22 -0400

On 09/14/2010 04:46 AM, Denis Pinkas wrote:
> responder has more than one certificate.

How do you know this?  Can't a client include the same 
PreferredSignatureAlgorithms extension in every OCSP request that it 
sends?  If a client only included a PreferredSignatureAlgorithms if it 
knew that the responder had more than one certificate, then it would 
likely also know what algorithms the responder supported, in which case 
it would only need to specify which of those algorithms it wanted the 
responder to use.  But, this is not how the extension is defined.  The 
client sends a SEQUENCE of algorithms that is prefers, but there is no 
guarantee that the responder supports any of them.

> Since the OCSP response has a certs field in Signature,
> If the certs field is present or set to TRUE, then the OCSP responder 
> SHALL return in the certs field from the Signature
> all the OCSP certificates issued by the CAs known by the OCSP 
> responder which guaranty the OCSP signing key

You said something similar to this in your comments on 
draft-cooper-pkix-rfc2560bis-00, and I still don't understand it.  Let's 
use Figure 9 from draft-cooper-pkix-rfc2560bis-00 as an example.  If an 
OCSP responder is sending a response that provides status information 
about one certificate, issued by CA 1, why should the responder be 
required to include in the response the certificates issued to it by CA 
2 and the Root CA?

> If the certs field is missing or set to FALSE, then the OCSP responder 
> SHALL NOT include any OCSP certificate
> In the first exchange, OCSP certificates are requested, in subsequent 
> exchanges the certs field is no more present
> and thus OCSP certificates are no more requested. This saves the 
> bandwidth. This also simplifies the client’s code

While the general idea seems life a good one, there are a couple of 
problems with it.  First, the AIA extension in a certificate only 
provides a URL.  It does not identity the OCSP responder.  So, in a 
high-volume environment there may be several designated OCSP responders 
that are authorized to provide status information about a certificate 
and the client will have no way of knowing to which responder its 
certificate will be sent.  It may have the certificate for one of these 
responders, but that wouldn't help if it set certs to FALSE and then 
received a response from a different responder.  Second, even if there 
is only a single OCSP responder associated with the URL, there is a 
chance that the responder changed signing keys and so the certificate 
that the client has cached cannot be used to verify the response.  (It 
is also the case that many OCSP responders are issued short-lived 
certificates, but I'll assume the client would notice if the responder's 
certificate had expired.)

A better solution (but for a new extension, not for inclusion in the 
PreferredSignatureAlgoriths extension) would be something similar to 
what Stefan is proposing for TLS: 
http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info.  The client 
could provide information about the OCSP responder certificate(s) that 
it has in its cache or about the public key(s) for which it has valid 
OCSP responder certificates and the responder could use that information 
to determine whether to include any certificates in the certs field of 
its response.  It is not clear to me if this would be useful, however.  
It would depend on the number of bytes that the extension tended to add 
to requests and the rate of success inclusion of the extension had in 
avoiding the need for the responder to include certificates in the response.

Another option would be to define a response extension with a URL 
similar to the id-ad-caIssuers access method of the authorityInfoAccess 
extension.  Rather than including certificates in the certs field of the 
response, the responder could provide a pointer to the location where 
the client could retrieve the certificate(s) if it didn't already have 
them in its cache.  A request extension would also have to be defined to 
allow the client to indicate support for this new response extension, so 
that the responder would continue to include certificates in the certs 
field when providing responses to clients that did not support the new 
response extension.  (This is similar to client certificate URLs in 
http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4366-bis.)  Again, 
however, if the client needed to follow the follow the URL to obtain the 
certificates too often then the result may be less efficient overall 
than if the responder simply included the certificates in the response.

Of course, either of the these options should be written as a separate 
Internet-Draft, and should not be added to either 
draft-ietf-pkix-ocspagility or 2560bis.

Dave

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 20 Sep 2010 16:59:56 +0200

Dave,

Responses in line.

Denis
---------- 
De : pkix-bounces 
À : Denis Pinkas 
Date : 2010-09-17, 17:48:22
Sujet : Re: [pkix] Comments on draft-ietf-pkix-ocspagility-09

OK. The OCSP responder may be unable to support any of the requested algorithms.

We are discussing draft-ietf-pkix-ocspagility-09, not draft-cooper-pkix-rfc2560bis-00.

While the general idea seems life a good one, there are a couple of 
problems with it. First, the AIA extension in a certificate only 
provides a URL. It does not identity the OCSP responder. So, in a 
high-volume environment there may be several designated OCSP responders 
that are authorized to provide status information about a certificate 
and the client will have no way of knowing to which responder its 
certificate will be sent. It may have the certificate for one of these 
responders, but that wouldn't help if it set certs to FALSE and then 
received a response from a different responder. Second, even if there 
is only a single OCSP responder associated with the URL, there is a 
chance that the responder changed signing keys and so the certificate 
that the client has cached cannot be used to verify the response. (It 
is also the case that many OCSP responders are issued short-lived 
certificates, but I'll assume the client would notice if the responder's 
certificate had expired.)
Let us change the proposed text:
If the certs field is present or set to TRUE, then the OCSP responder SHALL return 
in the certs field from the Signature all the OCSP certificates issued by the CAs known by the OCSP 
responder which guaranty the OCSP signing key with the algorithm chosen by the OCSP responder.
with this new text:
If the certs field is present or set to TRUE, then the OCSP responder SHOULD return 
in the certs field from the Signature the OCSP certificates from all the OCSP responders 
which respond to the same address and which guaranty the OCSP signing keys with the 
algorithm chosen by the OCSP responder.
A better solution (but for a new extension, not for inclusion in the 
PreferredSignatureAlgoriths extension) would be something similar to 
what Stefan is proposing for TLS: 
http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info. The client 
could provide information about the OCSP responder certificate(s) that 
it has in its cache or about the public key(s) for which it has valid 
OCSP responder certificates and the responder could use that information 
to determine whether to include any certificates in the certs field of 
its response. It is not clear to me if this would be useful, however. 
It would depend on the number of bytes that the extension tended to add 
to requests and the rate of success inclusion of the extension had in 
avoiding the need for the responder to include certificates in the response.

Dave

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix