Re: [pkix] RFC 6960 section 4.2.2.2. question

["David A. Cooper" <[e-mail]>]

Actually, this is not what the text is trying to say. The text is not imposing a constraint on relying parties, it is only saying that relying parties are not required to be able to handle the case in which the CA uses different keys to sign the certificate in question and the delegation certificate. As noted in RFC 6960, RFC 2560 was very clear that it did not impose such a constraint.

Here is the quoted text with more context included, which makes it clear that the text is not imposing a constraint on relying parties:

   The CA SHOULD use the same issuing key to issue a delegation
   certificate as that used to sign the certificate being checked for
   revocation.  Systems relying on OCSP responses MUST recognize a
   delegation certificate as being issued by the CA that issued the
   certificate in question only if the delegation certificate and the
   certificate being checked for revocation were signed by the same key.

   Note: For backwards compatibility with RFC 2560 [RFC2560], it is not
         prohibited to issue a certificate for an Authorized Responder
         using a different issuing key than the key used to issue the
         certificate being checked for revocation.  However, such a
         practice is strongly discouraged, since clients are not
         required to recognize a responder with such a certificate as an
         Authorized Responder.

I think the reason that the word "recognize" was used instead of "accept" is that verifying that the certificate in question and the delegation certificate were issued by the same CA is neither necessary nor sufficient to accept a response. The relying party could accept the response based on its being signed by a locally-trusted responder, and the relying party could reject the response for other reasons (e.g., response is too old or does not provide information about the certificate in question).

On 02/13/2015 03:59 PM, Santosh Chokhani wrote:

To me it is saying that the relying party must only accept CA-delegated OCSP Responder certificate only if both certificates were signed using the same key.  It is trying to disambiguate a purported ambiguity in 2560.

 

BTW, the two certificates are: OCSP Responder certificate and the certificate whose status is being checked by the OCSP Responder.

 

This constraint provides simple crypto binding to the delegation.

 

From: pkix [mailto:[e-mail]] On Behalf Of Antanas Živatkauskas
Sent: Friday, February 13, 2015 7:36 AM
To: '[e-mail]'
Subject: [pkix] RFC 6960 section 4.2.2.2. question

 

 

Need help in interpreting the following statement in RFC 6960 section 4.2.2.2.  Authorized Responders:

 

“Systems relying on OCSP responses MUST recognize a

delegation certificate as being issued by the CA that issued the

certificate in question only if the delegation certificate and the

certificate being checked for revocation were signed by the same key.”

 

It is not really clear if it is  a must for systems relying on OCSP responses in all cases accept a delegation certificate as long as CA uses “the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation”, so that the alternative option of providing “a means of locally configuring one or more OCSP signing authorities and specifying the set of CAs for which each signing authority is trusted” is irrelevant.

 

Is the word RECOGNIZE in the excerpt above interchangable with the word ACCEPT?

If not, what is the meaning of RECOGNIZE, respectively the purpose of such recognition?

 

 

--
This message has been scanned for viruses and
dangerous content by http://www.mailscanner.info/" rel="nofollow">MailScanner, and is
believed to be clean.

_______________________________________________
pkix mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pkix" rel="nofollow">https://www.ietf.org/mailman/listinfo/pkix