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

From: "Olle Mulmo" <[email-masked]>
Date: Fri, 1 Feb 2002 15:14:58 +0100

I don't quite agree with Denis on assuming a few hours to be OK in a general scheme. Clearly, the value of the maximum lag time on the producedAt field in an OCSP response must be defined in the Operational Requirements section of the CA's CPS -- to be defined and thought of months (or at least a few hours...) before the OCSP service is to come online.

However, revoked is revoked is revoked: shouldn't a client accept an OCSP response containing a SingleResponse with (status=revoked and reasonCode!=onHold), even though the producedAt field is long by gone?

Regards,

Olle

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Friday, February 01, 2002 10:34 AM
To: Ambarish Malpani
Cc: [email-masked]'
Subject: Re: Candidate for moving OCSP to a Draft Standard

Ambarish,,

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

I have the following remarks:

The current text states:

   7. The producedAt time in the response is sufficiently recent.

   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

If the nonce is used, then the value of the producedAt field does not matter 
anymore and no test needs to be made on it. So I would first propose to 
invert items 8 and 7.

Then it is questionable on how implementers can interpret what "sufficiently
recent" means for the producedAt time and set a value (a few minutes, hours 
or days ?).
 
In fact if no pre-computed response were being used, this could simply be
set to a few minutes.

If pre-computed responses are being used, setting it to a few minutes will
probably lead to rejections.

This means that using pre-computed responses is a real problem, since this
value cannot even be fixed but is even dependent upon each server supporting
pre-computed responses.

The easiest way would be to delete the support of pre-computed responses or
set a maximum limit in the standard. The basic question would first be: who
is using pre-computed responses with which retention period in the cache ?
If no-one is using it, then the solution is simple. :-)

In the following proposal, I have not yet "crossed the line".  

Proposed rephrasing:

[Prior to accepting a signed response as valid, OCSP clients SHALL
 confirm that:]

   7. If the request contained a nonce, the response contains the
      same nonce (see section 4.4.1).

   8. If the request did not contained a nonce, the producedAt time 
      in the response is considered as "sufficiently recent". 
      This means computing the difference between the current time 
      and the producedAt time and then comparing it with a time 
      period that will be set to a few minutes, or to a few hours 
      in the case where the OCSP servers accessed by the client 
      are supporting pre-computed responses. 

      Note: when pre-computed responses are being used by servers,
      it may be hard for clients to set a single maximum common value.

Denis

> 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: Fri, 01 Feb 2002 16:15:22 +0100

Olle,

> I don't quite agree with Denis on assuming a few hours to be OK 
> in a general scheme. Clearly, the value of the maximum lag time 
> on the producedAt field in an OCSP response must be defined in 
> the Operational Requirements section of the CA's CPS -- to be 
> defined and thought of months (or at least a few hours...) 
> before the OCSP service is to come online.

The problem is that an OCSP client is a client from different OCSP 
servers, each one may have different Operational Requirements. 
Since unfortunately Operational Requirement of the CA's CPS are 
not machine readable, there is no way for a client to automatically 
adjust the timing according to each CA, unless clients work in 
a closed environment with CAs that they all know in advance.

Denis

> However, revoked is revoked is revoked: shouldn't a client 
> accept an OCSP response containing a SingleResponse with 
> (status=revoked and reasonCode!=onHold), even though 
> the producedAt field is long by gone?
> 
> Regards,
> 
> Olle
>