RE: OCSP response pre-production

["Ambarish Malpani" <ambarish@xxxxxxxxxxx>]

Hi Florian, Denis,
    The proposal also adds not-very-desirable semantics to requests
being made by existing clients.

All clients today that make requests with nonces expect those nonces to
come back in the response. With the semantics below, todays clients would
be indicating that it is okay to get a response w/o the nonce.


I think we are adding a lot of meaning in the nonce extension. My original
rationale for nonces was to allow a client to force a response to its
request
and thus prevent any chance of a reply. This leaves the options very simple:

- If you (the client) want a fresh response, include a nonce in the request.
- If you don't care whether the response is fresh or not, exclude a nonce
	in the request (and therefore, don't check to see whether there is a
nonce
	in the reply or not - the cached response that you get back might
have been
	generated for an earlier request that did contain a nonce)

Yes, this doesn't cover all the possible options, but it doesn't add a lot
of complications to the protocol. As a client, if I do want to support all
the cases identified by Florian below, I can still do it - potentially at
the
cost of a couple of requests.

Regards,
Ambarish


> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Denis Pinkas
> Sent: Tuesday, September 30, 2003 12:41 AM
> To: Florian Oelmaier
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: OCSP response pre-production
> 
> 
> 
> Florian,
> 
> I have no problem with the new flow chart you propose below.
> 
> Making the nonce extension critical or not in the request, as 
> you propose in 
> another e-mail, is a good proposal since it does not involve 
> an ASN.1 module 
> change (if can avoid a new error code), but only 
> "clarifications" in the text.
> 
> It has the additional advantage of satisfying the "downgrade 
> to cache-only 
> iff that is all that is available", as requested by James.
> 
> Denis
> 
> 
> > I think a client should definitely and in every case reject 
> a response 
> > with a mismatching nonce. This is covered in RfC2560 in its current
> > form: mismatching nonce => reject.
> > 
> > So allow me to rephrase again based on your proposal:
> > 
> > A) always includes a nonce into his request;
> > B) checks the nonce in the response:
> > 
> >      - if it matches with the nonce from the request, then accept
> >        the response (pending other checks),
> > 
> >      - if it does not match with the nonce from the request, then
> >        reject the response
> > 
> >      - if nonce is not present, then are a local trusted time 
> >        available and a policy for cache responses both available ?
> >  
> >           - if both a local trusted time is available and 
> there exists
> >             a policy for cache responses, then compare the time
> >             difference between that local trusted clock and the
> >             producedAt field from ResponseData. If that 
> time difference
> >             is below the limit stated by that policy, then 
> accept the
> >             response (pending other checks).
> > 
> >           - if not, then reject the response.
> > 
> > 
> > [Additionally we add some checks:
> > 
> > i) if nextUpdate is present and is lower than the current date from 
> > our trusted clock before sending the request, we detected a clock 
> > problem in our "trusted" clocks.
> > 
> > ii) if thisUpdate is too old for our limit stated in the policy we 
> > reject the answer, too.
> > 
> > iii) additionally some sanity checks: 
> > thisUpdate<=producedAt<=nextUpdate
> > 
> > I have to double check, but I think thats all we do.]
> 
> 
>