RE: OCSP response pre-production

["Miguel Rodriguez" <mars@xxxxxxxxxxxxxx>]

I also agree with this idea proposed by Julien Stern, checking the
nextUpdate field is a good way of distinguishing fresh responses from
cached or pre-produced ones (in fact I think the date checking makes
sense for this type of responses, with all the clock drift associated
problems, as in the case of CRLs). 

However I object the use of a server generated nonce to avoid condition
1.2 in Julien's statement. How is that different from a replay attack? 

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Florian Oelmaier
> Sent: Tuesday, September 30, 2003 2:05 PM
> To: 'Julien Stern'; ietf-pkix@xxxxxxx
> Subject: RE: OCSP response pre-production
> 
> 
> 
> Thanks, Julien!
> 
> First: I love your client behaviour and your nextUpdate checking is
> cool.
> 
> Second: SyTrust ValidationWorks shows a similar behaviour in its
default
> configuration. So I am not alone out there. Hipp Hipp Hurray :)
> 
> We understood the RfC the same way and I like the flexibility of this
> approach.
> 
> And if a responder wants enforce nonce-checking on your client, it can
> simply include a server-generated nonce into all responses. Thus an
> attacker cannot get a response out of this OCSP responder that would
> force your client into 1.2.
> 
> --
> Florian Oelmaier
> SyTrust
> 
> > -----Original Message-----
> > From: owner-ietf-pkix@xxxxxxxxxxxx
> > [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Julien Stern
> > Sent: Tuesday, September 30, 2003 6:26 PM
> > To: ietf-pkix@xxxxxxx
> > Subject: Re: OCSP response pre-production
> >
> >
> >
> > If I may attempt to add my 2 cents, the RFC says that
> >
> > "If nextUpdate is not set, the responder is indicating that
> > newer revocation information is available all the time."
> >
> > The behavior of our (experimental) client currently is:
> >
> > 1) We send a nonce
> > 	1.1) We get a nonce back
> > 		=> We check the nonce
> > 	1.2) We do not get a nonce back
> > 		=> We check "nextUpdate", if absent, we reject, as a
> > 		live responder should really provide a nonce, if present
> > 		we assume the responder is keyless or proxy and we check
> > 		the local clock thingies
> >
> > 2) We do not send a nonce
> > 	Whether we get a nonce back or not.
> > 		=> We check "nextUpdate", if absent, we know very well
> > 		that we could be subject to an replay attack, we decide
> > 		based on user config (I would tend to reject but we
> > 		kinda looked for it...), if present, we also
> > know we could
> > 		be subject to a replay attacka (as in 1.2 actually) but
> > 		about as bad as what we have with CRLs, so we accept
> > 		after checking the local clock thingies
> >
> > If the two sets [Nonce-capable server] and [live servers] are
> > the same and if they are respecting the above RFC quote, the
> > replay attacks seem to be minimized by the above client
> > behavior. Also, we play fairly nicely with keyless and proxy
> > responders.
> >
> > The only thing we really do not accept is a "live" server
> > pretending it is unable to include nonces...
> >
> > Now, the question is whether the distinction between "live"
> > and "caching" servers can actually be made (in real life)
> > from the "nextUpdate" field as indicated by the RFC above quote?
> >
> > --
> > Julien
> >
> >