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

From: "Manger, James H" <[email-masked]>
Date: Wed, 19 Nov 2003 13:15:33 +1000

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.

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.

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

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, 19 November 2003 11:11 AM
To: Deacon, Alex
Cc: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)

At 14:44 -0800 11/18/03, Deacon, Alex wrote:
>Hi,
>
>I was surprised to read about the decision made at the PKIX meeting last
>week in MN regarding the action to update OCSPv1 to require servers to
>include the nonce in the response or return an error.  (See excerpts below
>from both the draft minutes sent by Steve and from the WG summary sent by
>Tim) 
>
>Let me summarize the reasons I feel this decision is a bad idea:
>
>1) It will cause currently conformant OCSPv1 implementations to be
>non-conformant.
>
>2) It will cause OCSP profiles defined in other standards bodies to be
>non-conformant.   
>
>3) It seems to be contrary to the "rough consensus" I thought was clear
>based on the various polls Mike Myers posted to the list on this subject in
>mid October. 
>
>Its to late in the game to make such a large change to basic OCSPv1
>behavior.  Keep OCSPv1 as it is.
>

Alex,

There is a clear feeling that when a server returns a canned 
(nonceless) response to a client request that included a nonce, that 
this is not conforming to the spirit of OCSP, even if the RFC did not 
spell out this case in excruciating detail. Russ Housely reaffirmed 
this in the quote I included in the minutes.

The question of what a server should do when it receives a request 
with a nonce and is unable to comply is still up in the air, in my 
opinion.  The list has discussed the merits and shortcomings of 
having a server send an (unsigned) error message. Not sending any 
response is certainly another option. A good fix to this problem may 
have to await a revision of OCSP. But, in any case, a client that 
sent a request with a nonce ought to reject a canned response, as 
Russ said.

I don't see this clarification as changing the OCSPv1 spec. 
Moreover, my reading of the responses to Mike's poll suggests that 
the vast majority of servers and clients operate in an appropriate 
manner in this regard, given the level of guidance provided in the 
RFC.

There is no suggestion here that servers that issue only canned 
responses are  bad. OCSP specifically allows for canned responses. 
The issue is that a server should not issue a canned response to a 
request that clearly requests a response that contains a nonce.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 19 Nov 2003 07:41:35 -0800

> From: Manger, James H
> Sent: Tuesday, November 18, 2003 7:16 PM
>
> . . .
>
> 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.

Yet the preceding poll (clients MUST reject and servers MUST
incorporate) established no breakage in an overwhelming majority
of implemented cases.  Implemented, mind you: running code,
rough consensus and all that.

Thus in the case of "MUST reject", the clarification as recorded
in the minutes simply codifies what has already been done
correctly even in the absence of a tutorial in normative
language on the proper use of nonces in a security protocol.

The only issue that emerged following the first poll was that
two out of twelve server side implementations would be unable to
comply with "MUST incorporate" due to their reliance on
pre-produced responses to achieve cache-based cost efficiency.

This led to "SHOULD incorporate but if can't, then SHALL <X>".
A variety of syntax, semantics and rules of behavior regarding X
were and continue to be discussed.

Read the minutes carefully and note that the language recorded
there does NOT call for an error code.  It simply asserts in
normative language a fundamental principle of security
engineering that seems to have been better understood than it
was documented.

So, that leaves us with yet having to determine a value for X.
The error code poll asked us to consider one such idea.  It did
NOT seek an implicit repudiation of the poll that preceded it,
wherein "MUST reject" was very clearly established.

Mike