Subject: RE: Candidate for moving OCSP to a Draft Standard

From: Ambarish Malpani <[email-masked]>
Date: Mon, 04 Feb 2002 12:05:41 -0800

Hi Denis,
    Responses inline.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, February 04, 2002 5:05 AM
> To: Ambarish Malpani
> Cc: [email-masked]'
> Subject: Re: Candidate for moving OCSP to a Draft Standard
> 
> 
> Ambarish,
> 
> Three remarks:
> 
> 1) It would be interresting to say what happens in case an 
> OCSP request
>    is made after the end of the validity period of a certificate.
> 
> nextUpdate is currently defined as: "The time at or before which newer
> information will be available about the status of *the* certificate".
> 
> If the certificate has expired, such information about *that* 
> certificate
> will never be available. Anyway, since the server does not 
> necessarily have
> access to the end-entity certificate, then it does not even 
> know that the
> certificate has expired.
> 
> A more appropriate definition about nextUpdate would be: "The 
> time at or
> before which newer status revocation information will be 
> available from the
> CA which has issued the certificate".

I disagree. A responder can get its information from a CA or some
other source. Nothing in OCSP restricts or implies restrictions
on the sources of information for a responder.

> 
> In addition, some guidance, in particular in the security 
> considerations
> section would be useful. Here is some tentative text:
> 
> An OCSP response does not indicate that the certificate is in 
> its validity
> interval. So, it is up to the clients to make sure that thisUpdate is
> within the validity period of the end-entity certificate, 
> which means that
> clients MUST be able to parse the end-entity certificate to 
> interpret the
> validity period.

This is already present in the text. Are you just asking for it
to be re-iterated in the Security Considerations section?
(it is in the section that explains good)

> 
> 
> 2) The "good" status has always been misleading. The text says: 
> 
>    The "good" state indicates that the certificate has not 
> been revoked.
> 
> According to this definition, which is correct, an 
> unambiguous status would
> better be called: "not revoked" rather than "good".

We went through this discussion a few times around earlier. I believe
"good" has been adequately explained here. I don't see any point in
raising this topic again.

> 
> 
> 3) A typo (suppress one "is"):
> 
>    It does not indicate that the certificate was ever issued,
>    is or is in its validity interval.
> 
> should be changed into:
> 
>    It does not indicate that the certificate was ever issued,
>    or is in its validity interval.

Will fix.

> 
> 
> Denis
> 
>  
> > Hi Guys,
> >     Here is a candidate for moving OCSP to a Draft Standard. There
> > are no changes in the bytes that go across the wire - basically all
> > clarifications.
> > 
> > A list of all the changes between this document and RFC 2560 are
> > in Appendix D (reproduced here).
> > 
> > I hope we can get to the Draft Standard state before this IETF.
> > 
> > Regards,
> > Ambarish
> > 
> > Appendix D. Changes
> > 
> >    This section contains the differences in this document 
> from RFC 2560
> > 
> >    - Mention Appendix D in Section 1 and added an appendix D.
> >    - Added a paragraph in Section 1 equating a client with 
> a requestor and
> >      server with responder
> >    - Section 2.2 - clarified the explanation of good, 
> revoked and unknown
> >    - Added Section 2.8 requiring clients and responders to 
> support HTTP
> >    - Added a note at the end of section 3.2, which allows a 
> client to
> >      accept a response that provides statuses for only some of the
> >      certificates requested.
> >    - Clarified the issuerKeyHash in Section 4.1.1
> >    - Added "DER encoding of the" in the third paragraph 
> Section 4.1.2
> >    - Section 4.2.1 - clarified that the signature is on the 
> DER encoding
> >      of tbsResponseData (and not its hash)
> >    - Section 4.2.1 - specified the use of the certs field in
> >      BasicOCSPResponse
> >    - Section 4.2.1 - clarified how you compute KeyHash when 
> providing
> >      the ResponderID byKey.
> >    - Section 4.2.2.2 - removed an extra quote in point 3
> >    - Section 4.3 - Made RSA mandatory. Also changed the 
> references to
> >      point to the appropriate documents. Added the references to the
> >      References section
> >    - Section 4.4.1 - Clarified that a nonce in the request MUST be
> >    - included in the response for the response to be trusted.
> >    - Appendix A - A.1.1. - Got rid of support for GET - not 
> sure that
> >      anybody does it. It is also unclear how a server would tell a
> >      client to ever use GET in the URL specified in the AIA
> >    - Add the module tag for the ASN.1 in OCSP
> >    - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE 
> SIZE(1..MAX) of
> >      Certificate OPTIONAL in the ASN.1 defintions. The avoids the
> >      ambiguity of whether the optional sequence may be present, but
> >      with 0 elements. This was done by definining a new 
> element called
> >      Certificates, which is used. Look at the defintion of both
> >      Signature and BasicOCSPResponse.
> >    - Clarified the meaning of nextUpdate being absent (Section 2.4)
> >    - Fixed typo where we referred to id-ad-ocspSigning, to 
> reflect the
> >      correct OID - id-kp-OCSPSigning
> >    - Clarified criteria for response acceptance (Section 3.2)
> >    - Added a line in Section 5 indicating that nonces can be used to
> >      prevent prevent attacks using replays of precomputed responses
> >    - Added a paragraph in Section 5 requiring nonces to be 
> unique for
> >      replay protection
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [email-masked]
> > 339 N. Bernardo Ave.                          
http://www.valicert.com
> Mountain View, CA 94043
----------------------------------------------------------------------------
>                         Name: OCSP-draft-03.txt
>    OCSP-draft-03.txt    Type: Plain Text (text/plain)
>                     Encoding: quoted-printable

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 05 Feb 2002 14:56:51 +0100

Ambarish,

(...)

> > OCSP request is made after the end of the validity period 
> > of a certificate.

> > nextUpdate is currently defined as: "The time at or before which 
> > newer information will be available about the status of *the* 
> > certificate".

> > certificate will never be available. Anyway, since the server 
> > does not necessarily have access to the end-entity certificate, 
> > then it does not even know that the certificate has expired.

> > time at or before which newer status revocation information 
> > will be available from the CA which has issued the certificate".
 
> on the sources of information for a responder.

You are right, but my point was to stress the fact that the OCSP responder
may not know when newer information about the status of *the* certificate 
will be available. So a correction is needed. What about the following:

"The time at or before which newer status revocation information will be
available". 

or much longer, but still exact:

"The time at or before which newer status revocation information will be
available either from the CA who issued the certificate in question, a
Trusted Responder whose public key is trusted by the requestor, or a CA
Designated Responder (Authorized Responder) who holds a specially marked
certificate issued directly by the CA, indicating that the responder may
issue OCSP responses for that CA."

> > considerations section would be useful. Here is some tentative text:

> > that thisUpdate is within the validity period of the end-entity 
> > certificate, which means that clients MUST be able to parse the 
> > end-entity certificate to interpret the validity period.
 
> (it is in the section that explains good)

No change in the main body of the document but an addition in the Security
Considerations section to explain the implications.

Denis

(...)