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

From: [email-masked]
Date: Fri, 11 Jan 2002 08:56:54 -0500

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
	Filename	: draft-ietf-pkix-dpv-dpd-req-01.txt
	Pages		: 14
	Date		: 10-Jan-02
	
This document specifies requirements for two main request/response 
pairs.
The first one, called Delegated Path Validation (DPV), can be used to 
fully delegate a path validation processing to an DPV server, 
according to a set of rules, called a validation policy.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-01.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-01.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-01.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: Petra Barzin <[email-masked]>
Date: Mon, 14 Jan 2002 11:26:41 +0100

Denis,

is there also a new version of the document "Delegated Path

Validation and Delegated Path Discovery Protocols" or just

a new requirement document?

- Petra

Petra,

A new version has been posted last Friday to the web master. It should be
published "soon". While waiting for the publication, here is an answer to
your comments.

[email-masked] schrieb:

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

Author(s)
: D. Pinkas

Filename
: draft-ietf-pkix-dpv-dpd-req-01.txt

Pages
: 14

Date
: 10-Jan-02

pairs.

The first one, called Delegated Path Validation (DPV), can be used
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

Send a message to:

[email-masked].

In the body type:

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.

Internet-Draft.

------------------------------------------------------------------------

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 14 Jan 2002 12:56:23 +0100

Petra,

> Validation and Delegated Path Discovery Protocols" 

Not at this time. Currently we need first to agree on the DPV / DPD
requirements, then we will discuss the solutions to these requirements.
 
The so-called "Delegated Path Validation and Delegated Path Discovery
Protocols" document could be a candidate to fulfill these requirements. 
It is too early to say and this will only be discussed once the requirements
document is adopted.

> or just a new requirement document?

Correct. It is a new document for both the DPV and DPD requirements.

There is also a companion document for the DSV requirements. 
We will only discuss the DSV requirements document in detail when 
the DPV / DPD requirements document has completed the WG last call.

Denis

---

From: Petra Barzin <[email-masked]>
Date: Mon, 14 Jan 2002 16:02:25 +0100

Denis,

may I still ask some questions concerning the document "Delegated

Path Validation and Delegated Path Discovery Protocols" ?

PathValues :: = SEQUENCE {
certificateValues      CertificateValues,
revocationValues       RevocationValues }

I'm missing some ASN.1 definitions. You refer to "CertificateValues"

and "RevocationValues" but I couldn't find these definitions.

By the way, you should move this definition of "PathValues" from

the chapter "5.2.1. Request" to the chapter "5.2.2.  Response
Syntax"

where it is used.

Another ASN.1 question:

UsefulRevoc ::= CHOICE {
certificateRevocationLists     CertificateRevocationLists,
completeRevocationRefs         CompleteRevocationRefs }

A DPV request may contain useful revocation information provided

by the client. Maybe it's because I don't know the element

"CompleteRevocationRefs" but where do I store OCSP answers?

Could you please send the definition of "CompleteRevocationRefs"

and "completeCertificateRefs"? I guess they are imported from [ES-F],

"Electronic Signature Formats for long term electronic signatures",
aren't they?

CertOrCertRef ::=  CHOICE {
certificate          [1]  Certificate,
certRef              [2]  OtherCertID }

I'm also missing the definition of OtherCertID used in a DPV and DPD request.

Thanks, Petra

Denis Pinkas schrieb:

Petra,

document is adopted.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 14 Jan 2002 18:25:27 +0100

Petra,

Please take a look at RFC 3126, where many of the ASN.1 structures were
imported from and are thus defined there. This should answer all your
questions.

Regards,

Denis
 
> the chapter "5.2.1. Request" to the chapter "5.2.2.  Response Syntax"
> where it is used.
> 
> Another ASN.1 question:
> 
> > UsefulRevoc ::= CHOICE {
> "Electronic Signature Formats for long term electronic signatures", aren't
> they?
>

---

From: Petra Barzin <[email-masked]>
Date: Wed, 16 Jan 2002 11:51:27 +0100

Yes, thanks for the pointer. I found the ASN.1 definitions there.

One more question turned up:
Is DPV restricted to X.509 public key certificates or is it possible
to use it for X.509 attribute certificates as well?

- Petra

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 16 Jan 2002 12:36:58 +0100

Petra,

> to use it for X.509 attribute certificates as well?

Clearly, both the DPV-DPD protocol draft and the DPV-DPD requirement draft
have been specifically written to support PKIX public key certificates.

At the last IETF meeting a question has been raised to the audience: 
Who, in the room, has implemented Attribute Certificates ? 
No hand showed up. 

So it seems that there is no urgence to support PKIX attribute certificates.

However, maybe by making some changes, PKIX attribute certificates could be
supported, but this is an exercise that I have not undertaken.

The basic question is thus whether to include the support of attribute
certificates in the current DPV-DPD requirement draft.

Unless you, or someone else, can rapidly provide arguments and demonstrate
that it will not delay the support of PKIX public key certificates, I would
rather think that it should not be included at this time.

Regards,

Denis