Subject: draft-ietf-pkix-dpv-dpd-req-00.txt

From: "Housley, Russ" <[email-masked]>
Date: Fri, 07 Dec 2001 15:15:55 -0500

Denis:

You have done a nice job on the document.  I think that we are close to 
consensus, but I do have a few comments.  I have divided my comments into 
technical and editorial.

Russ

= = = = = = = = = =

TECHNICAL

In section 3, 9th paragraph, I am surprised to see SHALL in a section on 
rationale.  I propose the following:

    Clients can direct the server about to perform path
    validation in accordance with a particular validation
    policy.

In section 3, last paragraph, I do not consider this a statement of 
rationale.  While it is obvious that the client must trust the server, I 
think that a discussion of this point belongs elsewhere.

In section 4, 1st paragraph, I think that we do trust the DPD server to 
return the most current information that is available.  Clearly, this is a 
radically different situation than a DPV server, but it is a security 
relevant point, especially if the DPD client does not have a good source of 
time.  In other words, the DPD client trusts the server to provide up to 
date data, not stale data.

In section 5, 5th paragraph, please change "self-signed certificates" to 
"trust anchors."  While trust anchors are often specified with self-signed 
certificates, other approaches are also effective.

In section 5, 8th paragraph, I understand the reasons why a client might 
want to perform DPV based on some previous time T.  DPD for  some previous 
time T is another matter, and I do not think that repositories provide the 
information necessary to implement such a service.

In section 5, last four paragraphs, the points made in these paragraphs 
belong in section 5.1.  They apply only to DPV.  They do not apply to DPD.

In section 5.2, last three paragraphs, the points made here do not apply to 
policy.  I think that these paragraphs describe protocol requirements.  I 
think these concepts belong in section 7.

In section 6, 1st paragraph, I am concerned about the structure of the MUST 
requirement.  I think that we agree on the concepts, but not on the 
wording.  These are requirements of the protocol, and the protocol MUST 
include support for client defined policies.  Thus, there are three cases 
that the protocol MUST support.  However, implementations of the protocol 
MUST support the first two cases, and implementations MAY also support the 
third case.  The three cases are:

    1. Client uses the DPV server's default policy.  When
       this is done, the response indicates the policy
       that was employed by the DPV server.
    2. Client selects one policy from a set of policies
       offered by the DPV server.  In the extreme case,
       the server only offers one policy.
    3. Client defines a new policy.

In section 6, 2nd paragraph, I am concerned about the structure.  The 
reference to the certificate MUST be unambiguous.  This MAY be accomplished 
by providing the certificate, or using ESSCertID, or something else.

In section 6, I think that the client should be able to get the 
certification path that was constructed by the DPV server and any 
revocation status information that was used to validate it.  Return of this 
information should not be the default, but it should be available in case 
the client wants to archive it.

In section 8.2, last paragraph, I am concerned about the structure.  While 
I agree that the stated conditions MAY apply to any particular policy, the 
protocol MUST support all of the choices.  Further, an additional policy 
alternative ought to permit the server to select any available revocation 
status information.

In section 8.3, 1st paragraph, I am concerned about the structure.  The 
protocol MUST allow the client to specify end-entity certificate requirements.

In section 8.4, I am do not see a requirement statement.  Is the protocol 
required to support cautionary period in the request to specify a new policy?

In section 9, I am concerned about the structure.  While I agree that the 
stated conditions MAY apply to any particular policy, the protocol MUST 
support all of these capabilities.

In section 10, 1st paragraph, I am concerned about the structure.  Is the 
protocol required to support policy definition?  This says that this 
capability is OPTIONAL.  I think that the protocol MUST include the 
capability, but that the capability is optional to implement.

In section 11, 1st paragraph, I have a strong disagreement.  The DPV server 
out to be able to return this information.  Most times it will not be 
requested, but I think that the capability ought to be available to all 
clients.

In section 11, 2nd paragraph, please delete this paragraph.  I am not 
concerned with any particular words in it, but I am concerned with the 
reference.  I do not want to delay publication of this document while 
[DSV-REQ] is being debated.  Please break the linkage.

In section 12, clients MUST trust their DPV server.

EDITORIAL

The subtitle and the upper left heading on the title page have two 
different file names.  I believe that the subtitle is correct.

Please change "rational" to "rationale" throughout the document.

Please change "end-certificate" to "end-entity certificate" throughout the 
document.

Please use the term "trust anchor" throughout the document.  The term "root 
key" is also used, but I do not think that this term is appropriate since 
the validity period and issuer name are needed as well as the public key.

In the Abstract (Section 1), 3rd paragraph, please change "leaf 
certificate" to "end-entity certificate."  Also, the Abstract does not 
usually get a section number.

In Section 2, please merge the two paragraphs.  The last sentence of the 
first paragraph really says the same thing as the whole second 
paragraph.  I suggest:

    These delegated processing provides two primary services:
    delegated signature validation, delegated path validation and
    delegated path discovery. Some clients require a server to
    perform path validation and have no need for data acquisition,
    while other clients require only delegated path discovery in
    support of local path validation.

In section 3, paragraph 7, please reword the second sentence:

    Even clients that are able to do their own path validation
    may rely on a trusted server to do path validation if
    centralized management of validation policies is needed.

Please delete the last paragraph in section 4.

I do not understand the 6th paragraph in section 5.  I think that it says 
different policies may be constructed to support the construction of 
certification paths in support of the provision of different security 
services.  Please reword.

In section 5.1, last paragraph, please change "leaf certificate" to 
"end-entity certificate."

In section 7, 1st paragraph, please change "to use" to "the client to use."

In section 7, 9th paragraph, item number 3, please change the comma to a 
period.

In section 8.2, 2nd paragraph, please change "It can then specified if" to 
"The policy can specify the source of revocation status information:"

Please add RFC 2634 to the list of references.

---

From: Petra Barzin <[email-masked]>
Date: Sun, 09 Dec 2001 14:41:42 +0100

Russ,

I agree with most of your comments - except the following:

> date data, not stale data.

Like Denis I see a DPD server as an untrusted server. A client doesn't need
to trust a DPD server because all information returned is integrity protected
and he can check the content, e.g. the validity period. The client needs to have
a good source of time! Otherwise he couldn't locally validate a certificate.
You must trust an DPD server as much as an LDAP server or an OCSP
responder. They are all untrusted servers, even so you have to trust the
administrator to always update the database in time.

> information necessary to implement such a service.

I think the DPD protocol MUST provide the possibilty to request and return
cert pathes based on some previous time T. That's an important requirement.
You agree that an DPV request/response need to be based on a previous
time T. Well, if the client only delegates the path discovery but does the
validation locally he may need the certificates from a previous time T.
An implementation of a DPD server MAY not support it or the repositories
MAY not provide this information. In this case the DPD server simply
returns an error.

Petra