RE: OCSP response pre-production

["Florian Oelmaier" <oelmaier@xxxxxxxxxxx>]

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

-- 
Florian Oelmaier
SyTrust