Re: DPD & DPV Basics

[Steve Hanna <steve.hanna@xxxxxxx>]

Frank Balluffi wrote:
> 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.

I agree that there's not much utility in having a DPD server return an
invalid (or unvalidated) path. However, I don't agree that path
discovery should be part of a DPV server's job. Instead, I would argue
that validation should be part of a DPD server's job.

My team has also implemented path discovery and validation (although not
yet delegated discovery and validation). Validation is a fairly simple
matter of running the PKIX validation algorithm using certain
parameters. Discovery is *much* more complicated, involving heuristics
for guessing which certificates might lead to the target certificate (or
to the trust anchor, if building forward), partial validation to
discover when a partial path is futile, and loop detection. I would
argue that DPD is substantially harder than DPV and DPV is often
sufficient. So it is definitely worthwhile to define DPV as a separate
operation. Many servers may only want to support that operation.

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

I think this item really belongs in the discussion of Steve's detailed
requirements. It doesn't pertain to reaching agreement on the basic
concepts. It's definitely a good point to discuss, just not in this
thread.

Thanks,

Steve

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