Subject: Re: [pkix] draft-pinkas-rfc2560bis-00

From: Santosh Chokhani <[email-masked]>
Date: Wed, 5 Sep 2012 16:47:11 -0400

Denis,

Thanks for this.  My initial review indicates that this a very good first draft.  Note that I did not review ASN.1 carefully (I assume it was copied from the existing RFC).   I do have the following comment though:

Section 2.2: When the CA is signing the response, should it not also use the same key to sign the response as the certificate in question?  The later part of the section indicates this as a requirement.  In that case, why not make this explicit like the OCSP Responder.

Section 3.1.3, First paragraph, the rational for CA certificates to have digital signature bit set because they sign OCSP certificates is incorrect.  May be what you mean is that a CA that signs OCSP responses needs to have digital signature bit set in its own certificate (i.e., the certificate for which the CA is the subject).

Section 3.1.3, Note 2, Again there is no requirement for digital signature bit to be set just because the CA signs certificates and CRLs.

Section 3.2: It not clear which accessLocation is being referred to here (cAissuers or OCSP).  If this is OCSP, the RFC is overly implementation specific.  A CA can use the same OCSP location and sign the response with appropriate key and include the appropriate CA certificate without having to change the OCSP pointer.

General: The I-D does not address how the CA deals with the situation when status of multiple certificates issued by the CA, but using different keys is requested.  May be the restriction in 3.2 is used to ensure that such situation does not occur.  If so, a short discussion would be helpful.

General: It not clear which accessLocation is being referred to in most places.  It would be worth stating that it refers to OCSP in all cases unless otherwise stated.

Section 3.3.2 does not fully and explicitly cover the most common implementation I have seen and that is short life certificates.  In that scenario, the CA needs to continue to issue the OCSP Responder certificate using the old CA key until all the certificates issued by the CA using the old key and for which the OCSP Responder is authoritative expire.  The text in 3.3.3 can form a model for this when CA rekeys and OCSP Responder has the old keys.

Section 3.3.3, The last sentence is not desirable and can cause problems with some implementations.  It is perfrectly ok for a Responder to change its key independent of certificate it is authoritative for.  Note that OCSP field in a issue certificate cannot be changed just because the Responder rekyed, be it routine or due to loss or compromise of Responder key.

Section 3.4, last paragraph, I would think that expiration checking need not be part of OCSP client.  Expiration checking should come under 5280 certificate validation.

Section 4.1, We should dilute two CAs "never have the same issuerKeyHash" to something more akin to statistically infeasible.

Titles of subsections under 4.3 could stand improvements.  Responders process request and produce response; they do not process responses.  Clients process responses.

Section 4.3.1.1, The entry should contain method used to gain access and sign just like the text in 4.3.1.2 as opposed to the private key.  In other words, align the two texts for accessing and using private key to sign OCSP responses.

Section 4.3.1,1, page 18 "defined in entry" could be misinterpreted as method define in request entry.

Section 4.3.1.2, Again the same comment, for the delegated OCSP Responder, changing the URL when key is changed is not required and breaks many implementations and hence is unacceptable.

Section 4.3.2, the check for thisUpdate is flawed since this value may be derived from CRL even for responses that are not pre-generated and hence can be hours or days off depending on CRL issuance frequency,  It is better to replace it with producedAt field in the response whether it is related to current time or time in the past.

Section 4,3,2 is missing processing signature on the response and processing response extension.

Section 5.5: Replay attack is also possible when not using pre-computed responses.

General: Removal of locally trusted Responder from the I-D is unacceptable.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, August 28, 2012 12:19 PM
To: [email-masked]
Subject: [pkix] draft-pinkas-rfc2560bis-00

A new Internet-Draft is available from the on-line Internet-Drafts directories.

   Title         : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
   Author(s)     : D. Pinkas
   Filename      : draft-pinkas-rfc2560bis
   Pages         : 41
   Date          : Aug. 27, 2012

  This document specifies a protocol useful in determining the current
  status of a digital certificate without requiring CRLs.  Additional
  mechanisms addressing PKIX operational requirements are specified in
  separate documents. This document obsoletes RFC 2560 and RFC 6277.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation
to automatically retrieve the ASCII version of the Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis><ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis>

A few explanations about the content of draft-ietf-pinkas-rfc2560bis-00.

25 changes are indicated at the beginning of the document.
I will only mention a few of them:

A - Explanations were missing to describe:

     - the building of a request by an OCSP client,
     - the processing of a request by an OCSP server,
     - the building of a response  by an OCSP server, and
     - the processing of a response by an OCSP client.

These explanations have been added.

B - Explanations were missing to  address CA key rollover and OCSP key rollover.
     These explanations have been added.

C - Backwards compatibility has been addressed in the following way:

      1) An OCSP response by be signed either by a CA or by an OCSP Responder.

      2) Besides local configuration settings which are optional, only two cases
       SHALL be supported by OCSP clients (and thus OCSP servers) as explained below.

       The key to be used to verify a SingleResponse (within a BasicOCSPResponse) MUST:

          (1) either be the same key that the one used to sign the target certificate,

          (2) or be the public key from an OCSP responder that is contained in an OCSP certificate
              that has been signed by the same key that the one used to sign the target certificate.
   .
The text allows to use the same general processing for a few other cases, since "escape"
sentences are provided to allow for these other cases, but only using "local configuration settings".

This means in particular that the Identrust model may be supported and that the "several many cases"
that were detailed in the annexes from draft -04 from David Cooper and Stefan Santesson
(but which were not interoperable with most current implementations) can take benefit of the description
of the general processing.

Denis

---

From: [email-masked]
Date: Mon, 17 Sep 2012 09:58:45 +0200

Santosh, 

Thank you for your very valuable comments. It took me "some time" to 
process them.
It will take you "some time" to review them. :-)

Since the comments and the changes were numerous, I have issued a new 
draft which is available at:
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt

For Santosh in particular, see my responses below in lines.

Denis,

Thanks for this.  My initial review indicates that this a very good first 
draft. 
Note that I did not review ASN.1 carefully (I assume it was copied from 
the existing RFC).

It was copied from the draft prepared by Stefan, but the ASN. 1 module 
needs to be modified 
since the syntax of nonce has been omitted. 

I have added:

   Nonce ::= OCTET STRING

Since the syntax of the nocheck extension was missing, I have also added:

   NoCheck ::= NULL

In the introduction, I have also added:

      o  Section 4.3.2 now indicates that the value of the nocheck 
         extension SHALL be NULL. 

The ASN.1 module that conforms to the 2002 version of ASN.1 which may be 
found in Section 4 
of RFC5912 has another problem, since the nocheck extension has been 
omitted.

I have added:

  --  Certificate Extension

  ocsp-nocheck EXTENSION ::= { SYNTAX NULL 
                                         IDENTIFIED BY
                                         id-pkix-ocsp-nocheck }

This means that we cannot keep the same OID for the two ASN. 1 modules and 
thus we will need two new ones.

I have now included both syntaxes in draft -01.

In the introduction, I have also added:

      o  Annex B includes a new ASN.1 module using the 1988 syntax 
         since the syntax of nonce had been omitted.  It also includes 
         a new ASN.1 module using the 2002 syntax since in the ASN.1 
         module which may be found in Section 4 of RFC5912 the nocheck 
         extension had been omitted.

I do have the following comment though:

Section 2.2: When the CA is signing the response, should it not also use 
the same key to sign the response 
as the certificate in question?  The later part of the section indicates 
this as a requirement. 
In that case, why not make this explicit like the OCSP Responder.

You are correct: I have added: 

   In the former case, the CA MUST use the same key as the one that was 
   used to issue the target certificate.

Section 3.1.3, First paragraph, the rational for CA certificates to have 
digital signature bit set because 
they sign OCSP certificates is incorrect.  May be what you mean is that a 
CA that signs OCSP responses 
needs to have digital signature bit set in its own certificate (i.e., the 
certificate for which the CA is the subject).

Oups! The text was:

   Therefore the digitalSignature bit in the keyUsage extension MUST 
   be set. 

Note 1: Since the CA issues certificates, the keyCertSign bit MUST also 
        be set.

Note 2: If the CA supports CRLs, in particular to revoke the 
        certificate of the OCSP Responders, then the cRLSign bit, the 
        digitalSignature bit and the keyCertSig bit MUST be set.

I have changed it into:

   Therefore the keyCertSign bit in the keyUsage extension MUST be set. 

   If the CA supports CRLs, in particular to revoke the certificate of 
   the OCSP Responders, then both the cRLSign bit and the keyCertSig 
   bit MUST be set.

Section 3.1.3, Note 2, Again there is no requirement for digital signature 
bit to be set just because the CA signs 
certificates and CRLs.

You are correct. See the correction proposed above.

Section 3.2: It not clear which accessLocation is being referred to here 
(cAissuers or OCSP).  If this is OCSP, 
the RFC is overly implementation specific.  A CA can use the same OCSP 
location and sign the response with 
appropriate key and include the appropriate CA certificate without having 
to change the OCSP pointer.

Section 3.2 addresses the case of CA that directly supports an OCSP 
service and which performs a key rollover. 
If the CA key changes, the OCSP location must change since it is only 
possible use a single key to sign the OCSP 
responses. Nevertheless, I take your other point to be more specific about 
the accessLocation. 
The point is addressed later on in another comment from you.

General: The I-D does not address how the CA deals with the situation when 
status of multiple certificates issued by the CA, 
but using different keys is requested.  May be the restriction in 3.2 is 
used to ensure that such situation does not occur. 
If so, a short discussion would be helpful.

Your comment is related to section 4.3.1.1. (“Processing by a CA acting as 
an OCSP responder”). 
The case is already addressed with the following text:

   For each target certificate, the OCSP responder SHALL verify whether 
   both the hash of the issuer's DN and the hash of the issuer public 
   key which are present in the request match respectively with the DN 
   and the hash of the public key of contained in an entry from the 
   list of entries maintained by this OCSP responder. 

   When there is no match, then the OCSP responder SHALL indicate the 
   "unknown" status and proceed with the next target certificate from 
   the OCSP request.

General: It not clear which accessLocation is being referred to in most 
places. 
It would be worth stating that it refers to OCSP in all cases unless 
otherwise stated.

I have added a note after the first occurrence of the word in section 
3.1.1.

Note: accessLocation is mentioned in several places of this document. 
      It refers in all cases to the accessLocation field that is present 
      in an AIA extension field to designate the location of the OCSP 
      responder.  In that case, the accessMethod field contains the 
      id-ad-ocsp OID.

Section 3.3.2 does not fully and explicitly cover the most common 
implementation I have seen and that is short life certificates. 
In that scenario, the CA needs to continue to issue the OCSP Responder 
certificate using the old CA key until all the certificates 
issued by the CA using the old key and for which the OCSP Responder is 
authoritative expire. 
The text in 3.3.3 can form a model for this when CA rekeys and OCSP 
Responder has the old keys.

The text in section 3.3.2 does not say what you say. Please be more 
specific or since the text is short, provide an alternative

Section 3.3.3, the last sentence is not desirable and can cause problems 
with some implementations. 
 It is perfectly ok for a Responder to change its key independent of 
certificate it is authoritative for. 
Note that OCSP field in a issue certificate cannot be changed just because 
the Responder rekyed, 
be it routine or due to loss or compromise of Responder key.

The text in section 3.3.3 does not say what you say. Please be more 
specific or since the text is short, provide an alternative.

Section 3.4, last paragraph, I would think that expiration checking need 
not be part of OCSP client. 
Expiration checking should come under 5280 certificate validation.

The text was:

   For each candidate certificate, the OCSP client SHALL verify that 
   the current time is within the validity period of the target 
   certificate.  If this is not the case, the candidate certificate 
   SHALL be discarded.

I have changed it into;

Note:  For each candidate certificate, when performing the path 
       validation algorithm, the OCSP client will verify that the 
       current time is within the validity period of the target 
       certificate.  Thus, certificates which are outside their 
       validity period will not be included in the request or will 
       be rejected later on by the OCSP responder.

Section 4.1, We should dilute two CAs “never have the same issuerKeyHash” 
to something more akin 
to statistically infeasible.

The text was:

      Two CAs will never, however, have the same public key unless the 
      CAs either explicitly decided to share their private key, or the 
      key of one of the CAs was compromised.

I have changed it into:

      However, it is statistically infeasible that two CAs use the same 
      public key unless the CAs either explicitly decided to share 
      their private key, or the key of one of the CAs was compromised.

Titles of subsections under 4.3 could stand improvements.  Responders 
process request and produce response; 
they do not process responses.  Clients process responses.

The titles were:

     4.3. Response processing
       4.3.1. Response processing by OCSP servers 
         4.3.1.1. Processing by a CA acting as an OCSP responder
         4.3.1.2. Processing by an OCSP Responder
       4.3.2. Response processing by an OCSP client 

I have changed them into:

     4.3. Processing of requests and responses
       4.3.1. Request processing by OCSP servers 
         4.3.1.1. Processing by a CA acting as an OCSP responder 
         4.3.1.2. Processing by an OCSP Responder 
       4.3.2. Response processing by an OCSP client 

Section 4.3.1.1, The entry should contain method used to gain access and 
sign just like the text in 4.3.1.2 
as opposed to the private key.  In other words, align the two texts for 
accessing and using private key 
to sign OCSP responses.

Both sections have been aligned.

Section 4.3.1,1, page 18 “defined in entry” could be misinterpreted as 
method define in request entry.

I don’t think that a change is necessary, since it uses the term “for each 
target certificate” and the entry thus 
refers to one of the entries from the tables of entries advertised at the 
beginning of the section. 
If you believe that a change is necessary, would you be able to make a 
proposal ?

Section 4.3.1.2, Again the same comment, for the delegated OCSP Responder, 
changing the URL 
when key is changed is not required and breaks many implementations and 
hence is unacceptable.

Would you be able to be more specific, since I don’t see that the text 
states what you mean ?

Section 4.3.2, the check for thisUpdate is flawed since this value may be 
derived from CRL even for responses 
that are not pre-generated and hence can be hours or days off depending on 
CRL issuance frequency, 
 It is better to replace it with producedAt field in the response whether 
it is related to current time or time in the past.

Good catch !

The text has been changed into :

   If the checking time is the current time, and if no nonce has been 
   used in the request, OCSP clients MUST check that the producedAt
   field is within a time window that is "close enough" to the current 
   time. 

   If the checking time is a time in the past, verifiers MUST check 
   that the producedAt field is in accordance with the verification 
   rules (e.g. close and/or after the date of a time-stamp token).

Section 4,3,2 is missing processing signature on the response and 
processing response extension.

I don’t understand your request about “missing processing signature on the 
response”, since this point is addressed 
under STEP 2. If you believe that a change is necessary, would you be able 
to be more specific ?

Processing response extension is only covered for singleExtensions when 
the criticality flag is set and 
the extension is not understood. So you are correct to request additional 
text to handle the other cases.

The following text has been added for the processing of 
responseExtensions:

   OCSP clients or verifiers SHALL check if the response contains a 
   critical responseExtensions. If such an extension is found and is 
   recognized, it MUST be processed.  If such an extension is found and 
   is not recognized, the whole OCSP response MUST be considered as 
   invalid.

The following text has been added for the processing of singleExtensions:

   If checks are successful, then OCSP clients MUST process the 
   singleExtensions field, if it is present. 

   If the criticality flag is set and the extension is not understood, 
   then the status of the certificate shall be "unknown" and proceed to 
   step 3.  Otherwise, proceed to step 2. 

   If the extension is understood, then the extension MUST be 
   processed.  According to its content proceed either to step 2 or to 
   step 3. 

Section 5.5: Replay attack is also possible when not using pre-computed 
responses.

I have added in new section with the following text:

5.7. Other replay attacks

   As already mentioned in section 5.5, replay attacks are possible 
   using precomputed responses.  Replay attacks are also possible when 
   no nonce is being used in the OCSP request and the time window 
   mentioned in section 4.3.2 (STEP 1)is too large.

General: Removal of locally trusted Responder from the I-D is 
unacceptable.

The intent was not to remove the “locally trusted Responder”. 
Nevertheless, the current text has been improved
 in several places. For example, in the introduction, I have added:

      The term “locally trusted Responder” is used to designate an OCSP 
      responder that is trusted using local rules.

In section 2.2, the text now states:

   A response message MUST be signed either by a certificate's issuer, 
   by an authorized OCSP Responder or according to local rules. 

   In the first case, the CA MUST use the same key as the one that was 
   used to issue the target certificate.

   In the second case, the CA MUST explicitly designate the OCSP 
   Responder by issuing an OCSP certificate to the OCSP Responder. 
   OCSP signing delegation SHALL be indicated 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 and under the same key 
   that was used to issue the target certificate.

   For these two cases, 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. 

   In the third case, the OCSP client uses a locally trusted Responder.
   The key used to sign OCSP responses may be directly trusted or be a 
   key contained in an OCSP certificate which is verified according to 
   local rules, instead of the rules detailed in this document.

In section I have changed the following text :

   The OCSP certificate SHALL be signed by the CA issuing private key 
   which corresponds to the issuing CA public key that is in this 
   entry, unless some specific rules are agreed between the OCSP 
   Responder and OCSP clients.  In that later case, the OCSP 
   certificate MAY be signed by a different entity.

into:

   The OCSP certificate SHALL be signed by the CA issuing private key 
   which corresponds to the issuing CA public key that is in this 
   entry, unless some specific rules are agreed between the OCSP 
   Responder and OCSP clients.  In that later case, which corresponds 
   to the case of a locally trusted Responder, the OCSP certificate MAY 
   be signed by a different entity.

There is now also a completely new section: 4.3.1.3, called “Processing by 
a locally trusted Responder”.

When reviewing the text, I found that, in section 4.3.1.2, the list only 
mentioned:

     - the method(s) used to obtain the revocation status of the 
       certificates issued under that CA issuing public key,

In practice, an OCSP responder may not be responsible for all the 
certificates issued by a CA. 
So it also needs to know which subset of the certificates issued by each 
CA it is responsible for.

Thus I have changed the text into:

     - the method(s) used to know for which subset of certificates 
       issued by the CA it is responsible for, 

     - the method(s) used to obtain the revocation status of that 
       subset of certificates issued under that CA issuing public key,

Denis
 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
Internet-Draft.
> 
> <ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis> 
> 

> B - Explanations were missing to address CA key rollover and OCSP 
>     key rollover. These explanations have been added. 
> 
>       2) Besides local configuration settings which are optional, 
>          only two cases SHALL be supported by OCSP clients (and thus 
OCSP servers) 
>          as explained below. 
>           (2) or be the public key from an OCSP responder that is 
>               contained in an OCSP certificate that has been signed by 
the same key 
>               that the one used to sign the target certificate.
>    . 
> The text allows to use the same general processing for a few other 
> cases, since "escape"  sentences are provided to allow for these other 
cases, 
> but only using "local configuration settings". 
> 
> This means in particular that the Identrust model may be supported 
> and that the "several many cases" that were detailed in the annexes f
> from draft -04 from David Cooper and Stefan Santesson (but which were 
not 
> interoperable with most current implementations) can take benefit of the 
description

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 18 Sep 2012 15:27:18 -0400

Denis,

Thanks.  Below are my updated recommended changes:

Section 3.2

Add the following Note after the second dash:

Note: The change in accessLocation is necessary when the CA rekeys to meet the following constraints imposed by this standard: 1) a BasicOCSPResponse can only be signed using a single private key; 2) the response must be signed using the same CA key that was used to sign the certificate in question; and 3) the OCSP response needs to cover all the certificates queried in the OCSP request.

Section 3.3.2:

Add the following Note to the 3rd and the last paragraph:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative for expire.

Section 3.3.3:

OLD TEXT:

“For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value.”

NEW TEXT:

“For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time.  For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use the old URI while using the new key”

Section 3.4:

OLD TEXT:

NEW TEXT:

Note:  For each candidate certificate, when performing the path
       validation algorithm, the OCSP client SHOULD verify that the
       current time is within the validity period of the target
       certificate.  Thus, certificates which are outside their
       validity period SHOULD not be included in the request.

Section 4.3.1.3:

OLD TEXT:

   For each CA from which the locally trusted Responder has received a
   delegation, the OCSP Responder SHALL maintain a list of entries.

NEW TEXT:

For each CA for which the locally trusted Responder is authoritative, the OCSP Responder SHALL maintain a list of entries.

RATIONALE:

The locally trusted responder need not have delegation from the CA

Section 4.3.2:

Add the following at the end of STEP 2:

check whether the response is signed using the OCSP Responder key:

             If it is the case, then the revocation status of that
             certificate as indicated in the certStatus field is
             accepted and proceed to step 3.

             If it is not the case, then the revocation status of that
             certificate is "unknown" and proceed to step 3.

Rationale: Current draft does not cover when the response is signed by the OCSP Responder

Change S. Shokhani to S. Chokhani

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 17, 2012 3:59 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: [pkix] draft-pinkas-rfc2560bis-00

Santosh,

Thank you for your very valuable comments. It took me "some time" to process them.
It will take you "some time" to review them. :-)

Since the comments and the changes were numerous, I have issued a new draft which is available at:
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt

Denis,

Thanks for this.  My initial review indicates that this a very good first draft.
Note that I did not review ASN.1 carefully (I assume it was copied from the existing RFC).

It was copied from the draft prepared by Stefan, but the ASN. 1 module needs to be modified
since the syntax of nonce has been omitted.

I have added:

   Nonce ::= OCTET STRING

   NoCheck ::= NULL

The ASN.1 module that conforms to the 2002 version of ASN.1 which may be found in Section 4
of RFC5912 has another problem, since the nocheck extension has been omitted.

I have added:

  --  Certificate Extension

This means that we cannot keep the same OID for the two ASN. 1 modules and thus we will need two new ones.

Section 2.2: When the CA is signing the response, should it not also use the same key to sign the response
as the certificate in question?  The later part of the section indicates this as a requirement.
In that case, why not make this explicit like the OCSP Responder.

Section 3.1.3, First paragraph, the rational for CA certificates to have digital signature bit set because
they sign OCSP certificates is incorrect.  May be what you mean is that a CA that signs OCSP responses
needs to have digital signature bit set in its own certificate (i.e., the certificate for which the CA is the subject).

Oups! The text was:

I have changed it into:

Section 3.1.3, Note 2, Again there is no requirement for digital signature bit to be set just because the CA signs
certificates and CRLs.

Section 3.2: It not clear which accessLocation is being referred to here (cAissuers or OCSP).  If this is OCSP,
the RFC is overly implementation specific.  A CA can use the same OCSP location and sign the response with
appropriate key and include the appropriate CA certificate without having to change the OCSP pointer.

Section 3.2 addresses the case of CA that directly supports an OCSP service and which performs a key rollover.
If the CA key changes, the OCSP location must change since it is only possible use a single key to sign the OCSP
responses. Nevertheless, I take your other point to be more specific about the accessLocation.
The point is addressed later on in another comment from you.

General: The I-D does not address how the CA deals with the situation when status of multiple certificates issued by the CA,
but using different keys is requested.  May be the restriction in 3.2 is used to ensure that such situation does not occur.
If so, a short discussion would be helpful.

Your comment is related to section 4.3.1.1. (“Processing by a CA acting as an OCSP responder”).
The case is already addressed with the following text:

General: It not clear which accessLocation is being referred to in most places.
It would be worth stating that it refers to OCSP in all cases unless otherwise stated.

I have added a note after the first occurrence of the word in section 3.1.1.

Section 3.3.2 does not fully and explicitly cover the most common implementation I have seen and that is short life certificates.
In that scenario, the CA needs to continue to issue the OCSP Responder certificate using the old CA key until all the certificates
issued by the CA using the old key and for which the OCSP Responder is authoritative expire.
The text in 3.3.3 can form a model for this when CA rekeys and OCSP Responder has the old keys.

The text in section 3.3.2 does not say what you say. Please be more specific or since the text is short, provide an alternative

Section 3.3.3, the last sentence is not desirable and can cause problems with some implementations.
It is perfectly ok for a Responder to change its key independent of certificate it is authoritative for.
Note that OCSP field in a issue certificate cannot be changed just because the Responder rekyed,
be it routine or due to loss or compromise of Responder key.

The text in section 3.3.3 does not say what you say. Please be more specific or since the text is short, provide an alternative.

Section 3.4, last paragraph, I would think that expiration checking need not be part of OCSP client.
Expiration checking should come under 5280 certificate validation.

The text was:

I have changed it into;

Section 4.1, We should dilute two CAs “never have the same issuerKeyHash” to something more akin
to statistically infeasible.

The text was:

I have changed it into:

Titles of subsections under 4.3 could stand improvements.  Responders process request and produce response;
they do not process responses.  Clients process responses.

The titles were:

     4.3. Response processing

Section 4.3.1.1, The entry should contain method used to gain access and sign just like the text in 4.3.1.2
as opposed to the private key.  In other words, align the two texts for accessing and using private key
to sign OCSP responses.

Section 4.3.1,1, page 18 “defined in entry” could be misinterpreted as method define in request entry.

I don’t think that a change is necessary, since it uses the term “for each target certificate” and the entry thus
refers to one of the entries from the tables of entries advertised at the beginning of the section.
If you believe that a change is necessary, would you be able to make a proposal ?

Section 4.3.1.2, Again the same comment, for the delegated OCSP Responder, changing the URL
when key is changed is not required and breaks many implementations and hence is unacceptable.

Would you be able to be more specific, since I don’t see that the text states what you mean ?

Section 4.3.2, the check for thisUpdate is flawed since this value may be derived from CRL even for responses
that are not pre-generated and hence can be hours or days off depending on CRL issuance frequency,
It is better to replace it with producedAt field in the response whether it is related to current time or time in the past.

Good catch !

I don’t understand your request about “missing processing signature on the response”, since this point is addressed
under STEP 2. If you believe that a change is necessary, would you be able to be more specific ?

Processing response extension is only covered for singleExtensions when the criticality flag is set and
the extension is not understood. So you are correct to request additional text to handle the other cases.

The following text has been added for the processing of responseExtensions:

The intent was not to remove the “locally trusted Responder”. Nevertheless, the current text has been improved
in several places. For example, in the introduction, I have added:

into:

There is now also a completely new section: 4.3.1.3, called “Processing by a locally trusted Responder”.

When reviewing the text, I found that, in section 4.3.1.2, the list only mentioned:

In practice, an OCSP responder may not be responsible for all the certificates issued by a CA.
So it also needs to know which subset of the certificates issued by each CA it is responsible for.

Denis

> implementation to automatically retrieve the ASCII version of the Internet-Draft.
>
>          only two cases SHALL be supported by OCSP clients (and thus OCSP servers)
>          as explained below.
>
>               contained in an OCSP certificate that has been signed by the same key
> cases, since "escape"  sentences are provided to allow for these other cases,
> from draft -04 from David Cooper and Stefan Santesson (but which were not
> interoperable with most current implementations) can take benefit of the description

---

From: [email-masked]
Date: Fri, 21 Sep 2012 15:21:37 +0200

Santosh,

Thank you for these new comments. I have one comment back and two nits.

You suggested to add text at the end of STEP 2, since the current draft 
does not cover when the response is signed by the OCSP Responder.
Your rational is quite true. However, your propose change does not fit 
well. I have changed the text differently 

Please take a look at draft -02 which has been issued today.
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-02.txt

First nit : 

PROPOSED TEXT:

Note: The CA may need to continue issuing certificates to the OCSP 
Responder using the old CA key until 
all the certificates issued under the CA’ old key for which the OCSP 
Responder is authoritative for expire.

NEW TEXT:

Note: The CA may need to continue issuing certificates to the OCSP 
Responder using the old CA key until 
all the certificates issued under the CA’ old key for which the OCSP 
Responder is authoritative have expired.

Second nit :

PROPOSED TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using 
the old key, and continue to use 
the old URI while using the new key”

NEW TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using 
the old key, and continue to use 
the same URI while using the new key.

Denis

De :    Santosh Chokhani <[email-masked]>
A :     "[email-masked]" <[email-masked]>
Cc :    "[email-masked]" <[email-masked]>
Date :  18/09/2012 21:27
Objet : RE: [pkix] draft-pinkas-rfc2560bis-00

Denis,

Section 3.2

Note: The change in accessLocation is necessary when the CA rekeys to meet 
the following constraints imposed by this standard: 1) a BasicOCSPResponse 
can only be signed using a single private key; 2) the response must be 
signed using the same CA key that was used to sign the certificate in 
question; and 3) the OCSP response needs to cover all the certificates 
queried in the OCSP request.
 
Section 3.3.2:

Note: The CA may need to continue issuing certificates to the OCSP 
Responder using the old CA key until all the certificates issued under the 
CA’ old key for which the OCSP Responder is authoritative for expire.
 
Section 3.3.3:
 
OLD TEXT:
 
“For a given URI value identifying the location of an OCSP Responder, the 
OCSP Responder SHALL only use one OCSP key pair value.”
 
NEW TEXT:
 
“For a given URI value identifying the location of an OCSP Responder, the 
OCSP Responder SHALL only use one OCSP key pair value for a given period 
of time.  For example, it is acceptable for an OCSP Responder to rekey, 
stop using the old key, and continue to use the old URI while using the 
new key”
 
Section 3.4:
 
OLD TEXT:

NEW TEXT:

Section 4.3.1.3:
 
OLD TEXT:

NEW TEXT:
 
For each CA for which the locally trusted Responder is authoritative, the 
OCSP Responder SHALL maintain a list of entries. 
 
RATIONALE:

Section 4.3.2:

 

Rationale: Current draft does not cover when the response is signed by the 
OCSP Responder

 
Santosh, 

Denis, 

I have added: 

   Nonce ::= OCTET STRING 

   NoCheck ::= NULL 

I have added: 

  --  Certificate Extension 

Oups! The text was: 

I have changed it into: 

The text was: 

I have changed it into; 

The text was: 

I have changed it into: 

The titles were: 

     4.3. Response processing 

Good catch ! 

into: 

Denis 
  
Internet-Draft.

OCSP servers) 
the same key 
cases, 
not 
description

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 21 Sep 2012 11:42:44 -0400

Denis,

Thanks.  I am ok with your changes.

One thing listed below is troubling me and I would like your and others’ opinion on it.

While you have revised the text in Section 3.3.3 as I requested, it is overly constraining and has been troublesome from the beginning.  The text I refer to is: “For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time”.

While I can see how this assertion simplifies the sausage-making of the standard and the data structures you spell out, it is something these need not be applies in order for the OCSP to work.   It is generally a bad ideas in a standard to impose a constraint that is not necessary for feasibility, security or interoperability reasons.

For example, one could have geographical load balancing and/or geographical redundancy for the URL and rather than porting the same key, have different keys for the Servers.  In that case, the actual Server that got the request routed would sign the response.

Another example, is the URL and the server map to the same machine and it has multiple keys and can use any one of them.

I do agree that there needs to be some constraint that specifies that the server must be able to provide response to all the queries it is authoritative for and meet the cryptographic binding requirement.

I think we need to work the 3.3.3 language so that the constraint is specified such that it does not prohibit valid architectures.

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 21, 2012 9:22 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: draft-pinkas-rfc2560bis-02

Santosh,

You suggested to add text at the end of STEP 2, since the current draft does not cover when the response is signed by the OCSP Responder.
Your rational is quite true. However, your propose change does not fit well. I have changed the text differently

First nit :

PROPOSED TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative for expire.

NEW TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative have expired.

Second nit :

PROPOSED TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the old URI while using the new key”

NEW TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the same URI while using the new key.

Denis

De :        Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
A :        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc :        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date :        18/09/2012 21:27
Objet :        RE: [pkix] draft-pinkas-rfc2560bis-00
________________________________

Denis,

Section 3.2

Section 3.3.2:

Section 3.3.3:

OLD TEXT:

NEW TEXT:

Section 3.4:

OLD TEXT:

NEW TEXT:

Section 4.3.1.3:

OLD TEXT:

NEW TEXT:

RATIONALE:

Section 4.3.2:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, September 17, 2012 3:59 AM
To: Santosh Chokhani
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [pkix] draft-pinkas-rfc2560bis-00

Santosh,

Denis,

I have added:

  Nonce ::= OCTET STRING

  NoCheck ::= NULL

I have added:

 --  Certificate Extension

Oups! The text was:

I have changed it into:

The text was:

I have changed it into;

The text was:

I have changed it into:

The titles were:

    4.3. Response processing

Good catch !

into:

Denis

---

From: [email-masked]
Date: Mon, 24 Sep 2012 08:16:43 +0200

Santosh,

Your point is valid. Here is a proposed change to solve the issue.

OLD TEXT:

   For a given URI value identifying the location of an OCSP Responder, 
   the OCSP Responder SHALL only use one OCSP key pair value for a 
   given period of time.  For example, it is acceptable for an OCSP 
   Responder to rekey, stop using the old key, and continue to use the 
   same URI while using the new key.

NEW TEXT:

   An OCSP Responder key rollover does not affect the values of the 
   URIs that are placed in the accessLocation field from the target 
   certificates.  One or more OCSP Responder MAY respond to an OCSP 
   request addressed at a given URI picked from the accessLocation 
   field from a target certificate.  Each OCSP Responder MAY use a 
   different signing key, as long as it got an OCSP certificate 
   appropriate for that signing key and for the target certificate. 

Denis

De :    Santosh Chokhani <[email-masked]>
A :     "[email-masked]" <[email-masked]>
Cc :    "[email-masked]" <[email-masked]>
Date :  21/09/2012 17:42
Objet : RE: draft-pinkas-rfc2560bis-02

Denis,

One thing listed below is troubling me and I would like your and others’ 
opinion on it.
 
While you have revised the text in Section 3.3.3 as I requested, it is 
overly constraining and has been troublesome from the beginning.  The text 
I refer to is: “For a given URI value identifying the location of an OCSP 
Responder, the OCSP Responder SHALL only use one OCSP key pair value for a 
given period of time”. 
 
While I can see how this assertion simplifies the sausage-making of the 
standard and the data structures you spell out, it is something these need 
not be applies in order for the OCSP to work.   It is generally a bad 
ideas in a standard to impose a constraint that is not necessary for 
feasibility, security or interoperability reasons.
 
For example, one could have geographical load balancing and/or 
geographical redundancy for the URL and rather than porting the same key, 
have different keys for the Servers.  In that case, the actual Server that 
got the request routed would sign the response.
 
Another example, is the URL and the server map to the same machine and it 
has multiple keys and can use any one of them.
 
I do agree that there needs to be some constraint that specifies that the 
server must be able to provide response to all the queries it is 
authoritative for and meet the cryptographic binding requirement. 
I think we need to work the 3.3.3 language so that the constraint is 
specified such that it does not prohibit valid architectures.

Santosh, 

First nit : 

PROPOSED TEXT: 

NEW TEXT: 

Second nit : 

PROPOSED TEXT: 

NEW TEXT: 

Denis 

Denis, 

Section 3.2 

  
Section 3.3.2: 

 
Section 3.3.3: 
 
OLD TEXT: 

NEW TEXT: 

Section 3.4: 
 
OLD TEXT: 

NEW TEXT: 

Section 4.3.1.3: 
 
OLD TEXT: 

NEW TEXT: 

RATIONALE: 

Section 4.3.2: 

  

 

Santosh, 

Denis, 

I have added: 

  Nonce ::= OCTET STRING 

  NoCheck ::= NULL 

I have added: 

 --  Certificate Extension 

Oups! The text was: 

I have changed it into: 

The text was: 

I have changed it into; 

The text was: 

I have changed it into: 

The titles were: 

    4.3. Response processing 

Good catch ! 

into: 

Denis 
 
Internet-Draft.

OCSP servers) 
the same key 
cases, 
not 
description

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 24 Sep 2012 12:21:48 -0400

Denis,

OK except a nit (replace “accessLocation field from” to “accessLocation field of”)

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 24, 2012 2:17 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: draft-pinkas-rfc2560bis-02

Santosh,

OLD TEXT:

NEW TEXT:

Denis

Denis,

Santosh,

First nit :

PROPOSED TEXT:

NEW TEXT:

Second nit :

PROPOSED TEXT:

NEW TEXT:

Denis

Denis,

Section 3.2

Section 3.3.2:

Section 3.3.3:

OLD TEXT:

NEW TEXT:

Section 3.4:

OLD TEXT:

NEW TEXT:

Section 4.3.1.3:

OLD TEXT:

NEW TEXT:

RATIONALE:

Section 4.3.2:

Santosh,

Denis,

I have added:

 Nonce ::= OCTET STRING

 NoCheck ::= NULL

I have added:

--  Certificate Extension

Oups! The text was:

I have changed it into:

The text was:

I have changed it into;

The text was:

I have changed it into:

The titles were:

   4.3. Response processing

Good catch !

into:

Denis

---

From: [email-masked]
Date: Tue, 25 Sep 2012 17:01:22 +0200

Santosh,

This text change has been included in draft -03 which is now available at 
:

http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt

Denis

Date :  24/09/2012 18:21

Denis,
 
OK except a nit (replace “accessLocation field from” to “accessLocation 
field of”)

Santosh, 

OLD TEXT: 

NEW TEXT: 

Denis 

Denis, 

  

  

  
Santosh, 

First nit : 

PROPOSED TEXT: 

NEW TEXT: 

Second nit : 

PROPOSED TEXT: 

NEW TEXT: 

Denis 

Denis, 

Section 3.2 

 
Section 3.3.2: 

 
Section 3.3.3: 
 
OLD TEXT: 

NEW TEXT: 

Section 3.4: 
 
OLD TEXT: 

NEW TEXT: 

Section 4.3.1.3: 
 
OLD TEXT: 

NEW TEXT: 

RATIONALE: 

Section 4.3.2: 

 

 

Santosh, 

Denis, 

I have added: 

 Nonce ::= OCTET STRING 

 NoCheck ::= NULL 

I have added: 

--  Certificate Extension 

Oups! The text was: 

I have changed it into: 

The text was: 

I have changed it into; 

The text was: 

I have changed it into: 

The titles were: 

   4.3. Response processing 

Good catch ! 

into: 

Denis 

Internet-Draft.

OCSP servers) 
the same key 
cases, 
not 
description

---

From: [email-masked]
Date: Tue, 25 Sep 2012 17:20:56 +0200

Oups !

I forgot the nit: replace “accessLocation field from” to “accessLocation 
field of”) 

I will wait for other comments before issuing a new draft.

Denis

De :    [email-masked]
A :     Santosh Chokhani <[email-masked]>
Cc :    "[email-masked]" <[email-masked]>
Date :  25/09/2012 17:01
Objet : [pkix] draft-pinkas-rfc2560bis-03
Envoyé par :    [email-masked]

Santosh, 

Denis 

Denis, 

  
Santosh, 

OLD TEXT: 

NEW TEXT: 

Denis 

Denis, 

 

 

 
Santosh, 

First nit : 

PROPOSED TEXT: 

NEW TEXT: 

Second nit : 

PROPOSED TEXT: 

NEW TEXT: 

Denis 

Denis, 

Section 3.2 

Section 3.3.2: 

Section 3.3.3: 

OLD TEXT: 

NEW TEXT: 

Section 3.4: 

OLD TEXT: 

NEW TEXT: 

Section 4.3.1.3: 

OLD TEXT: 

NEW TEXT: 

RATIONALE: 

Section 4.3.2: 

Santosh, 

Denis, 

I have added: 

Nonce ::= OCTET STRING 

NoCheck ::= NULL 

I have added: 

--  Certificate Extension 

Oups! The text was: 

I have changed it into: 

The text was: 

I have changed it into; 

The text was: 

I have changed it into: 

The titles were: 

  4.3. Response processing 

Good catch ! 

into: 

Denis 

Internet-Draft.

OCSP servers) 
the same key 
cases, 
not 
description 
> Denis _______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix