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

From: Ambarish Malpani <[email-masked]>
Date: Wed, 03 Apr 2002 09:59:50 -0800

Agreed!

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 9:19 AM
> To: Denis Pinkas; Ambarish Malpani
> Cc: [email-masked]
> Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
> 
> 
> Denis and Ambarish:
> 
> > > 3. Section 4 Para  12
> > >     In order to prevent replay attacks, you require the 
> nonce to be
> > > present in the response. As mentioned by Petra, if the response
> > > contained the request hash, it doesn't need to contain 
> the nonce. It
> > > is still bound to the request. Present of the request nonce in the
> > > reply shouldn't be a requirement in this case.
> >
> >Verification of equality of the nonce is simple and 
> straigthforward to
> >discard replay attacks. Since we do not require to use the 
> hash of the
> >request in the response, we have purposely maintained this 
> requirement.
> 
> Perhaps we have boxed ourselves into a corner.  Maybe there 
> is a simple way 
> forward.
> 
> Two requirements are getting muddled here.  One requirement 
> is to bind the 
> request to the response.  The second requirement is to 
> include a replay 
> detection mechanism.
> 
> Nonces and hashes are mechanisms that are used to implement 
> one of these 
> requirements.  Perhaps this document should simply state the 
> requirement, 
> and not impose a mechanism.
> 
> Russ
>

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 04 Apr 2002 11:35:14 -0800

Denis, Russ,
    I agree with the first phrase:

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

I don't agree with the requirement that a response needs to
contain all the information from the query in itself. That could
result in a lot of extra information that needs to be carried in
the response over what might be a bandwidth constrained channel.

In all cases, being able to tie the response to the request does
the job. If a client needs to be able to show that this response
was for a particular certificate, it can retain the original
request. If the client doesn't need to be able to prove that, it
can discard the request after it gets the response. I don't see
why the response needs to contain
     "the requested validation policy, including associated 
      parameters, if any."

I would prefer the second statement to read:

The DPV client MUST be able to confirm that the DPV server-generated 
response was constructed for the client's request.

(NOTE: I changed Russ's "from" to "for")

A

> Sent: Thursday, April 04, 2002 8:21 AM
> To: Denis Pinkas
> Cc: [email-masked]; [email-masked]
> 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
> 
> 
> At 03:30 PM 4/4/2002 +0200, Denis Pinkas wrote:
> >"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."
>