Subject: I-D ACTION:draft-ietf-pkix-dsv-dpv-dpd-req-00.txt

From: [email-masked]
Date: Mon, 22 Oct 2001 07:03:26 -0400

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 Signature Validation Delegated Path 
                          Validation and Delegated Path Discovery Protocol      
                          Requirements
	Author(s)	: D. Pinkas
	Filename	: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
	Pages		: 16
	Date		: 19-Oct-01
	
This document specifies requirements for three main request/response 
pairs. 
The first one, called Delegated Signature Validation (DSV), can be used 
to fully delegate signature validation processing to an DSV server, 
according to a set of rules, called a signature policy.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dsv-dpv-dpd-req-00.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-dsv-dpv-dpd-req-00.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-dsv-dpv-dpd-req-00.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.

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 24 Oct 2001 09:01:24 -0400

Denis:

Thank you for putting together this document.  I really appreciate your 
efforts to progress the DPV and DPD standards development.  Of course, I 
have several comments.  I have divided them into MAJOR concerns, MINOR 
concerns, and EDITORIAL comments.

MAJOR

Please remove the signature policy material.  I believe that this should be 
handled separately, if at all.  I do not want discussions of this new topic 
to further delay DPV and DPD.  If the signature topic has a constituency, 
it may not be the same as that of DPV/DPD.

Please review your use of "shall."  I believe that it should be changed to 
"MUST" or "SHALL" in every case.  Similarly, there are several cases where 
"may" ought to be changed to "MAY."

In section 3, the assertion that "client ... policy definition may be quite 
complex and only simple forms of policies can be defined in this way" needs 
clarification and justification.  What sorts of elements are anticipated 
within the policy definitions?  What will fall within the 
standard-supported scope as opposed to a server-side local matter?  I would 
strive for an approach that minimizes (or eliminates) the latter.

MINOR

In section 5, the client may want the path and related revocation 
information returned for archive purposes.  Please make this an option.

In section 7.2, should a DPV response from another server be considered as 
another candidate source of revocation status information?

In section 10, first paragraph, I do not understand the reference to "its 
dual."  Please clarify.

EDITORIAL

Please introduce the term "path."  At a minimum, the first use should be 
"certification path" and reference [PKIX-1].

Please change "certificate path" to "certification path" everywhere that it 
occurs (mostly at the end of the document).

In section 5, please change "copy and paste" to "provide."

In section 5, please change "additional protocol" to "additional protocol 
exchange."

In section 6, last paragraph, please change "client will only require" to 
"client MAY require."

Russ

---

From: [email-masked] ("Housley, Russ")
Date: Wed, 24 Oct 2001 20:21:14 +0000 (UTC)

Denis:

MAJOR

MINOR

EDITORIAL

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 Oct 2001 18:55:54 +0200

Russ,

Thank you for your detailed review and comments.

 
 
> it may not be the same as that of DPV/DPD.

RFC 3029, i.e. Data Validation and Certification Server Protocols (DVCS)
makes the difference between:

   - Validation of Digitally Signed Document (vsd), and
   - Validation of Public Key Certificates (vpkc).

  ... and I believe that this is fine.
 
Validation of Digitally Signed Documents is required in the context of a
non-repudiation service and requires either the use of Time-stamp tokens or
of Time-marks.

Validation of Public Key Certificates is fine for real-time use only, but
not for non repudiation purposes, otherwise clients would not be "thin" and
would have to do more processing.
 
Instead of removing this material, I believe that additional explanations
should be given in the document.

> "may" ought to be changed to "MAY."

You are quite right. I will make that review.
 
> strive for an approach that minimizes (or eliminates) the latter.

You are right. It is hard to draw a line. Instead of saying exactly what
falls inside and outside the line, I have attempted to characterize the way
the limit should be drawn:

"Alternatively, clients may also define policies. However, such policy
definition may be quite complex and only simple forms of policies should be
defined in this way, otherwise testing all the possible variations would
lead to non-interoperable implementations or would delay the time to make
sure that two implementations are really interoperable."

> information returned for archive purposes.  Please make this an option.

The client always wan the path and the related revocation information
returned, so it is not necessary to say why. It is primarly not for
archiving purposes but for real time use. Nevertheless, if you really want
this to be mentioned, please make a proposal for an insertion.
 
> another candidate source of revocation status information?

I do not think so. The two only sources of information are CRLs (including
delta-CRLs) and OCSP responses.

> In section 10, first paragraph, I do not understand the reference to "its

The support of these is request/response pairs is optional. These
request/response pairs allow either to define a policy, i.e. a signature
policy, a validation policy and/or a path discovery policy, and to receive
back a reference for that policy or to provide a reference to a previously
defined policy and to receive back the definition of that policy.
 
> "certification path" and reference [PKIX-1].

In section 2.2. I will add:

In order to validate a certificate, a chain of multiple certificates, called
a certification path, may be needed, comprising a certificate of the public
key owner (the end entity) signed by one CA, and zero or more additional
certificates of CAs signed by other CAs.

> occurs (mostly at the end of the document).

Done.

> In section 5, please change "copy and paste" to "provide."

Done in section 5 as well.
 
> In section 5, please change "additional protocol" to "additional protocol

Done.

> In section 6, last paragraph, please change "client will only require" to

Done.

Denis

---

From: [email-masked] (Denis Pinkas)
Date: Thu, 25 Oct 2001 19:41:10 +0000 (UTC)

Russ,

 

 

 

 

 

 

Done.

 

Done.

Done.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 25 Oct 2001 18:47:07 -0400

>should be given in the document.

Your comments do not address my concern.  If there is a constituency for 
DSV, then that work can proceed in a separate document.  Please do not 
further delay the DPV and DPD document progression while the working group 
debates the merits and details of DSV.

>sure that two implementations are really interoperable."

At first blush, this seems okay.  I want to think about it some more...

>this to be mentioned, please make a proposal for an insertion.

No, this was not my point.  In DPV, sometimes the client simply want a 
Yes/No.  Other times the client wants Yes/No and the supporting data.  The 
request should allow the client to say which should be returned.  Only sent 
the supporting info if the client wants it.

>defined policy and to receive back the definition of that policy.

The syntax may be different for each policy type.

Russ