Subject: RE: DID & DIP requirements

From: Frank Balluffi <[email-masked]>
Date: Thu, 18 Jan 2001 13:02:51 -0800

Peter Sylvester said:

> Which server, DPV or DPD? 
> The DPV client is assumed not to have trust in anything
> else than the server. The server maintains a trust base. It 
> comes to a solution by what local or external means. 

Since I'm no longer clear about what the differences are between a DPV and a
DPD server, whoever is performing the task of discovering paths. Put simply,
it is not clear to me that such a server knows when it has discovered a
complete path. In other words, there seem to be two types of trust points:
points along the path and points at the end of the path.

Frank

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Thursday, January 18, 2001 2:25 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: DID & DIP requirements
> 
> 
> Frank wrote:
> 
>  > Peter Sylvester wrote:
> > 
> > > - A client may indicate one or more certificates to be validated.
> > > 
> > > - 1 - Each certificate may be accompagnied by a 'lump' of 
> certificates
> > >       that may assist the server to find a valid path for that
> > >       particular certificate.  
> > > 
> > >   2 - There may be an additional bunch of certificates that may be
> > >       used by the server to determine valid paths.  
> > > 
> > > I tended to have 1, because for different certs the paths may be
> > > different, but I may be wrong since even if one throws all the
> > > different hints in 1 into one bag, the server could probably
> > > find out the good stuff anyway. 
> > 
> > 2 seems more efficient to me. I can't see any downside to 2.
> 
> Sounds reasonable. 
> 
> > 
> > How does the server know when it has completed the process 
> of discovering a
> > path? It finds a self-signed certificate [this would break 
> RFC 2459 path
> > validation]? The server maintains a collection of trusted 
> certificates? The
> > client sends a collection of trusted certificates?
> 
> Which server, DPV or DPD? 
> The DPV client is assumed not to have trust in anything
> else than the server. The server maintains a trust base. It 
> comes to a solution by what local or external means. 
> 
> 
> In DPD this may be completely the other way around. 
>  
> > 
> > The client and server algorithmic descriptions should help 
> resolve this.
> 
> For DPV you have no algorithmic description in the same way as 
> you don't know how a OCSP responder came to his conclusion.  
> 
> > 
> > I would argue that having the protocol define a functional 
> equivalent path
> > discovery algorithm, like RFC 2459 does for path 
> validation, will help
> > implementers.
> 
> For a DPV you don't need that. The DPV server verifies against against
> his local trust base.  
> 
> for DPD I am not sure at all, it rather sems to me like a 
> search in a directory
> anyway, and you may need to ask the DPD server several times. 
> 
> Peter
>

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 18 Jan 2001 20:18:40 -0800

I've been accused of being the cause for more than a few acronyms within
PKIX, most recently DPV and DPD.  But I haven't a clue what DID and DIP are.
Enlightenment or clarification requested.

Mike

> From: Frank Balluffi [mailto:[email-masked]]
> Sent: Thursday, January 18, 2001 1:03 PM
> To: 'Peter Sylvester'
> Cc: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 19 Jan 2001 10:37:21 -0500

Frank,

>points along the path and points at the end of the path.

How about the following definition:

A complete certification path is one that satisfies all of the 
validation criteria specified in RFC 2459bis and that terminates at a 
certificate configured as a trust anchor in the server and specified 
by reference to the policy containing that path, or a path that 
terminates at a trust anchor certificate supplied by the client in a 
request.