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

["Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>]

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.