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

From: "Deacon, Alex" <[email-masked]>
Date: Tue, 18 Nov 2003 14:44:12 -0800

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

========================

From the WG summary
> 3. OCSP v1 will be revised to specify the server and client
> processing requirements where the client included a nonce in 
> the request.  The revised document will require servers to include
> the nonce in the response or return an error.

From the Draft Meeting Minutes  
> OCSPv1 problem - Mike Meyers (Traceroute)
> 	OCSP has a facility in which a client may include a nonce in 
> a request, to detect and reject replays of responses. Unfortunately, 
> the RFC did not make perfectly clear that a client MUST reject a 
> response that did not include a nonce, if the client included a nonce 
> in the request. Similarly, the RFC did not make clear what a server 
> should do if it receives a request with a nonce, but is incapable of 
> generating a response containing a nonce, i.e., a server that deals 
> only with pre-signed responses.
> 	A straw poll indicated that the vast majority of clients deal 
> with these issues properly, but not all. OCSP servers that rely on 
> caching do not generate a unique response for each request, so they 
> omit nonces.  An error could be returned by a server to indicate the 
> inability to respond properly to a request with a nonce, but errors 
> are not signed, so this does not address the security concern.
> 	Russ Housley, the cognizant AD made the following observation 
> re this issue. "When an OCSP Client puts a nonce in an OCSP Request, 
> replay protection is expected. Therefore, the OCSP Responder MUST 
> include the same nonce value in the OCSP Response.  If the OCSP 
> Client receives an OCSP Response that fails to include the correct 
> nonce value, it MUST be rejected."

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Nov 2003 19:10:50 -0500

>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