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

[Denis Pinkas <[e-mail]>]

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