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

From: "Housley, Russ" <[email-masked]>
Date: Thu, 04 Apr 2002 16:42:48 -0500

Ambarish:

I am fine with this.

Russ

At 11:35 AM 4/4/2002 -0800, Ambarish Malpani wrote:

>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
>
>
>
>
>---------------------------------------------------------------------
>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: Thursday, April 04, 2002 8:21 AM
> > To: Denis Pinkas
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
> >
> >
> > 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."
> >

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Apr 2002 14:44:42 +0200

> I am fine with this.

.. but I am not.

> >the response over what might be a bandwidth constrained channel.

The proposal does not mandate this. The proposal from Russ (and I fully
agree with his proposal) is:

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

The first sentence is easily met using a hash from the request. Hence the
response does not need to contain all the information from the query.

> >request. 

This is exactly what is *not* desirable for thin clients, because the
argument you raised would then apply: this would result in a lot of extra
information that needs to be kept by the thin client.

> If the client doesn't need to be able to prove that, it

Exactly for the reason that it is not desirable to keep the whole request, 
e.g. when it is needed to prove two years later that you got a valid
response. 

Hence the reason to maintain the second sentence:

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

Denis