Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

From: Denis Pinkas <[email-masked]>
Date: Sun, 20 Jan 2013 17:12:42 +0100

Please find 32 comments on draft-ietf-pkix-rfc2560bis

1.The document states:

**

*    "This Internet-Draft is submitted to IETF in full conformance with the*

*    provisions of BCP 78 and BCP79."*

BCP 78 is RFC 3978.

However, this draft, if transformed into an RFC, does not meet the 
requirements that are present in RFC 3978.

RFC 3978 states:

*"4.2.Granting of Rights and Permissions*

**

*By submission of an RFC Editor Contribution, each person actually*

*submitting the RFC Editor Contribution, and each named co-*

*Contributor, is deemed to agree to the following terms and*

*conditions, and to grant the following rights, on his or her own*

*behalf and on behalf of the organization the Contributor represents*

*or is sponsored by (if any) when submitting the RFC Editor*

*Contribution.*

**

*(...)*

*7.1.Rights Granted in IETF Contributions*

**

*The IETF/ISOC must obtain the right to publish an IETF Contribution*

*as an RFC or an Internet-Draft from the Contributors.*

**

*(...)*

**

*7.2.Rights to use Contributed Material*

**

*Because, under the laws of most countries and applicable*

*international treaties, copyright rights come into existence whenever*

*a work of authorship is created (but see Section 8 below regarding*

*public domain documents), and IETF cannot make use of IETF*

*Contributions if it does not have sufficient rights with respect to*

*these copyright rights, it is important that the IETF receive*

*assurances from all Contributors that they have the authority to*

*grant the IETF the rights that they claim to grant.Without this*

*assurance, IETF and its participants would run a greater risk of*

*liability to the owners of these rights.*

**

*To this end, IETF asks Contributors to give the assurances in Section
3.4 above."*

Some of the contributors mentioned for this document have not sent any 
message related to OCSP for years, in particular:
Michael Myers, Rich Ankney, Slava Galperin, and Carlisle Adams.

The RFC editor will send an email to every author. Unfortunately, he 
will never receive an email from Rich Ankney because
he has no email address in the "other world".

http://www.rfc-editor.org/pubprocess.html#Authors states:

    "Authors' Final Review (AUTH48 State)

Once an RFC has been edited and is ready for publication, the author(s) 
are given "48 hours" (in practice, this often stretches over weeks)
to look over their document for errors, editorial and otherwise. We DO 
NOT make changes to RFCs once they have been published, so
please look over your document carefully. Upon approval by all authors, 
the RFC will be published.

The AUTH48 notification message sent to authors asks that they review 
the entire document, paying particular attention to:

  * IANA considerations updates (if applicable),
  * contact information, and
  * references.

If an author is no longer available, there are several options (as 
listed in the FAQ 
<http://www.rfc-editor.org/rfcfaq.html#missingauthor>http://www.rfc-editor.org/rfcfaq.html#missingauthor). 

Indefinite delays are not allowed, but when there is a choice, the RFC 
Editor would in general prefer to publish it right than to publish it 
early."

http://www.rfc-editor.org/rfcfaq.html#missingauthor states:

" *One of the authors is no longer available; how do we move forward?*

We recommend one of the following paths forward:

1.The author can be removed as an author and moved to the 
Acknowledgements section.

2.The author can be removed as an author and moved to a Contributors 
section.

3.An AD can approve the document in place of the unavailable author. 
(See the IESG Statement on AUTH48 State 
<http://www.ietf.org/iesg/statement/auth48.html>.)

Option 3 is typically used in instances where the missing author made 
significant contributions to the document,
so the other authors are not feel comfortable removing the individual 
from the author list".

The IESG Statement on AUTH48 states (5 Jan 2006):

"The IESG has decided that as of now, any IESG-approved drafts that 
enter the AUTH48 state, where the RFC Editor
waits for final text approval from all listed authors, may be released 
on the responsible AD's authority if any authors
have not responded after a reasonable time, typically two weeks".

*It looks more reasonable to anticipate the problem and to apply the 
path numbered 1, hence to move the names **
**of the original contributors to RFC **2560 in**to the Acknowledgments 
section. *

Obviously, the consequence is that there will be far less people 
contributing to this draft:

Stefan seems to be the single author/contributor, ... which is what he 
wanted :

   - he did not answered positively when, last summer, I sent him a 
private email proposing to share the editing of the draft.
   - after a meeting in London, he did not either responded at two 
proposals for a phone call.

Most of the following comments take advantage of 
draft-pinkas-rfc2560bis-03 which was built after a detailed examination
of the defects of RFC 2560. The writing of this draft took me about 40 
hours of work.

2.The current text from section 2 states:

2.   Protocol Overview

    In lieu of or as a supplement to checking against a periodic CRL, it

    may be necessary to obtain*timely information*  regarding the

    revocation status of a certificate (cf. RFC5280], Section 3.3).

    Examples include high-value funds transfer or large stock trades.

    The Online Certificate Status Protocol (OCSP) enables applications to

    determine the (revocation) state of an identified certificate. OCSP

    may be used to satisfy some of the operational requirements of

    providing*more timely revocation information*  than is possible with

    CRLs and may also be used to obtain additional status information.

This text is misleading because readers may think that OCPS necessarily provides "timely information".

Proposed text replacement:

*The Online Certificate Status Protocol (OCSP) is a client-server *

*protocol which enables applications to obtain the revocation status *

*of one or more certificates either "good", "revoked", or "unknown".*

**

*The revocation status may be provided by the server either using a *

*real time access to a database of issued certificates, or using a *

*batch access to a database of issued certificates, or using a *

*real time access to a database of revocation statuses of issued *

*certificates, or using a batch access to a database of revocation *

*statuses of issued certificates, or using CRLs, or using a *

*combination of base CRLs and delta CRLs.*

**

*In the first case, it is possible to obtain timely revocation status *

*information, whereas in the other cases, the freshness of the *

*revocation status is not better than the mechanisms it is based on.*

3.The current text from section 2 states:

    An OCSP client issues a status request to an OCSP responder and

    Suspends acceptance of*the certificate in question*  until the

    responder provides a response.

    This protocol specifies the data that needs to be exchanged between

    an application checking the status of a certificate and the server

    providing that status.

Thus is insufficient for an overview. More details are needed to know what the document provides,
in particular that the request may contain several requests for several certificates issued by different CAs.
The possibility of using extensions should also be advertised.

Proposed text replacement:

When using OCSP, an OCSP client issues a certificate revocation

status request to an OCSP responder *for one or more certificates *

*issued by the same CA or for one or more certificates issued by *

*different CAs *and then suspends acceptance of the certificate(s)

in question until the responder provides a response.

This document specifies the data that needs to be exchanged between

an application checking the status of a certificate and the server

providing that status.

*OCSP may also provide additional status information using *

*extensions. *

4.Page 6. Editorial. Punctuation and a CR/LF are missing.

The text states:

*    3. the request contains the information needed by the responder If*

*       any one of the prior conditions are not met, the OCSP responder*

*       produces an error message; otherwise, it returns a definitive*

*       response.*

It should state:

*    4. the request contains the information needed by the responder.*

*  *

*       If any one of the prior conditions are not met, the OCSP responder*

*       produces an error message; otherwise, it returns a definitive*

*       response.*

5.On page 7, the text states:

**

*All definitive response messages SHALL be digitally signed. The key*

*used to sign the response MUST belong to one of the following:*

*  *

*    -   the CA who issued the certificate in question*

*    -   a Trusted Responder whose public key is trusted by the requester*

*    -   a CA Designated Responder (Authorized Responder) who holds a*

*       specially marked certificate issued directly by the CA, indicating*

*       that the responder may issue OCSP responses for that CA.*

**

The paragraph is ambiguous on several aspects.

Delegation is addressed in at least three different places, but with 
different terms and conditions.
If some one picks a sentence in one paragraph rather than another, it 
will lead to a different conclusion.
RFCs are supposed to be clear.

On page 10, the current text states in section*2.6 OCSP Signature 
Authority Delegation *states:

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

*same key that signed the certificate.**A certificate's issuer*

*explicitly delegates OCSP signing authority by issuing a certificate*

*containing a unique value for extendedKeyUsage in the OCSP signer's*

*certificate. This certificate MUST be issued directly to the*

*responder by the cognizant CA.*

On page 16, there is a section *4.2.2.2***called*"**Authorized 
Responders"*dealing with the same topic.

Section 4.2.2.2 states:

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

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

*ensure that the entity signing this information is authorized to do*

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

*responses itself or it MAY explicitly designate this authority to*

*another entity.OCSP signing delegation SHALL be designated by the*

*inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate*

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

*certificate MUST be issued directly by the CA that issued the*

*certificate in question.*

**

*The CA SHOULD use the same issuing key to issue a delegation*

*certificate as was used to sign the certificate being checked for*

*revocation. Systems relying on OCSP responses MUST recognize a*

*delegation certificate as being issued by the CA that issued the*

*certificate in question only if the delegation certificate and the*

*certificate being checked for revocation was signed by the same key.***

The last sentence above in yellow is the key sentence that is missing in 
the two other sections.

Most implementations only support the case where the OCSP Responder receives an OCSP certificate that is signed by the same key
that was used to sign the target certificate. They do not support the case where the OCSP Responder receives an OCSP certificate
that is signed by a key that is different from the one that was used to sign the target certificate.

It is inappropriate to have three sections dealing with the same topic 
with a slightly different meaning.

It is proposed the following.

On page 7, after:

*    -   a CA Designated Responder (Authorized Responder) who holds a*

*       specially marked certificate issued directly by the CA, indicating*

*       that the responder may issue OCSP responses for that CA.*

it is proposed to add "(*see section 4.2.2.2 for further details**)"*, 
so that the reader knows that more details are provided later on.

Then we do not need two sections to address delegation which start with 
the same sentence:

"*The key that signs a certificate's status information need not be the 
same key that signed the certificate".*

**

It is thus proposed to delete section 2.6.

Section 4.2.2.2 will thus remain the single section providing full details.

6.  Page 7, the text states:

*    A definitive response message is composed of:*

*  *

*    -   version of the response syntax*

*    -   name of the responder*

*    -   responses for each of the certificates in a request*

*    -   optional extensions*

*    -   signature algorithm OID*

*    -  signature computed across hash of the response*

This description does not fit with the ASN.1 syntax which is detailed 
later on, and in particular:

*    ResponseData ::= SEQUENCE {*

*       version               [0] EXPLICIT Version DEFAULT v1,*

*       **responderID               ResponderID,*

*       producedAt                GeneralizedTime,*

*       responses                 SEQUENCE OF SingleResponse,*

*       responseExtensions    [1] EXPLICIT Extensions OPTIONAL }*

Proposed text replacement:

*A definitive response message is composed of:*

**

*- a response status and if there is no error, the following:*

*- the version of the response syntax,*

*- an identifier of the OCSP server,*

*- the time at which the response was produced,*

*- single responses for each of the target certificates,*

*- optional extensions,*

*- the signature algorithm OID,*

*- the signature computed across hash of the response, and*

*- optional certificates.*

7.The text states on page 7:

*The response for each of the certificates in a request consists of*

**

*-target certificate identifier*

*-certificate status value*

*-response validity interval*

*-optional extensions*

However, there are no explanations for the purpose of these parameters 
and how they should be processed.

There are also no explanations on how to process a single response and 
how to verify that it is its presence within the signed structure
is valid or not valid. This is a major deficiency of the current 
description of RC 2560 where there is no explanation on how to validate
a single response.

Text proposal to be added after:

*The purpose of the identifier of the OCSP server is to allow OCSP *

*clients to find whether the definitive response was signed by a CA *

*or by an OCSP Responder.*

**

*The identifier of the OCSP server SHOULD either be the name or the *

*key from a CA, or the name or the key from a OCSP Responder.*

**

*Unless there exist local rules (which are outside the scope of this *

*document) for verifying that a single response is correctly signed, *

*the following applies:*

*When the identifier matches with the name of the CA which has issued *

*the target certificate or corresponds to the key used to issue the *

*target certificate, then a single response is correctly signed *

*only if the digital signature of the OCSP response is valid using the *

*key used to sign the target certificate.*

**

*When the identifier does not match with the name of the CA which has *

*issued the target certificate or does not correspond to the key used *

*to issue the target certificate, then an single response is correctly *

*signed only if :*

**

*(a) there exists in the response an OCSP certificate issued by *

*the CA which has issued the target certificate which is *

*signed by the same key as the one used to issue the *

*target certificate, and*

**

*(b) the digital signature of the OCSP response is valid using *

*the subjectPublicKey contained in this OCSP certificate.*

8.The text states on page 7:

The "revoked" state indicates that the certificate has been revoked

*(either permanently or temporarily (on hold)). *This state MAY also be

returned if the responder knows that the requested certificate has

*never been issued during the history of the associated CA *using any

current or previous issuing key. **

The text is ambiguous because there are two embedded parenthesis and it 
is unclear whether the inner parenthesis means "i.e" or "e.g".
This single sentence may let think that on hold is the single case for 
temporarily revocation. Since neither X.509 nor RFC 5280 address
the case of a temporary revocation in the context of an OCSP response 
(but only in the context of CRLs), we are able to add another case
of temporary revocation which will only apply in the context of OCSP.

The above sentence using the terms"*never been issued during the history 
of the associated CA*"does not capture the fact
that it could be issued in the future, hence why using"*not yet been 
used"*would be more appropriate.

Finally, it would have been more logical to use "unknown". So it is 
important to add a note to explain why we have chosen that case for 
"legacy clients",
otherwise the people who have not participate to the exchanges will not 
understand.

Proposed text replacement:

    *The "revoked" state indicates that the certificate has been revoked,*

*    either permanently or temporarily.*

    A certificate may be temporarily revoked either because it is

    placed on hold (*i.e. the revocation reason is certificateHold*) or

    because the responder is able to know, using a positive list of

    issued certificates, that the serial number from the requested

    certificate has*not yet been used*  by the CA to issue a certificate

    (*i.e. the revocation reason is notIssuedOrIrregularlyIssued*).

*NOTE: The "revoked" state is used rather than the "unknown" state, to*

*       make sure that relying parties that were conformant to RFC 2560*

*       will not use CRLs as a fall back mechanism.*

9.The text states on page 8:

*When a responder responds revoked to a status request for a non-*

*issued certificate, the responder MUST also;*

**

*- include the extended revoked definition response extension*

*(section 4.8), indicating that the OCSP responder supports the*

*extended definition of revoked state to also cover non-issued*

*certificates,*

**

*- provide the revocation reason certificateHold (6), and;*

**

*- specify the revocation date January 1, 1970. *

As already explained on the PKIX list, using the revocation 
reason**certificateHold is not appropriate
because it changes the meaning of certificateHold.

The extended revoked definition response extension is a means to signal 
that it not a true certificate hold but a "not issued certificate".
Legacy applications cannot take advantage of it.

Some applications which handle non repudiation enter a waiting state 
when the revocation reason certificateHold is used thus
it is not appropriate to overload the meaning.

**

It is possible to use another enumeration for signalling that specific case:

notIssuedOrIrregularlyIssued (7).

**

Thus for new applications it would be much better to use 
notIssuedOrIrregularlyIssued (7) as already proposed on the PKIX list.

The above sentence uses the text:  

"a status request for a*non-issued certificate*"

whereas it would be more appropriate to state:  

"a status request for a*  serial number which has not been used by the CA or used irregularly to issue a certificate".*

*  *

Placing the ASN.1 description at such a place in the document is inappropriate since the ASN.1 structures have not yet been described.
Thus only the functional aspects should be mentioned, but not the ASN.1 implications.

*  *

BTW, the description should follow the same order as the ASN.1. This is not the case.

This text should be deleted from this section and the appropriate text should be added when the parameters of the response are described.

The text proposed in the previous comment should be sufficient at this time of reading.

In addition, section*4.4.8Extended Revoked Definition *should be deleted.**

10.The text states on page 8:

*2.4Semantics of thisUpdate, nextUpdate and producedAt*

This section is misplaced. At this time of reading, the reader does not 
know that thisUpdate, nextUpdate and producedAt are values
used by the ASN.1 structures. It is appropriate to describe what theses 
parameters mean when the ASN.1 syntax is described.
The current ASN.1 syntax is very badly described. One would expect that 
after every ASN.1 structure description every parameter is described.
Unfortunately this is not the case.

The text from this section is not aligned with the text that is present 
in section 4.2.2.1.

In particular, in section 2.4:

**

*If nextUpdate is not set, the responder is indicating that newer*

*revocation information is available all the time.*

While in section 4.2.2.1:

*Responses where the nextUpdate value is not set are equivalent *

*to a CRL with no time for nextUpdate (see Section 2.4).*

It is not appropriate to have two different descriptions in two 
different places.

Delete section 2.4. See comment number 19 for the description of these 
parameters.

11.Section 2.5 is also misplaced. They use values from the ASN.1 syntax 
which has not yet been described.
They should be moved or incorporated in the document once the ASN.1 
description has been done.

12.Remainder: Section 2.6 should be deleted (see comment number 5).

13.Section 2.7 states:

*2.7CA Key Compromise*

**

*If an OCSP responder knows that a particular CA's private key has*

*been compromised, it MAY return the revoked state for all*

*certificates issued by that CA.*

This section is misleading and should be removed. The reason is the 
following:

The relying party must verify that the singleResponse is signed by a 
responder which is entitled to do so.

a) If the CA key has been compromised and if the response is signed by 
that CA key then the singleResponse will be discarded
when performing the certification path validation _whatever the content 
of the response may be_.

b) If the CA key which has issued the OCSP certificate has been 
compromised and if the response is signed by the key present
in the OCSP certificate then the singleResponse will be discarded when 
performing the certification path validation
_whatever the content of the response may be_.

Security must be provided using the validation of the certification 
path. Thus it does not matter what the OCSP responder states.

14.The text states on page 11:

*3.2Signed Response Acceptance Requirements*

**

*Prior to accepting a signed response as valid, OCSP clients SHALL*

*confirm that:*

**

*1. The certificate identified in a received response corresponds to*

*that which was identified in the corresponding request;*

**

*2. The signature on the response is valid;*

**

*3. The identity of the signer matches the intended recipient of the*

*request.*

**

*4. The signer is currently authorized to sign the response.*

**

*5. The time at which the status being indicated is known to be*

*correct (thisUpdate) is sufficiently recent.*

**

*6. When available, the time at or before which newer information will*

*be available about the status of the certificate (nextUpdate) is*

*greater than the current time.*

This section is misplaced since it uses terms from the ASN.1 syntax and 
the protocol description has not yet been made,
since it is the next section 4. Its text is not correct either.

This description does not take into account the fact that 
a*BasicOCSPResponse *may contain one or several *SingleResponses. *
In particular, the sentence"*The signer is currently authorized to sign 
the response*" is misleading because a signer
may be authorized to include some***SingleResponses *but not necessarily 
all of them.

The appropriate explanations should be done after the description of the 
response, when describing the processing of the response.

Delete that section.

15.On page 12, after the ASN.1 description, the only parameters which 
are described are:

*hashAlgorithm,**issuerNameHash, issuerKeyHash and serialNumber.*

**

This is insufficient.In order to cover the full list of parameters, the 
following text is proposed:

*requestorName is optional and MAY be used by the server for access *

*control and audit purposes.*

**

*requestList contains one or more single requests.*

**

*requestExtensions is OPTIONAL.Any specific extension is OPTIONAL.*

*The critical flag SHOULD NOT be set for any of them. Section 4.4 *

*suggests several useful extensions.Additional extensions MAY be *

*defined in additional RFCs.*

**

*reqCert contains the identifier of a target certificate.*

**

*issuerNameHash is the hash of the Issuer's distinguished name.The *

*hash shall be calculated over the DER encoding of the issuer's name *

*field in the certificate being checked. *

**

*issuerKeyHash is the hash of the Issuer's public key.The hash *

*shall be calculated over the value (excluding tag and length) of the *

*subject public key field in the issuer's certificate.The hash *

*algorithm used for both these hashes, is identified in *

*hashAlgorithm. *

**

*The primary reason to use the hash of the CA's public key in *

*addition to the hash of the CA's name, to identify the issuer, *

*is that it is possible that two CAs may choose to use the same *

*name (uniqueness in the Name is a recommendation that cannot be *

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

**

*serialNumber is the serial number of the certificate for which *

*status is being requested.*

**

*singleRequestExtensions is OPTIONAL.Any specific extension is *

*OPTIONAL.The critical flag SHOULD NOT be set for any of them. *

**

*The requestor MAY choose to sign the OCSP request.In that case, the*

*signature is computed over the tbsRequest structure.If the request*

*is signed, the requestor SHALL specify its name in the requestorName*

*field.Also, for signed requests, the requestor MAY include*

*certificates that help the OCSP responder verify the requestor's*

*signature in the certs field of Signature.*

16.Section 4.1.2 is called:"*Notes on the Request Syntax"*

The first paragraph has been moved after the description 
of*issuerKeyHash *and thus is no more needed.

The second paragraph has been moved after the description 
of*requestExtensions. *
However, the sentence
" *Unrecognized extensions MUST be ignored (unless they have the 
critical flag set and are not understood)*"
has been deleted since it applies to the OCSP responder and not to the 
OCSP client. Thus it is no more needed.

The third paragraph applies to signed requests. However, it should 
belong to a section dedicated on how clients should build OCPS requests,
which is currently missing. See the next comment.

This section should be deleted.

17.There should be a new section called: "*Requirements for OCSP clients". *

It is important first to re-advertise that the request may be about 
several certificates.
Thus it is important to describe the process for building a request, 
which is currently missing.

*An OCSP request allows getting in the same response the revocation *

*status of one or more certificates.In order to request the *

*status of one or more certificates in a single request, OCSP *

*clients SHALL follow the following rules :*

**

*For each candidate certificate, OCSP clients SHALL verify *

*whether there exists a locally defined rule for the certificate in *

*question which indicates the URI where the OCSP responder is *

*located.If this rule exists, it SHALL be followed. *

**

*Otherwise, OCSP clients SHALL determine whether the candidate *

*certificate contains an AIA extension with an accessMethod which *

*contains the id-ad-ocsp OID.If it is the case, the accessLocation *

*contains a uniformResourceIdentifier (URI) which indicates the *

*location of the OCSP server for that certificate. *

**

*Certificates that contain the same URI MAY be grouped in a single *

*request.*

**

*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.Certificates which are outside their validity *

*period SHOULD NOT be included in the request.*

*The requestor MAY choose to sign the OCSP request. In that case, the*

*signature is computed over the tbsRequest structure. If the request*

*is signed, the requestor SHALL specify its name in the requestorName*

*field. Also, for signed requests, the requestor MAY include*

*certificates that help the OCSP responder verify the requestor's*

*signature in the certs field of Signature.*

18.The text states on page 14:

*The responder MAY include certificates in the*

*certs field of BasicOCSPResponse that help the OCSP client verify the*

*responder's signature. If no certificates are included then certs*

*SHOULD be absent.*

While this sentence is true, it is not sufficient. In order to allow 
verifying every *SingleResponse*,
it is important to include the relevant certificates which are pertinent 
to every *SingleResponse.*

Proposed full text replacement:

The responder MAY include certificates in the certs field of

BasicOCSPResponse that help the OCSP client verify the responder's

signature.

*For every SingleResponse where the responder is not a CA, the *

*responder SHALL include the relevant OCSP certificate in the certs *

*field of BasicOCSPResponse in order to allow the OCSP client *

*verifying the responder was entitled to include that SingleResponse *

*in the signed BasicOCSPResponse.*

**

**If no certificates are included then certs SHOULD be absent.

19.Page 15. The ASN.1 syntax should be changed in order to be able to 
use the enumeration case 7 that is not used for CRLs.
This leads to the following change:

Current text:

**

*revocationReason[0]EXPLICIT CRLReason OPTIONAL }*

Proposed text change:

Current text:

**

*revocationReason [0]EXPLICIT RevocationReason OPTIONAL }*

*RevocationReason ::= ENUMERATED {*

*unspecified(0),*

*keyCompromise(1),*

*cACompromise(2),*

*affiliationChanged(3),*

*superseded(4),*

*cessationOfOperation(5),*

*certificateHold(6),*

*notIssuedOrIrregularlyIssued (7),*

*removeFromCRL(8),*

*privilegeWithdrawn(9),*

*aACompromise(10) }*

20.Page 15. After the ASN.1 syntax, there is no description of every 
parameter, neither on its use
(except a few words in section*4.2.2.1 Time *about*thisUpdate, 
nextUpdate and producedAt).*

**

Every parameter needs to be described and explained.

**

*responderID indicates either the name or the key from a CA, or the *

*name or the key from a OCSP Responder.*

**

*producedAt indicates the time at which this response was signed.*

**

*responses contains one or more single responses.*

**

*responseExtensions is OPTIONAL.Any specific extension is OPTIONAL.*

*The critical flag may or may not be set.*

**

*certID is usually a copy of the same field which was placed in the *

*request, but for OCSP responders which pre-produce signed responses *

*certID may be the identifier of a target certificate that was not *

*present in the request (see the end of section 4.2).*

**

*certStatus indicates the status of the certificate: either good, *

*revoked or unknown.*

**

*thisUpdate indicates the time at which the status being indicated *

*is known to be correct.*

**

*nextUpdate indicates the time at or before which newer information *

*will be available about the status of the certificate.If *

*nextUpdate is not set, the server is indicating that newer *

*revocation information is available all the time. *

**

*If nextUpdate is set, it often corresponds to the {thisUpdate, *

*nextUpdate} interval in CRLs.Responses whose nextUpdate value is *

*earlier than the local UTC time value SHOULD be considered *

*unreliable.Responses whose thisUpdate time is later than the local *

*UTC time SHOULD be considered unreliable.*

**

*singleExtensions is OPTIONAL.Any specific extension is OPTIONAL.*

*The critical flag SHOULD NOT be set for any of them.*

**

*revocationTime indicates the time at which the certificate was *

*revoked.*

**

*revocationReason is OPTIONAL. It includes all the cases that are *

*present in CRLReason used for CRLs and an additional case 7 which is*

*not used for CRLs.Case 7 is called notIssuedOrIrregularlyIssued. *

**

*- "notIssued" corresponds to the case where the certificate *

*serial number that was sent was erroneous and has not yet *

*been used by the CA at the time of the query,*

**

*- "irregularlyIssued" corresponds to the case where the *

*certificate serial number that was sent really exists in a *

*certificate that is correctly signed, but to its knowledge *

*the CA has not issued a certificate with such a serial *

*number. As an example, it may have been issued by the CA *

*because the RA was compromised. *

**

*    When a responder responds revoked to a status request for which it*

*    knows that the serial number has not been used by the CA or has*

*    been irregularly used irregularly to issue a certificate, then*

*    in RevokedInfo the responder MUST:*

*  *

*          - specify the revocationTime :   January 1, 1970,*

*           - provide the revocationReason: notIssuedOrIrregularlyIssued (7).*

*  *

*    and in SingleResponse the responder MUST NOT include the nextUpdate.*

**

*The response MUST include a SingleResponse for each certificate in*

*the request and SHOULD NOT include any additional SingleResponse*

*elements.However, there is one exception: *

**

*OCSP responders MAY pre-produce signed responses specifying the *

*status of certificates at a specified time.The time at which *

*the status was known to be correct SHALL be reflected in the *

*thisUpdate field of the response. *

**

*OCSP responders that pre-generate status responses MAY return *

*responses that include additional SingleResponse elements if*

*necessary to improve response pre-generation performance or cache*

*efficiency (as permitted in [RFC5019]).*

Since the text above provides all the explanations at the level of the 
ASN.1 parameters, the general text
from section*4.2.2.3 Basic Response *is no more need and should be 
deleted.**

**

21.0n page 16, there is a section *4.2.2.2***called*"**Authorized 
Responders"***

Section 4.2.2.2 states:

*(...)*

*This certificate MUST be issued directly by the CA that issued the*

*certificate in question.*

**

*The CA SHOULD use the same issuing key to issue a delegation*

*certificate as was used to sign the certificate being checked for*

*revocation. Systems relying on OCSP responses MUST recognize a*

*delegation certificate as being issued by the CA that issued the*

*certificate in question only if the delegation certificate and the*

*certificate being checked for revocation was signed by the same key.*

This section would need to reformatted to address CA requirements first 
and then OCSP responder requirements:

*(...)*

*This certificate MUST be issued directly by the CA that issued the*

*certificate in question.The CA SHOULD use the same issuing key to *

*issue a delegation certificate as was used to sign the certificate *

*being checked for revocation. *

**

*Systems relying on OCSP responses MUST _be able to_ recognize a *

*delegation certificate as being issued by the CA that issued the *

*certificate in question if the delegation certificate and *

*the certificate being checked _were_ signed by the same key.*

22.On page 17, the text states:

*They MUST reject the*

*response if the certificate required to validate the signature on the*

*response fails to meet at least one of the following criteria:*

This is ambiguous. It is inappropriate to have a negative statement 
like"*They MUST reject". *
The sentence should be turned in the positive form"*They SHALL accept"*

Since the ASN.1 syntax has now be described, it is possible to be more 
specific.

The first occurrence of the word "response" should be changed into 
"singleResponse", while the second occurrence
of the word "response" should be changed into "ResponseData"

Proposed text replacement:

*They SHALL accept a singleResponse if the certificate required to *

*validate the signature placed on the ResponseData meets one of the *

*following criteria:*

23.On page 17, the text states:

*3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage*

*extension and is issued by the CA that issued the certificate in*

*question as stated above."*

In order to be crystal clear, it is proposed to change the wording in 
the following way:

*3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage*

*extension and was signed by the CA using the same key that used *

*to issue the certificate in question.*

24.On page 17, the text states:

*This SHOULD be a non-critical extension. The value of the extension *

*SHALL be NULL.*

**

The ASN.1 syntax is missing. Add:

**

*NoCheck ::= NULL*

**

25.Remainder: On page 18, the general text from section***4.2.2.3 Basic 
Response***is no more needed and
should be deleted. See comment 20.

**

26.On page 24, text should be added to the Security consideration section:

*Different results when using OCSP and CRLs*

**

*OCSP clients or verifiers must build and verify a certification path *

*for each target certificate up to a trusted root.When an OCSP *

*Responder is using published CRLs, it must also build and verify a *

*certification path for the CRLs it uses up to a trusted root.*

**

*However, it should be realized that the root used by an OCSP *

*Responder to verified these CRLs is not necessarily the same as the *

*one that would be used by the OCSP client, if it were going to verify *

*the CRLs itself.Hence the revocation status may not be identical *

*in both cases.*

**

**

27.On page 24, text should be added to the Security consideration section:

**

*Denial of service attack using a flood of queries*

**

*A denial of service vulnerability is evident with respect to a flood *

*of queries.The production of a cryptographic signature *

*significantly affects response generation cycle time, thereby *

*exacerbating the situation. *

**

*The flood of queries may either come from a flood attack or from the *

*fact that there are too many certificates supported by the same OCSP *

*responder.In the later case, the number of queries can be *

*reduced by using a technique similar to the splitting of CRLs: *

**

*When a block of certificates have been issued with the same *

*accessLocation in the AIA extension field of these certificates, *

*then the accessLocation should be changed.In this way, a given *

*OCSP server will only be responsible for a block of certificates.*

**

**

28.On page 31, the text states.

*An alternative to this module that conforms to the 2002 version of *

*ASN.1 may be found in Section 4 of [RFC5912]. *

**

RFC 5912 omits to define the nocheck extension. Thus it is inappropriate 
to refer to RFC 5912.

The corrected module should be defined in this new draft.
A corrected module is providedin *draft-pinkas-rfc2560bis-03.*

29.Different topics are not covered by the document. These topics are 
important.
The following comments propose text to be placed in annexes. Three 
annexes are being proposed.

Note: The texts are extracted from*draft-pinkas-rfc2560bis-03.*

30.First annex being proposed. This annex is important, because key 
rollover is not addressed in the draft.

*KEY ROLLOVER*

**

*1. CA that directly supports an OCSP service*

**

*When a CA that directly supports an OCSP service performs a key *

*rollover:*

**

*- for certificates issued under the old key, the CA SHALL continue *

*to sign the revocation status of OCSP responses with that old key *

*at least until all these certificates are expired, and*

**

*- for certificates issued under the new key, the CA SHALL change the *

*accessLocation in the AIA extension field of these certificates *

*and sign the revocation status of OCSP responses with that new key *

*at least until all these certificates are expired.*

**

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

*2. CA that uses OCSP responders*

*When a CA that uses OCSP Responders performs a key rollover, then *

*it MUST either designate a new OCSP Responder or keep the current *

*OCSP Responder(s).*

**

*If the CA designates a new OCSP Responder, then it SHALL change the *

*accessLocation in the AIA extension field for the newly issued *

*certificates and issue an OCSP certificate to the new OCSP Responder *

*using its new key.*

**

*If the CA keeps the same OCSP Responder(s), then it SHALL continue *

*to use the same accessLocation(s) in the AIA extension field for the *

*newly issued certificates and issue an OCSP certificate to the *

*appropriate OCSP Responder(s) using its new key.*

**

*Note: The CA may need to continue issuing certificates to the OCSP *

*Responder(s) using the old CA key until all the certificates issued *

*under the CA' old key for which the OCSP Responder(s) are *

*authoritative have expired.*

**

*3. OCSP Responder key rollover*

**

*When an OCSP Responder performs a key rollover (asynchronously from *

*a CA key rollover), then each CA which has designated an OCSP *

*Responder SHALL issue a new certificate for that OCSP Responder and *

*for each of its issuing keys which meets the following property: *

**

*- the issuing key has been used to sign at least one certificate *

*which contains an AIA extension designating that OCSP Responder *

*and that certificate is not yet expired.*

**

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

31.Second annex being proposed. This annex is important because it 
describes the validation of an OCSP response in the past
which is of a particular importance when validating electronic signatures.

*Response processing by an OCSP client*

**

*OCSP responses can be verified at the current time by an OCSP client *

*when receiving a response, whereas old responses can be verified at *

*a time in the past by a verifier.The algorithm below addresses *

*both cases.*

**

*Prior to processing a basic response, OCSP clients MUST determine *

*the checking time, which may be either the current time or a time *

*in the past.*

**

*OCSP clients or verifiers SHALL check if the response contains *

*responseExtensions. If such an extension is found and is recognized, *

*it MUST be processed.If such a critical extension is found and *

*is not recognized, the whole OCSP response MUST be considered as *

*invalid.*

**

*If the checking time is the current time, and if a nonce extension *

*has been used in the request and is recognized (see section 4.5.1), *

*OCSP clients MUST check whether the same nonce is present in the *

*response.If the nonce is not present or is different, then the *

*OCSP response MUST be discarded.*

**

*Only the single response(s) which are/is of interest SHALL be *

*checked.*

**

*STEP 1*

**

*OCSP clients or verifiers SHALL verify that the certificate *

*identified in a single response is of interest.Otherwise, proceed *

*to step 3.*

**

*If the certificate status included in a single certificate response *

*is "unknown", then the revocation status of that certificate is *

*"unknown", and proceed to step 3.*

**

*If the certificate status from the single certificate response is *

*either "good" or "revoked", OCSP clients or verifiers SHALL check *

*that the checking time is within the validity period of the target *

*certificate.If it is not the case, then the revocation status of *

*that certificate is "unknown" and proceed to step 3.*

**

*If the checking time is the current time, and if a nonce has been *

*used in the request, then proceed to step 2.*

**

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

**

*Note: the notion of "close enough" is a local matter.It can be set *

*to a few minutes to allow for small UTC time differences *

*between the client and the server or to a few hours in case *

*the server is producing pre-computed responses.*

**

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

**

*In addition, if the nextUpdate field is present, OCSP clients MUST *

*check that the time which is indicated is greater than the checking *

*time, otherwise the single response MUST be discarded.*

**

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

**

*STEP 2*

**

*OCSP clients or verifiers MUST build and verify a certification path *

*for that certificate up to a trusted root, so that they have the *

*knowledge of the CA public key value that was used to sign the *

*target certificate.The revocation status of each certificate of *

*that certification path (except the target certificate) SHALL be *

*checked.*

**

*If no path can be built or if one of the certificates of the path is *

*revoked, then the revocation status of that certificate is "unknown", *

*and proceed to step 3. *

**

*If the certification path (except the target certificate) is valid, *

*then two cases need to be considered:*

**

*a) If the responderID matches with the name or the key from the CA *

*which has issued the target certificate, then check whether the *

*OCSP response is signed by the same key that was used to sign *

*the target certificate.*

**

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

**

*b) If the responderID does not match with the name or the key from *

*the CA which has issued the target certificate, then it indicates *

*the name or the key from an OCSP Responder.Check whether there *

*exists a local rule which applies to this target certificate to *

*verify that the signature of the BasicOCSPResponse is valid for *

*that single response.If this rule exists, it SHALL be followed. *

**

*Otherwise check whether there is an OCSP certificate (i.e. which *

*has both the ocspSigning OID in the extended key usage extension *

*and the digitalSignature bit in the key usage extension) signed *

*by the same key that was used to sign the target certificate. *

*This certificate MUST be present in the certs field from the *

*BasicOCSPResponse. *

**

*If such certificate is not found or is invalid, then the *

*revocation status of that certificate is "unknown" and *

*proceed to step 3.*

**

*If such certificate exists and if the checking time is *

*within the validity period of this certificate, then it MUST *

*be verified whether the OCSP response can be verified using *

*the public key that is present in the OCSP Certificate. *

**

*If it is not the case, then the revocation status of that *

*certificate is "unknown" and proceed to step 3.*

**

*If it is the case, then it MUST be verified that the OCSP *

*Certificate has not been revoked.*

**

*If one of these conditions is met, then the status for the target *

*certificate as indicated in the certStatus field is accepted, *

*otherwise the revocation status is "unknown".*

**

*STEP 3*

**

*If there exists another single certificate status response for a *

*target certificate that is of interest, then proceed to step 1. *

*Otherwise the basic response is now processed.*

32.Third annex being proposed. This annex is important because it 
provides guidance on how to build an OCSP responder in the three cases.
Many text portions are similar, but three full texts are provided in 
order to provide a better clarity for each of the three cases.

*1. Request processing by OCSP servers*

**

*The behavior of an OCSP server will be different whether the OCSP *

*server is a CA acting as an OCSP responder, is an OCSP Responder *

*which received a delegation from one or more CAs, or is a locally *

*trusted Responder.*

**

*1.1. Processing by a CA acting as an OCSP responder*

**

*The OCSP responder SHALL maintain a list of entries. Each entry *

*SHALL contain:*

**

*- the URI associated to the OCSP responder, from which the OCSP *

*requests are received, *

**

*- the DN from a CA,*

**

*- an issuing public key from a CA,*

**

*- 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, *

*and*

**

*- the method used to gain access and sign with the private key *

*corresponding to the issuing public key.*

**

*For a given URI value, the OCSP responder SHALL only use one CA *

*key pair value. *

**

*When it receives an OCSP request on that URI, the OCSP responder *

*SHALL handle exceptions according to section 2.3. *

**

*If the OCSP request contains the name of a requestor, the OCSP *

*responder SHALL verify whether there exists a locally defined rule *

*which regulates access control.If this rule exists, it SHALL be *

*followed.*

**

*Then, 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 are eligible to a *

*locally defined rule which indicates that the OCSP responder is *

*responsible to provide the revocation status of that target *

*certificate.If this rule exists, it SHALL be followed.*

**

*Otherwise, the OCSP responder SHALL determine whether it is *

*responsible to provide the revocation status of that target *

*certificate according to the following rule.*

**

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

**

*When there is a match, then the OCSP responder SHALL use the serial *

*number of the target certificate that is present in the request and *

*determine the revocation status of that certificate according to *

*the method(s) defined in the entry. *

**

*When the revocation status is provided by the server using a real *

*time access to a database of revocation statuses of issued *

*certificates, then the thisUpdate field SHALL be present in the*

*SingleResponse response whereas the nextUpdate field SHALL be *

*missing. *

**

*Otherwise, both the thisUpdate and the nextUpdate fields SHALL be *

*present in the SingleResponse. *

**

*The time at which this response will be signed MUST be indicated in *

*the producedAt field from the SingleResponse.*

**

*If a singleRequestExtensions is present in the request it MUST be *

*processed.*

**

*If there is another target certificate present in the request, it *

*SHALL be processed in the same way.*

**

*If a requestExtensions is present in the request it MUST be *

*processed.*

**

*The OCSP response MUST be signed using the CA issuing private key.*

**

**

*1.2. Processing by an OCSP Responder*

**

*For each CA from which the OCSP Responder has received a delegation, *

*the OCSP Responder SHALL maintain a list of entries. *

**

*Each entry SHALL contain:*

**

*- the URI associated to this OCSP Responder, from which the OCSP *

*requests are received, *

**

*- the DN from a CA,*

**

*- an issuing public key from a CA,*

**

*- 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,*

**

*- an OCSP certificate, *

**

*- the OCSP public key contained in that OCSP certificate, and*

**

*- the method used to gain access and sign with the OCSP private *

*key corresponding to that OCSP certificate.*

**

*For a given URI value, the OCSP Responder SHALL only use one OCSP *

*key pair value.Therefore there cannot be two entries with the *

*same URI value and a different OCSP public key value.*

**

*NOTE: a BasicOCSPResponse can only be signed using a single private *

*key. *

**

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

**

*When it receives an OCSP request, the OCSP responder SHALL handle *

*exceptions according to section 2.3. *

**

*If the OCSP request contains the name of a requestor, the OCSP *

*responder SHALL verify whether there exists a locally defined rule *

*which regulates access control.If this rule exists, it SHALL be *

*followed.*

**

*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 OCSP request match with those *

*from an entry.*

**

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

**

*When there is a match, the OCSP Responder SHALL use the serial *

*number of the target certificate this is present in the OCSP *

*request to determine the revocation status of that certificate *

*according to the method(s) indicated in the entry. *

**

*When the revocation status is provided by the server using a real *

*time access to a database of revocation statuses of issued *

*certificates, then the thisUpdate field SHALL be present in the*

*SingleResponse response whereas the nextUpdate field SHALL be *

*missing. *

**

*Otherwise, both the thisUpdate and the nextUpdate fields SHALL be *

*present in the SingleResponse. *

**

*The time at which this response will be signed MUST be indicated in *

*the producedAt field from the SingleResponse.*

**

*If a singleRequestExtensions is present in the request it MUST be *

*processed.*

**

*If there is another target certificate present in the request, it *

*SHALL be processed in the same way.*

**

*If a requestExtensions is present in the request it SHALL be *

*processed.*

**

*The OCSP response MUST be signed using the OCSP private key.*

**

*Unless there is a local rule which states differently, for every *

*target certificate which matches both with the hash of a CA DN and an *

*issuing public key from an entry, the OCSP certificate of that entry *

*SHALL be placed in the certs field.*

**

*It may happen, that none of the target certificates from the OCSP*

*request matches both with the hash of a CA DN and an issuing public *

*key from an entry.In that case and unless a local rule states *

*differently, the certs field from the BasicOCSPResponse SHOULD be *

*kept empty (to limit the disclose of the names of the CAs from which *

*the OCSP Responder received a delegation from).*

**

*1.3. Processing by a locally trusted Responder*

**

*For each CA for which the locally trusted Responder is *

*authoritative, the OCSP Responder SHALL maintain a list of entries. *

**

*Each entry SHALL contain:*

**

*- the URI associated to this OCSP Responder, from which the OCSP *

*requests are received, *

**

*- the DN from a CA,*

**

*- an issuing public key from a CA,*

**

*- 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,*

**

*- the method used to gain access to the private key in order to *

*sign the OCSP response. *

**

*For a given URI value, the OCSP Responder SHALL only use one private *

*key.Therefore there cannot be two entries with the same URI value *

*and a different method to gain access to the appropriate private key.*

**

*NOTE: a BasicOCSPResponse can only be signed using a single private *

*key. *

**

*When it receives an OCSP request, the OCSP responder SHALL handle *

*exceptions according to section 2.3. *

**

*If the OCSP request contains the name of a requestor, the OCSP *

*responder SHALL verify whether there exists a locally defined rule *

*which regulates access control.If this rule exists, it SHALL be *

*followed.*

**

*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 OCSP request match with those *

*from an entry.*

**

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

**

*When there is a match, the OCSP Responder SHALL use the serial *

*number of the target certificate this is present in the OCSP *

*request to determine the revocation status of that certificate *

*according to the method(s) indicated in the entry. *

**

*When the revocation status is provided by the server using a real *

*time access to a database of revocation statuses of issued *

*certificates, then the thisUpdate field SHALL be present in the*

*SingleResponse response whereas the nextUpdate field SHALL be *

*missing. *

**

*Otherwise, both the thisUpdate and the nextUpdate fields SHALL be *

*present in the SingleResponse. *

**

*The time at which this response will be signed MUST be indicated in *

*the producedAt field from the SingleResponse.*

**

*If a singleRequestExtensions is present in the request it MUST be *

*processed.*

**

*If there is another target certificate present in the request, it *

*SHALL be processed in the same way.*

**

*If a requestExtensions is present in the request it SHALL be *

*processed.*

**

*The OCSP response MUST be signed using the OCSP private key.*

**

*The certs field may contain no, one or several OCSP certificates *

*according to local rules followed by the locally trusted Responder.*

End of comments

Denis

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 20 Jan 2013 17:39:01 +0100

Denis,

I will go trough the rest of your comments later, but I just wanted to
respond quicklyto the first.

This is an issue where I have thoroughly discussed the matter wth Sean
Turner.
He has approved the current way of including the past editors.

I have received permission and support from all of those who are still alive
to have them as co-editors.
I wil not further comment on your issue 1, but will leave it to Sean and
Steve to espond to this.

I'm sorry if you feel that you have not got enough special treatment. I have
responded to you to the best of m abilities and capacity.

/Stefan

From:  Denis Pinkas <[email-masked]>
Date:  Sunday, January 20, 2013 5:12 PM
To:  Stefan Santesson <[email-masked]>, Stephen Kent <[email-masked]>
Cc:  pkix <[email-masked]>
Subject:  Re: [pkix] Review of 2560-bis draft . Answer to WGLC

>     
>    
> 
> Please find 32 comments on draft-ietf-pkix-rc2560bis
>  
>  
>  
> 1. The document states:
>  
>  
>  
>    ³This Internet-Draft is submitted to IETF in full conformance with the
>  
>    provisions of BC 78 and BCP 79.²
>  
>  
>  
> BCP 78is RFC 3978.
>  
>  
>  
> However, this draft, if transformed into an RFC, does not met the
> RFC 398 states:
> ³4.2.  Granting of Rights and Permissions
>  
>  
>  
>    By submission of an RFC Editor Contribution, each person actually
>  
>    submiting the RFC Editor Contribution, and each named co-
>  
>    Contributor, is deemed to agree to the follwing terms and
>  
>    conditions, and to grat the following rights, on his or her own
>  
>    behalf and on behalf of the oganization the Contributor represents
>  
>    or is sponsored by (if any) wen submitting the RFC Editor
>  
>    Contribution.
>  
>  
>  
> (Š)
>  
> 
>  
> 7.1.  Rights Granted in IETF Contributions
>  
>  
>  
>    The IETF/ISOC must obtain theright to publish an IETF Contribution
>  
>    as an RFC or an Internet-Draftfrom the Contributors.
>  
>  
>  
> (Š)
>  
>  
>  
> 7.2.  Rights to use ontributed Material
>  
>  
>  
>    Because, under the laws of most countries and applicable
>  
>    interational treaties, copyright rights come into existence whenever
>  
>    a wrk of authorship is created (but see Section 8 below regarding
>  
>    public domain documents), and IETF annot make use of IETF
>  
>    Contributions if it does not have suffcient rights with respect to
>  
>    these copyright rights, it is impotant that the IETF receive
>  
>    assurances from all Contibutors that they have the authority to
>  
>    grant the IETF the rights that the claim to grant.  Without this
>  
>    assurance, IETF and its partcipants would run a greater risk of
>  
>    liability to the owners of these rights.
>  
>  
>  
>    To this end, IETF asks Contributors to gie the assurances in Section
>     3.4 above.²
>  
>  
>  
> Some of the contributors mentioned for thi document have not sent any message
> reated to OCSP for years, in particular:
>  Michael Myers, Rich Ankney, Slava Galperin,and Carlisle Adams.
>  
>  
>  
> The RFC editor will send an email to every author. Unfortunately, he will
> never receive an email from ich Ankney because
>  he has no email address in the ³other world².
>  
>  
>  
> http://www.rfc-editororg/pubprocess.html#Authors states:
>  
>  
>  
> ³Authors' Final Review (AUTH48 State)
>  
> Once an RFC has been edited ad is ready for publication, the author(s) are
> given "48 hours" (in practice, this often stretches over weeks)
>  to look over their document for errors, editorial and otherwise. e DO NOT
> make changes to RFCs once they have been published, so
>  please look over your document carefully. Upon approval by all authors, the
> RFC will be published.
>  
> 
>  
>  
> 
> The AUTH48 notification messag sent to authors asks that they review the
> entire documen, paying particular attention to:
>  
> 
>  
>  
> If an author is no longer available, there are several options (as listed in
> the FAQ <http://www.rfc-editor.org/rfcfaq.html#missingauthor>
> http://www.rfc-editor.org/rfcfaq.html#missingauthor).
>  Indefinite delays are not allowed, but when there is a choice, the RFC Editor
> would in general prefer to publish it right than to publish it early.²
>  
> 
>  
>  
> 
> " One of the authors is no longer available; how do we move forward?
>  
>  
>  
> 1.       The author can be removed as an author and moved to the
> 2.       The author can be removed as an author and moved to a Contributors
> section. 
>  
> 3.       An AD can approve the document in place of the unavailable author.
> <http://www.ietf.org/iesg/statement/auth48.html> .)
>  
>  
>  
>  so the other authors are not feel comfortable removing the individual from
> the author list².
>  
>  
>  
> ³The IESG has decided that as of now, any IESG-approved drafts that enter the
> AUTH48 state, where the RFC Editor
>  waits for final text approval from all listed authors, may be released on the
> responsible AD's authority if any authors
>  have not responded after a reasonable time, typically two weeks².
>  
> 
>  
>  
> It looks more reasonable to anticipate the problem and to apply the path
> numbered 1, hence to move the names
>  of the original contributors to RFC 2560 into the Acknowledgments section.
>  
>  
>  
> Obviously, the consequence is that there will be far less people contributing
> to this draft: 
>  
>  
> 
>  Stefan seems to be the single author/contributor, Š which is what he wanted :
>  
>   - he did not answered positively when, last summer, I sent him a private
> email proposing to share the editing of the draft.
>    - after a meeting in London, he did not either responded at two proposals
> for a phone call.
>  
>  
>  
> Most of the following comments take advantage of draft-pinkas-rfc2560bis-03
> which was built after a detailed examination
>  of the defects of RFC 2560. The writing of this draft took me about 40 hours
> of work. 
>  
>  
>  
>  
>  
> 2. The current text from section 2 states:
>  
>  
>  
> 2.  Protocol Overview
>  
>  
>  
>    may be necessary to obtain timely information regarding the
>  
>    providing more timely revocation information than is possible with
>  
> This text is misleading because readers may think that OCPS necessarily
> provides ³timely information².
>  
>  
>  
>    The Online Certificate Status Protocol (OCSP) is a client-server
>  
>    protocol which enables applications to obtain the revocation status
>  
>    of one or more certificates either "good", "revoked", or "unknown".
>  
>  
>  
>    The revocation status may be provided by the server either using a
>  
>    real time access to a database of issued certificates, or using a
>  
>    batch access to a database of issued certificates, or using a
>  
>    real time access to a database of revocation statuses of issued
>  
>    certificates, or using a batch access to a database of revocation
>  
>    statuses of issued certificates, or using CRLs, or using a
>  
>    combination of base CRLs and delta CRLs.
>  
>  
>  
>    In the first case, it is possible to obtain timely revocation status
>  
>    information, whereas in the other cases, the freshness of the
>  
>    revocation status is not better than the mechanisms it is based on.
>  
>  
>  
>  
>  
> 3. The current text from section 2 states:
>  
>  
>  
>    Suspends acceptance of the certificate in question until the
>  
>    status request to an OCSP responder for one or more certificates
>  
>    issued by the same CA or for one or more certificates issued by
>  
>    different CAs and then suspends acceptance of the certificate(s)
>  
>    OCSP may also provide additional status information using
>  
>    extensions. 
>  
>  
>  
>  
>  
> 4. Page 6. Editorial. Punctuation and a CR/LF are missing.
>  
>  
>  
> The text states:
>  
>  
>  
>    3. the request contains the information needed by the responder If
>  
>       any one of the prior conditions are not met, the OCSP responder
>  
>       produces an error message; otherwise, it returns a definitive
>  
>       response.
>  
>  
>  
> It should state:
>  
>  
>  
>    4. the request contains the information needed by the responder.
>  
>  
>  
>       If any one of the prior conditions are not met, the OCSP responder
>  
>       produces an error message; otherwise, it returns a definitive
>  
>       response.
>  
>  
>  
>  
>  
> 5. On page 7, the text states:
>  
>  
>  
>    All definitive response messages SHALL be digitally signed. The key
>  
>    used to sign the response MUST belong to one of the following:
>  
>  
>  
>    -  the CA who issued the certificate in question
>  
>    -  a Trusted Responder whose public key is trusted by the requester
>  
>    -  a CA Designated Responder (Authorized Responder) who holds a
>  
>       specially marked certificate issued directly by the CA, indicating
>  
>       that the responder may issue OCSP responses for that CA.
>  
>  
>  
> Delegation is addressed in at least three different places, but with different
> terms and conditions.
>  If some one picks a sentence in one paragraph rather than another, it will
> lead to a different conclusion.
> On page 10, the current text states in section 2.6 OCSP Signature Authority
> Delegation states:
>  
>  
>  
>    The key that signs a certificate's status information need not be the
>  
>    same key that signed the certificate. A certificate's issuer
>  
>    explicitly delegates OCSP signing authority by issuing a certificate
>  
>    containing a unique value for extendedKeyUsage in the OCSP signer's
>  
>    certificate. This certificate MUST be issued directly to the
>  
>    responder by the cognizant CA.
>  
>  
>  
> On page 16, there is a section 4.2.2.2 called ³Authorized Responders² dealing
> with the same topic.
>  
>  
>  
> Section 4.2.2.2 states:
>  
>  
>  
>    The key that signs a certificate's status information need not be the
>  
>    same key that signed the certificate. It is necessary however to
>  
>    ensure that the entity signing this information is authorized to do
>  
>    so.  Therefore, a certificate's issuer MAY either sign the OCSP
>  
>    responses itself or it MAY explicitly designate this authority to
>  
>    another entity.  OCSP signing delegation SHALL be designated by the
>  
>    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
>  
>    extension included in the OCSP response signer's certificate.  This
>  
>    certificate MUST be issued directly by the CA that issued the
>  
>    certificate in question.
>  
>  
>  
>    The CA SHOULD use the same issuing key to issue a delegation
>  
>    certificate as was used to sign the certificate being checked for
>  
>    revocation. Systems relying on OCSP responses MUST recognize a
>  
>    delegation certificate as being issued by the CA that issued the
>  
>    certificate in question only if the delegation certificate and the
>  
>    certificate being checked for revocation was signed by the same key.
>  
>  
>  
> The last sentence above in yellow is the key sentence that is missing in the
> two other sections.
>  
>  
>  
> Most implementations only support the case where the OCSP Responder receives
> an OCSP certificate that is signed by the same key
> that was used to sign the target certificate. They do not support the case
> where the OCSP Responder receives an OCSP certificate
> It is inappropriate to have three sections dealing with the same topic with a
> slightly different meaning.
>  
>  
>  
>    -  a CA Designated Responder (Authorized Responder) who holds a
>  
>       specially marked certificate issued directly by the CA, indicating
>  
>       that the responder may issue OCSP responses for that CA.
>  
>  
>  
> it is proposed to add ³(see section 4.2.2.2 for further details)², so that the
> reader knows that more details are provided later on.
>  
>  
>  
> Then we do not need two sections to address delegation which start with the
> same sentence: 
>  
>  
> 
>  ³The key that signs a certificate's status information need not be the same
> key that signed the certificate².
>  
>  
>  
>    A definitive response message is composed of:
>  
>  
>  
>    -  version of the response syntax
>  
>    -  name of the responder
>  
>    -  responses for each of the certificates in a request
>  
>    -  optional extensions
>  
>    -  signature algorithm OID
>  
>    -  signature computed across hash of the response
>  
>  
>  
> This description does not fit with the ASN.1 syntax which is detailed later
> on, and in particular:
>  
>  
>  
>    ResponseData ::= SEQUENCE {
>  
>       version              [0] EXPLICIT Version DEFAULT v1,
>  
>       responderID              ResponderID,
>  
>       producedAt               GeneralizedTime,
>  
>       responses                SEQUENCE OF SingleResponse,
>  
>       responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
>  
>  
>  
>    A definitive response message is composed of:
>  
>  
>  
>    - a response status and if there is no error, the following:
>  
>    - the version of the response syntax,
>  
>    - an identifier of the OCSP server,
>  
>    - the time at which the response was produced,
>  
>    - single responses for each of the target certificates,
>  
>    - optional extensions,
>  
>    - the signature algorithm OID,
>  
>    - the signature computed across hash of the response, and
>  
>    - optional certificates.
>  
>  
>  
>  
>  
> 7. The text states on page 7:
>  
>  
>  
>    The response for each of the certificates in a request consists of
>  
>  
>  
>    -  target certificate identifier
>  
>    -  certificate status value
>  
>    -  response validity interval
>  
>    -  optional extensions
>  
>  
>  
> However, there are no explanations for the purpose of these parameters and how
> they should be processed.
>  
> There are also no explanations on how to process a single response and how to
> verify that it is its presence within the signed structure
>  is valid or not valid. This is a major deficiency of the current description
> of RC 2560 where there is no explanation on how to validate
>  a single response.
>  
>  
>  
>    The purpose of the identifier of the OCSP server is to allow OCSP
>  
>    clients to find whether the definitive response was signed by a CA
>  
>    or by an OCSP Responder.
>  
>  
>  
>    The identifier of the OCSP server SHOULD either be the name or the
>  
>    key from a CA, or the name or the key from a OCSP Responder.
>  
>  
>  
>    Unless there exist local rules (which are outside the scope of this
>  
>    document) for verifying that a single response is correctly signed,
>  
>    the following applies:
>  
>  
>  
>    When the identifier matches with the name of the CA which has issued
>  
>    the target certificate or corresponds to the key used to issue the
>  
>    target certificate, then a single response is correctly signed
>  
>    only if the digital signature of the OCSP response is valid using the
>  
>    key used to sign the target certificate.
>  
>  
>  
>    When the identifier does not match with the name of the CA which has
>  
>    issued the target certificate or does not correspond to the key used
>  
>    to issue the target certificate, then an single response is correctly
>  
>    signed only if :
>  
>  
>  
>          (a) there exists in the response an OCSP certificate issued by
>  
>              the CA which has issued the target certificate which is
>  
>              signed by the same key as the one used to issue the
>  
>              target certificate, and
>  
>  
>  
>          (b) the digital signature of the OCSP response is valid using
>  
>              the subjectPublicKey contained in this OCSP certificate.
>  
>  
>  
>  
>  
> 8. The text states on page 7:
>  
>  
>  
>    (either permanently or temporarily (on hold)). This state MAY also be
>  
>    never been issued during the history of the associated CA using any
>  
>    current or previous issuing key.
>  
>  
>  
> The text is ambiguous because there are two embedded parenthesis and it is
> unclear whether the inner parenthesis means ³i.e² or ³e.g².
>  the case of a temporary revocation in the context of an OCSP response (but
> only in the context of CRLs), we are able to add another case
> The above sentence using the terms ³never been issued during the history of
> the associated CA ³does not capture the fact
>  that it could be issued in the future, hence why using ³not yet been used²
> would be more appropriate.
>  
>  
>  
> Finally, it would have been more logical to use ³unknown². So it is important
> to add a note to explain why we have chosen that case for ³legacy clients²,
>    The "revoked" state indicates that the certificate has been revoked,
>  
>    either permanently or temporarily.
>  
>  
>  
>    placed on hold (i.e. the revocation reason is certificateHold) or
>  
>    certificate has not yet been used by the CA to issue a certificate
>  
>    (i.e. the revocation reason is notIssuedOrIrregularlyIssued).
>  
>  
>  
> NOTE: The "revoked" state is used rather than the ³unknown² state, to
>  
>       make sure that relying parties that were conformant to RFC 2560
>  
>       will not use CRLs as a fall back mechanism.
>  
>  
>  
>  
>  
> 9. The text states on page 8:
>  
>  
>  
>    When a responder responds revoked to a status request for a non-
>  
>    issued certificate, the responder MUST also;
>  
>  
>  
>     - include the extended revoked definition response extension
>  
>       (section 4.8), indicating that the OCSP responder supports the
>  
>       extended definition of revoked state to also cover non-issued
>  
>       certificates,
>  
>  
>  
>     - provide the revocation reason certificateHold (6), and;
>  
>  
>  
>     - specify the revocation date January 1, 1970.
>  
>  
>  
> As already explained on the PKIX list, using the revocation reason
> certificateHold is not appropriate
> The extended revoked definition response extension is a means to signal that
> it not a true certificate hold but a ³not issued certificate².
> Some applications which handle non repudiation enter a waiting state when the
> revocation reason certificateHold is used thus
> ³a status request for a non-issued certificate²
>  
>  
>  
> ³a status request for a serial number which has not been used by the CA or
> used irregularly to issue a certificate².
>  
>  
>  
> Placing the ASN.1 description at such a place in the document is inappropriate
> since the ASN.1 structures have not yet been described.
> This text should be deleted from this section and the appropriate text should
> be added when the parameters of the response are described.
>  
>  
>  
> In addition, section 4.4.8  Extended Revoked Definition should be deleted.
>  
>  
>  
>  
>  
> 10. The text states on page 8:
>  
>  
>  
> 2.4  Semantics of thisUpdate, nextUpdate and producedAt
>  
>  
>  
> This section is misplaced. At this time of reading, the reader does not know
> that thisUpdate, nextUpdate and producedAt are values
>  The current ASN.1 syntax is very badly described. One would expect that after
> every ASN.1 structure description every parameter is described.
> The text from this section is not aligned with the text that is present in
> section 4.2.2.1. 
>  
>  
>  
>    If nextUpdate is not set, the responder is indicating that newer
>  
>    revocation information is available all the time.
>  
>  
>  
>    Responses where the nextUpdate value is not set are equivalent
>  
>    to a CRL with no time for nextUpdate (see Section 2.4).
>  
>  
>  
> It is not appropriate to have two different descriptions in two different
> places.
>  
>  
>  
> 11. Section 2.5 is also misplaced. They use values from the ASN.1 syntax which
> has not yet been described.
> 12. Remainder: Section 2.6 should be deleted (see comment number 5).
>  
>  
>  
>  
>  
> 13. Section 2.7 states:
>  
>  
>  
> 2.7  CA Key Compromise
>  
>  
>  
>    If an OCSP responder knows that a particular CA's private key has
>  
>    been compromised, it MAY return the revoked state for all
>  
>    certificates issued by that CA.
>  
>  
>  
> This section is misleading and should be removed. The reason is the following:
>  
>  
>  
> The relying party must verify that the singleResponse is signed by a responder
> which is entitled to do so.
>  
>  
>  
> a) If the CA key has been compromised and if the response is signed by that CA
> key then the singleResponse will be discarded
>  when performing the certification path validation whatever the content of the
> response may be.
>  
>  
>  
> b) If the CA key which has issued the OCSP certificate has been compromised
> and if the response is signed by the key present
>  whatever the content of the response may be.
>  
>  
>  
>  
>  
> Security must be provided using the validation of the certification path. Thus
> it does not matter what the OCSP responder states.
>  
>  
>  
>  
>  
> 14. The text states on page 11:
>  
>  
>  
> 3.2  Signed Response Acceptance Requirements
>  
>  
>  
>    Prior to accepting a signed response as valid, OCSP clients SHALL
>  
>    confirm that:
>  
>  
>  
>    1. The certificate identified in a received response corresponds to
>  
>       that which was identified in the corresponding request;
>  
>  
>  
>    2. The signature on the response is valid;
>  
>  
>  
>    3. The identity of the signer matches the intended recipient of the
>  
>       request.
>  
>  
>  
>    4. The signer is currently authorized to sign the response.
>  
>  
>  
>    5. The time at which the status being indicated is known to be
>  
>       correct (thisUpdate) is sufficiently recent.
>  
>  
>  
>    6. When available, the time at or before which newer information will
>  
>       be available about the status of the certificate (nextUpdate) is
>  
>       greater than the current time.
>  
>  
>  
> This section is misplaced since it uses terms from the ASN.1 syntax and the
> protocol description has not yet been made,
> This description does not take into account the fact that a BasicOCSPResponse
> may contain one or several SingleResponses.
>  In particular, the sentence ³The signer is currently authorized to sign the
> response² is misleading because a signer
>  may be authorized to include some SingleResponses but not necessarily all of
> them. 
>  
>  
>  
> 15. On page 12, after the ASN.1 description, the only parameters which are
> described are: 
>  
> hashAlgorithm, issuerNameHash, issuerKeyHash and serialNumber.
>  
>  
>  
> This is insufficient.  In order to cover the full list of parameters, the
>    requestorName is optional and MAY be used by the server for access
>  
>    control and audit purposes.
>  
>  
>  
>    requestList contains one or more single requests.
>  
>  
>  
>    requestExtensions is OPTIONAL.  Any specific extension is OPTIONAL.
>  
>    The critical flag SHOULD NOT be set for any of them. Section 4.4
>  
>    suggests several useful extensions.  Additional extensions MAY be
>  
>    defined in additional RFCs.
>  
>  
>  
>    reqCert contains the identifier of a target certificate.
>  
>  
>  
>    issuerNameHash is the hash of the Issuer's distinguished name.  The
>  
>    hash shall be calculated over the DER encoding of the issuer's name
>  
>    field in the certificate being checked.
>  
>  
>  
>    issuerKeyHash is the hash of the Issuer's public key.  The hash
>  
>    shall be calculated over the value (excluding tag and length) of the
>  
>    subject public key field in the issuer's certificate.  The hash
>  
>    algorithm used for both these hashes, is identified in
>  
>    hashAlgorithm.
>  
>  
>  
>       The primary reason to use the hash of the CA's public key in
>  
>       addition to the hash of the CA's name, to identify the issuer,
>  
>       is that it is possible that two CAs may choose to use the same
>  
>       name (uniqueness in the Name is a recommendation that cannot be
>  
>       enforced). 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.
>  
>  
>  
>    serialNumber is the serial number of the certificate for which
>  
>    status is being requested.
>  
>  
>  
>    singleRequestExtensions is OPTIONAL.  Any specific extension is
>  
>    OPTIONAL.  The critical flag SHOULD NOT be set for any of them.
>  
>  
>  
>    The requestor MAY choose to sign the OCSP request.  In that case, the
>  
>    signature is computed over the tbsRequest structure.  If the request
>  
>    is signed, the requestor SHALL specify its name in the requestorName
>  
>    field.  Also, for signed requests, the requestor MAY include
>  
>    certificates that help the OCSP responder verify the requestor's
>  
>    signature in the certs field of Signature.
>  
>  
>  
>  
>  
> 16. Section 4.1.2 is called: ³Notes on the Request Syntax²
>  
>  
>  
> The first paragraph has been moved after the description of issuerKeyHash and
> thus is no more needed.
>  
>  
>  
> The second paragraph has been moved after the description of
> requestExtensions.
>  However, the sentence
>  ³ Unrecognized extensions MUST be ignored (unless they have the critical flag
> set and are not understood)²
>  has been deleted since it applies to the OCSP responder and not to the OCSP
> client. Thus it is no more needed.
>  
>  
>  
> The third paragraph applies to signed requests. However, it should belong to a
> section dedicated on how clients should build OCPS requests,
> 17. There should be a new section called: ³Requirements for OCSP clients².
>  
>  
>  
> It is important first to re-advertise that the request may be about several
> certificates. 
>  Thus it is important to describe the process for building a request, which is
> currently missing.
>  
>  
>  
>    An OCSP request allows getting in the same response the revocation
>  
>    status of one or more certificates.  In order to request the
>  
>    status of one or more certificates in a single request, OCSP
>  
>    clients SHALL follow the following rules :
>  
>  
>  
>    For each candidate certificate, OCSP clients SHALL verify
>  
>    whether there exists a locally defined rule for the certificate in
>  
>    question which indicates the URI where the OCSP responder is
>  
>    located.  If this rule exists, it SHALL be followed.
>  
>  
>  
>    Otherwise, OCSP clients SHALL determine whether the candidate
>  
>    certificate contains an AIA extension with an accessMethod which
>  
>    contains the id-ad-ocsp OID.  If it is the case, the accessLocation
>  
>    contains a uniformResourceIdentifier (URI) which indicates the
>  
>    location of the OCSP server for that certificate.
>  
>  
>  
>    Certificates that contain the same URI MAY be grouped in a single
>  
>    request.
>  
>  
>  
> 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.  Certificates which are outside their validity
>  
>        period SHOULD NOT be included in the request.
>  
>  
>  
>    The requestor MAY choose to sign the OCSP request. In that case, the
>  
>    signature is computed over the tbsRequest structure. If the request
>  
>    is signed, the requestor SHALL specify its name in the requestorName
>  
>    field. Also, for signed requests, the requestor MAY include
>  
>    certificates that help the OCSP responder verify the requestor's
>  
>    signature in the certs field of Signature.
>  
>  
>  
>  
>  
> 18. The text states on page 14:
>  
>  
>  
>    The responder MAY include certificates in the
>  
>    certs field of BasicOCSPResponse that help the OCSP client verify the
>  
>    responder's signature. If no certificates are included then certs
>  
>    SHOULD be absent.
>  
>  
>  
> While this sentence is true, it is not sufficient. In order to allow verifying 
> every SingleResponse, 
>  it is important to include the relevant certificates which are pertinent to 
> every SingleResponse.
>  
>  
>  
>    For every SingleResponse where the responder is not a CA, the 
>  
>    responder SHALL include the relevant OCSP certificate in the certs 
>  
>    field of BasicOCSPResponse in order to allow the OCSP client 
>  
>    verifying the responder was entitled to include that SingleResponse 
>  
>    in the signed BasicOCSPResponse.
>  
>  
>  
>    If no certificates are included then certs SHOULD be absent.
>  
>  
>  
>  
>  
> 19. Page 15. The ASN.1 syntax should be changed in order to be able to use the 
> enumeration case 7 that is not used for CRLs. 
>        revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }
>  
>  
>  
> Proposed text change:
>  
>  
>  
> Current text:
>  
>  
>  
>        revocationReason    [0]     EXPLICIT RevocationReason OPTIONAL }
>  
>  
>  
> RevocationReason ::= ENUMERATED {
>  
>         unspecified                    (0),
>  
>         keyCompromise                  (1),
>  
>         cACompromise                   (2),
>  
>         affiliationChanged             (3),
>  
>         superseded                     (4),
>  
>         cessationOfOperation           (5),
>  
>         certificateHold                (6),
>  
>         notIssuedOrIrregularlyIssued   (7),
>  
>         removeFromCRL                  (8),
>  
>         privilegeWithdrawn             (9),
>  
>         aACompromise                  (10) }
>  
>  
>  
>  
>  
> 20. Page 15. After the ASN.1 syntax, there is no description of every 
>  (except a few words in section 4.2.2.1 Time about thisUpdate, nextUpdate and 
> producedAt).
>  
>  
>  
>    responderID indicates either the name or the key from a CA, or the 
>  
>    name or the key from a OCSP Responder.
>  
>  
>  
>    producedAt indicates the time at which this response was signed.
>  
>  
>  
>    responses contains one or more single responses.
>  
>  
>  
>    responseExtensions is OPTIONAL.  Any specific extension is OPTIONAL.
>  
>    The critical flag may or may not be set.
>  
>  
>  
>    certID is usually a copy of the same field which was placed in the 
>  
>    request, but for OCSP responders which pre-produce signed responses 
>  
>    certID may be the identifier of a target certificate that was not 
>  
>    present in the request (see the end of section 4.2).
>  
>  
>  
>    certStatus indicates the status of the certificate: either good, 
>  
>    revoked or unknown.
>  
>  
>  
>    thisUpdate indicates the time at which the status being indicated 
>  
>    is known to be correct.
>  
>  
>  
>    nextUpdate indicates the time at or before which newer information 
>  
>    will be available about the status of the certificate.  If 
>  
>    nextUpdate is not set, the server is indicating that newer 
>  
>    revocation information is available all the time. 
>  
>  
>  
>    If nextUpdate is set, it often corresponds to the {thisUpdate, 
>  
>    nextUpdate} interval in CRLs.  Responses whose nextUpdate value is 
>  
>    earlier than the local UTC time value SHOULD be considered 
>  
>    unreliable.  Responses whose thisUpdate time is later than the local 
>  
>    UTC time SHOULD be considered unreliable.
>  
>  
>  
>    singleExtensions is OPTIONAL.  Any specific extension is OPTIONAL.
>  
>    The critical flag SHOULD NOT be set for any of them.
>  
>  
>  
>    revocationTime indicates the time at which the certificate was 
>  
>    revoked.
>  
>  
>  
>    revocationReason is OPTIONAL.  It includes all the cases that are 
>  
>    present in CRLReason used for CRLs and an additional case 7 which is
>  
>    not used for CRLs.  Case 7 is called notIssuedOrIrregularlyIssued. 
>  
>  
>  
>       - "notIssued" corresponds to the case where the certificate 
>  
>          serial number that was sent was erroneous and has not yet 
>  
>          been used by the CA at the time of the query,
>  
>  
>  
>       - "irregularlyIssued" corresponds to the case where the 
>  
>          certificate serial number that was sent really exists in a 
>  
>          certificate that is correctly signed, but to its knowledge 
>  
>          the CA has not issued a certificate with such a serial 
>  
>          number.  As an example, it may have been issued by the CA 
>  
>          because the RA was compromised. 
>  
>  
>  
>    When a responder responds revoked to a status request for which it 
>  
>    knows that the serial number has not been used by the CA or has 
>  
>    been irregularly used irregularly to issue a certificate, then 
>  
>    in RevokedInfo the responder MUST:
>  
>  
>  
>       - specify the revocationTime :  January 1, 1970,
>  
>       - provide the revocationReason: notIssuedOrIrregularlyIssued (7).
>  
>  
>  
>    and in SingleResponse the responder MUST NOT include the nextUpdate.
>  
>  
>  
>    The response MUST include a SingleResponse for each certificate in
>  
>    the request and SHOULD NOT include any additional SingleResponse
>  
>    elements.  However, there is one exception: 
>  
>  
>  
>       OCSP responders MAY pre-produce signed responses specifying the 
>  
>       status of certificates at a specified time.  The time at which 
>  
>       the status was known to be correct SHALL be reflected in the 
>  
>       thisUpdate field of the response. 
>  
>  
>  
>       OCSP responders that pre-generate status responses MAY return 
>  
>       responses that include additional SingleResponse elements if
>  
>       necessary to improve response pre-generation performance or cache
>  
>       efficiency (as permitted in [RFC5019]).
>  
>  
>  
> Since the text above provides all the explanations at the level of the ASN.1 
> parameters, the general text 
>  from section 4.2.2.3 Basic Response is no more need and should be deleted.
>  
>  
>  
>  
>  
> 21. 0n page 16, there is a section 4.2.2.2 called ³Authorized Responders²
>  
>  
>  
> Section 4.2.2.2 states:
>  
>  
>  
>    (Š)
>  
>    This certificate MUST be issued directly by the CA that issued the
>  
>    certificate in question.
>  
>  
>  
>    The CA SHOULD use the same issuing key to issue a delegation
>  
>    certificate as was used to sign the certificate being checked for
>  
>    revocation. Systems relying on OCSP responses MUST recognize a
>  
>    delegation certificate as being issued by the CA that issued the
>  
>    certificate in question only if the delegation certificate and the
>  
>    certificate being checked for revocation was signed by the same key.
>  
>  
>  
> This section would need to reformatted to address CA requirements first and 
> then OCSP responder requirements:
>  
>  
>  
>    (Š)
>  
>    This certificate MUST be issued directly by the CA that issued the
>  
>    certificate in question.  The CA SHOULD use the same issuing key to 
>  
>    issue a delegation certificate as was used to sign the certificate 
>  
>    being checked for revocation. 
>  
>  
>  
>    Systems relying on OCSP responses MUST be able to recognize a 
>  
>    delegation certificate as being issued by the CA that issued the 
>  
>    certificate in question if the delegation certificate and 
>  
>    the certificate being checked were signed by the same key.
>  
>  
>  
>  
>  
> 22. On page 17, the text states:
>  
>  
>  
>    They MUST reject the
>  
>    response if the certificate required to validate the signature on the
>  
>    response fails to meet at least one of the following criteria:
>  
>  
>  
> This is ambiguous. It is inappropriate to have a negative statement like ³They 
> MUST reject². 
>  The sentence should be turned in the positive form ³They SHALL accept² 
>  
>  
>  
> The first occurrence of the word ³response² should be changed into 
> ³singleResponse², while the second occurrence 
>  of the word ³response² should be changed into ³ResponseData²
>  
>  
>  
>    They SHALL accept a singleResponse if the certificate required to 
>  
>    validate the signature placed on the ResponseData meets one of the 
>  
>    following criteria:
>  
>  
>  
>  
>  
> 23. On page 17, the text states:
>  
>  
>  
>    3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
>  
>    extension and is issued by the CA that issued the certificate in
>  
>    question as stated above."
>  
>  
>  
> In order to be crystal clear, it is proposed to change the wording in the 
> following way:
>  
>  
>  
>    3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
>  
>    extension and was signed by the CA using the same key that used 
>  
>    to issue the certificate in question.
>  
>  
>  
>  
>  
> 24. On page 17, the text states:
>  
>  
>  
>    This SHOULD be a non-critical extension. The value of the extension 
>  
>    SHALL be NULL.
>  
>  
>  
>    NoCheck ::= NULL
> 25. Remainder: On page 18, the general text from section 4.2.2.3 Basic 
> Response is no more needed and 
> 26. On page 24, text should be added to the Security consideration section:
>  
>  
>  
> Different results when using OCSP and CRLs
>  
>  
>  
>    OCSP clients or verifiers must build and verify a certification path 
>  
>    for each target certificate up to a trusted root.  When an OCSP 
>  
>    Responder is using published CRLs, it must also build and verify a 
>  
>    certification path for the CRLs it uses up to a trusted root.
>  
>  
>  
>    However, it should be realized that the root used by an OCSP 
>  
>    Responder to verified these CRLs is not necessarily the same as the 
>  
>    one that would be used by the OCSP client, if it were going to verify 
>  
>    the CRLs itself.  Hence the revocation status may not be identical 
>  
>    in both cases.
>  
>  
>  
>  
>  
> 27. On page 24, text should be added to the Security consideration section:
>  
>  
>  
> Denial of service attack using a flood of queries
>  
>  
>  
>    A denial of service vulnerability is evident with respect to a flood 
>  
>    of queries.  The production of a cryptographic signature 
>  
>    significantly affects response generation cycle time, thereby 
>  
>    exacerbating the situation. 
>  
>  
>  
>    The flood of queries may either come from a flood attack or from the 
>  
>    fact that there are too many certificates supported by the same OCSP 
>  
>    responder.  In the later case, the number of queries can be 
>  
>    reduced by using a technique similar to the splitting of CRLs: 
>  
>  
>  
>       When a block of certificates have been issued with the same 
>  
>       accessLocation in the AIA extension field of these certificates, 
>  
>       then the accessLocation should be changed.  In this way, a given 
>  
>       OCSP server will only be responsible for a block of certificates.
>  
>  
>  
>  
>  
> 28. On page 31, the text states.
>  
>  
>  
>    An alternative to this module that conforms to the 2002 version of 
>  
>    ASN.1 may be found in Section 4 of [RFC5912]. 
>  
>  
>  
> RFC 5912 omits to define the nocheck extension. Thus it is inappropriate to 
> refer to RFC 5912. 
>  
>  
>  
>  A corrected module is provided in draft-pinkas-rfc2560bis-03.
>  
>  
>  
>  
>  
> 29. Different topics are not covered by the document. These topics are 
> important. 
>  The following comments propose text to be placed in annexes. Three annexes 
> are being proposed.
>  
>  
>  
> Note: The texts are extracted from draft-pinkas-rfc2560bis-03.
>  
>  
>  
>  
>  
> 30. First annex being proposed. This annex is important, because key rollover 
> is not addressed in the draft.
>  
>  
>  
> KEY ROLLOVER
>  
>  
>  
> 1. CA that directly supports an OCSP service
>  
>  
>  
>    When a CA that directly supports an OCSP service performs a key 
>  
>    rollover:
>  
>  
>  
>    - for certificates issued under the old key, the CA SHALL continue 
>  
>      to sign the revocation status of OCSP responses with that old key 
>  
>      at least until all these certificates are expired, and
>  
>  
>  
>    - for certificates issued under the new key, the CA SHALL change the 
>  
>      accessLocation in the AIA extension field of these certificates 
>  
>      and sign the revocation status of OCSP responses with that new key 
>  
>      at least until all these certificates are expired.
>  
>  
>  
>    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.
>  
>  
>  
> 2. CA that uses OCSP responders
>  
>  
>  
>    When a CA that uses OCSP Responders performs a key rollover, then 
>  
>    it MUST either designate a new OCSP Responder or keep the current 
>  
>    OCSP Responder(s).
>  
>  
>  
>    If the CA designates a new OCSP Responder, then it SHALL change the 
>  
>    accessLocation in the AIA extension field for the newly issued 
>  
>    certificates and issue an OCSP certificate to the new OCSP Responder 
>  
>    using its new key.
>  
>  
>  
>    If the CA keeps the same OCSP Responder(s), then it SHALL continue 
>  
>    to use the same accessLocation(s) in the AIA extension field for the 
>  
>    newly issued certificates and issue an OCSP certificate to the 
>  
>    appropriate OCSP Responder(s) using its new key.
>  
>  
>  
>    Note: The CA may need to continue issuing certificates to the OCSP 
>  
>    Responder(s) using the old CA key until all the certificates issued 
>  
>    under the CA' old key for which the OCSP Responder(s) are 
>  
>    authoritative have expired.
>  
>  
>  
> 3. OCSP Responder key rollover
>  
>  
>  
>    When an OCSP Responder performs a key rollover (asynchronously from 
>  
>    a CA key rollover), then each CA which has designated an OCSP 
>  
>    Responder SHALL issue a new certificate for that OCSP Responder and 
>  
>    for each of its issuing keys which meets the following property: 
>  
>  
>  
>       - the issuing key has been used to sign at least one certificate 
>  
>         which contains an AIA extension designating that OCSP Responder 
>  
>         and that certificate is not yet expired.
>  
>  
>  
>    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. 
>  
>  
>  
>  
>  
> 31. Second annex being proposed. This annex is important because it describes 
> the validation of an OCSP response in the past 
> Response processing by an OCSP client
>  
>  
>  
>    OCSP responses can be verified at the current time by an OCSP client 
>  
>    when receiving a response, whereas old responses can be verified at 
>  
>    a time in the past by a verifier.  The algorithm below addresses 
>  
>    both cases.
>  
>  
>  
>    Prior to processing a basic response, OCSP clients MUST determine 
>  
>    the checking time, which may be either the current time or a time 
>  
>    in the past.
>  
>  
>  
>    OCSP clients or verifiers SHALL check if the response contains 
>  
>    responseExtensions. If such an extension is found and is recognized, 
>  
>    it MUST be processed.  If such a critical extension is found and 
>  
>    is not recognized, the whole OCSP response MUST be considered as 
>  
>    invalid.
>  
>  
>  
>    If the checking time is the current time, and if a nonce extension 
>  
>    has been used in the request and is recognized (see section 4.5.1), 
>  
>    OCSP clients MUST check whether the same nonce is present in the 
>  
>    response.  If the nonce is not present or is different, then the 
>  
>    OCSP response MUST be discarded.
>  
>  
>  
>    Only the single response(s) which are/is of interest SHALL be 
>  
>    checked.
>  
>  
>  
> STEP 1
>  
>  
>  
>    OCSP clients or verifiers SHALL verify that the certificate 
>  
>    identified in a single response is of interest.  Otherwise, proceed 
>  
>    to step 3.
>  
>  
>  
>    If the certificate status included in a single certificate response 
>  
>    is "unknown", then the revocation status of that certificate is 
>  
>    "unknown", and proceed to step 3.
>  
>  
>  
>    If the certificate status from the single certificate response is 
>  
>    either "good" or "revoked", OCSP clients or verifiers SHALL check 
>  
>    that the checking time is within the validity period of the target 
>  
>    certificate.  If it is not the case, then the revocation status of 
>  
>    that certificate is "unknown" and proceed to step 3.
>  
>  
>  
>    If the checking time is the current time, and if a nonce has been 
>  
>    used in the request, then proceed to step 2.
>  
>  
>  
>    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. 
>  
>  
>  
>    Note: the notion of "close enough" is a local matter.  It can be set 
>  
>          to a few minutes to allow for small UTC time differences 
>  
>          between the client and the server or to a few hours in case 
>  
>          the server is producing pre-computed responses.
>  
>  
>  
>    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).
>  
>  
>  
>    In addition, if the nextUpdate field is present, OCSP clients MUST 
>  
>    check that the time which is indicated is greater than the checking 
>  
>    time, otherwise the single response MUST be discarded.
>  
>  
>  
>    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. 
>  
>  
>  
> STEP 2
>  
>  
>  
>    OCSP clients or verifiers MUST build and verify a certification path 
>  
>    for that certificate up to a trusted root, so that they have the 
>  
>    knowledge of the CA public key value that was used to sign the 
>  
>    target certificate.  The revocation status of each certificate of 
>  
>    that certification path (except the target certificate) SHALL be 
>  
>    checked.
>  
>  
>  
>    If no path can be built or if one of the certificates of the path is 
>  
>    revoked, then the revocation status of that certificate is "unknown", 
>  
>    and proceed to step 3. 
>  
>  
>  
>    If the certification path (except the target certificate) is valid, 
>  
>    then two cases need to be considered:
>  
>  
>  
>    a) If the responderID matches with the name or the key from the CA 
>  
>       which has issued the target certificate, then check whether the 
>  
>       OCSP response is signed by the same key that was used to sign 
>  
>       the target certificate.
>  
>  
>  
>              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.
>  
>  
>  
>    b) If the responderID does not match with the name or the key from 
>  
>       the CA which has issued the target certificate, then it indicates 
>  
>       the name or the key from an OCSP Responder.  Check whether there 
>  
>       exists a local rule which applies to this target certificate to 
>  
>       verify that the signature of the BasicOCSPResponse is valid for 
>  
>       that single response.  If this rule exists, it SHALL be followed. 
>  
>  
>  
>       Otherwise check whether there is an OCSP certificate (i.e. which 
>  
>       has both the ocspSigning OID in the extended key usage extension 
>  
>       and the digitalSignature bit in the key usage extension) signed 
>  
>       by the same key that was used to sign the target certificate. 
>  
>       This certificate MUST be present in the certs field from the 
>  
>       BasicOCSPResponse. 
>  
>  
>  
>           If such certificate is not found or is invalid, then the 
>  
>           revocation status of that certificate is "unknown" and 
>  
>           proceed to step 3.
>  
>  
>  
>           If such certificate exists and if the checking time is 
>  
>           within the validity period of this certificate, then it MUST 
>  
>           be verified whether the OCSP response can be verified using 
>  
>           the public key that is present in the OCSP Certificate. 
>  
>  
>  
>              If it is not the case, then the revocation status of that 
>  
>              certificate is "unknown" and proceed to step 3.
>  
>  
>  
>              If it is the case, then it MUST be verified that the OCSP 
>  
>              Certificate has not been revoked.
>  
>  
>  
>      If one of these conditions is met, then the status for the target 
>  
>      certificate as indicated in the certStatus field is accepted, 
>  
>      otherwise the revocation status is "unknown".
>  
>  
>  
> STEP 3
>  
>  
>  
>    If there exists another single certificate status response for a 
>  
>    target certificate that is of interest, then proceed to step 1. 
>  
>    Otherwise the basic response is now processed.
>  
>  
>  
>  
>  
> 32. Third annex being proposed. This annex is important because it provides 
> guidance on how to build an OCSP responder in the three cases. 
>  Many text portions are similar, but three full texts are provided in order to 
> provide a better clarity for each of the three cases.
>  
>  
>  
> 1. Request processing by OCSP servers
>  
>  
>  
>    The behavior of an OCSP server will be different whether the OCSP 
>  
>    server is a CA acting as an OCSP responder, is an OCSP Responder 
>  
>    which received a delegation from one or more CAs, or is a locally 
>  
>    trusted Responder.
>  
>  
>  
> 1.1. Processing by a CA acting as an OCSP responder
>  
>  
>  
>    The OCSP responder SHALL maintain a list of entries. Each entry 
>  
>    SHALL contain:
>  
>  
>  
>      - the URI associated to the OCSP responder, from which the OCSP 
>  
>        requests are received, 
>  
>  
>  
>      - the DN from a CA,
>  
>  
>  
>      - an issuing public key from a CA,
>  
>  
>  
>      - 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, 
>  
>        and
>  
>  
>  
>      - the method used to gain access and sign with the private key 
>  
>        corresponding to the issuing public key.
>  
>  
>  
>    For a given URI value, the OCSP responder SHALL only use one CA 
>  
>    key pair value. 
>  
>  
>  
>    When it receives an OCSP request on that URI, the OCSP responder 
>  
>    SHALL handle exceptions according to section 2.3. 
>  
>  
>  
>    If the OCSP request contains the name of a requestor, the OCSP 
>  
>    responder SHALL verify whether there exists a locally defined rule 
>  
>    which regulates access control.  If this rule exists, it SHALL be 
>  
>    followed.
>  
>  
>  
>    Then, 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 are eligible to a 
>  
>    locally defined rule which indicates that the OCSP responder is 
>  
>    responsible to provide the revocation status of that target 
>  
>    certificate.  If this rule exists, it SHALL be followed.
>  
>  
>  
>    Otherwise, the OCSP responder SHALL determine whether it is 
>  
>    responsible to provide the revocation status of that target 
>  
>    certificate according to the following rule.
>  
>  
>  
>    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.
>  
>  
>  
>    When there is a match, then the OCSP responder SHALL use the serial 
>  
>    number of the target certificate that is present in the request and 
>  
>    determine the revocation status of that certificate according to 
>  
>    the method(s) defined in the entry. 
>  
>  
>  
>    When the revocation status is provided by the server using a real 
>  
>    time access to a database of revocation statuses of issued 
>  
>    certificates, then the thisUpdate field SHALL be present in the
>  
>    SingleResponse response whereas the nextUpdate field SHALL be 
>  
>    missing. 
>  
>  
>  
>    Otherwise, both the thisUpdate and the nextUpdate fields SHALL be 
>  
>    present in the SingleResponse. 
>  
>  
>  
>    The time at which this response will be signed MUST be indicated in 
>  
>    the producedAt field from the SingleResponse.
>  
>  
>  
>    If a singleRequestExtensions is present in the request it MUST be 
>  
>    processed.
>  
>  
>  
>    If there is another target certificate present in the request, it 
>  
>    SHALL be processed in the same way.
>  
>  
>  
>    If a requestExtensions is present in the request it MUST be 
>  
>    processed.
>  
>  
>  
>    The OCSP response MUST be signed using the CA issuing private key.
>  
>  
>  
>  
>  
> 1.2. Processing by an OCSP Responder
>  
>  
>  
>    For each CA from which the OCSP Responder has received a delegation, 
>  
>    the OCSP Responder SHALL maintain a list of entries. 
>  
>  
>  
>    Each entry SHALL contain:
>  
>  
>  
>      - the URI associated to this OCSP Responder, from which the OCSP 
>  
>        requests are received, 
>  
>  
>  
>      - the DN from a CA,
>  
>  
>  
>      - an issuing public key from a CA,
>  
>  
>  
>      - 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,
>  
>  
>  
>      - an OCSP certificate, 
>  
>  
>  
>      - the OCSP public key contained in that OCSP certificate, and
>  
>  
>  
>      - the method used to gain access and sign with the OCSP private 
>  
>        key corresponding to that OCSP certificate.
>  
>  
>  
>    For a given URI value, the OCSP Responder SHALL only use one OCSP 
>  
>    key pair value.  Therefore there cannot be two entries with the 
>  
>    same URI value and a different OCSP public key value.
>  
>  
>  
>    NOTE: a BasicOCSPResponse can only be signed using a single private 
>  
>          key. 
>  
>  
>  
>    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.
>  
>  
>  
>    When it receives an OCSP request, the OCSP responder SHALL handle 
>  
>    exceptions according to section 2.3. 
>  
>  
>  
>    If the OCSP request contains the name of a requestor, the OCSP 
>  
>    responder SHALL verify whether there exists a locally defined rule 
>  
>    which regulates access control.  If this rule exists, it SHALL be 
>  
>    followed.
>  
>  
>  
>    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 OCSP request match with those 
>  
>    from an entry.
>  
>  
>  
>    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.
>  
>  
>  
>    When there is a match, the OCSP Responder SHALL use the serial 
>  
>    number of the target certificate this is present in the OCSP 
>  
>    request to determine the revocation status of that certificate 
>  
>    according to the method(s) indicated in the entry. 
>  
>  
>  
>    When the revocation status is provided by the server using a real 
>  
>    time access to a database of revocation statuses of issued 
>  
>    certificates, then the thisUpdate field SHALL be present in the
>  
>    SingleResponse response whereas the nextUpdate field SHALL be 
>  
>    missing. 
>  
>  
>  
>    Otherwise, both the thisUpdate and the nextUpdate fields SHALL be 
>  
>    present in the SingleResponse. 
>  
>  
>  
>    The time at which this response will be signed MUST be indicated in 
>  
>    the producedAt field from the SingleResponse.
>  
>  
>  
>    If a singleRequestExtensions is present in the request it MUST be 
>  
>    processed.
>  
>  
>  
>    If there is another target certificate present in the request, it 
>  
>    SHALL be processed in the same way.
>  
>  
>  
>    If a requestExtensions is present in the request it SHALL be 
>  
>    processed.
>  
>  
>  
>    The OCSP response MUST be signed using the OCSP private key.
>  
>  
>  
>    Unless there is a local rule which states differently, for every 
>  
>    target certificate which matches both with the hash of a CA DN and an 
>  
>    issuing public key from an entry, the OCSP certificate of that entry 
>  
>    SHALL be placed in the certs field.
>  
>  
>  
>    It may happen, that none of the target certificates from the OCSP
>  
>    request matches both with the hash of a CA DN and an issuing public 
>  
>    key from an entry.  In that case and unless a local rule states 
>  
>    differently, the certs field from the BasicOCSPResponse SHOULD be 
>  
>    kept empty (to limit the disclose of the names of the CAs from which 
>  
>    the OCSP Responder received a delegation from).
>  
>  
>  
> 1.3. Processing by a locally trusted Responder
>  
>  
>  
>    For each CA for which the locally trusted Responder is 
>  
>    authoritative, the OCSP Responder SHALL maintain a list of entries. 
>  
>  
>  
>    Each entry SHALL contain:
>  
>  
>  
>      - the URI associated to this OCSP Responder, from which the OCSP 
>  
>        requests are received, 
>  
>  
>  
>      - the DN from a CA,
>  
>  
>  
>      - an issuing public key from a CA,
>  
>  
>  
>      - 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,
>  
>  
>  
>      - the method used to gain access to the private key in order to 
>  
>        sign the OCSP response. 
>  
>  
>  
>    For a given URI value, the OCSP Responder SHALL only use one private 
>  
>    key.  Therefore there cannot be two entries with the same URI value 
>  
>    and a different method to gain access to the appropriate private key.
>  
>  
>  
>    NOTE: a BasicOCSPResponse can only be signed using a single private 
>  
>          key. 
>  
>  
>  
>    When it receives an OCSP request, the OCSP responder SHALL handle 
>  
>    exceptions according to section 2.3. 
>  
>  
>  
>    If the OCSP request contains the name of a requestor, the OCSP 
>  
>    responder SHALL verify whether there exists a locally defined rule 
>  
>    which regulates access control.  If this rule exists, it SHALL be 
>  
>    followed.
>  
>  
>  
>    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 OCSP request match with those 
>  
>    from an entry.
>  
>  
>  
>    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.
>  
>  
>  
>    When there is a match, the OCSP Responder SHALL use the serial 
>  
>    number of the target certificate this is present in the OCSP 
>  
>    request to determine the revocation status of that certificate 
>  
>    according to the method(s) indicated in the entry. 
>  
>  
>  
>    When the revocation status is provided by the server using a real 
>  
>    time access to a database of revocation statuses of issued 
>  
>    certificates, then the thisUpdate field SHALL be present in the
>  
>    SingleResponse response whereas the nextUpdate field SHALL be 
>  
>    missing. 
>  
>  
>  
>    Otherwise, both the thisUpdate and the nextUpdate fields SHALL be 
>  
>    present in the SingleResponse. 
>  
>  
>  
>    The time at which this response will be signed MUST be indicated in 
>  
>    the producedAt field from the SingleResponse.
>  
>  
>  
>    If a singleRequestExtensions is present in the request it MUST be 
>  
>    processed.
>  
>  
>  
>    If there is another target certificate present in the request, it 
>  
>    SHALL be processed in the same way.
>  
>  
>  
>    If a requestExtensions is present in the request it SHALL be 
>  
>    processed.
>  
>  
>  
>    The OCSP response MUST be signed using the OCSP private key.
>  
>  
>  
>    The certs field may contain no, one or several OCSP certificates 
>  
>    according to local rules followed by the locally trusted Responder.
>  
>  
>  
>  
>  
> End of comments
>  
>  
> 
>  Denis
>  
>  
>  
>   
> _______________________________________________ pkix mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Jan 2013 11:12:22 -0800

On Jan 20, 2013, at 8:12 AM, Denis Pinkas <[email-masked]> wrote:

> . . . 
> 1.       The author can be removed as an author and moved to the Acknowledgements section.
> 2.       The author can be removed as an author and moved to a Contributors section.
> 3.       An AD can approve the document in place of the unavailable author. (See the IESG Statement on AUTH48 State.)
>  
> . . . 
> It looks more reasonable to anticipate the problem and to apply the path numbered 1, hence to move the names 

Fully agree. This would make the process better.

> Obviously, the consequence is that there will be far less people contributing to this draft: 

Disagree. Anyone who is listed as an author who has not contributed by now is probably not going to all of a sudden decide to contribute between now and the end of IETF Last Call.

> Stefan seems to be the single author/contributor, … which is what he wanted :

And what many of us wanted as well.

>   - he did not answered positively when, last summer, I sent him a private email proposing to share the editing of the draft. 
>   - after a meeting in London, he did not either responded at two proposals for a phone call.

You have contributed many comments, some of them valuable to the effort. However, WG chairs need to choose authors for WG document who are expected to follow WG consensus. Stefan and Stephen may have decided that you do not fit that criterion. If I were chair (and there are many people who are thankful that I am not...), I would have come to the same conclusion.

--Paul Hoffman

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 27 Jan 2013 13:28:53 +0100

Denis,

Responding to your comments below.

However, one genral remark to make recurring comments easier to understand.

The WG decided to adopt a minimalistic approach to updating RFC 2560. That
means that 
1. We don't change anything from RFC 2560 nless it is broken, or the
industry clearly need clarifications in order to aoid interoperability
issues.
2. We retain the document structure of RFC 2560 as much as possible to allow
easy comparison of wht the changes are in comparison withRFC 2560.

One can always think up more clever ways to write things out in words. But
that also comes with a risk.
The current words has been around for a long time and we knw from
experience which words worked to produce workig implementations, and which
did not.
Introducing new ways to say the same thingmay introduce new problems and
people might disagree on what the new perfect wording should be. And this
could go on forever.

So when my reply is "Not broken",then that is because the current wordng
does not have such problems that is merits a change.

From:  Denis Pinkas <[email-masked]>
Date:  Sunday, January 20, 2013 5:12 PM
To:  Stefan Santesson<[email-masked]>, Stephen Kent <[email-masked]>
Cc:  pkix <[email-masked]>
Subject:  Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

>     
>    
> 
> Pleas find 32 comments on draft-ietf-pkix-rfc2560bis
>  
>  
>  
> 1. The document states:
>  
>  <Cut away isue 1 regarding authorship etc, as it has beenresponded to
> separately>
>  

Responded to separately.

> 2.  Protocol Oerview
>    In lieu of or as a supplement to checking against aperiodic CRL, it
>  
>    reocation status of a certificate (cf. RFC5280], Section 3.3).
>  
>    Example include high-value funds transfer or large stock trades.
>  
>  
>  
>    he Online Certificate Status Protocol (OCSP) enables applications to
>  
>    determine the (revocation) stae of an identified certificate. OCSP
>  
>    may be used to satisfy some ofthe operational requirements of
>  
>    providing more timely revocation information than is possible with>  
>    CRLs and may also be used to obtain additional status informaion.
>  
>  
>  
> This text is misleading because readers may think tha OCPS necessarily

may" does not mean "necessarily".

> Proposed text replacement:
    The Online Certificate Status Protocol (OCSP) is a client-server>  
>    of one or more certificates either "good", "revoked", or "nknown".
>  
>  
>  
>    eal time access to a database of issued ertificates, or using a
>  
>    batch access to a database of issued certificates, o using a
>  
>    certificates, or using a batch access to a dataase of revocation
>  
>    combinaton of base CRLs and delta CRLs.
>  
>  
>  

Not broken

>  
> 
> . The current text from section 2 states:
>  
>  
>  
>    This protocol specifies the data that needs to be excanged between
>  

Not broken

>       produces an error message; otherwise, it returns a definitive

Fixed in draft 10.

> Section 4.2.2.2 will thus remain the single section providing full details.

I have added references to section 4.2.2.2 in the quoted sections in 2.2 and
2.6.
(will be included in draft 11)

>    - the signature computed across hash of the response, and

This is an overview section. We ought not try to duplicate the level of
detail provided in the detailed protocol section.
A "definitive response" according to tho 2.1 is a response to an error-free
request, so your first remark is redundant.

I have added a note about time to the current list, and changed "name" to
identifier in bullet 2.
(will be included in draft 11)

>              the subjectPublicKey contained in this OCSP certificate.

Not broken.
All of this is already covered by the document.

>       will not use CRLs as a fall back mechanism.

I removed the double parenthesis and adopted your clarification with regard
to "on hold". 

The text in draft 10 has changed from what you have commented on. I believe
that text is better.

You "Note" has problems.
1. We do not prevent responders to respond "unknown" if their assessment is
that this is an appropriate response, considering what they know about the
requested serial number. Thus the term "is used" is misleading.
2. This mechanisms does not "make sure" that the clients do anything. It's
up to the discretion of the relying party to decide what source of
revocation checking they rely on. This does however reduce the risk of
clients falling back to CRL:s
3. This mechanism is not just relevant to old clients, but also to new one
for the same reason.

I have adopted a modified version of your Note:

   NOTE: The "revoked" state for known non-issued certificate serial
         numbers is allowed in order to reduce the risk of relying
         parties using CRLs as a fall back mechanism, which would be
         considerably higher if an "unknown" response was returned.

> In addition, section 4.4.8  Extended Revoked Definition should be deleted.

The referred text has been updates in draft 09.

This has been discussed on the list and you have yet to convince the list of
your new reason code.
I disagree as the risk of running into problems with the deployed base of
application is hugely larger with introduction of a new reason code, rather
than using certificateHold.
No application should be broken, since no application have business asking
for non-issued cert serial numbers in the first place. Secondly, no
application can assume that a certificateHold reason will be cleared any
time soon.

> Delete section 2.4. See comment number 19 for the description of these

Not broken.
The current text segments fits well into a protocol overview section.

> description has been done.

Not broken.

> 12. Remainder: Section 2.6 should be deleted (see comment number 5).

Not broken.

> it does not matter what the OCSP responder states.

Not broken.
An OCSP responder does not have to be chained to the broken CA. The relying
party may have other trust configuration at choice.

> response, when describing the processing of the response.

Not broken.

>    signature in the certs field of Signature.

Not broken.
The current text is short, but it is actually sufficient from the context of
the ASN.1 definitions of the section. This is a detailed protocol section
and the reader need to understand ASN.1 in any case to understand and
implement the section.
The information about criticality is already covered in the extension
section.

> This section should be deleted.

Not broken.

>    signature in the certs field of Signature.

Not broken.

Your text may provide guidance that could be useful to some implementers,
but is completely beyond this document and further, not generally applicable
or true.
As an example, an organisation may setup an in house locally configured OCSP
responder that responds to all certificates "out there" that is relevant to
that organisation.
Such clients would just blindly send OCSP requests to their local responder,
disregarding any information in the cert.
It's totally beyond this spec to have an opinion about this.

>    If no certificates are included then certs SHOULD be absent.

Not broken.

This requirement would break backwards compatibility with RFC 2560.
Further this would not be needed for a locally configured responder.

>         notIssuedOrIrregularlyIssued   (7),

Not broken.

You have to convince the list about your new reason code.

>  from section 4.2.2.3 Basic Response is no more need and should be deleted.

Preliminary I would say "not broken".
If you don't replace 4.2.2.3, then what really are you missing?

>    the certificate being checked were signed by the same key.

I disagree. The CA is actually free to do anything, but cannot expect the 
client to recognise the responder as authorised unless the same private key 
is used.
The current text places the requirement where they belong.

>    validate the signature placed on the ResponseData meets one of the 

No, this change is not backwards compatible.
So state the requirements for rejection is not equivalent to stating 
requirements for acceptance.
There may be other locally configured reasons to reject in addition to those 
listed in the standard.

>    to issue the certificate in question.

No, issuing with another key is not prohibited, and may be accepted by some 
clients as an authorised responder.

> The ASN.1 syntax is missing. Add: 

Moving this to a separate discussion.
I'm not sure what the preferred way to describe this is.

>  should be deleted. See comment 20.

Not broken.

>    the CRLs itself.  Hence the revocation status may not be identical 

I don't understand this one.

>       OCSP server will only be responsible for a block of certificates.

If the security considerations section is talking about splitting OCSP 
responders in this way, then the document itself need to introduce the 
subject.
I would suggest that it is beyond this update to do so.

>  A corrected module is provided in draft-pinkas-rfc2560bis-03.

Will move this (as stated above) to a separate discussion.

> Note: The texts are extracted from draft-pinkas-rfc2560bis-03.

Not broken.
Each such amendment need to be thoroughly reviewed and motivated.

>    according to local rules followed by the locally trusted Responder.

Not broken.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 27 Jan 2013 14:13:31 +0100

I feel uncertain how to nest deal with this comment from Denis.

I have compared with RFC 5912 and it does only define the extension OID, but
provides no extension definition.

This seem to be the model used in several places where an extension with
absent extension value (empty octet string) is used.
Is there any reason to go beyond this and do as Denis suggests. That is, to
provide an Extension definition with a Syntaxt holding an element with a
NULL value?

If this is the case, the same would apply to the new OCSP extension for
extended revoke definition.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 27 Jan 2013 14:19:06 +0100

3 new drafts on RFC2560bis merits an explanation.
1. Firs I resubmitted version 09, which I unsuccessfully tried to publish on
the 16th of Jan. This draft captures changes to respond the the extensive
debate and reviews on the list up until the 16th.
2. Draft 10 deals with Alexey's comments.
3. Draft 11 includes updates due to Deni's list of comments, excluding the
ASN.1 question posted separately on the list.
/Stefan

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 27 Jan 2013 14:41:41 +0100

On 01/27/2013 02:13 PM, Stefan Santesson wrote:
> I have compared with RFC 5912 and it does only define the extension OID, but provides no extension 
> definition.
indeed, it doesn't define an extension for that OID.
>
> This seem to be the model used in several places where an extension with absent extension value 
> (empty octet string) is used.
No.

An instance of an ASN.1 type is not empty. If you want to have an extension, you have to
define it as such, which is not done done thus the 5912 module does not define an
extension identified by that oid with a syntax ???

defining the oid doesn't make the 5912 a wrong asn.1  it just doesn't implement all of ocsp.
> Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension 
> definition with a Syntaxt holding an element with a NULL value?
try to make a definition according 5912.
>
> If this is the case, the same would apply to the new OCSP extension for extended revoke definition.
>
indeed. as soon as there is a specification of an extension in Ocsp there must be
  syntax definitions of an oid and a type

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 27 Jan 2013 08:17:03 -0800

I'll defer to Jim Schaad on this, but I think what Denis is asking for is alright, but overkill. A standalone definition without an example of usage adds no value to the document; using a generic name like "NoCheck" could in fact be dangerous to someone reading the document not terribly carefully. But adding a definition and a usage for it seems fine.

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 27 Jan 2013 10:05:27 -0800

In terms of what I did for 5912 - This fell into the general space of the
document was underspecified.

Defining the NULL is optional and not necessary but nice.

The following would be added to 5912

re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY
id-pkix-ocsp-nocheck } ---- without the type defined
re-ocsp-nocheck EXTENSION := {SYNTAX NoCheck IDENTIFIED BY
id-pkix-ocsp-nocheck } ---- with the type defined

They are the effectively the same.  Most ASN.1 compilers have a NULL type
that can be directly referenced so adding the extra layer of indirection
does not make the user's job any easier or harder.

However, I would not know from reading the text if this was part of the
extension sequence for ResponseData.responseExtensions or
SingleResponse.singleExtensions or both.  For this reason I did not create
the ASN.1 object.

Jim

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Sunday, January 27, 2013 8:17 AM
> To: Stefan Santesson
> Cc: Denis Pinkas; Stephen Kent; Jim Schaad; pkix
> Subject: Re: ASN.1 expression of extensions with absent extension value
> 
> I'll defer to Jim Schaad on this, but I think what Denis is asking for is
alright,
> but overkill. A standalone definition without an example of usage adds no
> value to the document; using a generic name like "NoCheck" could in fact
be
> dangerous to someone reading the document not terribly carefully. But
> adding a definition and a usage for it seems fine.
> 
> --Paul Hoffman=

---

From: Russ Housley <[email-masked]>
Date: Sun, 27 Jan 2013 13:28:06 -0500

From RFC 5280, the extension structure is:

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }

We know that some software automatically tries to decode the content of the OCTET STRING.  Will this software fail if the OCTET STRIN is zero length?

Russ

On Jan 27, 2013, at 8:13 AM, Stefan Santesson wrote:

> I have compared with RFC 5912 and it does only define the extension OID, but provides no extension definition.
> 
> This seem to be the model used in several places where an extension with absent extension value (empty octet string) is used.
> Is there any reason to go beyond this and do as Denis suggests. That is, to provide an Extension definition with a Syntaxt holding an element with a NULL value?
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 27 Jan 2013 19:46:23 +0100

Jim,

The noCheck is a cert extension. Its included in OCSP responder certs to
signal that this responder cert does not have to be checked for revocation.

Would it be OK if I just included the following in the ASN.1 module of
2560bis:

id-pkix-ocsp-nocheck }

That extension definition is not present in 5912, but the extension oid
definition is:
id-pkix-ocsp-nocheck         OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

Or is even this neededŠ?
Since this document does not define cert ASN.1 that extension definition
will not be referred to.

/Stefan

---

From: Carl Wallace <[email-masked]>
Date: Sun, 27 Jan 2013 13:56:17 -0500

>re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY

You should add some text discussing the fact that implementations need to
handle both empty and NULL, since 2560 was not clear enough on this and
there are apparently implementations of each in the field. I think
encoding NULL is the common practice.  You may want to add a MUST NOT to
steer future implementations away from generating empty extensions.

>Or is even this needed??

Yes it is needed and should have been in the ASN.1 module of 2560, not
just in the prose.  It should probably land in the errata of 5912 as well.

>Since this document does not define cert ASN.1 that extension definition

There are many extensions defined in documents that do not define
certificate ASN.1.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 27 Jan 2013 11:05:30 -0800

If I had realized that this is how it is used, I would have done the
following:

1.  Defined the OCSP extension, but with the name ext-ocsp-nocheck (thus
saying it is a certificate extension)

2.  Defined a new object set

--
--  This is the set of PKIX X.509 certificate extensions defined by this
document
--  Add this to the CertExtensions Object Set defined for RFC 5280 in RFC
5912
--

CertificateExtensions EXTENSION ::= {ext-ocsp-nocheck }

3.  Do the same for the other OIDs that are defined but for which no ASN.1
Object is defined in that bottom list.

Jim

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Sunday, January 27, 2013 10:46 AM
> To: Jim Schaad; 'Paul Hoffman'
> Cc: 'Denis Pinkas'; 'Stephen Kent'; 'pkix'
> re-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY id-pkix-ocsp-
> nocheck }
> 
> 
> 
> Or is even this neededS?
will
> not be referred to.
> >In terms of what I did for 5912 - This fell into the general space of
> >the document was underspecified.
> >
> >id-pkix-ocsp-nocheck } ---- without the type defined re-ocsp-nocheck
> >EXTENSION := {SYNTAX NoCheck IDENTIFIED BY id-pkix-ocsp-nocheck } ----
> >with the type defined
> >
> >They are the effectively the same.  Most ASN.1 compilers have a NULL
> >type that can be directly referenced so adding the extra layer of
> >indirection does not make the user's job any easier or harder.
> >
> >SingleResponse.singleExtensions or both.  For this reason I did not
> >create the ASN.1 object.
> >
> >Jim
> >
> >
> >> but overkill. A standalone definition without an example of usage
> >>adds no  value to the document; using a generic name like "NoCheck"
> >>could in fact
> >be

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 27 Jan 2013 20:16:38 +0100

Sorry Carl,

But my understanding of ASN-1 is apparently missing something.

What is the difference between absent and NULL?

What i mean by that is whether there is a difference between a NULL value
and an absent value.
I don't mean to totally omit the OCTET STRING, as that to me is a
violation of RFC 5280 since the extnValue is not OPTIONAL.

Or do you mean that some have implemented this extension omitting the
OCTET STRING altogether.
That should result in a decoding error in such case.

/Stefan

On 1/27/13 7:56 PM, "Carl Wallace" <[email-masked]> wrote:

>>>type
>>>create

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 27 Jan 2013 11:23:42 -0800

Huge difference between absent and NULL

0x30 0x0 --- absent
0x30 0x2 0x5 0x0 -- null

(may be wrong encoding but you get the drift.  I did it off the top of my
head without any verifications)

Jim

> Sent: Sunday, January 27, 2013 11:17 AM
> To: Carl Wallace; Jim Schaad; 'Paul Hoffman'
> Cc: 'pkix'
> Subject: Re: [pkix] ASN.1 expression of extensions with absent extension
> value
> 
> Sorry Carl,
> 
violation of
> RFC 5280 since the extnValue is not OPTIONAL.
> 
> >>The noCheck is a cert extension. Its included in OCSP responder certs
> >>to signal that this responder cert does not have to be checked for
> >>revocation.
> >>
> >You should add some text discussing the fact that implementations need
> >to handle both empty and NULL, since 2560 was not clear enough on this
> >and there are apparently implementations of each in the field. I think
> >encoding NULL is the common practice.  You may want to add a MUST NOT
> >to steer future implementations away from generating empty extensions.
> >
> >>
> >>
> >>That extension definition is not present in 5912, but the extension
> >>oid definition is:
> >>Since this document does not define cert ASN.1 that extension
> >>definition will not be referred to.
> >
> >>>EXTENSION := {SYNTAX NoCheck IDENTIFIED BY id-pkix-ocsp-nocheck }
> >>>---- with the type defined
> >>>
> >>>However, I would not know from reading the text if this was part of
> >>>the extension sequence for ResponseData.responseExtensions or
> >>>> dangerous to someone reading the document not terribly carefully.
> >>>> But adding a definition and a usage for it seems fine.
> >>>>
> >>>> --Paul Hoffman=
> >>>
> >>
> >>

---

From: Carl Wallace <[email-masked]>
Date: Sun, 27 Jan 2013 14:38:19 -0500

>What is the difference between absent and NULL?

Jim gave a good example of the difference between NULL and absent.  Here's
a snip from a responder certificate that illustrates NULL usage in context
(where the first column is the length):

15:         SEQUENCE {
 9:           OBJECT IDENTIFIER ocspNoCheck (1 3 6 1 5 5 7 48 1 5)
 2:           OCTET STRING, encapsulates {
 0:             NULL
         :             }
         :           }

Here's the hex of the dump above: 300F06092B060105050730010504020500.
Replace 020500 with 00 and update the SEQUENCE length for the absent
version.  

I don't ever recall seeing a certificate that used an empty OCTET STRING,
but list traffic has indicated they exist so it probably warrants a
mention.  

>>>>> I'll defer to Jim Schaad on this, but I think what Denis is asking
>>>>>for
>>>>>is
>>>>alright,
>>>>>adds
>>>>>no

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 27 Jan 2013 20:44:08 +0100

Jim, thanks, but I think we are talking cross each other.

What I think you outline here is the extension DER encoding, starting with
a SEQUENCE.

When I talked about absent, I meant absent value, not absent OCTET STRING.
I know,. That was sloppy wording. Perhaps I should say empty value instead
of absent.

Your absent example seems to be absent OCTET STRING, which to me seems
like an ASN-1 error, given the definition of Extension:

Extension  ::=  SEQUENCE  {

extnValue is not optional.

/Stefan

On 1/27/13 8:23 PM, "Jim Schaad" <[email-masked]> wrote:

>> >>>>for is

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 27 Jan 2013 20:59:00 +0100

Oh thanks,

The coin just dropped.

NULL actually has a DER encoding of its own. 05 00
Which indeed means that absent and NULL is very different.

OK. Since we have already decided that NoChek SHALL have a NULL value,
then its just a matter of describing it accurately in the ASN.1 of the
spec.
What ever method we choose I will do the same with the extended revoke
extension syntax.

/Stefan

On 1/27/13 8:38 PM, "Carl Wallace" <[email-masked]> wrote:

>>>>to
>>>to
>>>>>the
>>>>>>But

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 27 Jan 2013 21:01:34 +0100

Top clarify.

OCTET STRING with no value would be: 04 00
OCTET STRING with NULL value is: 04 02 05 00

/Stefan

On 1/27/13 8:59 PM, "Stefan Santesson" <[email-masked]> wrote:

>>>>>oid

---

From: Carl Wallace <[email-masked]>
Date: Sun, 27 Jan 2013 15:08:03 -0500

Yep.  Or in the full context:

300F06092B060105050730010504020500

300D06092B06010505073001050400

On 1/27/13 3:01 PM, "Stefan Santesson" <[email-masked]> wrote:

>>>>>>>> value to the document; using a generic name like "NoCheck" could
>>>>>>>>in
>>>>>>>>fact
>>>>>>>be

---

From: Michael StJohns <[email-masked]>
Date: Sun, 27 Jan 2013 17:17:39 -0500

The X.509 standard uses:

>Extension ::= SEQUENCE {
>         extnId EXTENSION.&id ({ExtensionSet}),
>               (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
>                ENCODED BY der)}

Which suggests that you can't just use an empty OCTET STRING since there is no "empty" ExtnType.  For  NULL is a better choice than <empty>.

>>From: Denis Pinkas <<mailto:[email-masked]>[email-masked]>
>>To: Stefan Santesson <<mailto:[email-masked]>[email-masked]>, Stephen Kent <<mailto:[email-masked]>[email-masked]>
>>Cc: pkix <<mailto:[email-masked]>[email-masked]>
>><mailto:[email-masked]>[email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Sun, 27 Jan 2013 17:30:23 -0500

As a general question, not exactly related to the encoding problem, why are you using the presence of an extension to signal something?  Did I see that there are other signal only extensions?

Why not define:

id-ce-CA-assertions -- -- extension id

CAAssertions ::= SET OF CAAssertion  -- could be SEQUENCE

CAAssertion ::= OBJECT IDENTIFIER

Or if you need a per assertion critical flag - 

CAAssertion ::  SEQUENCE  { 
         assertion OBJECT IDENTIFIER, 
         critical BOOLEAN DEFAULT TRUE
   }  

The presence of CA Assertions extension and the specific assertion in the list would be equivalent to what you're trying to do with the OCSP stuff, and could be reused for other assertions.  (E.g. no revocation mechanism provided, sample certificate - relying parties should not rely, etc).

The major difference between this and something like the Policy extensions is that its specific to the CA operation and not the chain of trust above the CA.

Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 27 Jan 2013 18:47:43 -0800

Michael,

It is perfectly legal for it to not have a value even with the newer syntax.
That is both absent and not absent are legal to put here.  There is not
current syntax to say that the internal value is optional.  But if there is
no type associated with the OID then the correct answer is that the ASN.1
for it would be an empty string.

Russ,

It would not surprise me if something that was just randomly decoding would
have problems in this case.  However, if the decoding is not directed by the
OID then there is a problem because it will not know how to treat all of the
ASN.1 it might encode.  For example while it could decode the basic pieces
of an implicitly tagged value, it would have no idea what any of it meant.
I don't think I would overly worry about this case except for things like
Peter's ASN.1 dumpper.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael StJohns
Sent: Sunday, January 27, 2013 2:18 PM
To: Russ Housley; IETF PKIX
Subject: Re: [pkix] ASN.1 expression of extensions with absent extension
value

   Extension  ::=  SEQUENCE  {

We know that some software automatically tries to decode the content of the
OCTET STRING.  Will this software fail if the OCTET STRIN is zero length?

Russ

The X.509 standard uses:

Extension ::= SEQUENCE {

Which suggests that you can't just use an empty OCTET STRING since there is
no "empty" ExtnType.  For  NULL is a better choice than <empty>.

/Stefan

From: Denis Pinkas <[email-masked] >
Date: Sunday, January 20, 2013 5:12 PM
To: Stefan Santesson <[email-masked]>, Stephen Kent <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

 
 
   NoCheck ::= NULL

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

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

---

From: Michael StJohns <[email-masked]>
Date: Mon, 28 Jan 2013 00:29:25 -0500

At 09:47 PM 1/27/2013, Jim Schaad wrote:

>It is perfectly legal for it to not have a value even with the newer syntax.  That is both absent and not absent are legal to put here.  There is not current syntax to say that the internal value is optional.  But if there is no type associated with the OID then the correct answer is that the ASN.1 for it would be an empty string.
>
> 

Um - probably not.

The "new" syntax  (e.g. both X.509 and RFC5912) to define an extension is 

extensionName EXTENSION ::= {
         SYNTAX   <valid ASN1 type or user type>
          IDENTIFIED BY <object identifier>
}

NULL is a valid type.   The empty string is not.  Or is there a way you can see where this can be expressed?

You had 

>id-pkix-ocsp-nocheck } ---- with the type defined

And either of those would work.  But I don't think that

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

is valid ASN1. 

And I don't think that

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

is a valid extension definition.

Mike

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 28 Jan 2013 09:16:10 +0100

On 01/28/2013 03:47 AM, Jim Schaad wrote:
>
> Michael,
>
> It is perfectly legal for it to not have a value even with the newer syntax.  That is both absent 
> and not absent are legal to put here.  There is not current syntax to say that the internal value 
> is optional.  But if there is no type associated with the OID then the correct answer is that the 
> ASN.1 for it would be an empty string.
>

an asn.1 value is not empty.

5280 asn.1 syntax allows an empty octet string but this
is not conformant with the comment.

if a relying party knows about an extension there is a bilateral
agreement with the issuer of the extension about a type and
that there is an encoding of a value of that type.
in this case the octet string cannot be empty.

there may be relying parties that do not decode non recognized
extensions, but creating one that has no value seems clearly wrong
according to the definition.

The newer syntax makes an empty octet string illegal in asn.1
a correctly implemented encoder would require a value in its api.
decoders that reject this, that's another story.

> Russ,
>
> It would not surprise me if something that was just randomly decoding would have problems in this 
> case.  However, if the decoding is not directed by the OID then there is a problem because it will 
> not know how to treat all of the ASN.1 it might encode.  For example while it could decode the 
> basic pieces of an implicitly tagged value, it would have no idea what any of it meant.  I don't 
> think I would overly worry about this case except for things like Peter's ASN.1 dumpper.
>
> Jim
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf Of *Michael StJohns
> *Sent:* Sunday, January 27, 2013 2:18 PM
> *To:* Russ Housley; IETF PKIX
> *Subject:* Re: [pkix] ASN.1 expression of extensions with absent extension value
>
> We know that some software automatically tries to decode the content of the OCTET STRING.  Will 
> this software fail if the OCTET STRIN is zero length?
>
> Russ
>
>
>
> The X.509 standard uses:
>
>
> *Extension ::= SEQUENCE {
>                 ENCODED BY der)}*
> Which suggests that you can't just use an empty OCTET STRING since there is no "empty" ExtnType.  
> For  NULL is a better choice than <empty>.
>
>
>
>
>
> From: Denis Pinkas <[email-masked] <mailto:[email-masked]> >
> To: Stefan Santesson <[email-masked] <mailto:[email-masked]>>, Stephen Kent <[email-masked] 
> <mailto:[email-masked]>>
> Cc: pkix <[email-masked] <mailto:[email-masked]>>
> *   This SHOULD be a non-critical extension. The value of the extension
>    SHALL be NULL.
>
> *The ASN.1 syntax is missing. Add:
> *
>    NoCheck ::= NULL
> *
>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 28 Jan 2013 08:59:03 +0000

Hi Stefan,

On 27 Jan 2013, at 13:19, Stefan Santesson <[email-masked]> wrote:

> Firs I resubmitted version 09, which I unsuccessfully tried to publish on the 16th of Jan. This draft captures changes to respond the the extensive debate and reviews on the list up until the 16th.
> Draft 10 deals with Alexey's comments.

This looks good. I will reply to your point about proxies/clients separately.
> Draft 11 includes updates due to Deni's list of comments, excluding the ASN.1 question posted separately on the list.
> /Stefan
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 28 Jan 2013 09:56:19 +0100

Jim,

RFC 2560bis currently has no 2002 syntax as it just refers to 5912.

I realise that we need this not only for the nocheck extension, but also
for the new extended-revoke extension, which is an OCSP extension BTW.

I would hate for the RFC2560bis to have to wait for an update of 5912.
Should I just import the ASN.1 from 5912 into RFC 2560 bis, get a new
module OID and then add the extension definitions to this new module?

I would then:
- Add that rfc2560bis updates 5912
- Add: 
ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY
id-pkix-ocsp-nocheck }

- Add:
re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY
id-pkix-ocsp-extended-revoke }

Is that a reasonable course of action?

/Stefan

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 28 Jan 2013 12:48:06 +0100

>From a pure ASN.1 view point, both an empty octet string syntax and a NULL
syntax are legal. However, in the latter case, the NULL has to be imbedded
in the octet string, i.e., is encoded as: 24020500H.

However, you have a much more fundamental problem. A general tool is not
able to judge whether the syntax imbedded in the octet string is legal or
not. Only a specialised tool that "knows" the different extension can make
that check.

An extension with syntax octet string without restriction is a goody for an
attacker attempting to do a collision attack.

The X.509 definition of extension does not have that problem.

Erik

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af
Michael StJohns
Sendt: 28. januar 2013 06:29
Til: Jim Schaad; 'Russ Housley'; 'IETF PKIX'
Emne: Re: [pkix] ASN.1 expression of extensions with absent extension value

At 09:47 PM 1/27/2013, Jim Schaad wrote:

>It is perfectly legal for it to not have a value even with the newer
syntax.  That is both absent and not absent are legal to put here.  There is
not current syntax to say that the internal value is optional.  But if there
is no type associated with the OID then the correct answer is that the ASN.1
for it would be an empty string.

Um - probably not.

extensionName EXTENSION ::= {
         SYNTAX   <valid ASN1 type or user type>
          IDENTIFIED BY <object identifier> }

NULL is a valid type.   The empty string is not.  Or is there a way you can
see where this can be expressed?

You had 

is valid ASN1. 

And I don't think that

Mike

---

From: Russ Housley <[email-masked]>
Date: Mon, 28 Jan 2013 12:35:23 -0500

Jim:

Peter's ASN.1 dumper is one example.  What about Microsoft's certificate viewer?

Russ

On Jan 27, 2013, at 9:47 PM, Jim Schaad wrote:

> It would not surprise me if something that was just randomly decoding would have problems in this case.  However, if the decoding is not directed by the OID then there is a problem because it will not know how to treat all of the ASN.1 it might encode.  For example while it could decode the basic pieces of an implicitly tagged value, it would have no idea what any of it meant.  I don’t think I would overly worry about this case except for things like Peter’s ASN.1 dumpper.
>  
> Jim
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael StJohns
> Subject: Re: [pkix] ASN.1 expression of extensions with absent extension value
>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 28 Jan 2013 10:32:26 -0800

If memory serves, for those things which it understands it decodes content.
For everthing else it just does a hex dump of the contents and would handle
an empty octet string just fine.

jim

From: Russ Housley [mailto:[email-masked]] 
Sent: Monday, January 28, 2013 9:35 AM
To: Jim Schaad
Cc: IETF PKIX
Subject: Re: [pkix] ASN.1 expression of extensions with absent extension
value

Jim:

Peter's ASN.1 dumper is one example.  What about Microsoft's certificate
viewer?

Russ

Michael,

Russ,

Jim

   Extension  ::=  SEQUENCE  {

Russ

The X.509 standard uses:

Extension ::= SEQUENCE {

/Stefan

 

   NoCheck ::= NULL

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 28 Jan 2013 12:09:27 -0800

Suggest changing "may" to "MAY".

On Jan 27, 2013, at 4:28 AM, Stefan Santesson wrote:

>> This text is misleading because readers may think that OCPS necessarily provides “timely information”.
>>  
> 
> "may" does not mean "necessarily".
> 

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 28 Jan 2013 21:07:58 +0100

Before we drift too far away from the core issue, Is there an opinion
about whether what I propose here would be the right way to go?
/Stefan

---

From: Simon Tardell <[email-masked]>
Date: Mon, 28 Jan 2013 21:39:46 +0100

Sent from my iPhone

> Suggest changing "may" to "MAY".

 MAY to me means "it is permissible" (which is quite distinct from "may" in this context).

I think Denis has a point, but uses to precise examples. It suffices to say that the timelyness of the information depends on implementational details of the responder and is in no way guaranteed by the protocol.

/Simon

>>>   may be necessary to obtain timel information regarding the

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 28 Jan 2013 22:12:47 +0100

I believe the lower case "may":s are intentional as it does not express
testable requirements for interoperability.
This is just background information, helping the reader understand the
rationale for the protocol.

Thus I think the text is sufficiently OK to be left as it is.

/Stefan

On 1/28/13 9:39 PM, "Simon Tardell" <[email-masked]> wrote:

>I think Denis has a point, but uses to precise examples. It suffices to
>say that the timelyness of the information depends on implementational
>details of the responder and is in no way guaranteed by the protocol.
>
>/Simon
>
>
>> 
>>>> This text is misleading because readers may think that OCPS
>>>>necessarily provides ³timely information².
>>>

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 28 Jan 2013 22:44:09 +0100

On 01/28/2013 07:32 PM, Jim Schaad wrote:
>
> If memory serves, for those things which it understands it decodes content.  For everthing else it 
> just does a hex dump of the contents and would handle an empty octet string just fine.
>
yes:

A relying party that doesn't understant the OID, refuses to do whatever.
For the convenvience of the poor user it may try like the other Peter's dumpasn.
Well, sorry dear user, there is an extension  taht I don't understant etc, the content
of the thingy is this and that. A consequence of this is that there may be somewhere
a recommendation not to use implicit context tags for such syntaxes for primitive types

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 29 Jan 2013 09:52:29 +1100

> >I realise that we need this not only for the nocheck extension, but
> >also for the new extended-revoke extension, which is an OCSP extension
> BTW.
> >

> about whether what I propose here would be the right way to go?

Yes, adding "ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY id-pkix-ocsp-nocheck }" is the right way to go.

P.S. We had this discussion on this list 7 months ago. See thread titled "id-pkix-ocsp-nocheck extension: NULL vs empty": starting at http://www.ietf.org/mail-archive/web/pkix/current/msg31222.html, concluding http://www.ietf.org/mail-archive/web/pkix/current/msg31226.html.

--
James Manger

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 29 Jan 2013 09:08:47 +0100

On a very minor side note.

I have a JavaScript based DER decoder on my website:
http://aaa-sec.com/other/jsasn1/index.html
I can upload binary DER, paste hex dumps or paste Base64 coded certs to
examine content.

I pasted the Nocheck hex dump with NULL value
(300F06092B060105050730010504020500) and that decodes just fine.
Then I pasted the Nocheck example with absent value
(300D06092B06010505073001050400) and that crashes.

Not that this need to say much butŠ

/Stefan

From:  Jim Schaad <[email-masked]>
Date:  Monday, January 28, 2013 7:32 PM
To:  Russ Housley <[email-masked]>
Cc:  'IETF PKIX' <[email-masked]>
Subject:  Re: [pkix] ASN.1 expression of extensions with absent extension
value

> For everthing else it just does a hex dump of the contents and would handle an
> empty octet string just fine.
>  
> jim
>  
> 
> current syntax to say that the internal value is optional.  But if there is no
> type associated with the OID then the correct answer is that the ASN.1 for it
> would be an empty string.
> 
>  
> 
> Russ,
> 
>  
> 
> ASN.1 it might encode.  For example while it could decode the basic pieces of
> an implicitly tagged value, it would have no idea what any of it meant.  I
> don¹t think I would overly worry about this case except for things like
> Peter¹s ASN.1 dumpper.
> 
>  
> 
> Jim
> 
>  
> 
>  
> 
> Which suggests that you can't just use an empty OCTET STRING since there is no
> "empty" ExtnType.  For  NULL is a better choice than <empty>.
> 
> 
> 
> 
> 
> 
> provide an Extension definition with a Syntaxt holding an element with a NULL
> value?
>

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 29 Jan 2013 10:35:40 +0100

I agree with James. This correct ASN.1 and will complete the ASN.1 module.
It will also be consistent with other specifications, e.g. X.509.

Erik Andersen 

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af
Manger, James H
Sendt: 28. januar 2013 23:52
Til: Stefan Santesson; Jim Schaad; 'pkix'
Emne: [Spam] Re: [pkix] ASN.1 expression of extensions with absent extension
value

> about whether what I propose here would be the right way to go?

Yes, adding "ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY
id-pkix-ocsp-nocheck }" is the right way to go.

P.S. We had this discussion on this list 7 months ago. See thread titled
"id-pkix-ocsp-nocheck extension: NULL vs empty": starting at
http://www.ietf.org/mail-archive/web/pkix/current/msg31222.html, concluding
http://www.ietf.org/mail-archive/web/pkix/current/msg31226.html.

--
James Manger