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

From: Stefan Santesson <[email-masked]>
Date: Wed, 10 Oct 2012 13:38:05 +0200

Denis,

Posting my major comments on this draft:

- This is a substantial rewrite of the original standard. There has been a
WG decision to limit changes to RFC 2560 to what is necessary to resolve
previous ambiguity. In many places, the text provided in your draft adds
confusion and adds ambiguity instead of removing them.

- This is a protocol specification. That is, it defines the data elements
exchanged for the purpose of doing OCSP checks. It is NOT a system design
specification. Processing rules are only relevant if they have a direct
impact on the bits on the wire.

- The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on
either side of the protocol.

/Stefan

From:  <[email-masked]>
Date:  Tuesday, September 25, 2012 5:01 PM
To:  Santosh Chokhani <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  [pkix] draft-pinkas-rfc2560bis-03

> 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
> <http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt>
> 
> Denis
> 
> 
> 
> De :       Santosh Chokhani <[email-masked]>
> A :       "[email-masked]" <[email-masked]>
> Cc :       "[email-masked]" <[email-masked]>
> Date :       24/09/2012 18:21
> Objet :       RE: draft-pinkas-rfc2560bis-02
> 
> 
> 
> 
> Denis,
>  
> OK except a nit (replace ³accessLocation field from² to ³accessLocation field
> of²)
>  
> From: [email-masked] [mailto:[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,
> 
> 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]
> <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 :        21/09/2012 17:42
> Objet :        RE: draft-pinkas-rfc2560bis-02
> 
> 
> 
> 
> 
> 
> 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]>
> [mailto:[email-masked] <mailto:[email-masked]> ]
> Sent: Friday, September 21, 2012 9:22 AM
> To: Santosh Chokhani
> Cc: [email-masked] <mailto:[email-masked]>
> Subject: draft-pinkas-rfc2560bis-02
>   
> 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
> <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]
> <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, 
>  
> 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: 
>  
> 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.
>  
>  
> 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]>
> [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, 
> 
> 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
> <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 
> 
>> > 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
>> <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/ <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 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 
>> > of the general processing.
>> > 
>> > Denis 
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Oct 2012 01:29:56 +0200

All,

PKIX has been rescheduled in Atlanta for a 1 hour session on Thursday
afternoon.
This because the AD has limited the meeting to focus on finalising adopted
documents before WG closure.

This means that we will not accept any presentations that is a request for
new work.

Presentations not focusing on current work will only be accepted if we have
time over and if its inclusion in the meeting can be motivated.

Please send me any requests for agenda items ASAP.

/Stefan

---

From: Denis Pinkas Bull <[email-masked]>
Date: Thu, 11 Oct 2012 07:42:04 +0200

Stefan,

Thank you for your comments.

However, your first two comments are not specific enough to know 
portions of text you would like to be removed.
Would you be able to be more specific ?

On your third comment, you say: The distinction between OCSP responder, 
OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on 
either side of the protocol.

You are right to say that there is no need to make a difference between 
an OCSP server and
an OCSP responder, and I can change this in the draft.

However, the distinction between an OCSP service supported by one or 
more OCSP responders should be maintained.

Denis

> From: <[email-masked] <mailto:[email-masked]>>
> To: Santosh Chokhani <[email-masked] 
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[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 : 24/09/2012 18:21
>     ------------------------------------------------------------------------
>
>
>
>     Denis,
>
>     OK except a nit (replace "accessLocation field from" to
>     "accessLocation field of")
>
>     *From:* [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *
>     Sent:* Monday, September 24, 2012 2:17 AM*
>     To:* Santosh Chokhani*
>     Cc:* [email-masked] <mailto:[email-masked]>*
>     Subject:* RE: draft-pinkas-rfc2560bis-02
>
>     Santosh,
>
>     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 : 21/09/2012 17:42
>     ------------------------------------------------------------------------
>
>
>
>
>     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
>     geographicalredundancy for the URL and rather than porting the
>     same key, have differentkeys 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]>[_mailto:[email-masked]] *
>     Sent:* Friday, September 21, 2012 9:22 AM*
>     To:* Santosh Chokhani*
>     Cc:* [email-masked] <mailto:[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
>
>     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*expire*d*.
>
>     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
>     ------------------------------------------------------------------------
>
>
>
>
>
>     Denis,
>
>     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 3^rd 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:
>
>          validation algorithm, the OCSP client SHOULDverify that the
>          validity period SHOULDnot be included in the request.
>
>     Section 4.3.1.3:
>
>     OLD TEXT:
>
>     For each CA forwhich the locally trusted Responder is
>     authoritative, the OCSP Responder SHALL maintain a list of entries.
>
>     RATIONALE:
>
>     Rationale: Current draft does not cover when the response is
>     signed by the OCSP Responder
>
>     *
>     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,
>
>     Thank you for your very valuable comments. It took me "some time"
>     to process them.
>     Since the comments and the changes were numerous, I have issued a
>     new draftwhich is available at:_
>     __http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt_
>
>     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
>     The ASN.1 module that conforms to the 2002 version of ASN.1 which
>     may be found in Section 4
>     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.
>     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:
>
>     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 serviceand 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.
>     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.
>     Your comment is related to section 4.3.1.1. ("Processing by a CA
>     acting as an OCSP responder").
>     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.
>
>     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,
>     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.
>     Section 4.1, We should dilute two CAs "never have the same
>     issuerKeyHash" to something more akin
>     Titles of subsections under 4.3 could stand improvements.
>      Responders process request and produce response;
>     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 !
>
>     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.
>
>     Section 5.5: Replay attack is also possible when not using
>     pre-computed responses.
>
>     The intent was not to remove the "locally trusted Responder".
>     Nevertheless, the current text has been improved
>        The term "locally trusted Responder" is used to designate an OCSP
>     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.
>
>     >    Title         : X.509 Internet PublicKey Infrastructure Online
>     > _http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.txt_
>     >
>     > _ftp://ftp.ietf.org/internet-drafts/_
>     >
>     > implementation to automatically retrieve the ASCII version of
>     the Internet-Draft.
>     >
>     > <_ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis_>
>     >
>     >       1) An OCSP response by be signed either by a CA or by an
>     OCSP Responder.
>     >
>     >          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,
>     > interoperable with most current implementations) can take
>     benefit of the description
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/pkix 
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Oct 2012 14:37:02 +0200

Denis,

Unfortunately, the number changes are too many to make a fast detailed
review providing suggestions on corrections to all issues.
I could provide examples, but that would not be a complete list.

However,

As the WG and AD has decided that we should start with as few changes as
possible and only add what is necessary, I would like to reverse this.
Could you provide an argument for each change to the current WG draft that
you think is necessary?

/Stefan

From:  Denis Pinkas Bull <[email-masked]>
Date:  Thursday, October 11, 2012 7:42 AM
To:  Stefan Santesson <[email-masked]>
Cc:  Santosh Chokhani <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: [pkix] draft-pinkas-rfc2560bis-03

>  However, your first two comments are not specific enough to know portions of
> text you would like to be removed.
>  On your third comment, you say: The distinction between OCSP responder, OCSP
> server and OCSP service is
> in this context confusing and adds nothing useful to an implementer on either
> side of the protocol.
>  
>  You are right to say that there is no need to make a difference between an
> OCSP server and 
>  However, the distinction between an OCSP service supported by one or more
> OCSP responders should be maintained.
>  
>  Denis
>  
>  
>  
>>  
>> Denis,
>>  
>> 
>>  
>>  
>>>  OK except a nit (replace ³accessLocation field from² to ³accessLocation
>>> field of²)
>>>   
>>>  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².
>>>   
>>> 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,
>>> geographicalredundancy for the URL and rather than porting the same key,
>>> have differentkeys 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.
>>>   
>>> 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.
>>>   
>>>  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
>>>  
>>>  all the certificates issued under the CA¹ old key for which the OCSP
>>> Responder is authoritative for expire.
>>>  
>>>  NEW TEXT: 
>>>  
>>>  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
>>>  For example, it is acceptable for an OCSP Responder to rekey, stop using
>>> the old key, and continue to use
>>>  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:
>>>  
>>> 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
>>> 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: 
>>>  
>>>  For each CA for which the locally trusted Responder is authoritative, the
>>> OCSP Responder SHALL maintain a list of entries.
>>>  
>>>  RATIONALE: 
>>>  
>>>  Thank you for your very valuable comments. It took me "some time" to
>>> process them. 
>>>  Since the comments and the changes were numerous, I have issued a new
>>> draftwhich is available at:
>>>  It was copied from the draft prepared by Stefan, but the ASN. 1 module
>>> needs to be modified
>>>  The ASN.1 module that conforms to the 2002 version of ASN.1 which may be
>>> found in Section 4
>>>  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.
>>>  they sign OCSP certificates is incorrect.  May be what you mean is that a
>>> CA that signs OCSP responses
>>>  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.
>>>  
>>>  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
>>> serviceand 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.
>>>  but using different keys is requested.  May be the restriction in 3.2 is
>>> used to ensure that such situation does not occur.
>>>  Your comment is related to section 4.3.1.1. (³Processing by a CA acting as
>>> an OCSP responder²).
>>>  It would be worth stating that it refers to OCSP in all cases unless
>>> otherwise stated.
>>>  
>>>  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.
>>>  Note that OCSP field in a issue certificate cannot be changed just because
>>> the Responder rekyed,
>>>  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.
>>>  Section 4.1, We should dilute two CAs ³never have the same issuerKeyHash²
>>> to something more akin
>>>  Titles of subsections under 4.3 could stand improvements.  Responders
>>> process request and produce response;
>>>  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
>>>  Section 4.3.1,1, page 18 ³defined in entry² could be misinterpreted as
>>> method define in request entry.
>>>  
>>>  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 ?
>>>  
>>>  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 ! 
>>>  
>>>  under STEP 2. If you believe that a change is necessary, would you be able
>>> to be more specific ?
>>>  
>>>  the extension is not understood. So you are correct to request additional
>>> text to handle the other cases.
>>>  
>>>  There is now also a completely new section: 4.3.1.3, called ³Processing by
>>> a locally trusted Responder².
>>>  
>>>  So it also needs to know which subset of the certificates issued by each CA
>>> it is responsible for.
>>>  
>>>>  >          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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 11 Oct 2012 15:08:09 +0200

Stefan,

You will find detailed explanations of all the changes in the first 
pages of my draft.
You win a special prize, if you find a major change that is not indicated !

Since the RFC was badly structured, for example, the description of the 
parameters for the request and the response
was scattered all over the document, some descriptions were missing, 
then its current format could not be kept.

In my draft, each parameter is now described either with the request or 
with the response. the processing is described just after,
from a client and then from a server prospective.

Some processing of the elements were missing and the most important was 
that the processing of the response was wrong.

I have added information for handling key rollover that influence the 
way to use the protocol. I believe this information is important,
but I would not object to move it in an annex

Since we now both know that it will be possible to have a quick face to 
face meeting in London next week on Tuesday,
I propose that we both come with a printed version of the draft and then 
we can discuss the changes and the rational of each change
that is not always fully explained, since this will have overloaded the 
document (which is already sufficiently heavy).

Denis

> As the WG and AD has decided that we should start with as few changes 
> as possible and only add what is necessary, I would like to reverse this.
> Could you provide an argument for each change to the current WG draft 
> that you think is necessary?
>
> /Stefan
>
>
> From: Denis Pinkas Bull <[email-masked] 
> <mailto:[email-masked]>>
> To: Stefan Santesson <[email-masked] <mailto:[email-masked]>>
> Cc: Santosh Chokhani <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     On your third comment, you say: The distinction between OCSP
>     responder, OCSP server and OCSP service is
>     in this context confusing and adds nothing useful to an
>     implementer on either side of the protocol.
>
>     You are right to say that there is no need to make a difference
>     between an OCSP server and
>     However, the distinction between an OCSP service supported by one
>     or more OCSP responders should be maintained.
>
>     Denis
>
>>     Denis,
>>
>>         Cc : "[email-masked] <mailto:[email-masked]>"
>>         <[email-masked] <mailto:[email-masked]>>
>>         Date : 21/09/2012 17:42
>>         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 geographicalredundancy for the URL and rather than
>>         porting the same key, have differentkeys 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.
>>         *
>>         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
>>
>>         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*expire*d*.
>>
>>         Second nit :
>>
>>         PROPOSED TEXT:
>>
>>         For example, it is acceptable for an OCSP Responder to rekey,
>>         stop using the old key, and continue to use
>>         For example, it is acceptable for an OCSP Responder to rekey,
>>         stop using the old key, and continue to use
>>         Cc : "[email-masked] <mailto:[email-masked]>"
>>         <[email-masked] <mailto:[email-masked]>>
>>         Date : 18/09/2012 21:27
>>         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, 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:
>>
>>         Thank you for your very valuable comments. It took me "some
>>         time" to process them.
>>         Since the comments and the changes were numerous, I have
>>         issued a new draftwhich is available at:_
>>         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
>>         The ASN.1 module that conforms to the 2002 version of ASN.1
>>         which may be found in Section 4
>>         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.
>>         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:
>>
>>         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 serviceand 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
>>         but using different keys is requested.  May be the
>>         restriction in 3.2 is used to ensure that such situation does
>>         not occur.
>>         Your comment is related to section 4.3.1.1. ("Processing by a
>>         CA acting as an OCSP responder").
>>         General: It not clear which accessLocation is being referred
>>         to in most places.
>>         Section 3.3.2 does not fully and explicitly cover the most
>>         common implementation I have seen and that is short life
>>         certificates.
>>         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,
>>         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.
>>
>>         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
>>         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
>>         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 !
>>
>>         Section 4,3,2 is missing processing signature on the response
>>         and processing response extension.
>>
>>         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.
>>
>>         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.
>>
>>         > implementation to automatically retrieve the ASCII version
>>         of the Internet-Draft.
>>         >
>>         > C - Backwards compatibility has been addressed in the 
>>

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 12 Oct 2012 11:50:21 +0200

Denis,

In-line

From:  Denis Pinkas <[email-masked]>
Date:  Thursday, October 11, 2012 3:08 PM
To:  Stefan Santesson <[email-masked]>
Cc:  Santosh Chokhani <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: [pkix] draft-pinkas-rfc2560bis-03

>     
>  
> Stefan,
>  
>  You will find detailed explanations of all the changes in the first pages of
> my draft.

I have seen and read them. But they do not provide what's needed.

I need to know for each change:
* What is the problem you try to solve (I.e. Why is a change necessary)?
* Motivate why your proposed solution is the best way forward.
In order to make it to the update you need to convoke the WG on both points.

>  was scattered all over the document, some descriptions were missing, then its
> current format could not be kept.

I disagree. The structure of 2560 is not ideal, but it is good enough.
The value of having an update that is easy to compare with the original
standard is greater than the benefit of changing the structure.

>  
>  In my draft, each parameter is now described either with the request or with
> the response. the processing is described just after,
>  Some processing of the elements were missing and the most important was that
> the processing of the response was wrong.

This is valuable information. Here I would need to know (as stated above) 1)
What is the problem? 2) Why solve it your way?
Just saying that something is missing is not enough. You have to explain
what negative impact this has.
Something might be missing because it is not necessary.

>  
>  I have added information for handling key rollover that influence the way to
> use the protocol. I believe this information is important,

I think on the contrary that describing key rollover is completely
unnecessary.
The mechanisms of key rollover is already explained in other documents.

>  
>  Since we now both know that it will be possible to have a quick face to face
> meeting in London next week on Tuesday,
>  I propose that we both come with a printed version of the draft and then we
> can discuss the changes and the rational of each change

I just need the list of motivations stated above.
Then we can process them one by one here on the list.

Having a face to face discussion is good however.

/Stefan

>  
>  Denis
>  
>  
>  
>  
>>  
>> Denis,
>>  
>> 
>>  
>>  
>> Unfortunately, the number changes are too many to make a fast detailed review
>> providing suggestions on corrections to all issues.
>>  
>>>  However, your first two comments are not specific enough to know portions
>>> of text you would like to be removed.
>>>>> 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
>>>>> 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
>>>>>  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
>>>>> 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: 
>>>>>  
>>>>>  Rationale: Current draft does not cover when the response is signed by
>>>>> the OCSP Responder
>>>>>  
>>>>>  Note that I did not review ASN.1 carefully (I assume it was copied from
>>>>> the existing RFC).
>>>>>  
>>>>>  This means that we cannot keep the same OID for the two ASN. 1 modules
>>>>> and thus we will need two new ones.
>>>>>  
>>>>>  responses. Nevertheless, I take your other point to be more specific
>>>>> about the accessLocation.
>>>>>  General: The I-D does not address how the CA deals with the situation
>>>>> when status of multiple certificates issued by the CA,
>>>>>  Your comment is related to section 4.3.1.1. (³Processing by a CA acting
>>>>> as an OCSP responder²).
>>>>>  I don¹t think that a change is necessary, since it uses the term ³for
>>>>> each target certificate² and the entry thus
>>>>>  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 intent was not to remove the ³locally trusted Responder².
>>>>>  There is now also a completely new section: 4.3.1.3, called ³Processing 
>>>>> by a locally trusted Responder².
>>>>>  
>>>>>  So it also needs to know which subset of the certificates issued by each 
>>>>> CA it is responsible for. 
>>>>>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 12 Oct 2012 16:21:08 +0200

Stefan,

Let us wait until Tuesday: it is less than one and a half working days.

Denis

> Denis,
>
> In-line
>
> From: Denis Pinkas <[email-masked] <mailto:[email-masked]>>
>     You will find detailed explanations of all the changes in the
>     first pages of my draft.
>     Since the RFC was badly structured, for example, the description
>     of the parameters for the request and the response
>     was scattered all over the document, some descriptions were
>     missing, then its current format could not be kept.
>
>
> The value of having an update that is easy to compare with the 
> original standard is greater than the benefit of changing the structure.
>
>
>     In my draft, each parameter is now described either with the
>     request or with the response. the processing is described just after,
>     Some processing of the elements were missing and the most
>     important was that the processing of the response was wrong.
>
>
> This is valuable information. Here I would need to know (as stated 
> above) 1) What is the problem? 2) Why solve it your way?
> Just saying that something is missing is not enough. You have to 
> explain what negative impact this has.
>     I have added information for handling key rollover that influence
>     the way to use the protocol. I believe this information is important,
>     Since we now both know that it will be possible to have a quick
>     face to face meeting in London next week on Tuesday,
>     I propose that we both come with a printed version of the draft
>     and then we can discuss the changes and the rational of each change
>     that is not always fully explained, since this will have
>     overloaded the document (which is already sufficiently heavy).
>
>
>>     Unfortunately, the number changes are too many to make a fast
>>     detailed review providing suggestions on corrections to all issues.
>>     As the WG and AD has decided that we should start with as few
>>     changes as possible and only add what is necessary, I would like
>>     to reverse this.
>>     Could you provide an argument for each change to the current WG
>>     draft that you think is necessary?
>>
>>     /Stefan
>>
>>
>>         However, your first two comments are not specific enough to
>>         know portions of text you would like to be removed.
>>         You are right to say that there is no need to make a
>>         difference between an OCSP server and
>>         However, the distinction between an OCSP service supported by
>>         one or more OCSP responders should be maintained.
>>
>>         Denis
>>
>>>         Denis,
>>>
>>>             A : "[email-masked]
>>>             <mailto:[email-masked]>" <[email-masked]
>>>             Cc : "[email-masked] <mailto:[email-masked]>"
>>>             <[email-masked] <mailto:[email-masked]>>
>>>             Date : 24/09/2012 18:21
>>>             A : "[email-masked]
>>>             <mailto:[email-masked]>" <[email-masked]
>>>             One thing listed below is troubling me and I would like
>>>             your and others' opinion on it.
>>>
>>>             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".
>>>
>>>             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.
>>>
>>>             and/or geographicalredundancy for the URL and rather
>>>             than porting the same key, have differentkeys 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.
>>>
>>>             specifies that the server must be able to provide
>>>             response to all the queries it is authoritative for and
>>>             meet the cryptographic binding requirement.
>>>             constraint is specified such that it does not prohibit
>>>             valid architectures.
>>>             *
>>>             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
>>>
>>>             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*expire*d*.
>>>
>>>             Second nit :
>>>
>>>             PROPOSED TEXT:
>>>
>>>             For example, it is acceptable for an OCSP Responder to
>>>             rekey, stop using the old key, and continue to use
>>>             For example, it is acceptable for an OCSP Responder to
>>>             rekey, stop using the old key, and continue to use
>>>             A : "[email-masked]
>>>             <mailto:[email-masked]>" <[email-masked]
>>>             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:
>>>
>>>             Rationale: Current draft does not cover when the
>>>             response is signed by the OCSP Responder
>>>
>>>             Thank you for your very valuable comments. It took me
>>>             "some time" to process them.
>>>             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
>>>             The ASN.1 module that conforms to the 2002 version of
>>>             ASN.1 which may be found in Section 4
>>>             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
>>>             they sign OCSP certificates is incorrect.  May be what
>>>             you mean is that a CA that signs OCSP responses
>>>             certificate (i.e., the certificate for which the CA is
>>>             the subject).
>>>
>>>             Oups! The text was:
>>>
>>>             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 serviceand 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.
>>>             General: The I-D does not address how the CA deals with
>>>             the situation when status of multiple certificates
>>>             issued by the CA,
>>>             restriction in 3.2 is used to ensure that such situation
>>>             does not occur.
>>>             Your comment is related to section 4.3.1.1. ("Processing
>>>             by a CA acting as an OCSP responder").
>>>             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.
>>>
>>>             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.
>>>             Note that OCSP field in a issue certificate cannot be
>>>             changed just because the Responder rekyed,
>>>             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.
>>>             Section 4.1, We should dilute two CAs "never have the
>>>             same issuerKeyHash" to something more akin
>>>             Titles of subsections under 4.3 could stand
>>>             improvements.  Responders process request and produce
>>>             response;
>>>             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.
>>>
>>>             I don't think that a change is necessary, since it uses
>>>             the term "for each target certificate" and the entry thus
>>>             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
>>>             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,
>>>             response whether it is related to current time or time
>>>             in the past.
>>>
>>>             Good catch !
>>>
>>>             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
>>>             Section 5.5: Replay attack is also possible when not
>>>             using pre-computed responses.
>>>
>>>             The intent was not to remove the "locally trusted
>>>             Responder". Nevertheless, the current text has been improved
>>>             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.
>>>
>>>             > implementation to automatically retrieve the ASCII
>>>             version of the Internet-Draft.
>>>             >
>>>             >

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 12 Oct 2012 19:22:18 +0000

Stefan, 

We're working to close outstanding comments on the EST draft and will be publishing our update soon. Its probably appropriate for us to provide a status update and solicit any final comments as the draft heads toward the final stages of the process. Please reserver some time on the schedule for that. 

Thanks,

- max

On Oct 10, 2012, at 5:29 PM, Stefan Santesson <[email-masked]> wrote:

> All,
> 
> PKIX has been rescheduled in Atlanta for a 1 hour session on Thursday afternoon.
> This because the AD has limited the meeting to focus on finalising adopted documents before WG closure.
> 
> This means that we will not accept any presentations that is a request for new work.
> 
> Presentations not focusing on current work will only be accepted if we have time over and if its inclusion in the meeting can be motivated.
> 
> 
> [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Oct 2012 15:32:14 -0400

If this next draft will (hopefully) resolve the outstanding comments, I would like to push for WG Last Call.  That way, the face-to-face time in Atlanta can be used to resolve any issues that surface during the WG Last Call.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 14 Oct 2012 13:04:16 +0200

Hi Max,

I'll put you up for the agenda.
How long time do you want?

/Stefan

On 10/12/12 9:22 PM, "Max Pritikin (pritikin)" <[email-masked]> wrote:

>Stefan, 
>
>We're working to close outstanding comments on the EST draft and will be
>publishing our update soon. Its probably appropriate for us to provide a
>status update and solicit any final comments as the draft heads toward
>the final stages of the process. Please reserver some time on the
>schedule for that.
>
>Thanks,
>
>- max
>
>> Presentations not focusing on current work will only be accepted if we
>>have time over and if its inclusion in the meeting can be motivated.
>> 
>>

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 14 Oct 2012 13:07:39 +0200

I think that is a good call.

Max, do you think the next draft is WGLC ready, and when will it be
submitted.
If it's ready, I will initiate a WGLC once published.

/Stefan

On 10/12/12 9:32 PM, "Russ Housley" <[email-masked]> wrote:

>If this next draft will (hopefully) resolve the outstanding comments, I
>would like to push for WG Last Call.  That way, the face-to-face time in
>Atlanta can be used to resolve any issues that surface during the WG Last
>Call.
>
>Russ
>
>
>> We're working to close outstanding comments on the EST draft and will
>>be publishing our update soon. Its probably appropriate for us to
>>provide a status update and solicit any final comments as the draft
>>heads toward the final stages of the process. Please reserver some time
>>on the schedule for that.
>> 
>> Thanks,
>> 
>> - max
>>