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

From: Denis Pinkas <[email-masked]>
Date: Fri, 01 Feb 2002 10:33:31 +0100

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: "Florian Oelmaier" <[email-masked]>
Date: Fri, 1 Feb 2002 18:01:48 +0100

> If no-one is using it, then the solution is simple. :-)

Just to clarify: You can always replace the term "pre-computed responses"
with "cached responses". Please be aware of that before dropping support for
pre-computed responses. It is hard enough for caching Responders with the
current nonce-requirements: A client using a nonce will disallow caching on
the OCSP-Responder.

Having a setup like 10 Sub-CAs, each certifying 1000 servers for SSL or
1.000.000 users for S/MIME, this will easily result in 30.000 OCSP-req/min
per Sub-CA. This means that in the course of the chain-validation, the
root-Responder will get 5.000 OCSP-requests per second. Given that I will
place the root-Responder in a specially secured network-envirmonment these
figures will make caching/pre-computed responses an issue. Within this
scenario the possiblity of a client to disallow caching at the responder
(with sending a nonce that MUST be answered) is a network and production
problem. But as the RfC correctly states, not using nonces will leave the
somewhat problematic producedAt time as our last defense-line regarding
replay-attacks.

Please discuss this controversly as it will determine the usability of the
protocol.

ciao, Fl0

BTW: I agree to Denis suggestion to invert point 7. and 8.

--
Dipl.Inf. Florian Oelmaier
Head of Development
syTrust S.A.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 04 Feb 2002 14:04:41 +0100

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

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.

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

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.

Denis

---

From: Michael Ströder <[email-masked]>
Date: Wed, 20 Feb 2002 22:55:23 +0100

Florian Oelmaier wrote:
> problem.

If I understand you correctly one could rephrase the last sentence
to ".. enables the OCSP client to easily launch a DoS attack".

Ciao, Michael.