Subject: RE: One last comment on DPD requirements

From: Ambarish Malpani <[email-masked]>
Date: Thu, 04 Apr 2002 11:11:49 -0800

Russ,
    A minor nit - a DPD server might also be a DPV server, who
a client is not willing to trust (and whose work the client wants
to verify for itself).

To summarize, what I think what I hear you, Santosh and Steve say
is that it might make sense to require a DPD server to return a
single path back, but if we want to enable that, we need to let
the client specify his requirements more precisely. Is that
correct?

It would make sense to show (in the protocol doc), what those
requirements are for protocols like S/MIME, TLS, IPSec and let
other protocols define their own requirements if they can't
fit into one of the three above.

Does that make sense to you? What about others on the list?

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

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Thursday, April 04, 2002 7:00 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: RE: One last comment on DPD requirements
> 
> 
> 
> 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
> 
> At 08:20 PM 4/3/2002 -0500, Santosh Chokhani wrote:
> >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:
> > >>
> > >>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
> > >
> > >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: Thu, 4 Apr 2002 14:33:30 -0500

Ambarish:

Your language is acceptable to me as long as the returned path will
satisfy the client requirements for certification path validation.

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Thursday, April 04, 2002 2:12 PM
To: 'Housley, Russ'; Santosh Chokhani
Cc: [email-masked]
Subject: RE: One last comment on DPD requirements

Russ,
    A minor nit - a DPD server might also be a DPV server, who a client
is not willing to trust (and whose work the client wants to verify for
itself).

To summarize, what I think what I hear you, Santosh and Steve say is
that it might make sense to require a DPD server to return a single path
back, but if we want to enable that, we need to let the client specify
his requirements more precisely. Is that correct?

It would make sense to show (in the protocol doc), what those
requirements are for protocols like S/MIME, TLS, IPSec and let other
protocols define their own requirements if they can't fit into one of
the three above.

Regards,
Ambarish

> >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
> >protocol requires the client to adequately specify its criteria.
> This could be
> >done

---

From: Tim Polk <[email-masked]>
Date: Thu, 04 Apr 2002 18:20:25 -0500

Folks,

I posted the following summary of this thread/issue in a summary for 
DPD/DPV, and identified it as one of the two FINAL issues to be resolved so 
that we can forward this specification.

Please take a look at my summary, and correct it where appropriate!

Open Issue #2

The second issue is conformance requirements for multiple paths in the DPD 
service.  As I read it, the current draft requires support for multiple 
paths at the server, but not the client.  The client may request a maximum 
number of paths N; if the request does not specify N, it defaults to 
one.  The DPD server includes zero, one, or up to N paths in a 
response.  If the number of paths is less than N, this indicates that the 
server could not find as many paths as the client requested.

Since the DPD process is performed with respect to a policy, just as in 
DPV, it has been suggested that a DPD server could be designed to always 
return a single path.  If the specified policy matches the path validation 
process performed at the client (e.g., same certificate policies and same 
trust anchor) the client should be able to use that path.

However, this could result in an ambiguity.  How does the DPD client that 
requested three paths tell the difference between the following answers:
	"I gave you one path because it is the only one that exists"
      and
	"I gave you one path 'cause that's the way I was designed"

In the case where the single path failed, a client may need to know the 
difference!

Careful selection of conformance requirements and error condition 
statements will be required to permit building single answer DPD servers.

---

Have I characterized this correctly?  It seems that permitting single 
answer DPD servers demands an ability to clarify a response with M paths 
where M < N the requested number of paths.  Given that, can we reach 
consensus that a conforming DPD server may be designed to always return a 
single path?

Thanks,

Tim Polk

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Apr 2002 14:50:50 +0200

Ambarish,

> a client is not willing to trust (and whose work the client wants

This is not a minor nit. A DPV server is always trusted by the client, while
a DPD server does not need to be trusted.  A DPV server is not necessarily
trusted by *other* clients. So the case of an untrusted DPV server, as
mentionned, does not exist. 

Denis

---

From: Tim Polk <[email-masked]>
Date: Fri, 05 Apr 2002 10:29:40 -0500

Denis,

>mentionned, does not exist.

I disagree strongly.  If a client requests that a DPV server return the 
certification path, it may do so for either of two reasons:
(1) it wishes to cache the information for audit purposes; or
(2) the client does not trust the DPV server for this application, and will 
perform the path validation locally as well.

The same client may trust the DPV server for low value applications (e.g., 
email) but organizational policy may demand that the client perform path 
validation locally for funds transfer or other high value applications.  It 
makes perfect sense for the client to use the DPV server in both cases.

Note that only the client can tell which mode it operates in...

Thanks,

Tim

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Apr 2002 17:55:14 +0200

Tim,

> I disagree strongly.  

What a strong word for a "minor nit" !

:-)

> If a client requests that a DPV server return the

> (1) it wishes to cache the information for audit purposes; or

Not exactly. Audit is not the reason. The reason is that *another* party
will not necessarilly trust the "valid" answer from that server. However
that other party might want to test the validity of the certificate later on
and may not trust the same DPV server. Since later on all the information to
do the validation may not be available, it is captured with the "valid
answer" so that this other party can use it as as "useful information" with
a request made later on to another DPV server that it trusts.  

> perform the path validation locally as well.

DPV is first designed for thin clients or clients unable to perform the path
validation themselves. If they would, then they would use DPD. Now, nothing
would prevent an application to do what you say, but it does not make sense.

> makes perfect sense for the client to use the DPV server in both cases.

I would disagree as well.

Now, I do not remember that this comment was raised during the last call
period ... or could you refer to which comment number it relates ?

Thanks,

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 5 Apr 2002 09:42:28 -0800

Tim,

I think I agree with Denis (at least if I'm reading him
correctly).

One of the needs that drove DPD into existence in the first
place was the observation that a DPV server, due to its use of a
signing key, would fall within scope of various trusted systems
certification programs while a server strictly limited in its
design and implementation to DPD functionality could arguably
avoid that.

Thus, a DPV server would be trusted from a system certification
perspective even though a client of that server may choose not
to fully delegate its trust to that server.  Not to say that DPD
server could not also be so certified, but the value of doing so
would be minimal.

This is all hypothetical of course since it's not within our
scope in this forum to set rules for what does and does not
require such certification, but predictable enough that Stephen,
Carlisle and I went around and around on the issues way back
when and thus why DPD was initially proposed to the WG as
basically a subset of a DPV functionality.

Just thought that context might be useful FWIW.

Mike

> [mailto:[email-masked]]On Behalf Of Tim Polk
> Sent: Friday, April 05, 2002 7:30 AM
> To: Denis Pinkas; Ambarish Malpani
> Cc: 'Housley, Russ'; Santosh Chokhani; [email-masked]