Re: DPD & DPV Basics

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> > Here's my take on the basic concepts of DPD and DPV:
> > 
> > The basic job of a DPV server is to validate a certification path. 
> 
> I disagree. The basic job of a DPV server is to say whether a given
> certificate is valid according to some validation policy. The client may not
> provide any certification path.

I second that. The server should/may provide a trustworthy 
certification path but even this may be considered as not necessary
by the policy or application context. 


> > 2) Validate the supplied certification path using the supplied inputs
> 
> No. He will have to fetch information (certs and revocation data).

A server creates a valid/non-valid response acoording whatever information
is available. IF the server returns a certification path, this path
must be a path that can be validated even by the client or a client of
the client. 

One question is if the client provides one intermediate CA
cert (maybe expired), and the server knows that this intermediate
CA cert is bad but has a good one, I think it is better to
let the server decide whether to honour the input CA cert.
 
> > 3) Send a response containing the results of the validation (at least,
> >    an indication of success or failure)
> 
> Yes, and as an option the data used for the assertion.

Note that the certification path is part of these data.

All data returned should be part of the signed structure.

>  
> > Many refinements to this are possible: the client supplying only a
> > subset of the necessary inputs (by referring to an established policy),
> 
> .. or no subset at all.
> 
> > the server returning supporting evidence such as CRLs and OCSP
> > responses, 
> 
> No. The server returning a blob. The fact that the blob contains certs,
> CRLs, delta CRLs, OSCP or whatever, is not visible.
If it is not VISIBLE, then it doesn't make sense. It is not necessary
for the client to know the complete interpretation of the 'blob'.

> 
> > the client supplying CRLs or OCSP responses that may be
> > useful to the server, etc. But I think it may be useful to reach
> > agreement on the basic model described above before discussing these
> > refinements (however worthy).
>  
> > The basic job of a DPD server is to discover a certification path. 
> 
> No. The basic job of a DPD server is to help the PKI-aware client to perfom
> the validation itself.

In current PKI a validation always results in having a certification path, thus
I do not see what else a DPD can provide to a client other than a
certification path or some part of it.    


> Certification paths or/and revocation information may be returned. More than
> one certification path and one than one revocation information (e. g. both
> CRLs and OCSP responses) may be returned.

> > In its most basic form, it will perform the following steps:
> > 
> > 1) Receive a request containing a target certificate and inputs to the
> >    validation algorithm (trust anchors, etc.)
> 
> Yes.
> 
> > 2) Attempt to discover a certification path ending in the target
> >    certificate that will validate properly given the supplied inputs
> 
> One or more paths.
See below. The server does not know which of many path the client likes.

> 
> > 3) Send a response containing the results of the discovery process
> >    (at least an indication of success or failure and, in the success
> >    case, the discovered certification path)
> 
> Succes or failure of finding the requested elements (i.e. certification
> paths or/and revocation information)

Is a DPD successful when it finds at least one path or some part of it?

> 
> > Most of the refinements listed above with respect to the DPV server can
> > also be applied to the DPD server. 
> 
> No. See above.

> 
> > In addition, other refinements might
> > include having the client supply additional certificates that may be
> > useful to the server (such as certificates received with an S/MIME email
> > message).
> 
> Yes.

The structure for sending in additional certs together with the certs
for which you ask a service, should be well defined. Both for DPV and DPD.

For DPD there is the question about *how* does the server know when
to stop filling up all possible cert chains that may be considered
valid by the client. (That's why there is an interative approach
in OSCP-DPD).


> 
> > I look forward to seeing a discussion on this topic. If no discussion
> > results, I suppose that I will conclude that there is general agreement
> > about these basic concepts. However, simple affirmative messages
> > agreeing with these basic concepts would be useful in judging rough
> > consensus.
> 
> Sorry, my message is going in the reverse direction. :-(

The direction of consensus is not necessarily defined by the chairman :-)

Peter