Subject: Re: [pkix] 12 comments on draft-cooper-pkix-rfc2560bis-00 (re-sent)

From: Stefan Santesson <[email-masked]>
Date: Fri, 08 Oct 2010 15:12:10 +0200

Denis,

On 10-09-30 2:23 PM, "Denis Pinkas" <[email-masked]> wrote:

> (Re-sent since the send key was hit two early).
>  
> David,
>  
> Let us focus the debate on the case of designated OCSP responders and
> let us deal with CA key rollover. Other topics will be discussed later.
> 
> The paragraph that creates the major problem is the following from
> the draft (page 18):
> 
>    o  Designated OCSP responder
> 
> (...)
> 
>       The CA does not need to sign this certificate using the same key
>       as was used to sign the target certificate(s), but the certificate
>       MUST be issued to the OCSP responder directly by the CA that
>       issued the target certificate(s).
> 
>          Note: Some OCSP clients, when accepting OCSP responses from a
>          designated OCSP responder, will only accept OCSP responses if
>          the certificate required to validate the signature on the OCSP
>          response was signed using the same key as the target
>          certificate(s).
> 
> The second part of the sentence creates a problem. It is:
> 
>       the certificate MUST be issued to the OCSP responder directly
>       by the CA that issued the target certificate(s).
> 
> When a key rollover is made, this sentence is ambiguous: is the certificate
> signed by the new CA key only or both the old and the new CA key ?

A certificate can only be signed by one key. It is clear by the draft that
any key, as long as it is valid, provides a valid designation.

> The draft makes the assumption of the former case and thus does not ensure
> backwards compatibility: the draft then depicts cases that should NOT exist.
> The way to ensure backwards compatibility is to build on the later case.
> 
> This sentence also uses the plural with an s into parenthesis. The presence
> of the s opens a new can of worms, when the request is about multiple
> certificates 
> from the same CA or from different CAs.
> 

This is clear by the leading text "In order for a CA to designate an OCSP
responder other than itself..."

This this section talks about one CA.

> RFC 2560 (which was not better in this case) was saying:
> 
>       This certificate MUST be issued directly by the CA that issued
>       the certificate in question.
> 
> Let see how a system should behave when a CA performs a key rollover.
> 
> We should consider two cases: integrated OCSP responders and designated OCSP
> responders. 
> For the time being, let us only consider designated OCSP responders.
> 
> The note in the draft states:
> 
>    Note: Some OCSP clients, when accepting OCSP responses from a
>          designated OCSP responder, will only accept OCSP responses if
>          the certificate required to validate the signature on the OCSP
>          response was signed using the same key as the target
>          certificate(s).
> 
> This is true. In order to allow these clients to continue working, the draft
> should say what 
> both the CA and the OCSP responder need to do.
> 
> When a key rollover happens, in order to allow these clients to continue
> working, 
> two scenarios may be followed:
> 
> Scenario 1: the OCSP responder key is changed at the time of the key rollover.
> 
> In such a case:
> 
> a) certificates issued under the new key shall include a new value for the
> accessLocation element
> from the authority information access extension.
> 
> b) a new OCSP responder is established behind this accessLocation. The OCSP
> responder generates
> a new key pair and its public key is certified under the new CA key. The
> responses will then be signed
> by an OCSP responder key certified under the new CA key. In order to allow an
> easy verification,
> the OCSP responder SHOULD include this certificate in the certs field from
> BasicOCSPResponse.
> 
> Note: the previous OCSP responder continue working with a key certified under
> the ³old² CA key
> 

I don't think you have motivated why the OCSP responder need to change key
when the CA changes key.

This would e.g. Be hard if the OCSP responder serves more than one CA.

> Scenario 2: the OCSP responder key is changed before the key rollover and a
> new OCSP responder
> certificate is issued before the key rollover.
> 
> In this way, the same key can be maintained and can be certified under the new
> CA key. In such a case:
> 
> a) certificates issued under the new key may include the same value for the
> accessLocation element from
> the authority information access extension.
> 
> b) an OCSP responder is established behind this accessLocation. The OCSP
> responder uses the same
> private key that was previously used but the public key is certified under the
> new CA key. The responses
> may then be signed by an OCSP responder key certified both under the old CA
> key and under the new CA key.
> In order to allow an easy verification, the OCSP responder SHOULD include the
> two OCSP responder certificates
> in the certs field from BasicOCSPResponse. If the OCSP responder wants to
> apply a finer level of granularity,
> it SHOULD only include the OCSP responder certificates issued under the keys
> which match one of the
> issuerKeyHash field of the CertID fields present in the request.
> 
> These explanations do not appear in RFC 2560 and this is one of the
> motivations to "clarify" RFC 2560.
> 

I don't find this to be valid clarifications. I think the current text is
fine. An OCSP responder does not have to adjust to clients that has not
fully implemented the standard, especially not if it serves a closed
community where the functionality of the clients is known.

I find the current notes sufficient. Be ware that some clients do require
the same key to be used to sign certificates and a designated OCSP
certificate.

> Before going into other discussions and further comments, I believe that we
> need to solve this major issue.
> 
> Strawman proposal rewording for the whole section about designated OCSP
> responders:
> 
> ³   o  Designated OCSP responder
> 
>       In order for a CA to designate an OCSP responder other than itself
>       as authorized to provide revocation status information for the
>       certificates that it issues, the CA:
> 
>          o  MUST include in each certificate that it issues, an authority
>             information access extension which contains an accessLocation
>             element.
> 
>       For each accessLocation, the CA SHALL issue one or more OCSP
>       responder certificates which shall contain an extended key usage
>       extension that includes the id-kp-OCSPSigning OID.
> 
>             id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
> 
>       For any given accessLocation value in use, the CA SHALL ensure
>       there exists a valid OCSP responder certificate issued under
>       the same key that was used to sign the certificate in which the
>       given accessLocation value was included.
> 
>       For any given accessLocation value in use, the OCSP responder
>       SHOULD include in the certs field from BasicOCSPResponse the OCSP
>       responder certificates issued under the keys which match one of
>       the issuerKeyHash field of the CertID fields present in the request."
> 
> In this way, backwards compatibility is achieved.

And we have just killed the option to provide one OCSP responder for many
CAs (or key rollover for such CA).

Hence I don't think this is a valid change to the protocol.

/Stefan

> 
> Denis
> 
> =====================================================
> 
> De : David A. Cooper <mailto :[email-masked]>
>>  
>> À  : Denis Pinkas <mailto :[email-masked]>
>>  
>> Date  : 2010-09-10, 17:15:38
>>  
>> Sujet  : Re: 12 comments on draft-cooper-pkix-rfc2560bis-00
>>  
>> 
>>  
>>  
>>  
>> On 09/08/2010 05:13 AM, Denis Pinkas wrote:
>>>   
>>> 1) The text states on page 5:
>>>  
>>>  
>>>  
>>> Authorized OCSP responders fall into one of three categories:  integrated,
>>> designated, or locally trusted.
>>>  
>>> While OCSP responders behave roughly the same, OCSP clients shall use a
>>> different code 
>>> whether there are tailored to verify the responses from  integrated OCSP
>>> responders, designated OCSP responders,
>>> or locally  trusted OCSP responders.
>>>  
>>>  
>>>  
>>> This means that the document should include three different sections to
>>> describe interoperability requirements
>>> namely for three types of OCSP  clients:
>>>  
>>>  
>>>  
>>> a) OCSP clients able to interoperate with integrated OCSP  responders,
>>> b) OCSP clients able to interoperate with designated OCSP  responders,
>>> c) OCSP clients able to interoperate with locally trusted  OCSP responders.
>>>  
>>>  
>>>  
>>> The goal is being able to say, e.g: ³my OCSP client code is compliant  with
>>> OCSP client type 2².
>>>  
>>>  
>>>  
>>> Section 2.3.6.2 should be revisited and split to take this comment into
>>> consideration.
>> 
>> I don't see anything in RFC 2560 to  support the idea of three types of OCSP
>> clients.  I read RFC 2560 to say  that OCSP clients MUST be able to accept
>> responses from integrated and  designated OCSP responders and MAY be
>> configurable to also accept responses  from locally trusted OCSP responders.
>> 
>>  
>>>  
>>> 2) The text states on page 5: 1.2.1.  Integrated OCSP  Responders
>>>  
>>>    A responder is an integrated OCSP responder if the  subject
>>>    distinguished name (DN) in the certificate  containing the public key
>>>    required to verify the signature  on the OCSP response is the same as
>>>    the issuer DN in the  target certificate(s).  In other words, an
>>>    integrated  OCSP responder is a responder that provides revocation
>>>     status information for its own certificates.  An integrated  OCSP
>>>    responder may sign certificates and OCSP responses  using the same
>>>    private key or may use different keys to sign  certificates and OCSP
>>>    responses.
>>>  
>>>  
>>>  
>>> The wording ³integrated OCSP responder² did not existed in RFC  2560.
>>>  
>>>  
>>>  
>>> RFC 2560 was saying:
>>>  
>>>  
>>>  
>>> The key used to sign the response MUST belong to one of the  following:
>>>  
>>>    -- the CA who issued the certificate in question
>>>  
>>>  
>>>  
>>> but RFC 2560 was also saying:
>>>  
>>>  
>>>  
>>>    The key that signs a certificate's status information need  not be the
>>>    same key that signed the certificate. A  certificate's issuer
>>>    explicitly delegates OCSP signing  authority by issuing a certificate
>>>    containing a unique value  for extendedKeyUsage in the OCSP signer's
>>>    certificate.
>>>  
>>>  
>>>  
>>> When reading the two sections together, it may be interpreted the  following
>>> way: 
>>> the key to sign the OCSP response and the key to sign the  certificate is
>>> the same when there is no delegation.
>>>  
>>>  
>>>  
>>> We are now opening a can of worms if we allow the CA to sign OCSP  responses
>>> with a key different from
>>> the key which initially signed the  certificate, in particular when the CA
>>> changes its issuing key.
>>>  
>>>  
>>>  
>>> We must guarantee backward compatibility. This means that the CA MUST
>>> continue to sign OCSP responses with the same key.
>>>  
>>>  
>>>  
>>> After a CA key rollover, the key question is whether OCSP responses for
>>> ³old certificates² can ALSO be signed with a new key.
>>> If there is only  one accessLocation in the AIA extension field, this is not
>>> possible for the  integrated case. For allowing this scheme,
>>> this would mean that two  accessLocation fields should be placed in the AIA
>>> extension. One would be  placed in advance of the key rollover.
>>>  
>>>  
>>>  
>>> However, the drawback is that we would need to distinguish between more
>>> types of OCSP clients.
>>>  
>>> OCSP clients able to process the old-by-new CA self signed  certificate AND
>>> to take into consideration
>>> the second accessLocation  field in the AIA extension.
>>>  
>>>  
>>>  
>>> This would make an additional type of OCSP client.
>>>  
>>>  
>>>  
>>> A conservative solution to the problem would be:
>>>  
>>>  
>>>  
>>> a) to rephrase the new definition with:
>>>  
>>>    A responder is an integrated OCSP responder if the  subject
>>>    distinguished name (DN) in the certificate  containing the public key
>>>    required to verify the signature  on the OCSP response is the same as
>>>    the issuer DN in the  target certificate(s) and if the key used to
>>>    sign the OCSP  response is the same as the key used to sign the
>>>     certificate.
>>>  
>>>  
>>>  
>>> b) to delete the following sentence:
>>>  
>>>    An integrated OCSP responder may sign certificates and  OCSP
>>>    responses using the same private key or may use  different keys
>>>    to sign certificates and OCSP  responses.
>>>  
>>>  
>>>  
>>> c) to change the text on page 18. The current text is:
>>>  
>>>       When a CA signs OCSP responses to  provide revocation
>>>       status information for  its own certificates, it may sign the
>>>        responses using the same key as was used to sign the  target
>>>       certificate(s) or using a different  key.  One reason that a CA may
>>>       sign  an OCSP response using a different key would be if the CA  had
>>>       performed a key rollover since it  issued the target
>>>       certificate(s).
>>>  
>>>  
>>>  
>>>          Note: Some OCSP  clients, when accepting responses from  an
>>>          integrated OCSP  responder, will only accept OCSP responses  that
>>>          are signed using  the same key as the target certificate(s).
>>>  
>>>  
>>>  
>>> It would be changed into:
>>>  
>>>  
>>>  
>>>       When a CA signs OCSP responses to  provide revocation
>>>       status information for  its own certificates, it MUST sign the
>>>        responses using the same key as was used to sign the  target
>>>       certificate(s).
>>>  
>>>  
>>>  
>>> d) to change text in section 2.3.6.2 item 2.
>>>  
>>>  
>>>  
>>> This would solve the whole problem and the note, otherwise we would  have to
>>> consider a fourth case of OCSP client.
>>> I am not opposed to the  fourth case, as long as it is clearly indicated
>>> along with the requirements  placed in the CA.
>> 
>> I believe that we are in agreement  that 2560bis is not supposed to change
>> OCSP.  However, while you argue  that RFC 2560 "may be interpreted" to
>> require integrated OCSP responders to  sign responses using the same key as
>> the target certificate, that is not what  RFC 2560 actually says.
>> 
>> RFC 2560 says that a response may be accepted  if "The key used to sign the
>> response [belongs] to ... the CA who issued the  certificate in question".
>> You argue that this criteria is not satisfied  in the example in Figure 2.
>> However, in Figure 2 the key used to sign  the response appears in a
>> self-issued certificate, in which the key used to  sign the self-issued
>> certificate is the same as the key used to sign the  target certificate.  Are
>> you saying that the subject public key in a  self-issued certificate doesn't
>> belong to the issuer of the certificate?   RFC 5280 explicitly states that
>> "Self-issued certificates are CA certificates  in which the issuer and
>> subject are the same entity."
>> 
>> While you point  to text in Section 2.6 that you believe implies that
>> (despite what RFC 2560  actually says) the intent was to require the OCSP
>> response and the target  certificate to be signed using the same key, the
>> text in Section 2.6 is just a  shortened version of the text in Section
>> 4.2.2.2:
>> 
>>    The key  that signs a certificate's status information need not be the
>>     same key that signed the certificate. It is necessary however  to
>>    ensure that the entity signing this information is  authorized to do
>>    so.  Therefore, a certificate's issuer  MUST either sign the OCSP
>>    responses itself or it MUST  explicitly designate this authority to
>>    another entity.   OCSP signing delegation SHALL be designated by the
>>    inclusion  of id-kp-OCSPSigning in an extendedKeyUsage certificate
>>     extension included in the OCSP response signer's certificate.   This
>>    certificate MUST be issued directly by the CA that issued  the
>>    certificate in question.
>> 
>> It would be inconsistent  to say that a certificate's issuer has not
>> "sign[ed] the OCSP responses  itself" if it signs using a different key while
>> also saying that a self-issued  certificate (even if it is not self-signed)
>> is a CA certificate "in which the  issuer and subject are the same entity."
>> 
>> I do not understand at all  your point about multiple AIA extensions.  A CA
>> that had performed a key  rollover that was acting as an integrated OCSP
>> responder could sign every OCSP  response using the same key as the target
>> certificates even if all  certificates issued by the OCSP responder included
>> the same OCSP URL in the  AIA extension.  The CA (acting as an OCSP
>> responder) would just choose  the key to use the sign the response based on
>> the certificate identified in  the reqCert field of the request.  There is no
>> reason that an OCSP  responder has to sign responses to all requests
>> submitted to the same URL  using the same key.  Similarly, it can include
>> different certificates in  the certs field of the response depending on the
>> set of certificates for which  the response message is providing status
>> information.
>> 
>>  
>>>  
>>> 3) On page 18 for ³Designated OCSP responders² the text states:
>>>  
>>>       The CA does not need to sign this  certificate using the same key
>>>       as was used  to sign the target certificate(s), but the  certificate
>>>       MUST be issued to the OCSP  responder directly by the CA that
>>>       issued  the target certificate(s).
>>>  
>>>  
>>>  
>>>          Note: Some OCSP  clients, when accepting OCSP responses from  a
>>>          designated OCSP  responder, will only accept OCSP responses  if
>>>          the certificate  required to validate the signature on the  OCSP
>>>          response was signed  using the same key as the  target
>>>           certificate(s).
>>>  
>>>  
>>>  
>>> We have a backwards compatibility problem here.
>>>  
>>>  
>>>  
>>> Today OCSP clients do not expect a new certificate issued by a new key  from
>>> the same CA. 
>>>  
>>> We are faced with two choices:
>>>  
>>>  
>>>  
>>> a) mandate the same key or
>>>  
>>> b) mandate the inclusion in the OCSP response of two OCSP certificates  for
>>> the same responder.
>>>  
>>>  
>>>  
>>> I would prefer the later.
>>>  
>>>  
>>>  
>>> Note that changes are also needed in section 2.3.6.2 item  3.
>> 
>> This is the same as issue 2).  RFC 2560 says  that the certificate required
>> to verify the signature on the OCSP response  must be issued directly by the
>> CA that issued the certificate in question and  must include an extended key
>> usage extension that asserts the  id-kp-OCSPSigning OID.  It does not say
>> that the certificate must be  signed using the same key as was used to sign
>> the certificate in  question.
>> 
>>  
>>>  
>>> 4) The text states in section 2.3.5.2 from page 18:
>>>  
>>>    Since an authorized OCSP responder provides revocation  status
>>>    information for one or more CAs, OCSP clients need to  know how to
>>>    check that an authorized responder's certificate  has not been
>>>    revoked.
>>>  
>>>  
>>>  
>>> The sentence is incorrect since it is not true for integrated  responders.
>>>  
>>> Change into:
>>>  
>>>    OCSP clients need to know how to check that an authorized  responder's
>>>    certificate has not been  revoked.
>> 
>> The text that you quoted from copied,  nearly word-for-word, from Section
>> 4.2.2.2.1 of RFC 2560:
>> 
>>     Since an Authorized OCSP responder provides status information  for
>>    one or more CAs, OCSP clients need to know how to check  that an
>>    authorized responder's certificate has not been  revoked.
>> 
>> I don't understand what in the sentence is incorrect.   While I think Section
>> 4.2.2.2.1 of RFC 2560 (Section 2.3.5.2 in the draft) was  primarily about
>> designated OCSP responders, an integrated OCSP responder does  provide
>> revocation status information for one or more CAs.  It provides  revocation
>> status information for itself (and it is a CA), and while it is  unlikely it
>> may also (acting as a designated OCSP responder) provide  revocation status
>> information for other CAs.
>> 
>>  
>>>  
>>> 5) The text states in section 2.3.6.2 from page 18:
>>>  
>>>  
>>>  
>>>    Systems or applications that rely on OCSP responses MUST  be capable
>>>    of detecting and enforcing use of the  id-ad-ocspSigning value as
>>>    described in Section  2.3.5.1.  They MAY provide a means of locally
>>>     configuring one or more OCSP signing authorities, and specifying  the
>>>    set of CAs for which each signing authority is  trusted.
>>>  
>>>  
>>>  
>>> The first sentence is untrue for locally trusted OCSP responders while  the
>>> second sentence is only true
>>> for locally trusted OCSP responders. As  stated in the very first comment,
>>> this whole section needs to be
>>> restructured according to the three (or four)  cases.
>> 
>> This comes directly from Section 4.2.2.2 of  RFC 2560:
>> 
>>    Systems or applications that rely on OCSP  responses MUST be capable
>>    of detecting and enforcing use of  the id-ad-ocspSigning value as
>>    described above. They MAY  provide a means of locally configuring one
>>    or more OCSP  signing authorities, and specifying the set of CAs for
>>    which  each signing authority is trusted.
>> 
>> I take this to mean that OCSP  clients MUST be able to accept responses from
>> designated OCSP responders and  MAY additionally provide the means to accept
>> responses from locally trusted  OCSP responders.  It does not seem to allow
>> for an OCSP client that only  accepts responses from locally trusted OCSP
>> responders or one that only  accepts responses from integrated OCSP
>> responders.
>> 
>>  
>>>  
>>> 6) The text states in section 4.1 from page 23 in the discussion about  the
>>> use of insecure algorithms
>>> inside the security consideration  section.
>>>  
>>>  
>>>  
>>>    In archival applications it is quite possible that an OCSP  responder
>>>    might be asked to report the validity of a  certificate on a date in
>>>    the distant past.
>>>  
>>>  
>>>  
>>> This functionality does not exist: there is no date in the request to  ask
>>> the revocation at a time in the past.
>>> OCSP responders are not  required to report the validity of a certificate on
>>> a date in the distant  past. Please delete.
>> 
>> Section 4.1 of the draft was copied  from Section 8.1 of
>> draft-ietf-pkix-ocspagility-09, so this is really a  comment on that draft.
>> 2560bis will incorporate  draft-ietf-pkix-ocspagility, so any issues with the
>> text in that draft should  be dealt with in the context of
>> draft-ietf-pkix-ocspagility, and any changes  made to
>> draft-ietf-pkix-ocspagility will also be made in 2560bis.
>> 
>>  
>>>  
>>> 7) All the sections from section D need to be revisited to take into
>>> considerations the previous comments.
>>>  
>>>  
>>>  
>>> In section D.1, figures 2 and 3 should be  deleted.
>> 
>> But, these are legitimate examples of  integrated OCSP responders.  Figures
>> 1, 2, and 3 all depict scenarios in  which the OCSP response is signed by
>> "the CA who issued the certificate in  question".
>> 
>>  
>>>  
>>> In section D.2, figure 5 should be deleted because it is unlikely that  a
>>> root CA uses the same key to sign OCSP responses.
>> 
>> I  agree that Figure 5 depicts a highly unlikely scenario.  However, I
>> wanted to include at least one example that showed that a single OCSP
>> responder could be both a designated OCSP responder and an integrated OCSP
>> responder.
>> 
>>  
>>>  
>>> In figure 6, this means that the client MUST be capable to process the
>>> old-by-new self signed certificate.
>> 
>> I have noted  many places in the draft that not all clients will be able to
>> accept OCSP  responses, and thus that not all clients will be able to accept
>> OCSP responses  in an environment as depicted in Figure 6.
>> 
>>  
>>>  
>>> While it is a nice feature, all clients are not able to do it, unless  we
>>> define a new class of clients able to process that case.
>>> This is  related to the first and second comment about the distinction of
>>> different  classes of OCSP clients (three or four).
>> 
>> While RFC 2560  does say that clients MUST be able to accept responses from
>> designated OCSP  responders ("MUST be capable of detecting and enforcing use
>> of the  id-ad-ocspSigning value") and MAY be capable of accepting responses
>> from  locally trusted OCSP responders, it does not specify requirements at
>> the level  that you suggest.
>> 
>> Sections 5 and 5.1.1.3 of RFC 5280 includes  statements along these lines
>> about requirements for CRL processing  capabilities:
>> 
>>    Conforming applications that support CRLs  are REQUIRED to
>>    process both version 1 and version 2 complete  CRLs that
>>    provide revocation information for all certificates  issued by one
>>    CA.  Conforming applications are not  required to support
>>    processing of delta CRLs, indirect CRLs,  or CRLs with a scope
>>    other than all certificates issued by one  CA.
>> 
>>    Applications that perform CRL checking MUST  support
>>    certification path validation when certificates and  CRLs are
>>    digitally signed with the same CA private key.   These
>>    applications SHOULD support certification path  validation when
>>    certificates and CRLs are digitally signed  with different CA private
>>    keys.
>> 
>> Something similar could  be included in 2560bis, but that would be something
>> new compared to RFC  2560.
>> 
>>  
>>>  
>>> In figure 7, it is a bad example since it is unlikely that a root CA  uses
>>> the same key to sign OCSOP responses.
>>> This case should be deleted  or modified.
>> 
>> In Figure 7, the root does not sign  OCSP responses.  The root has only
>> issued a certificate to a designated  OCSP responder.  OCSP responses are
>> signed using the designated  responder's key (Root's OCSP Responder's key).
>> 
>>  
>>>  
>>> 8) On page 39, the text clearly indicates the problem:
>>>  
>>>  
>>>  
>>>    As noted in Section 2.3.5.1, some OCSP clients cannot  validate
>>>    signatures on OCSP responses created by designated  OCSP responders if
>>>    the OCSP responder's certificate has been  signed using a different
>>>    key than the target  certificate.  Figure 8 depicts a CA that
>>>    accommodates  this limitation by issuing two certificates to the
>>>     designated OCSP responder, one signed with its old private key  and
>>>    one signed with its new private key.  Both  certificates include an
>>>    extended key usage extension with  the id-kp-OCSPSigning OID.
>>>  
>>>  
>>>  
>>> In order to achieve backward compatibility, if the CA issues an  old-by-new
>>> self signed certificate, then the CA SHALL issue
>>> two  certificates, which also mean that the OCSP responder SHALL include its
>>> two  certificates in the certs field from BasicOCSPResponse.
>>>  
>>>  
>>>  
>>> This requirement should be moved in the normative part of the  RFC.
>> 
>> What requirement?  Aside from the fact  that there is no old-by-new
>> self-issued certificate in Figure 8, there is no  requirement for the CA to
>> issue two certificates.  This example simply  explains that doing so will
>> improve compatibility with existing clients.   In addition,  I can't find a
>> requirement in RFC 2560 to include any  certificates in the certs field of
>> BasicOCSPResponse.  The closest  statement I can find is one about request
>> messages:
>> 
>>    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.
>> 
>> That is why the draft says the same  thing about the certs field in
>> BasicOCSPResponse (the responder MAY include  certificates that help the
>> client verify the responder's signature).  If  RFC 2560 requires that certain
>> certificates be included in the certs field of  BasicOCSPResponse, then
>> please identity the text with that imposes that  requirement.
>> 
>>  
>>>  
>>> 9) BTW, the field certs is not described and should be described. Other
>>> fields from BasicOCSPResponse are not described either !  :-(
>> 
>> Section 2.3 says:
>> 
>>    The  responder MAY include certificates in the certs field of
>>     BasicOCSPResponse that help the OCSP client verify the  responder's
>>    signature.
>> 
>>  
>>>  
>>> 10) In the case of figure 9, the OCSP responder SHALL include all three
>>> certificates in the field certs from BasicOCSPResponse.
>>> This requirement  should be moved in the normative part of the  RFC.
>> 
>> Again, I cannot find such a requirement in RFC  2560.  Also, there would be
>> no reason (other than possibly simplifying  the coding of the responder) to
>> include all three certificates in a  response.  The responder could include
>> just one certificate in each  response, as long as that one certificate were
>> that one that was issued by the  CA that issued the certificate in question.
>> 
>>  
>>>  
>>> 11) In figure 10, the text is missing to say what the client shall be
>>> doing.
>> 
>> What needs to be said about what the client  shall be doing?  Can you propose
>> some text?
>> 
>>  
>>>  
>>> 12) In the first comment, I said² While OCSP responders behave  *roughly*
>>> the same². 
>>> There is a distinction to introduce: the number of  certs that the OCSP
>>> response SHALL include in the case of the integrated  OCSP responders.
>> 
>> I don't understand this comment.   When you say certs includes in the
>> response, do you mean in the certs field of  BasicOCSPResponse or in the
>> responses field of ResponseData?  What is the  requirement that needs to be
>> imposed and where is the text in RFC 2560 that  imposes the requirement?
>> 
>> 
>> Dave
>> 
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 8 Oct 2010 16:03:35 +0200

Stefan,

Thanks for going into the debate. Let us start by the end of your comments.

1) You said:

"Be ware that some clients do require the same key to be used to sign certificates 
and a designated OCSP certificate".

We both strongly agree about this. It is precisely because I am aware of this, 
that I have proposed the new text which takes care of these clients.

2) You said:

"And we have just killed the option to provide one OCSP responder for many
CAs (or key rollover for such CA)".

Please reread the text:
 
a) there is nothing which prevents one OCSP responder for many CAs.

I proposed : "For any given accessLocation value in use, the OCSP responder
 SHOULD include in the certs field from BasicOCSPResponse the OCSP
 responder certificates issued under the keys which match one of
 the issuerKeyHash field of the CertID fields present in the request;

When multiple certificates from different CAs are in the request, there should be 
multiple OCSP certificates in the response.

b) there is nothing which prevents key rollover for any CA.

I said: "The responses may then be signed by an OCSP responder key 
certified both under the old CA key and under the new CA key".

If you still believe so or if I missed something, please provide detailed arguments.

3) You said: "I don't think you have motivated why the OCSP responder need to change key
when the CA changes key".

Doing so is easier, but is not mandatory.

then you said:

"This would e.g. Be hard if the OCSP responder serves more than one CA".

When there is more that one CA that designates the same OCSP responder, 
in order to change the key of the OCSP responder, all the OCSP certificates 
issued by the CAs must be obtained before the switch to the new OCSP key 
can be done.

Denis

---------- 
De : pkix-bounces 
À : denis.pinkas,David A. Cooper 
Date : 2010-10-08, 15:12:10
Sujet : Re: [pkix] 12 comments on draft-cooper-pkix-rfc2560bis-00 (re-sent)

Denis,

> the issuerKeyHash field of the CertID fields present in the request.."
> 

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 12 Oct 2010 16:07:09 +0200

I got no answer yet from Stefan on the mail below.

Nevertheless, in order to progress faster, I have written two text proposals to clarify 
how an OCSP client should process a response that may contain status responses for several certificates 
and also what it should do before constructing a request.

In the current text dealing with response verification, the begining of the description is as follows:
   Prior to accepting a response of the basic response type as valid,   OCSP clients MUST confirm that: 
      1.  the certificates identified in the response correspond to the          certificates that were identified in the corresponding          request; 
      2.  the signature on the response is valid;
The major problem is that this second step is impossible to perform : in order to verify a signature 
one must know which public key or certificate shall be used. The text is silent about this.

As it will be detailed herefter, the validity of the signature cannot be globally verified, 
but must be verified certificate by certificate.

There is also another concern: the current text is only dealing with the verification of a response 
in real time, whereas text should explain how to verify an OCSP response obtained in the past 
(i.e. when used for non repudiation purposes, e.g. for verifying electronic signatures).
 
I have dealt with the two cases in the text below by introducing the wording "checking time".
Since an OCSP response may contain statuses for several certificates but will be used just for one, 
I have introduced a step 1.

Below are the two text proposals:
========================================================================
2.3.6.  Response Verification

STEP 1

   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.  If it is a time in the past, OCSP clients SHALL only   check the certificates which are of interest.

STEP 2

   Prior to processing an individual certificate status response   within one basic response, OCSP clients MUST build and verify a   certification path from a trusted root key up to the target   certificate, 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 from the certification path (except the   target certificate) SHALL be checked.

STEP 3

   Prior to accepting an individual certificate status response   within one basic response as valid, OCSP clients SHOULD verify   whether there exists a specific rule locally defined for OCSP   responders for the certificate in question.  If this rule exists,   it SHALL be followed and if successfully passed, proceed to step 4.
   If the verification according to this rule fails, then the   individual response is rejected, the revocation status is unknown   and proceed to step 5. 
   Otherwise OCSP clients MUST discover whether the CA has signed   itself the basic OCSP response or has designated an OCSP   responder.  At least, one of the two following operations MUST be   done.  These operations may be performed in any order to take   advantage of a prior knowledge of which one may have a better   chance of success:

      1.  check whether the response is signed by the same key that          was used to sign the target certificate.
          If it is the case, then proceed to step 4.
          If it is not the case and if the second operation has not          been done, proceed with the second operation, otherwise          proceed to step 5. 
      2.  check whether there exists an OCSP certificate signed by the          same key that was used to sign the target certificate.  This          certificate may be obtained by any means, but may be present          in the certs field from the basic response. 
          If such certificate exists and is valid (i.e. it contains          the extended key usage extension that includes the           id-kp-OCSPSigning OID, the checking time is within the          validity period of this certificate and it is not revoked,           then proceed to step 4.

          If such certificate is not found and if the first operation          has not been done, proceed with the first operation,          otherwise proceed to step 5.

STEP 4

   OCSP clients MUST check:
       1.  whether the time at which the status being indicated is           known to be correct (thisUpdate) is sufficiently close to            the checking time; and
       2.  when available, the time at or before which newer information           will be available about the status of the certificate           (nextUpdate) is greater than the checking time.

   If all these checks are successful, then the status for the   individual certificate as indicated is accepted, otherwise the   status is unknown. 

STEP 5

   If there exists a next individual certificate status response in   the basic response, then proceed to step 2.  Otherwise the basic   response is now processed.
========================================================================

2.1.  OCSP Requests
   An OCSP request allows getting in a single 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 SHOULD 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.  In this way,    a URI can be associated with each candidate certificate. 

   Certificates that contain the same URI MAY be grouped in a    single request.
   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 responder for that certificate. 

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

   The syntax and description of the request is as follows:
[Proceed with the current text]
========================================================================

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : pkix 
Date : 2010-10-08, 16:03:35
Sujet : Re: [pkix] 12 comments on draft-cooper-pkix-rfc2560bis-00 (re-sent)

Stefan,

1) You said:

2) You said:

Please reread the text:

then you said:

Denis

---------- 
De : pkix-bounces 

Denis,

/Stefan