Subject: [pkix] 12 comments on draft-cooper-pkix-rfc2560bis-00

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 8 Sep 2010 11:13:24 +0200

Fist of all, I appreciate that we are in the process of replacing RFC 2560 rather than updating it.
 
I also acknowledge the nice work being done by David. Now, let us come to the comments.

Comments 1, 2, 3, 8 and 9 are major. Comments 4, 5 and 6 are editorial.

1) The text states on page 5:

Authorized OCSP responders fall into one of three categories: integrated, designated, or locally trusted.
While OCSP responders behave roughly the same, OCSP clients shall use a different code 
whether there are tailored to verify the responses from integrated OCSP responders, designated OCSP responders, 
or locally trusted OCSP responders.

This means that the document should include three different sections to describe interoperability requirements 
namely for three types of OCSP clients:

a) OCSP clients able to interoperate with integrated OCSP responders,
b) OCSP clients able to interoperate with designated OCSP responders,
c) OCSP clients able to interoperate with locally trusted OCSP responders.

The goal is being able to say, e.g: “my OCSP client code is compliant with OCSP client type 2”.

Section 2.3.6.2 should be revisited and split to take this comment into consideration.

2) The text states on page 5: 1.2.1.  Integrated OCSP Responders
   A responder is an integrated OCSP responder if the subject
   distinguished name (DN) in the certificate containing the public key
   required to verify the signature on the OCSP response is the same as
   the issuer DN in the target certificate(s).  In other words, an
   integrated OCSP responder is a responder that provides revocation
   status information for its own certificates.  An integrated OCSP
   responder may sign certificates and OCSP responses using the same
   private key or may use different keys to sign certificates and OCSP
   responses.

The wording “integrated OCSP responder” did not existed in RFC 2560.

RFC 2560 was saying:

The key used to sign the response MUST belong to one of the following:
   -- the CA who issued the certificate in question

but RFC 2560 was also saying:

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer
   explicitly delegates OCSP signing authority by issuing a certificate
   containing a unique value for extendedKeyUsage in the OCSP signer's
   certificate.

When reading the two sections together, it may be interpreted the following way: 
the key to sign the OCSP response and the key to sign the certificate is the same when there is no delegation.

We are now opening a can of worms if we allow the CA to sign OCSP responses with a key different from 
the key which initially signed the certificate, in particular when the CA changes its issuing key.

We must guarantee backward compatibility. This means that the CA MUST continue to sign OCSP responses with the same key. 

After a CA key rollover, the key question is whether OCSP responses for “old certificates” can ALSO be signed with a new key. 
If there is only one accessLocation in the AIA extension field, this is not possible for the integrated case. For allowing this scheme, 
this would mean that two accessLocation fields should be placed in the AIA extension. One would be placed in advance of the key rollover.

However, the drawback is that we would need to distinguish between more types of OCSP clients. 
OCSP clients able to process the old-by-new CA self signed certificate AND to take into consideration 
the second accessLocation field in the AIA extension.
 
This would make an additional type of OCSP client.

A conservative solution to the problem would be:

a) to rephrase the new definition with:
   A responder is an integrated OCSP responder if the subject
   distinguished name (DN) in the certificate containing the public key
   required to verify the signature on the OCSP response is the same as
   the issuer DN in the target certificate(s) and if the key used to 
   sign the OCSP response is the same as the key used to sign the 
   certificate.

b) to delete the following sentence:
   An integrated OCSP responder may sign certificates and OCSP 
   responses using the same private key or may use different keys 
   to sign certificates and OCSP responses.

c) to change the text on page 18. The current text is:
      When a CA signs OCSP responses to provide revocation
      status information for its own certificates, it may sign the
      responses using the same key as was used to sign the target
      certificate(s) or using a different key.  One reason that a CA may
      sign an OCSP response using a different key would be if the CA had
      performed a key rollover since it issued the target
      certificate(s).

         Note: Some OCSP clients, when accepting responses from an
         integrated OCSP responder, will only accept OCSP responses that
         are signed using the same key as the target certificate(s).

It would be changed into:

      When a CA signs OCSP responses to provide revocation
      status information for its own certificates, it MUST sign the
      responses using the same key as was used to sign the target
      certificate(s).

d) to change text in section 2.3.6.2 item 2.

This would solve the whole problem and the note, otherwise we would have to consider a fourth case of OCSP client. 
I am not opposed to the fourth case, as long as it is clearly indicated along with the requirements placed in the CA.

3) On page 18 for “Designated OCSP responders” the text states:
      The CA does not need to sign this certificate using the same key
      as was used to sign the target certificate(s), but the certificate
      MUST be issued to the OCSP responder directly by the CA that
      issued the target certificate(s).

         Note: Some OCSP clients, when accepting OCSP responses from a
         designated OCSP responder, will only accept OCSP responses if
         the certificate required to validate the signature on the OCSP
         response was signed using the same key as the target
         certificate(s).

We have a backwards compatibility problem here. 

Today OCSP clients do not expect a new certificate issued by a new key from the same CA. 
We are faced with two choices: 

a) mandate the same key or 
b) mandate the inclusion in the OCSP response of two OCSP certificates for the same responder. 

I would prefer the later.

Note that changes are also needed in section 2.3.6.2 item 3.

4) The text states in section 2.3.5.2 from page 18:
   Since an authorized OCSP responder provides revocation status
   information for one or more CAs, OCSP clients need to know how to
   check that an authorized responder's certificate has not been
   revoked.
 
The sentence is incorrect since it is not true for integrated responders.

Change into:
   OCSP clients need to know how to check that an authorized responder's 
   certificate has not been revoked. 

5) The text states in section 2.3.6.2 from page 18:

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-ad-ocspSigning value as
   described in Section 2.3.5.1.  They MAY provide a means of locally
   configuring one or more OCSP signing authorities, and specifying the
   set of CAs for which each signing authority is trusted.

The first sentence is untrue for locally trusted OCSP responders while the second sentence is only true 
for locally trusted OCSP responders. As stated in the very first comment, this whole section needs to be 
restructured according to the three (or four) cases.

6) The text states in section 4.1 from page 23 in the discussion about the use of insecure algorithms 
inside the security consideration section.

   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.

This functionality does not exist: there is no date in the request to ask the revocation at a time in the past. 
OCSP responders are not required to report the validity of a certificate on a date in the distant past. Please delete.

7) All the sections from section D need to be revisited to take into considerations the previous comments.

In section D.1, figures 2 and 3 should be deleted.

In section D.2, figure 5 should be deleted because it is unlikely that a root CA uses the same key to sign OCSP responses.

In figure 6, this means that the client MUST be capable to process the old-by-new self signed certificate. 
While it is a nice feature, all clients are not able to do it, unless we define a new class of clients able to process that case. 
This is related to the first and second comment about the distinction of different classes of OCSP clients (three or four).

In figure 7, it is a bad example since it is unlikely that a root CA uses the same key to sign OCSOP responses. 
This case should be deleted or modified.

8) On page 39, the text clearly indicates the problem:

   As noted in Section 2.3.5.1, some OCSP clients cannot validate
   signatures on OCSP responses created by designated OCSP responders if
   the OCSP responder's certificate has been signed using a different
   key than the target certificate.  Figure 8 depicts a CA that
   accommodates this limitation by issuing two certificates to the
   designated OCSP responder, one signed with its old private key and
   one signed with its new private key.  Both certificates include an
   extended key usage extension with the id-kp-OCSPSigning OID.

In order to achieve backward compatibility, if the CA issues an old-by-new self signed certificate, then the CA SHALL issue 
two certificates, which also mean that the OCSP responder SHALL include its two certificates in the certs field from BasicOCSPResponse.

This requirement should be moved in the normative part of the RFC.

9) BTW, the field certs is not described and should be described. Other fields from BasicOCSPResponse are not described either ! :-(

10) In the case of figure 9, the OCSP responder SHALL include all three certificates in the field certs from BasicOCSPResponse. 
This requirement should be moved in the normative part of the RFC.

11) In figure 10, the text is missing to say what the client shall be doing.

12) In the first comment, I said” While OCSP responders behave *roughly* the same”. 
There is a distinction to introduce: the number of certs that the OCSP response SHALL include in the case of the integrated OCSP responders.

END OF COMMENTS

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 10 Sep 2010 11:15:38 -0400

On 09/08/2010 05:13 AM, Denis Pinkas wrote:

Authorized OCSP responders fall into one of three categories:
integrated, designated, or locally trusted.

While OCSP responders behave roughly the same, OCSP clients
shall use a different code

whether there are tailored to verify the responses from integrated OCSP
responders, designated OCSP responders,

This means that the document should include three different
sections to describe interoperability requirements

a) OCSP clients able to interoperate with integrated OCSP
responders,

c) OCSP clients able to interoperate with locally trusted OCSP
responders.

The goal is being able to say, e.g: “my OCSP client code is
compliant with OCSP client type 2”.

Section 2.3.6.2 should be revisited and split to take this
comment into consideration.

I don't see anything in RFC 2560 to support the idea of three types of
OCSP clients.  I read RFC 2560 to say that OCSP clients MUST be able to
accept responses from integrated and designated OCSP responders and MAY
be configurable to also accept responses from locally trusted OCSP
responders.

responses.

The wording “integrated OCSP responder” did not existed in RFC
2560.

RFC 2560 was saying:

The key used to sign the response MUST belong to one of the
following:

The key that signs a certificate's status information need
not be the

certificate.

When reading the two sections together, it may be interpreted
the following way:

the key to sign the OCSP response and the key to sign the certificate
is the same when there is no delegation.

We are now opening a can of worms if we allow the CA to sign
OCSP responses with a key different from

the key which initially signed the certificate, in particular when the
CA changes its issuing key.

We must guarantee backward compatibility. This means that the CA
MUST continue to sign OCSP responses with the same key.

After a CA key rollover, the key question is whether OCSP
responses for “old certificates” can ALSO be signed with a new key.

If there is only one accessLocation in the AIA extension field, this is
not possible for the integrated case. For allowing this scheme,

this would mean that two accessLocation fields should be placed in the
AIA extension. One would be placed in advance of the key rollover.

However, the drawback is that we would need to distinguish
between more types of OCSP clients.

OCSP clients able to process the old-by-new CA self signed
certificate AND to take into consideration

certificate.

certificate(s).

Note: Some OCSP clients, when accepting responses from
an

certificate(s).

This would solve the whole problem and the note, otherwise we
would have to consider a fourth case of OCSP client.

I am not opposed to the fourth case, as long as it is clearly indicated
along with the requirements placed in the CA.

I believe that we are in agreement that 2560bis is not supposed to
change OCSP.  However, while you argue that RFC 2560 "may be
interpreted" to require integrated OCSP responders to sign responses
using the same key as the target certificate, that is not what RFC 2560
actually says.

RFC 2560 says that a response may be accepted if "The key used to sign
the response [belongs] to ... the CA who issued the certificate in
question".  You argue that this criteria is not satisfied in the
example in Figure 2.  However, in Figure 2 the key used to sign the
response appears in a self-issued certificate, in which the key used to
sign the self-issued certificate is the same as the key used to sign
the target certificate.  Are you saying that the subject public key in
a self-issued certificate doesn't belong to the issuer of the
certificate?  RFC 5280 explicitly states that "Self-issued certificates
are CA certificates in which the issuer and subject are the same
entity."

While you point to text in Section 2.6 that you believe implies that
(despite what RFC 2560 actually says) the intent was to require the
OCSP response and the target certificate to be signed using the same
key, the text in Section 2.6 is just a shortened version of the text in
Section 4.2.2.2:

same key that signed the certificate. It is necessary however to

ensure that the entity signing this information is authorized to do

so.  Therefore, a certificate's issuer MUST either sign the OCSP

responses itself or it MUST explicitly designate this authority to

another entity.  OCSP signing delegation SHALL be designated by the

inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate

extension included in the OCSP response signer's certificate.  This

certificate MUST be issued directly by the CA that issued the

certificate in question.

It would be inconsistent to say that a certificate's issuer has not
"sign[ed] the OCSP responses itself" if it signs using a different key
while also saying that a self-issued certificate (even if it is not
self-signed) is a CA certificate "in which the issuer and subject are
the same entity."

I do not understand at all your point about multiple AIA extensions.  A
CA that had performed a key rollover that was acting as an integrated
OCSP responder could sign every OCSP response using the same key as the
target certificates even if all certificates issued by the OCSP
responder included the same OCSP URL in the AIA extension.  The CA
(acting as an OCSP responder) would just choose the key to use the sign
the response based on the certificate identified in the reqCert field
of the request.  There is no reason that an OCSP responder has to sign
responses to all requests submitted to the same URL using the same
key.  Similarly, it can include different certificates in the certs
field of the response depending on the set of certificates for which
the response message is providing status information.

The CA does not need to sign this certificate using the
same key

Note: Some OCSP clients, when accepting OCSP responses
from a

certificate(s).

Today OCSP clients do not expect a new certificate issued by a
new key from the same CA.

b) mandate the inclusion in the OCSP response of two OCSP
certificates for the same responder.

This is the same as issue 2).  RFC 2560 says that the certificate
required to verify the signature on the OCSP response must be issued
directly by the CA that issued the certificate in question and must
include an extended key usage extension that asserts the
id-kp-OCSPSigning OID.  It does not say that the certificate must be
signed using the same key as was used to sign the certificate in
question.

revoked.

The sentence is incorrect since it is not true for integrated
responders.

Change into:

OCSP clients need to know how to check that an authorized
responder's

The text that you quoted from copied, nearly word-for-word, from
Section 4.2.2.2.1 of RFC 2560:

Since an Authorized OCSP responder provides status information for

one or more CAs, OCSP clients need to know how to check that an

authorized responder's certificate has not been revoked.

I don't understand what in the sentence is incorrect.  While I think
Section 4.2.2.2.1 of RFC 2560 (Section 2.3.5.2 in the draft) was
primarily about designated OCSP responders, an integrated OCSP
responder does provide revocation status information for one or more
CAs.  It provides revocation status information for itself (and it is a
CA), and while it is unlikely it may also (acting as a designated OCSP
responder) provide revocation status information for other CAs.

Systems or applications that rely on OCSP responses MUST be
capable

The first sentence is untrue for locally trusted OCSP responders
while the second sentence is only true

for locally trusted OCSP responders. As stated in the very first
comment, this whole section needs to be

This comes directly from Section 4.2.2.2 of RFC 2560:

described above. They MAY provide a means of locally configuring one

or more OCSP signing authorities, and specifying the set of CAs for

which each signing authority is trusted.

I take this to mean that OCSP clients MUST be able to accept responses
from designated OCSP responders and MAY additionally provide the means
to accept responses from locally trusted OCSP responders.  It does not
seem to allow for an OCSP client that only accepts responses from
locally trusted OCSP responders or one that only accepts responses from
integrated OCSP responders.

6) The text states in section 4.1 from page 23 in the discussion
about
the use of insecure algorithms

In archival applications it is quite possible that an OCSP
responder

the distant past.

This functionality does not exist: there is no date in the
request to ask the revocation at a time in the past.

OCSP responders are not required to report the validity of a
certificate on a date in the distant past. Please delete.

Section 4.1 of the draft was copied from Section 8.1 of
draft-ietf-pkix-ocspagility-09, so this is really a comment on that
draft.  2560bis will incorporate draft-ietf-pkix-ocspagility, so any
issues with the text in that draft should be dealt with in the context
of draft-ietf-pkix-ocspagility, and any changes made to
draft-ietf-pkix-ocspagility will also be made in 2560bis.

7) All the sections from section D need to be revisited to take
into considerations the previous comments.

But, these are legitimate examples of integrated OCSP responders.
Figures 1, 2, and 3 all depict scenarios in which the OCSP response is
signed by "the CA who issued the certificate in question".

In section D.2, figure 5 should be deleted because it is
unlikely that a root CA uses the same key to sign OCSP responses.

I agree that Figure 5 depicts a highly unlikely scenario.  However, I
wanted to include at least one example that showed that a single OCSP
responder could be both a designated OCSP responder and an integrated
OCSP responder.

In figure 6, this means that the client MUST be capable to
process the old-by-new self signed certificate.

I have noted many places in the draft that not all clients will be able
to accept OCSP responses, and thus that not all clients will be able to
accept OCSP responses in an environment as depicted in Figure 6.

While it is a nice feature, all clients are not able to do it,
unless
we define a new class of clients able to process that case.

This is related to the first and second comment about the distinction
of different classes of OCSP clients (three or four).

While RFC 2560 does say that clients MUST be able to accept responses
from designated OCSP responders ("MUST be capable of detecting and
enforcing use of the id-ad-ocspSigning value") and MAY be capable of
accepting responses from locally trusted OCSP responders, it does not
specify requirements at the level that you suggest.

Sections 5 and 5.1.1.3 of RFC 5280 includes statements along these
lines about requirements for CRL processing capabilities:

Conforming applications that support CRLs are REQUIRED to

process both version 1 and version 2 complete CRLs that

provide revocation information for all certificates issued by one

CA.  Conforming applications are not required to support

processing of delta CRLs, indirect CRLs, or CRLs with a scope

other than all certificates issued by one CA.

Applications that perform CRL checking MUST support

certification path validation when certificates and CRLs are

digitally signed with the same CA private key.  These

applications SHOULD support certification path validation when

certificates and CRLs are digitally signed with different CA private

keys.

Something similar could be included in 2560bis, but that would be
something new compared to RFC 2560.

In figure 7, it is a bad example since it is unlikely that a
root CA uses the same key to sign OCSOP responses.

In Figure 7, the root does not sign OCSP responses.  The root has only
issued a certificate to a designated OCSP responder.  OCSP responses
are signed using the designated responder's key (Root's OCSP
Responder's key).

In order to achieve backward compatibility, if the CA issues an
old-by-new self signed certificate, then the CA SHALL issue

two certificates, which also mean that the OCSP responder SHALL include
its two certificates in the certs field from BasicOCSPResponse.

This requirement should be moved in the normative part of the
RFC.

What requirement?  Aside from the fact that there is no old-by-new
self-issued certificate in Figure 8, there is no requirement for the CA
to issue two certificates.  This example simply explains that doing so
will improve compatibility with existing clients.  In addition,  I
can't find a requirement in RFC 2560 to include any certificates in the
certs field of BasicOCSPResponse.  The closest statement I can find is
one about request messages:

Also, for signed requests, the requestor MAY include

certificates that help the OCSP responder verify the requestor's

signature in the certs field of Signature.

That is why the draft says the same thing about the certs field in
BasicOCSPResponse (the responder MAY include certificates that help the
client verify the responder's signature).  If RFC 2560 requires that
certain certificates be included in the certs field of
BasicOCSPResponse, then please identity the text with that imposes that
requirement.

9) BTW, the field certs is not described and should be
described. Other
fields from BasicOCSPResponse are not described either ! :-(

Section 2.3 says:

The responder MAY include certificates in the certs field of

BasicOCSPResponse that help the OCSP client verify the responder's

signature.

10) In the case of figure 9, the OCSP responder SHALL include
all three
certificates in the field certs from BasicOCSPResponse.

Again, I cannot find such a requirement in RFC 2560.  Also, there would
be no reason (other than possibly simplifying the coding of the
responder) to include all three certificates in a response.  The
responder could include just one certificate in each response, as long
as that one certificate were that one that was issued by the CA that
issued the certificate in question.

11) In figure 10, the text is missing to say what the client
shall be
doing.

What needs to be said about what the client shall be doing?  Can you
propose some text?

12) In the first comment, I said” While OCSP responders behave
*roughly* the same”.

There is a distinction to introduce: the number of certs that the OCSP
response SHALL include in the case of the integrated OCSP responders.

I don't understand this comment.  When you say certs includes in the
response, do you mean in the certs field of BasicOCSPResponse or in the
responses field of ResponseData?  What is the requirement that needs to
be imposed and where is the text in RFC 2560 that imposes the
requirement?

Dave

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 30 Sep 2010 14:17:14 +0200

David,

Let us focus the debate on the case of designated OCSP responders and let us deal with CA key rollover. Other topics will be discussed later.
The paragraph that creates the major problem is the following from the draft (page 18):
   o  Designated OCSP responder
(...)
      The CA does not need to sign this certificate using the same key
      as was used to sign the target certificate(s), but the certificate
      MUST be issued to the OCSP responder directly by the CA that
      issued the target certificate(s).
         Note: Some OCSP clients, when accepting OCSP responses from a
         designated OCSP responder, will only accept OCSP responses if
         the certificate required to validate the signature on the OCSP
         response was signed using the same key as the target
         certificate(s).
The second part of the sentence creates a problem. It is:
      the certificate MUST be issued to the OCSP responder directly 
      by the CA that issued the target certificate(s).
When a key rollover is made, this sentence is ambiguous: is the certificate signed by the new CA key only or both the old and the new CA key ? The draft makes the assumption of the former case and thus does not ensure backwards compatibility: the draft then depicts cases that should NOT exist. The way to ensure backwards compatibility is to build on the later case.
This sentence also uses the plural with an s into parenthesis. The presence of the s opens a new can of worms, when the request is about multiple certificates from the same CA or from different CAs.
RFC 2560 (which was not better in this case) was saying: 
      This certificate MUST be issued directly by the CA that issued 
      the certificate in question.
Let see how a system should behave when a CA performs a key rollover.
We should consider two cases: integrated OCSP responders and designated OCSP responders. For the time being, let us only consider designated OCSP responders.
The note in the draft states:
   Note: Some OCSP clients, when accepting OCSP responses from a
         designated OCSP responder, will only accept OCSP responses if
         the certificate required to validate the signature on the OCSP
         response was signed using the same key as the target
         certificate(s).
This is true. In order to allow these clients to continue working, the draft should say what both the CA and the OCSP responder need to do.
When a key rollover happens, in order to allow these clients to continue working, two scenarios may be followed:
Scenario 1: the OCSP responder key is changed at the time of the key rollover. 
In such a case:
a) certificates issued under the new key shall include a new value for the accessLocation element from the authority information access extension.
b) a new OCSP responder is established behind this accessLocation. The OCSP responder generates a new key pair and its public key is certified under the new CA key. The responses will then be signed by an OCSP responder key certified under the new CA key. In order to allow an easy verification, the OCSP responder SHOULD include this certificate in the certs field from BasicOCSPResponse.
Note: the previous OCSP responder continue working with a key certified under the “old” CA key
Scenario 2: the OCSP responder key is changed before the key rollover and a new OCSP responder certificate is issued before the key rollover. 
In this way, the same key can be maintained and can be certified under the new CA key. In such a case:
a) certificates issued under the new key may include the same value for the accessLocation element from the authority information access extension.
b) an OCSP responder is established behind this accessLocation. The OCSP responder uses the same private key that was previously used but the public key is certified under the new CA key. The responses may then be signed by an OCSP responder key certified both under the old CA key and under the new CA key. In order to allow an easy verification, the OCSP responder SHOULD include the two OCSP responder certificates in the certs field from BasicOCSPResponse. If the OCSP responder wants to apply a finer level of granularity, it SHOULD only include the OCSP responder certificates issued under the keys which match one of the issuerKeyHash field of the CertID fields present in the request.
These explanations do not appear in RFC 2560 and this is one of the motivations to "clarify" RFC 2560.
Before going into other discussions and further comments, I believe that we need to solve this major issue.
Strawman proposal rewording for the whole section about designated OCSP responders:
“   o  Designated OCSP responder
      In order for a CA to designate an OCSP responder other than itself
      as authorized to provide revocation status information for the
      certificates that it issues, the CA:
         o  MUST include in each certificate that it issues, an authority 
            information access extension which contains an accessLocation
            element.
      For each accessLocation, the CA SHALL issue one or more OCSP 
      responder certificates which shall contain an extended key usage 
      extension that includes the id-kp-OCSPSigning OID.
            id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
      For any given accessLocation value in use, the CA SHALL ensure 
      there exists a valid OCSP responder certificate issued under 
      the same key that was used to sign the certificate in which the 
      given accessLocation value was included. 
      For any given accessLocation value in use, the OCSP responder 
      SHOULD include in the certs field from BasicOCSPResponse the OCSP 
      responder certificates issued under the keys which match one of 
      the issuerKeyHash field of the CertID fields present in the request.
In this way, backwards compatibility is achieved.
Denis

Denis Pinkas, [email-masked]
30/09/2010 
----- Message reçu ----- 
De : David A. Cooper 
À : Denis Pinkas 
Date : 2010-09-10, 17:15:38
Sujet : Re: 12 comments on draft-cooper-pkix-rfc2560bis-00

I don't see anything in RFC 2560 to support the idea of three types of OCSP clients.  I read RFC 2560 to say that OCSP clients MUST be able to accept responses from integrated and designated OCSP responders and MAY be configurable to also accept responses from locally trusted OCSP responders.

RFC 2560 was saying:

I believe that we are in agreement that 2560bis is not supposed to change OCSP.  However, while you argue that RFC 2560 "may be interpreted" to require integrated OCSP responders to sign responses using the same key as the target certificate, that is not what RFC 2560 actually says.

RFC 2560 says that a response may be accepted if "The key used to sign the response [belongs] to ... the CA who issued the certificate in question".  You argue that this criteria is not satisfied in the example in Figure 2.  However, in Figure 2 the key used to sign the response appears in a self-issued certificate, in which the key used to sign the self-issued certificate is the same as the key used to sign the target certificate.  Are you saying that the subject public key in a self-issued certificate doesn't belong to the issuer of the certificate?  RFC 5280 explicitly states that "Self-issued certificates are CA certificates in which the issuer and subject are the same entity."

While you point to text in Section 2.6 that you believe implies that (despite what RFC 2560 actually says) the intent was to require the OCSP response and the target certificate to be signed using the same key, the text in Section 2.6 is just a shortened version of the text in Section 4.2.2.2:

It would be inconsistent to say that a certificate's issuer has not "sign[ed] the OCSP responses itself" if it signs using a different key while also saying that a self-issued certificate (even if it is not self-signed) is a CA certificate "in which the issuer and subject are the same entity."

I do not understand at all your point about multiple AIA extensions.  A CA that had performed a key rollover that was acting as an integrated OCSP responder could sign every OCSP response using the same key as the target certificates even if all certificates issued by the OCSP responder included the same OCSP URL in the AIA extension.  The CA (acting as an OCSP responder) would just choose the key to use the sign the response based on the certificate identified in the reqCert field of the request.  There is no reason that an OCSP responder has to sign responses to all requests submitted to the same URL using the same key.  Similarly, it can include different certificates in the certs field of the response depending on the set of certificates for which the response message is providing status information.

This is the same as issue 2).  RFC 2560 says that the certificate required to verify the signature on the OCSP response must be issued directly by the CA that issued the certificate in question and must include an extended key usage extension that asserts the id-kp-OCSPSigning OID.  It does not say that the certificate must be signed using the same key as was used to sign the certificate in question.

Change into:

The text that you quoted from copied, nearly word-for-word, from Section 4.2.2.2.1 of RFC 2560:

I don't understand what in the sentence is incorrect.  While I think Section 4.2.2.2.1 of RFC 2560 (Section 2.3.5.2 in the draft) was primarily about designated OCSP responders, an integrated OCSP responder does provide revocation status information for one or more CAs.  It provides revocation status information for itself (and it is a CA), and while it is unlikely it may also (acting as a designated OCSP responder) provide revocation status information for other CAs.

I take this to mean that OCSP clients MUST be able to accept responses from designated OCSP responders and MAY additionally provide the means to accept responses from locally trusted OCSP responders.  It does not seem to allow for an OCSP client that only accepts responses from locally trusted OCSP responders or one that only accepts responses from integrated OCSP responders.

Section 4.1 of the draft was copied from Section 8.1 of draft-ietf-pkix-ocspagility-09, so this is really a comment on that draft.  2560bis will incorporate draft-ietf-pkix-ocspagility, so any issues with the text in that draft should be dealt with in the context of draft-ietf-pkix-ocspagility, and any changes made to draft-ietf-pkix-ocspagility will also be made in 2560bis.

But, these are legitimate examples of integrated OCSP responders.  Figures 1, 2, and 3 all depict scenarios in which the OCSP response is signed by "the CA who issued the certificate in question".

I agree that Figure 5 depicts a highly unlikely scenario.  However, I wanted to include at least one example that showed that a single OCSP responder could be both a designated OCSP responder and an integrated OCSP responder.

I have noted many places in the draft that not all clients will be able to accept OCSP responses, and thus that not all clients will be able to accept OCSP responses in an environment as depicted in Figure 6.

While RFC 2560 does say that clients MUST be able to accept responses from designated OCSP responders ("MUST be capable of detecting and enforcing use of the id-ad-ocspSigning value") and MAY be capable of accepting responses from locally trusted OCSP responders, it does not specify requirements at the level that you suggest.

Sections 5 and 5.1.1.3 of RFC 5280 includes statements along these lines about requirements for CRL processing capabilities:

Something similar could be included in 2560bis, but that would be something new compared to RFC 2560.

In Figure 7, the root does not sign OCSP responses.  The root has only issued a certificate to a designated OCSP responder.  OCSP responses are signed using the designated responder's key (Root's OCSP Responder's key).

What requirement?  Aside from the fact that there is no old-by-new self-issued certificate in Figure 8, there is no requirement for the CA to issue two certificates.  This example simply explains that doing so will improve compatibility with existing clients.  In addition,  I can't find a requirement in RFC 2560 to include any certificates in the certs field of BasicOCSPResponse.  The closest statement I can find is one about request messages:

That is why the draft says the same thing about the certs field in BasicOCSPResponse (the responder MAY include certificates that help the client verify the responder's signature).  If RFC 2560 requires that certain certificates be included in the certs field of BasicOCSPResponse, then please identity the text with that imposes that requirement.

Section 2.3 says:

Again, I cannot find such a requirement in RFC 2560.  Also, there would be no reason (other than possibly simplifying the coding of the responder) to include all three certificates in a response.  The responder could include just one certificate in each response, as long as that one certificate were that one that was issued by the CA that issued the certificate in question.

What needs to be said about what the client shall be doing?  Can you propose some text?

I don't understand this comment.  When you say certs includes in the response, do you mean in the certs field of BasicOCSPResponse or in the responses field of ResponseData?  What is the requirement that needs to be imposed and where is the text in RFC 2560 that imposes the requirement?

Dave

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 30 Sep 2010 14:23:17 +0200

(Re-sent since the send key was hit two early).

David,

Let us focus the debate on the case of designated OCSP responders and
let us deal with CA key rollover. Other topics will be discussed later.

The paragraph that creates the major problem is the following from 
the draft (page 18):

(...)

When a key rollover is made, this sentence is ambiguous: is the certificate 
signed by the new CA key only or both the old and the new CA key ? 
The draft makes the assumption of the former case and thus does not ensure 
backwards compatibility: the draft then depicts cases that should NOT exist. 
The way to ensure backwards compatibility is to build on the later case.

This sentence also uses the plural with an s into parenthesis. The presence 
of the s opens a new can of worms, when the request is about multiple certificates 
from the same CA or from different CAs.

We should consider two cases: integrated OCSP responders and designated OCSP responders. 
For the time being, let us only consider designated OCSP responders.

This is true. In order to allow these clients to continue working, the draft should say what 
both the CA and the OCSP responder need to do.

When a key rollover happens, in order to allow these clients to continue working, 
two scenarios may be followed:

In such a case:

a) certificates issued under the new key shall include a new value for the accessLocation element 
from the authority information access extension.

b) a new OCSP responder is established behind this accessLocation. The OCSP responder generates 
a new key pair and its public key is certified under the new CA key. The responses will then be signed 
by an OCSP responder key certified under the new CA key. In order to allow an easy verification, 
the OCSP responder SHOULD include this certificate in the certs field from BasicOCSPResponse.

Scenario 2: the OCSP responder key is changed before the key rollover and a new OCSP responder 
certificate is issued before the key rollover. 

a) certificates issued under the new key may include the same value for the accessLocation element from 
the authority information access extension.

b) an OCSP responder is established behind this accessLocation. The OCSP responder uses the same 
private key that was previously used but the public key is certified under the new CA key. The responses 
may then be signed by an OCSP responder key certified both under the old CA key and under the new CA key. 
In order to allow an easy verification, the OCSP responder SHOULD include the two OCSP responder certificates 
in the certs field from BasicOCSPResponse. If the OCSP responder wants to apply a finer level of granularity, 
it SHOULD only include the OCSP responder certificates issued under the keys which match one of the 
issuerKeyHash field of the CertID fields present in the request.

      For any given accessLocation value in use, the OCSP responder
      SHOULD include in the certs field from BasicOCSPResponse the OCSP
      responder certificates issued under the keys which match one of 
      the issuerKeyHash field of the CertID fields present in the request."

Denis

=====================================================

De : David A. Cooper 
À : Denis Pinkas 

RFC 2560 was saying:

Change into:

Section 2.3 says:

Dave