Re: [pkix] RFC 6960 section 4.2.2.2. question

[Santosh Chokhani <[e-mail]>]

Based on Section 2.2 which states "a Trusted Responder whose public key is trusted by the requestor" I would say that you can still trust a locally configured OCSP Responder and be compliant with the RFC.

From: Antanas Živatkauskas [mailto:[e-mail]]
Sent: Saturday, February 14, 2015 6:31 AM
To: David A. Cooper; Santosh Chokhani; '[e-mail]'
Subject: Re: [pkix] RFC 6960 section 4.2.2.2. question


What I am trying to understand in other words is whether systems or applications that rely on OCSP responses are still free to use local configuration of OCSP signing authority for the certificate in question even when the OCSP responses they get contain the delegation certificate which is signed by the same key as the certificate being checked for revocation?

You say that the text is not imposing a constraint on relying parties, meaning that the answer to the question above is "Yes". However for me it seems to conflict with the note which says:



         such a practice is strongly discouraged, since clients are not
         required to recognize a responder with such a certificate as an
         Authorized Responder.



This statement I interpret in the following way: clients are NOT REQUIRED to recognize responder if it is using a diffent key for delegation certificate as the one which signed certificate being checked for revocation which implies they are REQUIRED to recognize responder if the two keys are the same and consequently it does not matter what local configuration of OCSP signing authority they use.



I am still confused ...



________________________________
From: David A. Cooper <[e-mail]<mailto:[e-mail]>>
Sent: Friday, February 13, 2015 11:25 PM
To: Santosh Chokhani; Antanas Živatkauskas; '[e-mail]'
Subject: Re: [pkix] RFC 6960 section 4.2.2.2. question

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]<mailto:[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 MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.