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

[Sean Turner <[e-mail]>]

Denis,

You probably saw version -15 was published.  I reviewed your comments 
and I think it's time to move this draft down to IETF LC.

spt

On 3/11/13 5:14 AM, Denis Pinkas wrote:
> *Stefan,*
>
> **
>
> *The review of your individual draft, took me the time I had during the
> week for the IETF stuff;
> hence, why this reply has been delayed.*
>
> *The situation is rather simple, if we forget about the editorial comments,
> you have accepted one minor text change and that’s all.*
>
> **
>
> *So the major problems are not solved to my satisfaction.*
>
> **
>
> *I have maintained below the portion of the text which needs to be
> further discussed. **
> **My comments are in blue.*
>
> **
>
> *There is a new and very important issue that I discovered while reading
> your comments. **
> **See the discussion about singleExtensions and of responseExtensions.*
>
> *Comment 8*: You have changed the meaning of the revoked state in a way
> that is not what I requested.
>
> The original text was:
>
> *The "revoked" state indicates that the certificate has been revoked*
>
> *(either permanantly or temporarily (on hold)).*
>
> The new text is:
>
> *    The "revoked" state indicates that the certificate has been revoked*
>
> *    either permanently or temporarily on hold (i.e. the revocation reason*
>
> *    is certificateHold).*
>
> By doing this, you do not allow any other case in the future to have a
> temporary revocation: “*temporarily on hold”***is not the same
> as*“**temporarily revoked”**.*
>
> I propose the following rewording:
>
> *The "revoked" state indicates that the certificate has been revoked *
>
> *    either permanently or temporarily (e.g. placed on hold).*
>
> I substituted "temporarily on hold" with "temporarily. The rest
> unchanged since the only existing reason code for temporary revocation
> is certificateHold.
>
> *As you say, the only CURRENT existing reason code for temporary
> revocation is certificateHold. **
> **We must not PREVENT other reasons in the future to mean “temporary
> revocation”, hence why the change is needed.*
>
> The way the text from draft 13 is now written seems to allow using
> either *“unknown”*or *“revoked”*for non-issued certificates.
> If this is the intent, then the good news is that this does not come
> anymore into conflict with the French rules which apply
> for the Administration since OCSP responders from CAs used by the French
> Ministries having a direct access to the database of issued certificates
> will be able to use *“unknown*”, rather than *“revoked”*and the reason
> code *“onhold”.*
>
> However, the current text is still mandating the use of *Extended
> Revoked Definition*, but the rational for its need it is very poor.
> As I have said on the PKIX list, the fact that the revocation date is
> January 1rst, 1970 is fully sufficient to know that we are in that very
> special case,
> and you have not provided a rational to say the contrary.
>
> I have. And I have pointed you to the minutes of the last PKIC meeting.
>
> The consensus of the WG is to have the extension for just those reasons.
>
> As implementer, I don't like heuristics. A date of Jan 1st 1970 may
> indicate this behaviour,
> but may just be a misconfiguration. It is not an explicit statement.
>
> So we could get rid of it, … but the text from section 4.4.8 states:
>
> *    This extension MAY be present in other responses to signal that the*
>
> *    responder implements the extended revoked definition in section 2.2.*
>
> I have difficulties to understand what is really meant there (“other
> responses” ?), since the text states:
>
> *    This extension indicates that the responder supports the extended*
>
> *    definition of the "revoked" status to also include non-issued*
>
> *    certificates according to section 2.2.*
>
> Since both “unknown” and revoked” can be used, it would be desirable to
> be able to include the same extension in both cases,
> but in that case that extension should be renamed.
>
> This extension can be included in all responses to signal that a
> responder implements the expanded definition of revoked.
>
> Doing so makes this fact auditable without having to ask for a
> non-issued cert.
>
> I would propose to rename it: "*non-issued certificate*” which means
> that the associated CA has no record of ever having issued a certificate
> with the certificate serial number in the request (I still consider it
> as unnecessary in the case of “revoked”, but it would be very useful in
> the case of “unknown”).
> Of course, the text from section 4.4.8 would need to be revised.
>
> I propose the following:
>
> *  *
>
> *4.4.8   Non-issued certificate extension*
>
> *    This extension MUST be included in the OCSP response when the OCSP*
>
> *    responder knows that the CA identified in the request has no record*
>
> *    of ever having issued a certificate with the certificate serial*
>
> *    number indicated in the request.*
>
> *    Clients do not have to parse this extension in order to determine*
>
> *    the status of certificates in responses.*
>
> *    This extension is identified by the object identifier id-pkix-ocsp-*
>
> *    non-issued-cert.*
>
> *      id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}*
>
> *    The value of the extension SHALL be NULL. This extension MUST NOT be*
>
> *    marked critical.*
>
> Then the text on page 8 would need to be rearranged.
>
> Your extension  variant is a significant change to what has been agreed.
>
> Your extension would need to be a single response extension, and can't
> be used to audit the behaviour of the OCSP responder
> unless you send a request for a non-issued cert.
>
> *Hummm !!! We have a very important point there. Thanks to your comment,
> I now realize that the proposed extension
> applies to the whole response. However, this is not possible and I will
> now explain why. An OCSP responder may receive
> a delegation from several CAs. With some of them, it can use a direct
> access to the database of certificates,
> while for some others, it will use CRLs. So the meaning of “revoked”
> will depend of the CA. *
>
> **
>
> *This means that the indication cannot be global to the OCSP response.
> If we use an extension, it can only apply **
> **to an individual response and thus MUST in singleExtensions instead of
> responseExtensions.*
>
> **
>
> *Since it is singleExtension, it can used to “audit the behaviour of the
> OCSP responder” and I do not grasp your rational **
> **when you say “unless you send a request for a non-issued cert”. There
> is no need for sending anything.*
>
> We want to avoid sending such fake requests for audit purposes as it may
> interfere with systems at the responder trying to detect existence of
> rouge certificates.
>
> *There is no need to sending fake requests.*
>
> This is a type of change that I can't make unless you get support from a
> majority of the WG for the change of direction you propose.
>
> *The important point is that the text states:*
>
> **
>
> *“The "revoked" state (…) _MAY also be returned_ if the associated CA
> has no record of ever having issued a certificate
> with the certificate serial number in the request, using any current or
> previous issuing key (referred to as a
> "non-issued" certificate in this document).”*
>
> **
>
> *The test does **_not_**state “**_MUST_**also be returned”. This means
> that it is also possible to reply “unknown” if the associated CA **
> **has no record of ever having issued a certificate with the certificate
> serial number in the request. However, this is not **
> **straightforward when reading the text and thus the text should be made
> more explicit.*
>
> **
>
> *Now, we get to the main point. The reason for adding an extension is
> NOT to say that an extended meaning of revoked **
> **is being used, but that the INDIVIDUAL response is given using a
> direct access to the records of the certificates issued by the CA.*
>
> The current text is:
>
> *    This state MAY also be returned if the*
>
> *    associated CA has no record of ever having issued a certificate with*
>
> *    the certificate serial number in the request, using any current or*
>
> *    previous issuing key (referred to as a "non-issued" certificate in*
>
> *    this document).*
>
> *    The "unknown" state indicates that the responder doesn't know about*
>
> *    the certificate being requested.*
>
> *    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.*
>
> *    When a responder responds revoked to a status request for a non-*
>
> *    issued certificate, the responder MUST include the extended revoked*
>
> *    definition response extension (section 4.4.8) in the response,*
>
> *    indicating that the OCSP responder supports the extended definition*
>
> *    of revoked state to also cover non-issued certificates. In addition,*
>
> *    the SingleResponse related to this non-issued certificate;*
>
> *     - MUST provide the revocation reason certificateHold (6),*
>
> *     - MUST specify the revocationTime January 1, 1970, and;*
>
> *     - MUST NOT include a CRL References extension (section 4.4.2) or any*
>
> *       CRL Entry Extensions (section 4.4.5).*
>
> Proposed text for a replacement:
>
> *    The "unknown" state indicates that the responder doesn't know about*
>
> *    the certificate being requested.*
>
>
>
> *    If the OCSP responder knows that CA identified in the request has*
>
> *    no record of ever having issued a certificate with the certificate*
>
> *    serial number in the request, using any current or previous issuing*
>
> *    key (referred to as a "non-issued" certificate in this document),*
>
> *    the OCSP responder SHALL respond either “revoked “ or “unknown”.*
>
> This is unfortunately very common in your rewording efforts. When trying
> to fix one thing, you create new even bigger problems.
>
> An infrastructure that provides reproduced responses will respond
> "unauthorized". This text may be interpreted to interfere with such
> operations.
>
> *I fear I don’t understand your argument about “unauthorized”, but
> before replying see below my next comment.*
>
> Further, and worse. This is not backwards compatible. Current OCSP
> responders may respond "good" even if they have access to CA records.
>
> *You say: “Current OCSP responders may respond "good" even if they have
> access to CA records”. Originally RFC 2560 allowed
> returning “good” for OCSP responder using CRLs. Since RFC 2560 provided
> no way to indicate that a direct access to the database
> was being used or not, it was not possible to do better. *
>
> **
>
> *Now, if an OCSP responder has a direct access and indicates in the
> response that it has such an access, do you really believe
> that it will return good ? I don’t. *
>
> **
>
> *If an OCSP responder wants to return “good”, it can still do it, but in
> that case it will not signal that it is using a direct access **
> **and this is perfectly backwards compatible. So I do not “buy” your
> argumentation.*
>
> **
>
> *Now, may be you understand better why I propose to rename the extension
> “4.4.8 Non-issued certificate extension” and **
> **also to change its semantics.*
>
> *    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 possible when*
>
> *    the "unknown" response is returned.*
>
> *    When a responder responds revoked or unknown to a status request*
>
> *    for a non-issued certificate, the responder MUST include the*
>
> *    non-issued certificate extension (see section 4.4.8) in the*
>
> *    response.*
>
> *    When a responder responds revoked to a status request for a non-*
>
> *    issued certificate, in addition, the responder:*
>
> *     - MUST provide the revocation reason certificateHold (6),*
>
> *     - MUST specify the revocationTime January 1, 1970, and;*
>
> *     - MUST NOT include a CRL References extension (section 4.4.2) or any*
>
> *       CRL Entry Extensions (section 4.4.5).*
>
> Finally, the last bullet on page 4 should be reworded:
>
> Current text:
>
> *       o Section 4.4.8 specifies a new extension that indicates that the*
>
> *          responder supports the extended use of the "revoked" response*
>
> *          for non-issued certificates defined in section 2.2.*
>
> Proposed replacement text:
>
> *       o   Section 4.4.8 specifies a new extension that indicates that*
>
> *          the OCSP responder knows that CA identified in the request*
>
> *          has no record of ever having issued a certificate with the*
>
> *          certificate serial number present in the request, as defined*
>
> *          in section 2.2.*
>
> No. Again, this changes the scope of the extension and its audit properties.
>
> Such change requires WG consensus.
>
> *See earlier comments.*
>
> *Comment 9:*Solved, if the comment above may be solved.
>
> *Comment 20*:This comment is preliminary classified by you as “not
> broken”. However, since you asked: “If you don’t replace 4.2.2.3,
> then what really are you missing ?”, I will provide you with an answer.
>
> This is the wrong way to state the question. Providing an ASN.1 syntax
> as in 4.2.1 is not enough: the use of every parameter MUST be explained
> using English words. So if you explain the use of every parameter after
> the description of the ASN.1 syntax in section 4.2.1. then section 4.2.2.3
> is no more needed and thus can be deleted.
>
> The answer to your question “what is really missing” is a description of
> the use of every parameter listed in the ASN.1 in section 4.2.1
>
> There are sufficient descriptions in the subsections following the ASN.1
> description. Your change proposals are not compatible with the minimalistic
> approach adopted by the WG.
>
> *The key point is whether we want a “good” document or maintain the low
> quality of the original document.***
>
> *Comment 26*: You asked for explanations. Let me provide you with an
> example when CRLs are being used by the OCSP responder in the background.
> The OCSP responder needs to make sure that the CRL it uses is valid. If
> it is simply using published CRLs (i.e. no trusted link with the CA), it
> needs
> to make sure that the CA which has issued the CRL has no been revoked.
>
> No, this is a misstatement. You don't revoke CAs. You revoke CA
> certificates.
>
> *Right.*
>
> There might be a CA certificate that has been revoked for a reason that
> does not affect the OCSP responder.
>
> * ..but the contrary may also apply.*
>
> These are operational policies that are outside the scope of the protocol.
>
> *The proposed text does not affect the protocol.*
>
> The proposed text in comment 26 is plain wrong, or at least misleading.
> The OCSP responder does not have to validate the CRL up to any
> particular root.
> It may for example have been configured to directly trust the public key
> used to validate the CRL.
>
> *T**his depends how it makes sure that it is reading the right CRL. It
> may or may not use a root CA.*
>
> In France, there is a root CA for the Administration. However, the use
> of that root CA is optional. Thus a Ministry may have its own root,
> but may also have its key certified by the root CA of the
> Administration. The OCSP responder may use the root CA of the Ministry,
> while a relying party may use the root CA of the Administration (or the
> reverse) to validate the CRL for the target certificate.
> Thus the revocation status will be different if the certificate of the
> CA of the Ministry is revoked by the root CA of the Administration.
>
> Which reinforces my point. How the OCSP responder is configured to trust
> its information source is outside the scope of the protocol.
>
> The OCSP protocol never claims to provide the same conclusion about
> revocation than another source the relying party may use.
>
> *We both agree; however would you point me where this is said in the
> current draft? Since I could not find it,
> I believe it is useful to highlight the point in the security
> considerations section.
> *
>
> *
> *
>
> *Finally, I believe that the major point indicated earlier comes from
> the original "bad writing" of  RFC 2560.*
>
> *There is no clear distinction between what applies to
> ***BasicOCSPResponse* and ***what applies *to Single Response.*
>
> *On page 15 from draft-14, the text still states in section  4.2.2.2
> Authorized Responder:
>
>     "It is necessary however to ensure that the entity signing this
> information is authorized to do so".
>
> This is vague. What is "this information " ? This text is within section
> "4.2.2  Notes on OCSP Responses".
> This does not help much.
>
> Is it BasicOCSPResponse ? If it is , this is wrong.
>
> It is SingleResponse, since a single response may be signed by the right
> key and/or the right certificate,
> but not another single response.
>
> How can a reader guess that it is SingleResponse ?
>
> Once again the quality of the text is really bad, and that text and some
> other portions  (3.2  Signed Response Acceptance Requirements)
> would need to be changed.
> *
>
> **
>
> *Denis*
>
>
>
>> Denis,
>>
>> My replies in line;
>>
>> From: Denis Pinkas <[e-mail] <mailto:[e-mail]>>
>> Date: Monday, February 11, 2013 3:18 PM
>> To: Stefan Santesson <[e-mail] <mailto:[e-mail]>>
>> Cc: Stephen Kent <[e-mail] <mailto:[e-mail]>>, pkix
>> <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC
>>
>>     Stefan,
>>
>>     I have finally reviewed your disposition of comments. I have used
>>     draft 13.
>>
>>     I will not address the comments in sequence, but I will consider
>>     four categories:
>>
>>     *Category 1)*Some comments which seem to be solved. Yes indeed,
>>     they may be a few of them !
>>
>>     *Category 2)*Some comments which might possibly be solved at the
>>     WG level.
>>
>>     *Category 3)*Some comments that I will address at the IETF last
>>     call level, rather than the WG last call level, since I disagree
>>     that it is “new ways to say the same thing” and it is likely to be
>>     a waste of time for both of us to argue again at the WG level
>>     (these comments are commented as “not broken”).
>>
>>     *Category 4)*Some typos and editorials found while reading draft 13.
>>
>>     *CATEGORY 1*
>>
>>     *Comment 4*(was editorial).
>>
>>     *Comment 5.*
>>
>>     **
>>
>>     *Comment 6. *
>>
>>     *Comment 19*. Solved, since *“unknown”*seems now to be also
>>     allowed for non-issued certificates
>>     (even if the OCSP responder is using a direct access to the
>>     certificate database). See comment 8.
>>
>>     *Comment 13*: Acceptable, since the text uses *“MAY”.*
>>
>>     *Comment 18. *
>>
>>     *Comment 22.*
>>
>>     *Comment 23.*
>>
>>     *Comment 28.*
>>
>>     *CATEGORY 1*
>>
>>     *Comment 8*: You have changed the meaning of the revoked state in
>>     a way that is not what I requested.
>>
>>     The original text was:
>>
>>     *The "revoked" state indicates that the certificate has been revoked*
>>
>>     *(either permanantly or temporarily (on hold)).*
>>
>>     The new text is:
>>
>>     **
>>
>>     *    The "revoked" state indicates that the certificate has been revoked*
>>
>>     *    either permanently or temporarily on hold (i.e. the revocation reason*
>>
>>     *    is certificateHold).*
>>
>>     By doing this, you do not allow any other case in the future to
>>     have a temporary revocation: “*temporarily on hold”**
>>     *is not the same as*“**temporarily revoked”**.*
>>
>>     I propose the following rewording:
>>
>>     *The "revoked" state indicates that the certificate has been revoked *
>>
>>     *    either permanently or temporarily (e.g. placed on hold).*
>>
>>
>> I substituted "temporarily on hold" with "temporarily. The rest
>> unchanged since the only existing reason code for temporary revocation
>> is certificateHold.
>>
>>
>>
>>     The way the text from draft 13 is now written seems to allow using
>>     either *“unknown”*or *“revoked”*for non-issued certificates.
>>     If this is the intent, then the good news is that this does not
>>     come anymore into conflict with the French rules which apply for
>>     the Administration since OCSP responders from CAs used by the
>>     French Ministries having a direct access to the database
>>     of issued certificates will be able to use *“unknown*”, rather
>>     than *“revoked”*and the reason code *“onhold”.*
>>
>>     However, the current text is still mandating the use of *Extended
>>     Revoked Definition*, but the rational for its need it is very poor.
>>     As I have said on the PKIX list, the fact that the revocation date
>>     is January 1rst, 1970 is fully sufficient to know that we are in that
>>     very special case, and you have not provided a rational to say the
>>     contrary.
>>
>>
>> I have. And I have pointed you to the minutes of the last PKIC meeting.
>> The consensus of the WG is to have the extension for just those reasons.
>>
>> As implementer, I don't like heuristics. A date of Jan 1st 1970 may
>> indicate this behaviour, but may just be a misconfiguration. It is not
>> an explicit statement.
>>
>>     So we could get rid of it, … but the text from section 4.4.8 states:
>>
>>     *    This extension MAY be present in other responses to signal that the*
>>
>>     *    responder implements the extended revoked definition in section 2.2.*
>>
>>     I have difficulties to understand what is really meant there
>>     (“other responses” ?), since the text states:
>>
>>     *    This extension indicates that the responder supports the extended*
>>
>>     *    definition of the "revoked" status to also include non-issued*
>>
>>     *    certificates according to section 2.2.*
>>
>>     Since both “unknown” and revoked” can be used, it would be
>>     desirable to be able to include the same extension in both cases,
>>     but in that case that extension should be renamed.
>>
>>
>> This extension can be included in all responses to signal that a
>> responder implements the expanded definition of revoked.
>> Doing so makes this fact auditable without having to ask for a
>> non-issued cert.
>>
>>
>>     I would propose to rename it: "*non-issued certificate*” which
>>     means that the associated CA has no record of ever having issued
>>     a certificate with the certificate serial number in the request (I
>>     still consider it as unnecessary in the case of “revoked”, but it
>>     would be
>>     very useful in the case of “unknown”). Of course, the text from
>>     section 4.4.8 would need to be revised.
>>
>>     I propose the following:
>>
>>     *4.4.8   Non-issued certificate extension*
>>
>>     *  *
>>
>>     *    This extension MUST be included in the OCSP response when the OCSP*
>>
>>     *    responder knows that the CA identified in the request has no record*
>>
>>     *    of ever having issued a certificate with the certificate serial*
>>
>>     *    number indicated in the request.*
>>
>>     *  *
>>
>>     *    Clients do not have to parse this extension in order to determine*
>>
>>     *    the status of certificates in responses.*
>>
>>     *  *
>>
>>     *    This extension is identified by the object identifier id-pkix-ocsp-*
>>
>>     *    non-issued-cert.*
>>
>>     *  *
>>
>>     *      id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}*
>>
>>     *  *
>>
>>     *    The value of the extension SHALL be NULL. This extension MUST NOT be*
>>
>>     *    marked critical.*
>>
>>     Then the text on page 8 would need to be rearranged.
>>
>>
>> Your extension  variant is a significant change to what has been agreed.
>> Your extension would need to be a single response extension, and can't
>> be used to audit the behaviour of the OCSP responder unless you send a
>> request for a non-issued cert.
>> We want to avoid sending such fake requests for audit purposes as it
>> may interfere with systems at the responder trying to detect existence
>> of rouge certificates.
>>
>> This is a type of change that I can't make unless you get support from
>> a majority of the WG for the change of direction you propose.
>>
>>     The current text is:
>>
>>     *    This state MAY also be returned if the*
>>
>>     *    associated CA has no record of ever having issued a certificate with*
>>
>>     *    the certificate serial number in the request, using any current or*
>>
>>     *    previous issuing key (referred to as a "non-issued" certificate in*
>>
>>     *    this document).*
>>
>>     *  *
>>
>>     *    The "unknown" state indicates that the responder doesn't know about*
>>
>>     *    the certificate being requested.*
>>
>>     *  *
>>
>>     *    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.*
>>
>>     *  *
>>
>>     *    When a responder responds revoked to a status request for a non-*
>>
>>     *    issued certificate, the responder MUST include the extended revoked*
>>
>>     *    definition response extension (section 4.4.8) in the response,*
>>
>>     *    indicating that the OCSP responder supports the extended definition*
>>
>>     *    of revoked state to also cover non-issued certificates. In addition,*
>>
>>     *    the SingleResponse related to this non-issued certificate;*
>>
>>     *  *
>>
>>     *     - MUST provide the revocation reason certificateHold (6),*
>>
>>     *  *
>>
>>     *     - MUST specify the revocationTime January 1, 1970, and;*
>>
>>     *  *
>>
>>     *      - MUST NOT include a CRL References extension (section 4.4.2) or any*
>>
>>     *       CRL Entry Extensions (section 4.4.5).*
>>
>>     Proposed text for a replacement:
>>
>>     *    The "unknown" state indicates that the responder doesn't know about*
>>
>>     *    the certificate being requested.*
>>
>>     *  *
>>
>>     *    If the OCSP responder knows that CA identified in the request has*
>>
>>     *    no record of ever having issued a certificate with the certificate*
>>
>>     *    serial number in the request, using any current or previous issuing*
>>
>>     *    key (referred to as a "non-issued" certificate in this document),*
>>
>>     *    the OCSP responder SHALL respond either “revoked “ or “unknown”.*
>>
>>
>> This is unfortunately very common in your rewording efforts. When
>> trying to fix one thing, you create new even bigger problems.
>>
>> An infrastructure that provides reproduced responses will respond
>> "unauthorized". This text may be interpreted to interfere with such
>> operations.
>> Further, and worse. This is not backwards compatible. Current OCSP
>> responders may respond "good" even if they have access to CA records.
>>
>>     *  *
>>
>>     *    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 possible when*
>>
>>     *    the "unknown" response is returned.*
>>
>>     *  *
>>
>>     *    When a responder responds revoked or unknown to a status request*
>>
>>     *    for a non-issued certificate, the responder MUST include the*
>>
>>     *    non-issued certificate extension (see section 4.4.8) in the*
>>
>>     *    response.*
>>
>>     *  *
>>
>>     *    When a responder responds revoked to a status request for a non-*
>>
>>     *    issued certificate, in addition, the responder:*
>>
>>     *  *
>>
>>     *     - MUST provide the revocation reason certificateHold (6),*
>>
>>     *  *
>>
>>     *     - MUST specify the revocationTime January 1, 1970, and;*
>>
>>     *  *
>>
>>     *     - MUST NOT include a CRL References extension (section 4.4.2) or any*
>>
>>     *       CRL Entry Extensions (section 4.4.5).*
>>
>>     Finally, the last bullet on page 4 should be reworded:
>>
>>     Current text:
>>
>>     *       o Section 4.4.8 specifies a new extension that indicates that the*
>>
>>     *          responder supports the extended use of the "revoked" response*
>>
>>     *          for non-issued certificates defined in section 2.2.*
>>
>>     **
>>
>>     Proposed replacement text:
>>
>>     *       o  Section 4.4.8 specifies a new extension that indicates that*
>>
>>     *          the OCSP responder knows that CA identified in the request*
>>
>>     *          has no record of ever having issued a certificate with the*
>>
>>     *          certificate serial number present in the request, as defined*
>>
>>     *          in section 2.2.*
>>
>>
>> No. Again, this changes the scope of the extension and its audit
>> properties.
>> Such change requires WG consensus.
>>
>>
>>     *Comment 9:*Solved, if the comment above may be solved.
>>
>>     *Comment 20*:This comment is preliminary classified by you as “not
>>     broken”. However, since you asked: “If you don’t replace 4.2.2.3,
>>     then what really are you missing ?”, I will provide you with an
>>     answer.
>>
>>     This is the wrong way to state the question. Providing an ASN.1
>>     syntax as in 4.2.1 is not enough: the use of every parameter
>>     MUST be explained using English words. So if you explain the use
>>     of every parameter after the description of the ASN.1 syntax
>>     in section 4.2.1. then section 4.2.2.3 is no more needed and thus
>>     can be deleted.
>>
>>     The answer to your question “what is really missing” is a
>>     description of the use of every parameter listed in the ASN.1 in
>>     section 4.2.1
>>
>>
>> There are sufficient descriptions in the subsections following the
>> ASN.1 description. Your change proposals are not compatible with the
>> minimalistic approach adopted by the WG.
>>
>>
>>     *Comment 21.*
>>
>>     While I can agree in general with the intent of the text, I do not
>>     understand the first sentence of the Note which speaks of “CA key
>>     rollover”
>>     and is copied below:
>>
>>     *    Note: CA key rollover is not prohibited when issuing a certificate*
>>
>>     *          for an authorized responder for backwards compatibility with*
>>
>>     *          RFC 2560 [RFC2560]. That is, it is not prohibited to issue a*
>>
>>     *          certificate for an authorized responder using a different*
>>
>>     *          issuing key than the key used to issued the certificate being*
>>
>>     *          checked for revocation. However, such practice is strongly*
>>
>>     *          discouraged since clients are not required to recognize a*
>>
>>     *          responder with such certificate as an authorized responder.*
>>
>>     I would propose to delete it, since it does not add anything and
>>     thus to have:
>>
>>     *    Note: For backwards compatibility with RFC 2560 [RFC2560], it is*
>>
>>     *          not prohibited to issue a certificate for an authorized*
>>
>>     *          responder using a different issuing key than the key used to*
>>
>>     *          issued the certificate being checked for revocation.*
>>
>>     *          However, such practice is strongly discouraged since clients*
>>
>>     *          are not required to recognize a responder with such*
>>
>>     *          certificate as an authorized responder.*
>>
>>
>> I agree, your text is better. Updated.
>>
>>     *Comment 24*: The ASN.1 module in annex B.1 is still wrong, since
>>     it does not define NoCheck.
>>
>>
>> No you are wrong. We have confirmed with several ASN.1 experts that
>> definition of NoCheck is not necessary to define null content.
>> The current definition is perfectly valid ASN.1
>>
>>     *Comment 26*: You asked for explanations. Let me provide you with
>>     an example when CRLs are being used by the OCSP responder
>>     in the background. The OCSP responder needs to make sure that the
>>     CRL it uses is valid. If it is simply using published CRLs
>>     (i.e. no trusted link with the CA), it needs to make sure that the
>>     CA which has issued the CRL has no been revoked.
>>
>>
>> No, this is a misstatement. You don't revoke CAs. You revoke CA
>> certificates. There might be a CA certificate that has been revoked
>> for a reason that does not affect the OCSP responder.
>> These are operational policies that are outside the scope of the protocol.
>>
>> The proposed text in comment 26 is plain wrong, or at least
>> misleading. The OCSP responder does not have to validate the CRL up to
>> any particular root. It may for example have been configured to
>> directly trust the public key used to validate the CRL.
>>
>>
>>     In France, there is a root CA for the Administration. However, the
>>     use of that root CA is optional. Thus a Ministry may have its own
>>     root,
>>     but may also have its key certified by the root CA of the
>>     Administration. The OCSP responder may use the root CA of the
>>     Ministry,
>>     while a relying party may use the root CA of the Administration
>>     (or the reverse) to validate the CRL for the target certificate.
>>     Thus the revocation status will be different if the certificate of
>>     the CA of the Ministry is revoked by the root CA of the
>>     Administration.
>>
>>
>> Which reinforces my point. How the OCSP responder is configured to
>> trust its information source is outside the scope of the protocol.
>>
>> The OCSP protocol never claims to provide the same conclusion about
>> revocation than another source the relying party may use.
>>
>> I skip category 3 as this will be dealt with in IESG last call.
>>
>>
>>     *CATEGORY 3*
>>
>>     *Comments*2, 3, 7, 10, 12, 14, 15, 16, 17, 25 and 27.
>>
>>     *CATEGORY 4*
>>
>>     Page 4. The indentation of the bullets in section 1 is not uniform.
>>     Bullets 1, 4, 5 and 9 have problems.
>>
>>     Page 4. The fact that there is now an Annex B.2 dealing with the
>>     2008 ASN.1 syntax is missing. This should be added.
>>
>>     Page 10. Change “*Se further section 4.2.2.2”*into “*See further
>>     section 4.2.2.2”
>>     *
>>
>>
>>
>> Thanks. I have fixed them all.
>>
>> /Stefan
>>
>>
>>     Denis
>>     **
>>
>>     =====================================================================================
>>
>>
>>
>>>     Denis,
>>>
>>>     Responding to your comments below.
>>>
>>>     However, one general 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 unless it is broken,
>>>         or the industry clearly need clarifications in order to avoid
>>>         interoperability issues.
>>>      2. We retain the document structure of RFC 2560 as much as
>>>         possible to allow easy comparison of what the changes are in
>>>         comparison with RFC 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 know
>>>     from experience which words worked to produce working
>>>     implementations, and which did not.
>>>     Introducing new ways to say the same thing may 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 wording does not have such problems that is merits a change.
>>>
>>>
>>>
>>>     From: Denis Pinkas <[e-mail]
>>>     <mailto:[e-mail]>>
>>>     Date: Sunday, January 20, 2013 5:12 PM
>>>     To: Stefan Santesson <[e-mail]
>>>     <mailto:[e-mail]>>, Stephen Kent <[e-mail]
>>>     <mailto:[e-mail]>>
>>>     Cc: pkix <[e-mail] <mailto:[e-mail]>>
>>>     Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC
>>>
>>>         Please find 32 comments on draft-ietf-pkix-rfc2560bis
>>>
>>>         1.The document states:
>>>
>>>         **<Cut away issue 1 regarding authorship etc, as it has been
>>>         responded to separately>
>>>
>>>
>>>     Responded to separately.
>>>
>>>         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”.
>>>
>>>
>>>
>>>
>>>     "may" does not mean "necessarily".
>>>
>>>         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.*
>>>
>>>
>>>
>>>
>>>
>>>
>>>     Not broken
>>>
>>>         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. *
>>>
>>>
>>>     Not broken
>>>
>>>         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.*
>>>
>>>
>>>     Fixed in draft 10.
>>>
>>>         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.
>>>
>>>
>>>
>>>
>>>     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)
>>>
>>>
>>>         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.*
>>>
>>>
>>>     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)
>>>
>>>         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.*
>>>
>>>
>>>     Not broken.
>>>     All of this is already covered by the document.
>>>
>>>         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.*
>>>
>>>
>>>
>>>
>>>     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.
>>>
>>>
>>>
>>>         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.**
>>>
>>>
>>>
>>>
>>>
>>>
>>>     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.
>>>
>>>
>>>         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.
>>>
>>>
>>>     Not broken.
>>>     The current text segments fits well into a protocol overview section.
>>>
>>>         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.
>>>
>>>
>>>     Not broken.
>>>
>>>         12.Remainder: Section 2.6 should be deleted (see comment
>>>         number 5).
>>>
>>>
>>>     Not broken.
>>>
>>>         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.
>>>
>>>
>>>
>>>     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.
>>>
>>>
>>>
>>>         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.
>>>
>>>
>>>     Not broken.
>>>
>>>         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.*
>>>
>>>
>>>     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.
>>>
>>>
>>>         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.
>>>
>>>
>>>     Not broken.
>>>
>>>         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.*
>>>
>>>
>>>     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.
>>>
>>>
>>>         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.
>>>
>>>
>>>     Not broken.
>>>
>>>     This requirement would break backwards compatibility with RFC 2560.
>>>     Further this would not be needed for a locally configured responder.
>>>
>>>         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) }*
>>>
>>>
>>>     Not broken.
>>>
>>>     You have to convince the list about your new reason code.
>>>
>>>         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.**
>>>
>>>         **
>>>
>>>
>>>     Preliminary I would say "not broken".
>>>     If you don't replace 4.2.2.3, then what really are you missing?
>>>
>>>         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.*
>>>
>>>
>>>     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.
>>>
>>>         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:*
>>>
>>>
>>>
>>>     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.
>>>
>>>
>>>         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.*
>>>
>>>
>>>     No, issuing with another key is not prohibited, and may be
>>>     accepted by some clients as an authorised responder.
>>>
>>>         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*
>>>
>>>         **
>>>
>>>
>>>     Moving this to a separate discussion.
>>>     I'm not sure what the preferred way to describe this is.
>>>
>>>
>>>         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.
>>>
>>>         **
>>>
>>>
>>>     Not broken.
>>>
>>>         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.*
>>>
>>>         **
>>>
>>>         **
>>>
>>>
>>>     I don't understand this one.
>>>
>>>         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.*
>>>
>>>         **
>>>
>>>
>>>     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.
>>>
>>>         **
>>>
>>>         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.*
>>>
>>>
>>>     Will move this (as stated above) to a separate discussion.
>>>
>>>         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.*
>>>
>>>
>>>     Not broken.
>>>     Each such amendment need to be thoroughly reviewed and motivated.
>>>
>>>
>>>         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.*
>>>
>>>
>>>     Not broken.
>>>
>>>     /Stefan
>>>
>>>         End of comments
>>>
>>>
>>>         Denis
>>>
>>>         _______________________________________________ pkix mailing
>>>         list [e-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/pkix
>>>
>>
>