Re: DPD & DPV Basics

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Steve,

> It seems that at least some members of the working group have not yet
> agreed upon certain basic concepts. Perhaps it would be useful for me to
> articulate these concepts so that they can be discussed separately from
> the detailed requirements supplied by Steve. Discussion of those
> detailed requirements can proceed simultaneously, but it would be good
> if we could reach agreement on these basic concepts or at least
> understand why we don't agree on them. I suspect that we already have
> rough consensus on these concepts, but it would be good to get any
> debate on them out into the open so that we can understand the technical
> foundations from which that debate arises.
> 
> 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.

> In its most basic form, it will perform the following steps:
> 
> 1) Receive a request containing a certification path 

No. See above.

> and other inputs
>    to the validation algorithm (trust anchors, required certificate
>    policies, etc.)

Yes. 

> 2) Validate the supplied certification path using the supplied inputs

No. He will have to fetch information (certs and revocation data).

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

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

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

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

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

Regards,

Denis

 
> Thanks,
> 
> Steve
> 
> P.S. Due to the short timeline, I will submit more detailed comments on
> Steve's requirements soon.