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

[Stefan Santesson <[e-mail]>]

Denis,

My replies in line;

From: Denis Pinkas <[e-mail]>
Date:  Monday, February 11, 2013 3:18 PM
To  Stefan Santesson <[e-mail]>
Cc:  Stephen Kent <[e-mail]>, pkix <[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 lastcall level,
> rather than the WG last call level, since I disagree
>  that t is ³new ways to say the same thing² andit is likely to be a waste of
> time for both of us to argue again at the WG level
>  (these cmments are commented as ³not broken²).
>  
>  
>  
> Category 4) Some typos and edtorials 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 allowd for
> non-issued certificates
>  (even if the OCSP responder is using a direct ccess to the certificate
> database). See comment 8.
>  
>  
>  
> Comment 13: Aceptable, since the text uses ³MAY².
>  
>  
>  
> Comment 18. 
>  
>  
>  
> Comment 22.
>  
>  
>  
> Comment 23.
>  
>  
>  
> Comment 28.
>  
>  
>  
> CATEGORY 1
>  
>  
>  
> Comment 8: You have change 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 thatthe certificate has been revoked
>  
>    either permanentl or temporarily on hold (i.e. the revocation reason
>  
>    is certificateHold).
>  
>  
>  
> Bydoing this, you do not llow any other case in the future to have a
> temporary revocation: ³temporarilyon 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 "temporarly. The rest unchanged
since the only existing reason code for temporary revocation is
certificaeHold.


> 
>  
> 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 tothe 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 ratonal 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 t have the extension for just those reasons.

As implementer, I don't like heuritics. A date of Jan 1st 1970 may indicate
this behaviour, but may just be a misconiguration. It is not an explicit
statement.

>  
>  
> So we could get rid of it, Š but the text from section 4.4.8 states:
>  
>  
>  
>    This extension MA be present in other responses to signal that the
>  
>    responder implementsthe extended revoked definition in section 2.2.
>  
>  
>  
> I have difficulties to undersand what is really meant there (³other
 responses² ?), since the text states:
>  
>  
>  
>    This extension indicates that the reponder supports the extended
>  
>    definition of the "revoked" status to also include non-issued
>  
>    certificates according to section 2.2.
>  
>  
>  
> Sinc 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 canbe included in all responses to signal that a responder
implements the expandeddefinition of revoked.
Doing so makes this fact auditable without having to ask for a non-issued
cert.

> 
>  
> I would propse to rename it: "non-issued certificate² which means that the
> associated A has no record of ever having issued
>  a certificate with the certificate serialnumber in the request (I still
> consider it as unnecessary in the case of ³revoked², but it would be
>  very useful in the ase of ³unknown²). Of course, the text from section 4.4.8
> would need to be revisd.
>  
>  
>  
> I propose the following:
>  
>  
>  
> 4.4.8  Non-issued cetificate extension
>  
>  
>  
>    This extension MUST be included in the OCSP response when the OCSP
>  
>    responder knows that the CA identified in he request has no record
>  
>    of ever having issued a certificate with the cetificate 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 identifir id-pkix-ocsp-
>  
>    non-issued-cert.
>  
>  
>  
>      id-pkix-ocsp-nn-issued-cert OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}
>  
>  
>  
>    The value o the extension SHALL be NULL. This extension MUST NOT be
>  
>    marked critial.
>  
>  
>  
> Then the text on page 8 would need to be rearranged.
>  
>  

Your extensio  variant is a significant change to what has been agreed.
Your extension would ned 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.
e want to avoid sending such fake requests for audit purposes as it may
interfre with systems at the responder trying to detect existence of rouge
certificaes.

This is a type of change that I can't make unless you get support from amajority of the WG for the change of direction you propose.

>  
> 
> The curent 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 (reerred to as a "non-issued" certificate in
>  
>    this documnt).
>  
>  
>  
>    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
>  
>          numbes is allowed in order to reduce the risk of relying
>  
>          parties using RLs as a fall back mechanism, which would be
>  
>          considerably highe if an "unknown" response was returned.
>  
>  
>  
>    When a responder responds revoked to a status request for anon-
>  
>    issued certificate, the responder MUST include the extended revokd
>  
>    definition response extension (section 4.4.8) in the response,
>  
>    indicating that the OCSP responer supports the extended definition
>  
>    of revoked state to also cover non-isued certificates. In addition,
>  
>    the SingleResponse related to this nonissued certificate;
>  
>  
>  
>     - MUST provide the revocation reason cerificateHold (6),
>  
>  
>  
>     - MUST specify the revocationTime January 1, 1970, and;
>  
>  
>  
>     - MUS NOT include a CRL References extension (section 4.4.2) or any
>  
>       CRL Enry Extensions (section 4.4.5).
>  
>  
>  
> Proposed text for a replacement:
  
>  
>  
>    The "unknown" state indicates that the responder doesn't know bout
>  
>    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 previus issuing
>  
>    key (referred to as a "non-issued" certificate in this documet),
>  
>    the OCSP responder SHALL respond either ³revoked ³ or ³unknown².
>  

This is unfortunately very common n your rewording efforts. When trying to
fix one thing, you create new even bgger problems.

An infrastructure that provides reproduced responses will respond
"unauthorized". This text may be interpreted to interfer with such
operations.
Further, and worse. This is not backwards compatible. Curent 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
>  
>    he "unknown" response is returned.
>  
>  
>  
>    When a responder responds revoked or unknown to a status request
>  
>    for a non-issued certifiate, the responder MUST include the
>  
>    non-issued certificate extension (see section 4.4.8) in the
>  
>    response. 
>  
>  
>  
>    When a responder esponds 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 bulet 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-isued 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 requst
>  
>          has no record of ever having issued a ertificate with the
>  
>          certificate serial number present in the request, as defind
>  
>          in section 2.2.
>  
>  

No. Again, this changes the scope of theextension and its audit properties.
Such change requres WG consensus.


>  
> 
> Comment 9: Solved, if the comment above may be solved.
  
>  
>  
> Comment 20:  This comment is preliminary classified by you as ³not boken².
> 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 syntaxas in
> 4.2.1 is not enough: the use of every parameter
>  MUST be explainedusing English words. So if you explain the use of every
> parameter after the dscription of the ASN.1 syntax
>  in section 4.2.1. then section 4.2.2.3 is no ore needed and thus can be
> deleted.
>  
>  
>  
> The answer to your question ³what is really missing² is a descrition of the
> use of every parameter listed in the ASN.1 in section 4.2.1
>  
>  

here are sufficient descriptions in he subsections following the ASN.1
description. Your change proposals are not compatible withthe minimalistic
approach adopted by the WG.


>  
> 
> Comment 21.
>  
>  
>  
> While I can agree in general with the intent of the text, I d not understand
> the first sentence of the Note which speaks of ³CA key rollove²
>  and is copied below:
>  
>  
>  
>    Note: CA key rollover is not prohibted when issuing a certificate
>  
>          for an authorized responder for backwards compatibility with
>  
>          RFC 256 [RFC2560]. That is, it is not prohibited to issue a
>  
>          certificte for an authorized responder using a different
>  
>          issuing key than the key used to issued the certificate being
>  
>          checkedfor revocation. However, such practice is strongly
>  
>          discouraged since clients are not required to recognize a
>  
>          responder with such certiicate as an authorized responder.
>  
>  
>  
> I would propose to delete it, sinc it does not add anything and thus to have:
>  
>  
>  
>    Note: For backwards ompatibility with RFC 2560 [RFC2560], it is
>  
>          not prohibited to isse a certificate for an authorized
>  
>          responder using a different issing key than the key used to
>  
>          issued the certificate being checked fr revocation.
>  
>          However, such practice is strongly discouraged since clients
>  >          are not required to recognize a responder with such
>  
>          cerificate 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 des not
> define NoCheck. 
>  
>  

No you are wrong. We have confirmed with sveral ASN.1 experts that
definitionf NoCheck is not necessary to define null content.
The current definition is perfectly vaid ASN.1

>  
> 
> Comment 26: You asked for explanations. Let me provide yo with an example
> when CRLs are being used by the OCSP responder
>  in the background. The OCSP responder needs to make sure hat the CRL it uses
> is valid. If it is simply using published CRLs
>  (i.e. no rusted link with the CA), it needs to make sure that the CA which
> has issued te CRL has no been revoked.
>  
>  

No, this is a misstatement. You don't reoke CAs. You revoke CA
certificates. There might be a CA certificate that has been revoked fo 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 plan 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 configure to directly trust the public key
used to validate the CRL.


>  
> 
> In Frace, 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 rot CA of the Administration. The
> OCSP responder may use the root CA of the inistry,
>  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 stats will be different if the certificate of the CA of
> the Ministry s revoked by the root CA of the Administration.
>  
>  

Which reinforces my poit. 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 th relying party may use.

I skip category 3 as this will be dealt with in IESG ast 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. he 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 .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 genera remark to make recurring comments easier to understand.
>>  
>> 
>>  
>>  
>> Th WG decided to adopt a minimalistic approach to updating RFC 2560. That
>> means that 
>>  
>> 1. We don't chane anything from RFC 2560 unless it is broken, or the
>> industry clearly need clarifications in order to avoid interoperability
>> issues. 
>> 2. W retain the document structur of RFC 2560 as much as possible to allow
>> easy comparison of what the changes are in coparison with RFC 2560.
>>  
>> 
>>  
>>  
>> One can always thik 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 experince
>> 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 whatthe new perfect wording should be. And this
>> could go on forever.
>>  
>> 
>>  >>  
>> So when my reply is "Not broken", then that is because the current ording
>> does not have such problems that is merits a change.
>>  
>> 
>>  
>  
>> 
>>  
>>  
>> 
>>  
>>   
>> From:  Denis Pinkas <[e-mail]>
>>  Date:  Sunday, January 20, 2013 5:12 PM
>>  To:  Stefan Santesson <[e-mail]>, Stephen Kent <[e-mail]>
>>  Cc:  pkix <[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. Te current text from section 2 states:
>>>  
>>>  
>>>  
>>> 2.  rotocol Overview
>>>  
>>>  
>>>  
>>>    In lieu of or as a supplement to checking against  periodic CRL, it
>>>  
>>>    may be necessary to obtain timely information regrding the
>>>  
>>>    revocation status of a certificate (cf. RFC5280], Section 3.3).
>>>  
>>>    Examples include high-vaue funds transfer or large stock trades.
>>>  
>>>  
>>>  
>>>    The Online Certficate Status Protocol (OCSP) enables applications to
>>>  
>>>    determine te (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 thatOCPS necessarily
>>> provides ³timely information².
>>>  
>>>  
>>>  
>>>  
>>>  
>>   
>> 
>>  
>>  
>> "may" doe not mean "necessarily".
>>  
>> 
>>  
>>   >>>  
>>>  
>>>  
>>> Proposed text replacement:
>>>  
>>>  
>>>  
>>> 
>>>    The Online Cerificate Status Protocol (OCSP) is a client-server
>>>  
>>>    protocol which enables applications to obtain the revocation status
>>>  
>>>    of oneor more certificates either "good", "revoked", or "unknown".
>>>  
>>>  
>>>  
>>>    The revocation status may be rovided by the server either using a
>>>  
>>>    real time access to a database of issued certificates, or using a
>>>  
>>>    batchaccess 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 
>>>  
>>>    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 frehness of the
>>>  
>>>    revocation staus is not better than the mechanisms it is based on.
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>   
>> 
>>  
>>  
>> Not broken
>>  
>> 
>>  
>>   
>>>  
>>>  
>>>  
>>> 
>>> 3. The current text frm section 2 states:
>>>  
>>>  
>>>  
>>>    An OCSP cliet issues a status request to an OCSP responder and
>>>  
>>>    Suspends acceptance of te certificate in question until the
>>>  
>>>    responder provides a response.
>>>  
>>>  
>>>  
>>>    This protocol specifies th data that needs to be exchanged between
>>>  
>>>    an application checking the status of a certificate and the server
>>>  
>>>    providing that status.
>>>  
>>>  
>>>  
>>> Tus is insufficient for an overview. More details are needed to know what
>>> the document provides,
>>> in particular that the request may contain severl requests for several
>>> certificates issued by different CAs.
>>> The possbility of using extensions should also be advertised.
>>>  
>>>  
>>>  
>>> Proposed text replacement:
>>>  
>>>  
>>>  
>>>    When using OCSP, an OCSP client ssues 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 respondr provides a response.
>>>  
>>>  
>>>  
>>>    Ths document specifies the data that needs to be exchanged between
>>>  
>>>    an applicaion checking the status of a certificate and the server
>>>  
>>>    providing tat status.
>>>  
>>>  
>>>  
>>>    OCSP may also provide additional status infrmation using
>>>  
>>>    extensions. 
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>   
>> 
>>  
>>  
>> Not roken
>>  
>> 
>>  
>>   
>>>  
>>>  
>>>  
>>> 
>>> 4. Page 6. Editorial. Punctution 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 coditions are not met, the OCSP responder
>>>  
>>>       produces an error messag; 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, theOCSP responder
>>>  
>>>       produces an error message; otherwse, 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 th certificate in question
>>>  
>>>    -  a Tusted Responder whose public key is trusted by the requester
>>>  
>>>    -  a CA Designated esponder (Authorized Responder) who holds a
>>>  
>>>       specially marked certificate issued directly by the CA, indicating
>>>  
>>>       that th responder may issue OCSP responses for that CA.
>>>  
>>>  
>>>  
>>> The paragraph is ambiguous on several aspect.
>>>  
>>>  
>>>  
>>> Delegation  is addressed in at least three different places, but with
>>> different terms and conditions.
>>>  f 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 staes 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 OCS signer's
>>>  
>>>    certificate. This certificate MUST be issued directly o the
>>>  
>>>    responder by the cognizant CA.
>>>  
>>>  
>>>  
>>> On page16, there is a section 4.2.2.2 called ³Authorized Responders²
>>> dealing with thesame 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 ecessary however to
>>>  
>>>    ensure that the entity signing this information s authorized to do
>>>  
>>>    so.  Therefore, a certificate's issuer MAY either sign the OCSP
>>>  
>>>    responses itself or it MAY explicily 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 resonse signer's certificate.  This
>>>  
>>>    certificateMUST 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 esponses MUST recognize a
>>>  
>>>    delegation  certificate as being issued by the CA that ssued the
>>>  
>>>    certificate  in question only if the delegation certificat 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 issing in the
>>> two other sections.
>>>  
>>>  
>>>  
>>> Most implementations only support the case where the OCS Responder receives
>>> an OCSP certificate that i signed by the same key
>>> that was used to sign the target certificate. They do not suport the case
>>> where the OCSP Responder receives an OCSP certificate
>>> thatis signed by a key that is different from the one that was used to sign
>>> thetarget certificate.
>>>  
>>>  
>>>  
>>> It is inappropriate to have three sections dealing with the same toic with
>>> a slightly different meaning.
>>>  
>>>  
>>>  
>>> It is proposed th following.
>>>  
>>>  
>>>  
>>> On page 7, after:
>>>  
>>>  
>>>  
>>>    - a CA Designated Responder (Authorized Responder) who holds a
>>>  
>>>       specially marked certificate issued directl by the CA, indicating
>>>  
>>>       that the responder may issue OCSP responss for that CA.
>>>  
>>>  
>>>  
>>> it is proposed to add ³(see section 4.2.2.2 for further details)², so that
>>> thereader 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 ertificate'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 raft 11)
>>  
>> 
>>  
>>  
>> 
>>  
>>   
>>  
>>>  
>>>  
>>> 6. Page 7, the text states:
>>>  
>>> 
>>>  
>>>  
>>>    A definitive reponse message is composed of:
>>>  
>>>  
>>>  
>>>    -  version of the response syntax
>>>  
>>>    -  name of the responder
>>>  
>>>    -  responss for each of the certificates in a request
>>>  
>>>    -  optional extensions
>>>  
>>>    -  signature algorithmOID
>>>  
>>>    -  signature computed across hash of the response
>>>  
>>>  
>>>  
>>> This description does not fit with the ASN.1 sntax which is detailed later
>>> on, and in particular:
>>>  
>>>  
>>>  
>>>    ResponseData ::= SEQUENCE {
>>>  
>>>       version              [0] EXPLICIT Version DEFAULT v1,
>>>  
>>>       respoderID              ResponderID,
>>>  
>>>       producedAt               GeneralizedTime,
>>>  
>>>       responses                SEQUENCE OF SingleResponse,
>>>  
>>>       responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
>>>  
>>>  
>>>  
>>> Proposed text replacement:
>>>  
>>>  
>>>  
>>>    A definitive response message is composed of:
>>>  
>>>  
>>>  
>>>    - a rsponse 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.8  Extended  Revoked Definition should be deleted.
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>   
>> 
>>  
>>  
>> The referred text has been updates in draft 09.
>>  
>> 
>>  
>>  
>> This has been discussed on the list and you have yet to convince the list of 
>> your new reason code.
>>  
>> I disagree as the risk of running into problems with the deployed base of 
>> application is hugely larger with introduction of a new reason code, rather 
>> than using certificateHold.
>>  
>> No application should be broken, since no application have business asking 
>> for non-issued cert serial numbers in the first place. Secondly, no 
>> application can assume that a certificateHold reason will be cleared any time 
>> soon.
>>  
>> 
>>  
>>  
>> 
>>  
>>   
>>>  
>>>  
>>>  
>>> 
>>> 10. The text states on page 8:
>>>  
>>>  
>>>  
>>> 2.4  Semantics of thisUpdate, nextUpdate and producedAt
>>>  
>>>  
>>>  
>>> This section is misplaced. At this time of reading, the reader does not know 
>>> that thisUpdate, nextUpdate and producedAt are values 
>>>  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.7  CA Key Compromise
>>>  
>>>  
>>>  
>>>    If an OCSP responder knows that a particular CA's private key has
>>>  
>>>    been compromised, it MAY return the revoked state for all
>>>  
>>>    certificates issued by that CA.
>>>  
>>>  
>>>  
>>> This section is misleading and should be removed. The reason is the 
>>> following:
>>>  
>>>  
>>>  
>>> The relying party must verify that the singleResponse is signed by a 
>>> responder which is entitled to do so.
>>>  
>>>  
>>>  
>>> a) If the CA key has been compromised and if the response is signed by that 
>>> CA key then the singleResponse will be discarded 
>>>  when performing the certification path validation whatever the content of 
>>> the response may be.
>>>  
>>>  
>>>  
>>> b) If the CA key which has issued the OCSP certificate has been compromised 
>>> and if the response is signed by the key present 
>>>  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.2  Signed Response Acceptance Requirements
>>>  
>>>  
>>>  
>>>    Prior to accepting a signed response as valid, OCSP clients SHALL
>>>  
>>>    confirm that:
>>>  
>>>  
>>>  
>>>    1. The certificate identified in a received response corresponds to
>>>  
>>>       that which was identified in the corresponding request;
>>>  
>>>  
>>>  
>>>    2. The signature on the response is valid;
>>>  
>>>  
>>>  
>>>    3. The identity of the signer matches the intended recipient of the
>>>  
>>>       request.
>>>  
>>>  
>>>  
>>>    4. The signer is currently authorized to sign the response.
>>>  
>>>  
>>>  
>>>    5. The time at which the status being indicated is known to be
>>>  
>>>       correct (thisUpdate) is sufficiently recent.
>>>  
>>>  
>>>  
>>>    6. When available, the time at or before which newer information will
>>>  
>>>       be available about the status of the certificate (nextUpdate) is
>>>  
>>>       greater than the current time.
>>>  
>>>  
>>>  
>>> This section is misplaced since it uses terms from the ASN.1 syntax and the 
>>> protocol description has not yet been made, 
>>>  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 provided in 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] https://www.ietf.org/mailman/listinfo/pkix 
>>   
>  
>