Subject: OCSP response pre-production (was RE: POLL: Use of nonces in OCS P)

From: "Deacon, Alex" <[email-masked]>
Date: Fri, 26 Sep 2003 13:55:11 -0700

Hi Russ,

Agreed, however we do not have control of all OCSP clients.  In the case
where a responder is using pre-produced responses and can't respond to a
request with a nonce, the responder can do one of two things:

1) Send the pre-produced response without the nonce
2) return a malformedReqest OCSPResponseStatus

I feel that the first choice is better as it gives clients a chance to
accept the response, even though it does not contain a nonce.   

For clients that require a nonce not matter what the outcome of both optoins
is the same...i.e. the response is rejected.

Alex

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 9:31 AM
> To: Deacon, Alex
> Cc: [email-masked]
> Subject: RE: POLL: Use of nonces in OCSP
> 
> 
> Alex:
> 
> To support such an environment, the client should not include 
> a nonce in 
> the request.  Do you have control over the clients?  If so, 
> then the change 
> will not cause you a problem.
> 
> Russ
> 
> At 05:12 PM 9/25/2003 -0700, Deacon, Alex wrote:
> 
> 
> >Hi Mike,
> >
> >Although this new text would not break the existing VeriSign 
> OCSP code base,
> >it will break the (soon to be deployed) next generation of our OCSP
> >services.  These services are designed to serve PKI's with a 
> high volume of
> >RP's (such as TLS server and code signing CA's) and rely on response
> >pre-production, distribution and caching through out the network.
> >
> >In such a deployment it is not possible for a responder to 
> include a nonce
> >in the response.
> >
> >Regards,
> >Alex
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Michael Myers [mailto:[email-masked]]
> > > Sent: Wednesday, September 24, 2003 7:38 AM
> > > To: [email-masked]
> > > Cc: Stephen Kent; Ambarish Malpani
> > > Subject: POLL: Use of nonces in OCSP
> > >
> > >
> > >
> > > All,
> > >
> > > Recent list traffic indicates there might be some confusion out
> > > there regarding the use of nonces in OCSP.  This is
> > > understandable since RFC 2560 is regrettably silent on the
> > > point.  It seems that most folks correctly inferred our original
> > > intent but absent normative language there's a possibility that
> > > some may not.
> > >
> > > After some discussion with the Chairs and the AD, we will take
> > > action to clarify our original intent in one fashion or another
> > > but first need to poll IMPLEMENTORS to determine how many, if
> > > any, implementations of OCSP would break as a consequence of the
> > > following normative language:
> > >
> > >     "Clients that elect to include a request nonce
> > >      SHALL reject responses that fail to include
> > >      the client's nonce from the associated request."
> > >
> > >     "Correspondingly, upon receipt of a request
> > >      containing a nonce, a responder SHALL include
> > >      the value of such nonce in the production of
> > >      the associated response."
> > >
> > > IMPLEMENTORS ONLY, please, and just yes/no or equivalent.
> > >
> > > Mike
> > >
> > >
>

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 27 Sep 2003 10:53:48 -0700

>2) return a malformedReqest OCSPResponseStatus

That's not the correct status: "internalError" is much more 
appropriate. The request is *not* malformed: it is the responder that 
has an error (namely, that it cannot handle a valid request).

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 29 Sep 2003 12:07:02 +0200

Alex,

I support the idea, ... with some changes.

> is the same...i.e. the response is rejected.

If a nonce is present in the request then the server SHALL send back a 
response with the same nonce, if it is not using cached pre-produced responses.

If the server is using cached pre-produced responses, then he MAY send back 
a response with or without a nonce. In such a case, the client SHOULD check 
the freshness of the response using the producedAt field from ResponseData 
which is only possible if the client has a local trusted clock.

New text proposal:

     "Upon receipt of a request containing a nonce,
      a responder SHALL include the value of such nonce
      in the production of the associated response,
      if it is not using cached pre-produced responses.
      If the responder is using cached pre-produced responses,
      then it MAY send back a response with or without a nonce."

      "Clients that elect to include a request nonce
      MAY reject responses that fail to include
      the client's nonce from the associated request.
      Alternatively they MAY ignore the nonce field and accept
      the response, if they have a local trusted clock and are
      satisfied with the time difference between their local
      trusted clock and the producedAt field from ResponseData".

Denis