Re: OCSP response pre-production

["Julien Stern" <julien.stern@xxxxxxxxxxxxx>]

On Thu, Oct 02, 2003 at 08:45:39AM -0000, Florian Oelmaier wrote:
> 
> > As an alternative, pre-generated responses could include a flag or 
> > extension in their signed body to indicate that not only are they not 
> > supplying a nonce with this response, but that they don't supply nonces 
> > with any response, and if you trust that responder (via its public key 
> > cert), then you may choose to accept the non-nonce-bearing response from 
> > that server with this explicit flag (if that is your policy).
> > 
> > This avoids the risk of someone replaying a response to you in which the 
> > attacker chose not to supply a nonce, but you did.  It allows a client 
> > to distinguish between a server saying "Here's a response without a 
> > nonce because you I think you didn't ask for one" and "Here's a response 
> > without a nonce because the responder for you or your CA does not use 
> > nonces."
> > 
> > I believe the following is a valid security policy which some (most?) 
> > clients may choose to implement as an option:
> > 
> >    - Send a nonce with every request
> >    - Accept a response with a matching nonce from any trusted responder
> >    - Accept a response with a nonceUnsupported extension from any
> >        trusted responder
> >    - Reject a response with no nonce and no nonceUnsupported extension
> > 
> > This would allow the client to be much more usable with random public 
> > certs (using AIA fields and delegated responder certs) in real-world 
> > settings like secure email, etc.
> > 
> 
> I fully agree with this. It seems to be a good idea.
> 
> My idea of server-generated nonces is simply the other way round: If the responder wants to signal "nonceUnsupported", the response does not include a nonce, if the responder generally supports nonces it simply generates one for requests not containing one.
> 
> From my point of view both proposals do technically the same and are fine for me. Davids "nonceUnsupported"-extension is easier to understand and more clear while server generated nonces do not need changes in clients like Juliens or mine. I am fine with both - tell me when to begin implementing.

I fully agree with this too. The server has to indicate whether it
supports nonces or not INSIDE the signed content. Server generated
nonces are a way, this extension is another (hmm, well, the equivalent
of server generated nonces would be an ICanProvideANonceIfYouWish
extension, but ...).
On this other hand, I think that it is dangerous to indicate this fact
as an _unsigned_ error, as this error reply could easily be faked by an
attacker, making him think a server does not support nonces while in
fact it does.

--
Julien