RE: DISCUSSION: Nonce-specific error code for OCSP

["Florian Oelmaier" <oelmaier@xxxxxxxxxxx>]

David Engberg wrote:
> Dumb question:  why is it possible to add a new 
> OCSPResponseStatus code 
> value (a non-backward-compatible addition) for v1, but not to convey 
> this information through a new responseExtension in the 
> signed body (a 
> backward compatible change with better security semantics)?

/agree

Even more as all extension procressing is optional, meaning that such an
addition IS completely backward compatible with all clients out there by
definiton. Why did we add the extension system in the first place? I
thought this was done with such extensions in mind.

After all this discussion, we have two options for adding such an
extension:



Option A) "The-signer-of-this-response-intended-it-to-be-cached
extension": Even when the request containes a nonce a responder may
answer with a response containing no nonce but this extension.

Clients supporting nonces should not accept a nonce-less response
without this extension.



Option B) "Usually-I-support-nonce extension": Responders that are able
to generate nonces and get a request without nonce add this extension.
(A responder could also indicate this by producing a server-generated
nonce). 

Clients supporting nonces should not accept responses containing this
extension but NOT containing a fitting nonce. Getting a response without
nonce and without this extension indicates, that the responder is not
able to generate nonces.



Mind: These options do basically the same, we only need one of them.



I strongly vote to include an extension according option A (Davids
proposal) into OCSPv1. 

If this is not possible, I would like to advise all responder
implementers to use Option B with server-generated nonces, as this
behaviour is already covered by OCSPv1 and does not need any changes to
the RfC. For OCSPv2 we should then go for an extension according to
option A.

-- 
Florian Oelmaier
SyTrust