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

From: Ambarish Malpani <[email-masked]>
Date: Wed, 03 Apr 2002 08:40:00 -0800

Hi Denis,
    Thank you, the resolution to all these questions is
excellent (other than #3).

In case of the 3rd comment:

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

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.

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: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 7:00 AM
> To: Ambarish Malpani; [email-masked]
> Cc: [email-masked]
> Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
> 
> 
>  
> > Hi Denis, Russ,
> >      Great work on the new draft!
> 
> Thank you. It was quite harder than expected.
> 
> > A few comments:
> > 
> > 1. In 2 places you equate the "root" with a self-signed cert. I
> > hope you intend to allow the trust anchor to be a non-self-signed
> > cert. The 2 places are Para 4 of Section 4 and Para 4 of Section 5.
> 
> In Para 4 of Section 4, the text says "e.g. root self-signed 
> certificates".
> So there is nothing wrong, since this is only an example. No 
> change needed.
> 
> In Para 4 of Section 5, the text says: "The trust anchor self-signed
> certificate, if issued, is not included." Since Brian had 
> problems with 
> that sentence too, it is proposed to change it into:
> 
> "Each path consists of a sequence of certificates, starting with 
> the certificate to be validated and ending with a trust anchor. 
> If the trust anchor is a self-signed certificate, that self-signed 
> certificate is not included."
> 
> > 2. Section 4 Para 9
> >     You require the DPV server to "obtain" the certificate from the
> > reference provided by the client. This is *not* a requirement. If
> > the server obtains the certificate by some other means, 
> that is okay,
> > as long as it verifies that the certificate is indeed the one
> > being referred to by the client.
> 
> The current sentence is:
> 
> "If not provided in the request, the server MUST use the unambiguous 
> reference provided in the request to obtain it."
> 
> It is proposed to change the sentence into:
> 
> "If not provided in the request, the server MUST verify that 
> the certificate
> is indeed the one being unambiguous referenced by the client".
> 
> > 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.
>  
> > 4. Section 4 Para 16
> >     You require a DPV response to be signed - error response
> > might not be signed (e.g. badly formatted request, etc.) Please
> > allow for that case.
> 
> Certainly. The current text is:
> 
> "For the client to be confident that the certificate validation was 
> handled by the expected DPV server, the DPV response MUST be 
> authenticated.
> 
> For the client to be able prove to a third party that trusts the 
> same DPV server that the certificate validation was handled 
> correctly, 
> the DPV response MUST be digitally signed."
> 
> It is proposed to add at the end of each paragraph:
> 
> "unless an error is reported (e.g. badly formatted request, etc.)."
>  
> > That's it!
> 
> Thank you !
> 
> Denis
> 
> 
> > 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: Tim Polk [mailto:[email-masked]]
> > > Sent: Friday, March 29, 2002 2:55 PM
> > > To: [email-masked]
> > > Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
> > >
> > >
> > >
> > > Folks,
> > >
> > > The editors have informed me that they believe the -03 draft
> > > satisfies all
> > > WG Last Call comments and meets the criteria of rough
> > > consesnsus. My review
> > > agrees with their position, and I would like to ship the
> > > document to the
> > > ADs as soon as possible.
> > >
> > > If you have a dog in this fight, *please review the 
> specification by
> > > Tuesday COB.*  If I do not see any traffic on the list 
> stating that
> > > unresolved comments remain, I will forward the document to the ADs
> > > Wednesday morning.
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > > At 07:03 AM 3/29/02 -0500, you wrote:
> > > >A New Internet-Draft is available from the on-line 
> Internet-Drafts
> > > >directories.
> > > >This draft is a work item of the Public-Key Infrastructure
> > > (X.509) Working
> > > >Group of the IETF.
> > > >
> > > >         Title           : Delegated Path Validation and
> > > Delegated Path
> > > > Discovery
> > > >                           Protocol Requirements (DPV&DPD-REQ)
> > > >         Author(s)       : D. Pinkas, R. Housley
> > > >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> > > >         Pages           : 11
> > > >         Date            : 28-Mar-02
> > > >
> > > >This document specifies the requirements for Delegated Path
> > > Validation
> > > >(DPV) and Delegated Path Discovery (DPD) for Public Key 
> Certificates.
> > > >It also specifies the requirements for DPV and DPD 
> policy management.
> > > >
> > > >A URL for this Internet-Draft is:
> > > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > > eq-03.txt
> > > >
> > > >To remove yourself from the IETF Announcement list, send 
> a message to
> > > >ietf-announce-request with the word unsubscribe in the body
> > > of the message.
> > > >
> > > >Internet-Drafts are also available by anonymous FTP. Login
> > > with the username
> > > >"anonymous" and a password of your e-mail address. After 
> logging in,
> > > >type "cd internet-drafts" and then
> > > >         "get draft-ietf-pkix-dpv-dpd-req-03.txt".
> > > >
> > > >A list of Internet-Drafts directories can be found in
> > > >http://www.ietf.org/shadow.html
> > > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > >Internet-Drafts can also be obtained by e-mail.
> > > >
> > > >Send a message to:
> > > >         [email-masked].
> > > >In the body type:
> > > >         "FILE 
> /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt".
> > > >
> > > >NOTE:   The mail server at ietf.org can return the document in
> > > >         MIME-encoded form by using the "mpack" utility. 
>  To use this
> > > >         feature, insert the command "ENCODING mime" before
> > > the "FILE"
> > > >         command.  To decode the response(s), you will need
> > > "munpack" or
> > > >         a MIME-compliant mail reader.  Different
> > > MIME-compliant mail readers
> > > >         exhibit different behavior, especially when dealing with
> > > >         "multipart" MIME messages (i.e. documents which
> > > have been split
> > > >         up into multiple messages), so check your local
> > > documentation on
> > > >         how to manipulate these messages.
> > > >
> > > >
> > > >Below is the data which will enable a MIME compliant mail reader
> > > >implementation to automatically retrieve the ASCII version of the
> > > >Internet-Draft.
> > > >Content-Type: text/plain
> > > >Content-ID:     <[email-masked]>
> > > >
> > > >ENCODING mime
> > > >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> > > >
> > > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > > eq-03.txt>
> > >
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Apr 2002 19:00:10 +0200

Ambarish,
 
> you see any benefit to adding a requestNonce in the response? 

The benefit is that replay attacks can be detected very easily, 
in particular when using a traffic analyzer. Otherwise this is not
straightforward. A copy of this field in the response is worth the money.
:-)

> If not, the

This resolution has been taken at the Minneapolis meeting after a discussion
with Russ. 

Denis