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

From: "Ryan M. Hurst" <[email-masked]>
Date: Tue, 18 Nov 2003 17:03:20 -0800

I agree with this, in-fact it appears to be in conflict with the earlier
discussions on the thread on the same topic.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Deacon, Alex
Sent: Tuesday, November 18, 2003 2:44 PM
To: [email-masked]
Subject: OCSPv1 and nonces (RE: draft meeting minutes)

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: "Michael Myers" <[email-masked]>
Date: Tue, 18 Nov 2003 18:43:10 -0800

The initial poll I sent out on 9/24/03 was worded as follows:

[Who] would break as a consequence of the following normative
language:

    "Clients that elect to include a request nonce
     SHALL reject responses that fail to include
     the client's nonce from the associated request."

    "Correspondingly, upon receipt of a request
     containing a nonce, a responder SHALL include
     the value of such nonce in the production of
     the associated response."

11 of 12 client side implementors and 10 of 12 server side
implementors responded "no breakage".

Mike