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

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.

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.

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.

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:

   The key that signs a certificate's status information need not be the
   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.

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.

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.

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.

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.

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.

This comes directly from Section 4.2.2.2 of RFC 2560:

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-ad-ocspSigning value as
   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
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.

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.

 

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

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.
This case should be deleted or modified.

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

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.

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.
This requirement should be moved in the normative part of the RFC.

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