Subject: RE: One last comment on DPD requirements

From: "Housley, Russ" <[email-masked]>
Date: Thu, 04 Apr 2002 16:40:34 -0500

Ambarish:

Tim Polk and I just discussed this on the phone.  I will share my 
conclusion form the conversation (which might be different than Tim's 
conclusion).  I think that we need to allow for multiple certificates to be 
returned, but the default should be to return just one.  If the client 
wants more than one, it needs to explicitly request them (up to a maximum 
number).  If the server does not support returning extra certificates, then 
it should just return one, but it should include a status code that says, 
"I do not support the option you requested, but I thought that I should 
give you one just in case it meets your needs."

Russ

At 11:11 AM 4/4/2002 -0800, Ambarish Malpani wrote:

>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: Jeff Jacoby <[email-masked]>
Date: Thu, 04 Apr 2002 17:24:44 -0800

Russ,

> give you one just in case it meets your needs."

I think such a status code may be unnecessary.  If a multi-path-capable
client 
gets only one path back -- either because there really was only one
path, or the
server couldn't support multiple paths -- what can it usefully do with
that status code?  
In other words, what would/could it do differently if it saw that status
code or 
not?

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

[big snippage]

Jeff
-- 
Jeff Jacoby, Sr. Programmer                
RSA Security Inc., SMDC                    [email-masked]
2955 Campus Dr., Ste. 400                  (650) 295-7569
San Mateo, CA  94403

---

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

Russ,

> number).  

I fully agree.

> If the server does not support returning extra certificates, then

Hum ... I guess, this is not what you mean. A DPD server returns
certification paths, not certificates. 

> give you one just in case it meets your needs."

I have problems with that complicated meaning. All returned paths must meet
the criteria set by the path discovery policy. Paths that do not meet the
criteria are not returned. Such a (complicated) status is not needed.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 05 Apr 2002 11:00:56 -0500

Jeff:

>gets only one path back -- either because there really was only one path, 
>or the
>code or  not?

Recall that we are discussing DPD (not DPV).  So, if the client finds that 
the single path that was returned is unacceptable, then the client could go 
to a different (untrusted) DPD server in the hopes of getting a collection 
of paths (or at least a different one).  Clearly, this is not 
optimal.  But, the client needs to know that the first server did not even 
try to find more than one path.

Russ