RE: DPD & DPV Basics

[Frank Balluffi <frankb@xxxxxxxxxxxx>]

Steve,

I like your approach. Here goes ...

1. Can someone explain the value of a DPD server returning a path that may
not be valid? I would argue that path discovery should be an optional
internal operation performed by a DPV server. I say this as someone who has
implemented support for SCVP draft 4's path building types of check. To me
the operation should be implicit.

2. I would like to see the option of passing certificates and other input
(e.g., CRLs) by reference for use by PKI-unaware (e.g., XML-enabled)
applications.

Frank

> -----Original Message-----
> From: Steve Hanna [mailto:steve.hanna@xxxxxxx]
> Sent: Thursday, January 11, 2001 3:34 PM
> To: PKIX List
> Subject: DPD & DPV Basics
> 
> 
> 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. In
> its most basic form, it will perform the following steps:
> 
> 1) Receive a request containing a certification path and other inputs
>    to the validation algorithm (trust anchors, required certificate
>    policies, etc.)
> 2) Validate the supplied certification path using the supplied inputs
> 3) Send a response containing the results of the validation (at least,
>    an indication of success or failure)
> 
> Many refinements to this are possible: the client supplying only a
> subset of the necessary inputs (by referring to an 
> established policy),
> the server returning supporting evidence such as CRLs and OCSP
> responses, 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. 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.)
> 2) Attempt to discover a certification path ending in the target
>    certificate that will validate properly given the supplied inputs
> 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)
> 
> Most of the refinements listed above with respect to the DPV 
> server can
> also be applied to the DPD server. 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).
> 
> 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.
> 
> Thanks,
> 
> Steve
> 
> P.S. Due to the short timeline, I will submit more detailed 
> comments on
> Steve's requirements soon.
>