Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Nov 2003 09:55:55 -0500

At 13:15 +1000 11/19/03, Manger, James H wrote:
>I agree with Alex Deacon (& Ryan), not Stephen Kent, on this issue.
>
>Michael Myers initiated a poll about adding an error code that 
>responders would use when they could not copy a nonce from a request 
>to a response.  The poll was overwhelmingly rejected: something like 
>1 Yes, 20 No.  Clearly a new error code cannot be added.  Trying to 
>add text that a client must always reject a response missing a nonce 
>cannot be added as it would be against the spirit of the 
>overwhelming poll result.

James,

My comments addressed the question of proper behavior of clients and 
servers when there is a mismatch between the type of request offered 
and the capability of the server to respond consistent with the 
request type.  The poll I alluded too, perhaps not precisely enough, 
was on that topic.  I was not referring to the question of whether we 
should send an error message.

>Alex might not have to worry as the minutes did not actually say a 
>new version of OCSPv1 would be produced (apparently Tim Polk's "WG 
>summary" did but I have not seen that).  The previous poll shows it 
>would not be supported - and I don't think you are allowed to go 
>straight from editor to area director, bypassing the working group.

My comments did not suggest that we would change OCSPv1 to impose a 
new requirement to send new messages, etc. But there is certainly 
room to clarify what some folks see as an ambiguous area of the state 
machine.

>P.S. Russ Housley's quote fails to accommodate an OCSP client that 
>puts a nonce in an OCSP request because the client **prefers** to 
>get replay protection, though may be willing to forgo that 
>protection for the sake of a more scalable system if only cached 
>responses are available.  It would be ok to add text saying "a 
>client requiring replay detection can include a nonce in the request 
>and reject a nonce-less response".

Your comment immediately above assumes a possible motivation on the 
part of some clients who insert a nonce in a request. I can't rule 
out the possibility that some clients may behave in this fashion, but 
this assumption cannot generally be inferred from the OCSP spec.

We recognize now that the spec does not accommodate all the possible 
ways that a client and a server might interact, when the server 
supports only canned responses. To fix this problem completely will 
probably require a revised OCSP, probably with a new version number. 
Howeverm in the interim, it is reasonable to clarify what clients and 
servers should do under these circumstances, without changing the 
bits on the wire, and without introducing vulnerabilities of the sort 
that the use of nonces is designed to avoid. I believe Russ's 
statement sets the parameters for how we clarify this issue, within 
the bounds of OCSP v1.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 19 Nov 2003 08:29:00 -0800

> -----Original Message-----
> From: Stephen Kent
> Sent: Wednesday, November 19, 2003 6:56 AM
>
> . . .
>
> I believe Russ's statement sets the parameters
> for how we clarify this issue, within the bounds
> of OCSP v1.

At the risk of adding to my collection of PKIX battle
memorabilia yet more sticks, stones, arrows and flame residue,
what if caching servers send back a signed "unknown"?  It's
signed, cacheable and already in standing v1 codebases (or so
one presumes).

The only downside is that a client will have to retain state in
order to distinguish a true "unknown" from an "unknown due to
nonce" and thus trigger a non-nonced retry if so configured.

This would be in addition to "MUST reject", which protects the
client in the event it receives a non-nonced response anyway.

Mike