Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Apr 2002 20:02:24 +0200 (MET DST)

> 
> If the protocol does choose to return the requestHash in the response, do
> you see any benefit to adding a requestNonce in the response? If not, the
> requirement should go. I think it would be better for the requirements doc
> to say what is desired: "Prevent replay attacks on responses" and let the
> protocol decide how to do it.
> 
I seem to agree with Ambarish that the current texts is an overspecification.

Thus, a simple text like: "The protocol MUST provide a means to
protect itself against replay attacks." seems sufficient for this
document. 

Peter

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 04 Apr 2002 15:30:59 +0200

Ambarish,

> protect itself against replay attacks." seems sufficient for this

The current text is:

"In order to prevent replay attacks, the DPV client MUST be able to 
include a nonce in the DPV request. When the nonce is present in the 
request, then the DPV server MUST include the same nonce in the 
response.

(...)

The DPV response MUST be bound to the DPV request. This can be 
accomplished by repeating the important components from the request in 
the response or by including a one-way hash of the request in the 
response."

The new proposal is:

"The protocol MUST prevent replay attacks, including for the case where 
the client does not have a clock synchronized with UTC.

(...)

The requester MUST be able to verify that the response was constructed 
taking into consideration all the parameters from the request. In addition, 
without the need to store the request, a requester SHALL be able to prove 
that a valid DPV response was made for a given certificate and for a given 
validation policy, including associated parameters, if any." 

Now, a few explanations:

1) The sentence "including for the case where the client does not have a
clock synchronized with UTC" implies the use of a nonce. 

2) Placing a requestHash in the response is fine to make sure that no
information has been dropped or changed on its way to the server. However
this is not sufficient. Clients would like to store valid responses, without
the need to store the whole request as well, that may include a bunch of
certificates, CRLs and OCSP responses. In many cases, clients want to store
the "YES" answer and only prove that the YES is about THIS certificate and
THIS validation POLICY. Hence the need to include in the response both the
reference of the certificate and the reference of the policy to keep the
response as short as possible (in particular for thin clients).  

It is anticipated that in many applications, clients will only need a valid
DPV response, without the path and the associated revocation information.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 04 Apr 2002 11:21:25 -0500

Denis:

I prefer the following wording.  I think it provides the same end result.

"The protocol MUST prevent replay attacks, and the replay prevention 
mechanism employed by the protocol MUST NOT rely on clocks being 
synchronized with UTC."

(...)

The DPV client MUST be able to confirm that the DPV server-generated 
response was constructed from the client's request.  When the response 
indicates certificate validity, the response MUST allow the DPV client to 
readily confirm that the response was made for the requested certificate 
and for the requested validation policy, including associated parameters, 
if any."

Russ