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

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

Dave draw my attention on this draft since some comments made on 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 field 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 OCSPresponder 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 explanation: 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 exchanged 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