Subject: [pkix] RFC 6960 section 4.2.2.2. question

From: Antanas Živatkauskas <[email-masked]>
Date: Fri, 13 Feb 2015 12:35:32 +0000

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, and is
believed to be clean.

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 13 Feb 2015 20:59:35 +0000

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:[email-masked]] On Behalf Of Antanas Živatkauskas
Sent: Friday, February 13, 2015 7:36 AM
To: [email-masked]'
Subject: [pkix] RFC 6960 section 4.2.2.2. question

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

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

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 13 Feb 2015 16:25:37 -0500

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:[email-masked]] On Behalf Of
Antanas Živatkauskas

To: [email-masked]'

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?

--

dangerous content by MailScanner,
and is

believed to be clean.

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

---

From: Antanas Živatkauskas <[email-masked]>
Date: Sat, 14 Feb 2015 11:31:26 +0000

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 <[email-masked]>
Sent: Friday, February 13, 2015 11:25 PM
To: Santosh Chokhani; Antanas Živatkauskas; [email-masked]'
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).

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

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 15 Feb 2015 14:44:08 +0000

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:[email-masked]]
Sent: Saturday, February 14, 2015 6:31 AM
To: David A. Cooper; Santosh Chokhani; [email-masked]'
Subject: Re: [pkix] RFC 6960 section 4.2.2.2. question

I am still confused ...

From: David A. Cooper <[email-masked]<mailto:[email-masked]>>