RE: OCSP response pre-production

[David Engberg <dave@xxxxxxxxxxxxxx>]

I agree with the general idea of having an unambiguous way for a 
responder to indicate that it will not provide nonces in responses.  I 
think it may be unnecessarily restrictive to say that every client must 
automatically reject a response without a nonce, but that would not 
directly impact our software either way.

I would prefer a signalling mechanism that does not require two 
round-trip communications to establish nonce support, and that does not 
add any significant size to the body of pre-generated responses to 
indicate that they don't have nonces in them (which is evident).

Michael's initial proposal (below) could work, but has the two issues of 
requiring two round-trips for negotiation and returning the 
"unsupported" message in the unsigned portion of the body rather than in 
the signed body.  I also would prefer to remove the last sentence of the 
semantics or at least tone it down as unnecessarily focused on one 
hypothetical risk above all others (e.g. remote server key compromise).

> SYNTAX:     Expand v1 OCSPResponseStatus syntax to
>             include (7) noncesNotAccepted.
>
>
> SEMANTICS:  Responders SHOULD respond back with the
>             requestor's nonce but if can't then SHALL
>             respond with an error message of the value
>             noncesNotAccepted.
>
>             Requestors SHALL reject signed responses
>             that fail to incorporate a supplied nonce.
>
>             Upon receipt of noncesNotRequired, requestors
>             MAY retry the request without using a nonce.
>             Requestors are STRONGLY ADVISED that doing
>             so MAY subject them to additional risk.

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.