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

From: Ambarish Malpani <[email-masked]>
Date: Mon, 01 Apr 2002 13:59:58 -0800

Hi Denis, Russ,
     Great work on the new draft!

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.

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.

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.

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.

That's 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: 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: Brian Hunter <[email-masked]>
Date: Tue, 02 Apr 2002 15:24:01 +0200

Hello Denis and Russ,

>      Great work on the new draft!
I concur.

I have one question and a couple of small typographical comments to add.

5. Section 5 Para 4
    This comment goes along with Ambarish's comment 1.  I do not
understand what is meant by "if issued" in the following sentence:
  "The trust anchor self-signed certificate, if issued, is not
included."

Without understanding the "issued" point and assuming that all trust
anchor certificates, self-signed or not, are issued, then I would have
the sentence read:
  "The trust anchor is not included."
Note that I am agreeing with Ambarish that the self-signed requirement
for a root should be dropped.

6. Section 4 Para 11 c)
    "If another request could made later..."
    Suggest to change to: "...could be made..."

7. Section 7 Para 3
    "constrains" -> "constraints"

8. Section 7.1 Para 1
    "build" -> "built"

9. Section 9 Last paragraph point (3)
    Is it intended that the validation time should be adjusted for only
one of the four points, hence the use of "or" after point three? I would
suggest the use of "and".

Regards,
Brian

---

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

>      Great work on the new draft!

Thank you. It was quite harder than expected.

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

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

> 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.
 
> might not be signed (e.g. badly formatted request, etc.) Please

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

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Apr 2002 17:05:05 +0200

Brian,

 
> for a root should be dropped.

For this point, see the response to Ambarish. It is proposed to have the
following text:

All the following change requests have been granted.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 03 Apr 2002 11:53:06 -0500

>for a root should be dropped.

Trust anchors can be established using self-signed certificates or by other 
means, either way, the  trust anchor is not included.  Perhaps this point 
is only adding confusion.

>suggest the use of "and".

I disagree.  The time could be adjusted for one or more of these 
reasons.  It is an inclusive or.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 03 Apr 2002 12:18:44 -0500

>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: Brian Hunter <[email-masked]>
Date: Thu, 04 Apr 2002 11:10:17 +0200

Russ,

> is only adding confusion.

Not including non-self-signed trust anchors is contrary to Denis' change
sent to Ambarish.  I agree with Denis' clarification because it aligns
DPD with path validation in 2459bis section 6.1 para 7:

"When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of the
prospective certification path."

> reasons.  It is an inclusive or.

See Denis' response to me agreeing with the change to "and".
All in all, I think this is a small point, in the scope of this
document, but to clarify the meaning, perhaps the use of "and/or" would
be appropriate.

Brian

---

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

Brian,

I concur.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 04 Apr 2002 10:59:35 -0500

>prospective certification path."

Fine.

>document, but to clarify the meaning, perhaps the use of "and/or" would

I can live with "and/or"

Russ

---

From: Steve Hanna <[email-masked]>
Date: Thu, 04 Apr 2002 12:56:40 -0500

Actually, trust anchors are *never* part of the path for son-of-2459.
See section 6.1, which defines the valid path as "a sequence of n
certificates [that] satisfies the following conditions:

    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
    the issuer of certificate x+1;

    (b)  certificate 1 is issued by the trust anchor;"

The text quoted by Brian is just a clarification that a self-signed
certificate is not part of the path, even though it could meet the
criteria given above.

So non-self-signed trust anchors (and self-signed trust anchors)
should NOT be considered part of the path for the purposes of
DPD/DPV.

-Steve

---

From: Brian Hunter <[email-masked]>
Date: Fri, 05 Apr 2002 10:10:44 +0200

> certificates [that] satisfies the following conditions:

<snip>

> should NOT be considered part of the path for the purposes of
True.  And thanks for correcting my oversight.

Brian