RE: OCSP response pre-production

["Florian Oelmaier" <oelmaier@xxxxxxxxxxx>]

Michael,

> [...] An 
> environment called to task by a security auditor for sending 
> a canned response to a nonced request, the latter which by 
> technical definition is an assertion by a relying party that 
> the RP does NOT wish to receive a canned response, can very 
> easily send back any unsigned error.  

I want to comment two points here:

1) the "technical definition" you give in the sentence above: "[sending]
a nonced request [is by] technical definition [an] assertion by a
relying party [client] that the RP [client] does NOT wish to receive a
canned [pre-produced/cached] response".

I think the discussion here on the list shows that your "technical
definition" is not common ground here. It is NOT what I think and it is
NOT what RfC2560 states. There is another definition supported by
RfC2560 and some people here on the list: "A client sending a nonce
expresses its wish to get a nonced response."

>From my point of view this discussion showed:

A) your definition is not covered in RfC2560
B) there are multiple clients out there that make use of the benefits of
the definition as stated in RfC2560
C) there are multiple installations out there relying on these benefits

If you want to add such a change to the definition into the current
wording of RfC2560 one way or the other I think YOU are calling for
OCSPv2 - as this is a major change to some/many installations out there.

But I think thats the point where our discussion started :(

> [...] An 
> environment called to task by a security auditor for sending 
> a canned response to a nonced request, the latter which by 
> technical definition is an assertion by a relying party that 
> the RP does NOT wish to receive a canned response, can very 
> easily send back any unsigned error. It's best if we at least 
> standardize one for interoperability if nothing else.

2) I am not against an additional error message, as long as its use is
OPTIONAL for the responder and the current behaviour of the responders
(sending a non-nonced response back) is allowed, too. We can readily go
for a wording like this, if you need this error response urgently:

"If a responder cannot process a nonce he SHALL indicate this by sending
an error status "NonceNotAllowed" or by sending a response without
nonce."

-- 
Florian Oelmaier
SyTrust