RE: OCSP response pre-production

["Terry Hayes" <thayes0993@xxxxxxx>]

I also like this proposal.  I believe that it is compatible with 
existing responders that use pre-produced nonces, in the sense that 
there aren't any changes required to allow them to continue operations.

Responders that only use pre-produced responses (with no nonce) would 
benefit from changing their implement to add the extension.  This would 
allow them to support the clients that implement dual-mode policy as 
described in this thread.

As Florian has pointed out, this proposal is easier to understand than 
having the server generate nonces.  In fact, I was going to write an 
email that complained about overloading the nonce field to represent 
this bit of information.  Given this proposal, I don't have to!

I also agree with Mike that we need to define an error that says that a 
nonce is required for this responder.  This error is subject to 
denial-of-service attacks (since it's unsigned), but we're already 
exposed to that in this protocol anyway.

Terry

David Engberg wrote on 10/1/2003, 3:10 PM:

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