Subject: RE: DID & DIP requirements

From: Frank Balluffi <[email-masked]>
Date: Thu, 18 Jan 2001 06:49:22 -0800

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.

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?

The client and server algorithmic descriptions should help resolve this.

I would argue that having the protocol define a functional equivalent path
discovery algorithm, like RFC 2459 does for path validation, will help
implementers.

Frank

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 18 Jan 2001 20:24:39 +0100 (MET)

> 2 seems more efficient to me. I can't see any downside to 2.

Sounds reasonable. 

> 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.  

> discovery algorithm, like RFC 2459 does for path validation, will help

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: Frank Balluffi <[email-masked]>
Date: Fri, 19 Jan 2001 06:31:03 -0800

Mike,

I assumed that DID and DIP were typos, and that Peter meant DPD and DPV.

Frank

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Thursday, January 18, 2001 11:19 PM
> To: Frank Balluffi; 'Peter Sylvester'
> Cc: [email-masked]
> Subject: RE: DID & DIP requirements
> 
> 
> 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
> 
> 
> 
> > -----Original Message-----
> > From: Frank Balluffi [mailto:[email-masked]]
> > Sent: Thursday, January 18, 2001 1:03 PM
> > To: 'Peter Sylvester'
> > Cc: [email-masked]
> > Subject: RE: DID & DIP requirements
> >
> >
> > Peter Sylvester said:
> >
> > 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:
> > > >

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 19 Jan 2001 16:23:30 +0100 (MET)

> I assumed that DID and DIP were typos, and that Peter meant DPD and DPV.

Hm :-) It appeared first in 

> From: Frank Balluffi <[email-masked]>
> To: "'Peter Sylvester'" <[email-masked]>
> Cc: [email-masked]

> > - A client may indicate one or more certificates to be validated.
...
> Frank

An answer to my message 

> From: Peter Sylvester <[email-masked]>
> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA20034; Wed, 17 Jan 2001 14:15:06 +0100 (MET)
> Date: Wed, 17 Jan 2001 14:15:06 +0100 (MET)
> To: [email-masked], [email-masked]
> Subject: RE: DPD & DPV requirements
> Cc: [email-masked]
> 
> Frank wrote:
> 
> > I'm confused. Are people saying that the certificate whose path the client
> > would like to discover or validate is in the unordered lump of certificates
> > or that a separate lump of certificates may be sent to assist the server? I
> > thought the latter.
> 
> This is not quite clear to me either. 
> 
> Before going to specify a syntax we should state it differently,
> here some ideas:
> 
...

---

From: Frank Balluffi <[email-masked]>
Date: Fri, 19 Jan 2001 07:22:31 -0800

Peter is right. It first appeared in a message I sent. I assume that the
gremlin(s) meant DPD and DPV :-).

Frank

> Sent: Friday, January 19, 2001 10:24 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> > Received: (sylvest@localhost) by emeriau.edelweb.fr 
> (8.7.6/8.6.6) id OAA20034; Wed, 17 Jan 2001 14:15:06 +0100 (MET)

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Jan 2001 12:36:43 -0500

Peter,

>comes to a solution by what local or external means.

While it is true that the client puts its faith in a DPV server, that 
does not mean that the client has no input to the validation process, 
not is that process "unknowlable" by an external agent armed with 
knowledge of the validation parameters. It should be possible to 
predict the results of DPV operation armed with knowledge of the 
client request, locally configured policies, and knowledge of the 
other servers to which the DPC server has access.

>you don't know how a OCSP responder came to his conclusion.

I don't think we agree here. The DPV server must operate on an 
algorithmic basis and thus have a predictable output. We don't want 
non-deterministic operation

>For a DPV you don't need that. The DPV server verifies against against

Not entirely true, since the client may provide inputs to the 
validation process which will specify how the process works, mod any 
overrides configured into the server.

>anyway, and you may need to ask the DPD server several times.

I'd like to better understand what parameters the client will change 
between invocations of a DPD server, in a controlled fashion, to make 
multiple invocations for the same target certificate provide 
distinct, useful, answers. Do you have some examples that could 
clarify this scenario?

Steve

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 22 Jan 2001 18:55:45 +0100 (MET)

> other servers to which the DPC server has access.

I accept a locally configured policy harded coded as a representation
of the 'application'.  

For others I would be very careful.
 
> non-deterministic operation

Hm, even X509 does not operate on an algorithmic basis. It only specified
what criteria a valid path must follow, but not how to get to a valid path. 

The OCSP is also non-deterministic, also the possibilities are smaller,
you don't know whether the server has access to a CRL, or directly
to a CA base. 

> overrides configured into the server.

Well, we are back to case 1: What are the possible controls for
a DPV client? ;-)

> distinct, useful, answers. Do you have some examples that could 

Well, as a minimum client could just return a 'session id' as we
had discussed in the OCSP based DPD. This id contains in
a opaque way (for the client) enough info for the server to resume
to 'get the next'. 

If you allow a client to react on the first response to say something
like: 'oh well, you first answer is really not the right direction,
instead of using a bottom up algoritm, you'd better do yoyo', then
this gets rather complicated IMHO.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 25 Jan 2001 12:18:51 +0100 (MET)

Steve, 

since I seem to be in almost violant agreement, this answer can be short.

...

> My starting point are the 2459 bis path validation controls, but if 
> we reach consensus on others, we can add them in as well.
There is one proposal on the table, and it was questioned by
asking why or whether this cannot be made by existing means.

This question should always be asked, it means that we give
additional input, and this might be well be suited to modify
the path validation algorithm, thus should be integrated into it.

...
> 
> I agree, which is why I am reluctant to put in mechanisms to support 
> it at this time. if we can't explain how the procedure will work, and 
> provide explicit controls, then we have a placeholder that does not 
> permit interoperable implementation, the hallmark of a good IETF 
> standard.
No problem.