Subject: One last comment on DPD requirements

From: Ambarish Malpani <[email-masked]>
Date: Wed, 03 Apr 2002 08:36:47 -0800

Hi Group,
    One last (slightly late) comment on the DPD requirements that
has been troubling me:

In the DPD requirements, there is a reasonable amount of text that
talks about how a server can return multiple paths back to the
client (to allow the client to decide which path is the best).

The main goal of DPD is to try and simplify the client. In how many
cases do people really want multiple paths back from the server.
While it is the right requirement in principal, do folks really
think clients will want multiple paths back from a DPD server? Are
we adding the additional flexiblity/complexity just for
technical purity?

Comments will be appreciated.

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

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Apr 2002 18:53:19 +0200

Ambarish,

This is indeed a very late comment. 

> we adding the additional flexiblity/complexity just for

If there exists more than one path, and if the server only returns one path
and that path does not comply with the conditions set by the client, no
other path would never be sent back and there might well be another one that
would
satisfy the conditions set by the client. DPD clients are not clients as
simple as DPV clients, they are able to perform path validation themselves.

It would not make sense to only return one path.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Apr 2002 11:55:32 -0500

>Comments will be appreciated.

I too would favor simplifying the protocol requirement here. Some 
folks have suggested motivations for multiple paths, but this does 
seem to conflict with the fundamental goal of creating a protocol to 
satisfy the needs of thin clients.

Steve

---

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

Steve & Ambarish:

>I too would favor simplifying the protocol requirement here. Some folks 
>have suggested motivations for multiple paths, but this does seem to 
>conflict with the fundamental goal of creating a protocol to satisfy the 
>needs of thin clients.
>
>Steve

I agree with your goal.  It is far better for the client to tell the server 
what it wants, then get back a single path that satisfies all of the 
requirements.  To do this, we need to be able to fully specify the clients 
criteria and send them to the server.  I think that we know how to do this 
for many PKI-enabled applications, but I am not sure that we know how to do 
it for all applications, especially ones that are yet to be developed.

This leaves us with two choices.  Either the protocol returns multiple 
certification paths (the approach in the current document) or the protocol 
requires the client to adequately specify its criteria.  This could be done 
with the path discovery policy.  If we adopt this alternative, we should 
include additional text so that implements expect application-specific 
(perhaps several application-specific path discovery policy if there are 
multiple roles in the application).

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 3 Apr 2002 20:20:38 -0500

Russ:

I agree with you, but for a different reason.  I do not think this is
application specific issue.  I think it is the path validation issue.  I
do not think that the DPD server can know which paths are good without
doing a validation also, specially to see if there will be any name
constraints or certificate policy related failures.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Housley, Russ
Sent: Wednesday, April 03, 2002 2:12 PM
To: Ambarish Malpani; Stephen Kent
Cc: [email-masked]
Subject: Re: One last comment on DPD requirements

Steve & Ambarish:

>>Hi Group,
>>     One last (slightly late) comment on the DPD requirements that has

>>been troubling me:
>>talks about how a server can return multiple paths back to the client 
>>(to allow the client to decide which path is the best).
>>
>>cases do people really want multiple paths back from the server. While

>>it is the right requirement in principal, do folks really think 
>>clients will want multiple paths back from a DPD server? Are we adding

>>the additional flexiblity/complexity just for technical purity?
>>

I agree with your goal.  It is far better for the client to tell the
server 
what it wants, then get back a single path that satisfies all of the 
requirements.  To do this, we need to be able to fully specify the
clients 
criteria and send them to the server.  I think that we know how to do
this 
for many PKI-enabled applications, but I am not sure that we know how to
do 
it for all applications, especially ones that are yet to be developed.

This leaves us with two choices.  Either the protocol returns multiple 
certification paths (the approach in the current document) or the
protocol 
requires the client to adequately specify its criteria.  This could be
done 
with the path discovery policy.  If we adopt this alternative, we should

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 04 Apr 2002 11:34:53 +0100

And adding another reason: multiple paths may exist which only 
really differ in their validity fields. Unless the requirements
call for a pretty complex time specifier in the request the 
simplest thing is for the server to send back all such paths
found and let the client sort it out (i.e. even if the client 
picks a single point in time, there may still be >1 path such 
that the paths only differ in validity; to close this down some 
fairly hairy time specifier in the request would have to be
defined and no clients would bother filling that in properly
in any case).

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

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

Santosh:

I think that a DPD server will likely perform path validation.  Clients 
will not be happy if the paths that they are given are often 
invalid.  Clearly, the DPD server cannot know all of the parameters that 
the client will use for path validation (otherwise it would be a DPV 
server), but it can make some very reasonable assumptions to ensure that 
grossly invalid paths are not returned.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 10 Apr 2002 14:05:33 -0700

Russ, Denis:

Section 4, Delegated Path Validation Protocol Requirements
begins with:
"The Delegated Path Validation (DPV) protocol allows . . ."

Similarly, Section 5 Delegated Path Discovery Protocol
Requirements begins with:
"The Delegated Path Discovery (DPD) protocol allows . . ."

Since we're defining requirements and not protocols in this I-D,
you may wish to consider amending both these phrases towards
something along the lines of "DPV protocols allow . . ." and
"DPD protocols allow . . ." respectively.

Mike

Michael Myers
t: +415.819.1362
e: mailto:[email-masked]
w: http://www.traceroutesecurity.com

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 15 Apr 2002 19:05:12 +0200

Mike,

> "DPD protocols allow . . ." respectively.

Are we really defining multiple protocols ? 
I was assuming that we would like only one. 
I prefer to keep the current text.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 15 Apr 2002 10:16:44 -0700

Denis,

I believe we are defining requirements that will be applied
against perhaps multiple technical proposals with a view towards
the WG selecting one.  It seems premature to assume the WG's
consensus on this point.

Mike

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 10:05 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: Two more nits re: DPV/DPD rqmts
>
>
> Mike,
>
> > Russ, Denis:
> >

---

From: "todd glassey" <[email-masked]>
Date: Mon, 15 Apr 2002 19:01:43 -0700

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "Michael Myers" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 15, 2002 10:05 AM
Subject: Re: Two more nits re: DPV/DPD rqmts

> I prefer to keep the current text.

Denis - are you saying that it is PKIX's operating rule to only allow one of
each protocol type its working on? Is this true Tim and Steve Kent?

Todd

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Apr 2002 17:33:10 -0400

>each protocol type its working on? Is this true Tim and Steve Kent?

Todd,

In the case of DPV and DPD, the WG discussed the matter some time ago 
and agreed that it would be highly desirable to have just one 
standard protocol satisfying the requirements we agree upon.  We 
failed to do this in the case of CMC and CMP and the user and vendor 
community suffered as a result. So, yes, the intent in this case is 
to have just one standard for DPV and DPD.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 Apr 2002 15:23:58 +0200

Steve,

(...)

> to have just one standard for DPV and DPD.

I would rather say " ... just one protocol for DPV and one protocol for
DPD". At this time it is too early to say whether they will described in one
document or two.

Denis