Subject: Re: [pkix] Trusted responders in OCSP

From: Santosh Chokhani <[email-masked]>
Date: Mon, 6 Jun 2011 10:23:53 -0400

I finally got around to reading the current 2560 bis draft.

I would vote against it since it sacrifices security explicitly stated or implied in 2560.  My arguments are well recorded in PKIX forum.  I will not repeat those.  In addition, an OCSP client may have interoperability problems with a server claiming compliance with this draft standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Monday, May 30, 2011 5:47 AM
To: Tomas Gustavsson; [email-masked]
Subject: Re: [pkix] Trusted responders in OCSP

This is how I would like to change this section in RFC 2560bis

http://tinyurl.com/2560bis-tr

/Stefan

On 11-05-30 10:11 AM, "Tomas Gustavsson" <[email-masked]> wrote:

>
>I agree that, also according to my experience, this is how OCSP
>validation works in practice today. Wich is probably why it generally
>works quite well.
>
>Cheers,
>Tomas
>
>On 05/28/2011 09:24 PM, Stefan Santesson wrote:
>> I'm worried about the new wording in rfc2560bis regarding trusted
>> responders.
>> 
>> I've spent some time now doing actual implementation of OCSP checking
>> using existing libraries and I fear that current RFC 256obis will cause
>> more confusion and less interoperability, than if we keep 2560 as it is.
>> 
>> The current bis text might be all "X.509" purish but it is not very
>> helpful in attaining interoperability.
>> 
>> RFC 2560 does not deal with key rollover. It seams to assume that CAs do
>> what they in practice always do, i.e. They let the lifetime of their
>> issuing key exceed the lifetime of any certificate they issue.
>> The self designation express that the responder certificate "is THE
>> certificate of the CA" that issued the cert being checked. I interpret
>> this to be the CA certificate found in the cert path of the certificate
>> being validated.
>> 
>> Most implementers seems to have agreed and understood this to be an easy
>> check.
>> 
>> If (response signature can be verified by CA cert) {check OK} else {ceck
>> FAIL}
>> 
>> The same goes for designated responders:
>> 
>> If (designated responder cert can be verified by the CA cert) {check OK}
>> else {ceck FAIL}
>> 
>> 
>> Since this is the current configuration around which interoperability is
>> achieved, this is the configuration that should be promoted in
>> rfc2560bis as MUST implement for OCSP clients.
>> Anything else should be OPTIONAL.
>> 
>> Beyond this there are a kazillion of configuration options for allowing
>> key rollover, designated responders and even (which I have seen examples
>> of) designated CAs only issuing responder certs. These are all fine in
>> local communities under local policy, but no one should expect a general
>> OCSP client to handle them.
>> 
>> /Stefan
>> 
>> 
>> 
>> 
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

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

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 8 Jun 2011 15:06:53 +0200

We are not progressing on RFC2560bis.

I would also vote against the current draft whihc has major problems.

I sent an email last year (2010), which proposes text replacements. I copy it again below since they are still applicable:

12 comments on draft-cooper-pkix-rfc2560bis-00

Fist of all, I appreciate that we are in the process of replacing RFC 2560 instead of 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 take into consideration the second accessLocation filed in the AIA extension AND able to process the old-by-new CA self signed certificate.
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: mandate the same key or 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 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 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.

:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Monday, May 30, 2011 5:47 AM
To: Tomas Gustavsson; [email-masked]
Subject: Re: [pkix] Trusted responders in OCSP

/Stefan