RE: DPD & DPV Basics

["Covey, Carlin" <ccovey@xxxxxxxxxx>]

Steve Hanna,

Your take on the basic concepts of DPV and DPD services matches mine.  
I think a bit of confusion was introduced during discussions of how 
those services should be mapped to protocols.  There was a suggestion
that a DPV-service protocol might also return a chain of evidence 
supporting the validation status - thus providing a kind of DPD service 
within the same protocol.  It has also been observed that there is no point 
in returning invalid (or unvalidated) paths in a DPD response  -- thus
implying a sort of DPV service as part of the DPD protocol.  I suppose
the distinguishing characteristic is whether or not the client trusts the
response, or will perform its own validation.  This is out of the scope 
of the protocol itself, unless we want to build in mechanisms for the client
to impose constraints on the path construction and validation process.

Regards,

Carlin

---------------------------------
- Carlin Covey
  Cylink Corp.
   

-----Original Message-----
From: Steve Hanna [mailto:steve.hanna@xxxxxxx]
Sent: Thursday, January 11, 2001 1: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.