Re: DPD & DPV Basics

[Steve Hanna <steve.hanna@xxxxxxx>]

Stephen Kent wrote:
> The strawman already calls for a DPD server to perform validation.
> You're suggesting that a DPV server should not have to perform
> discovery. That would imply that either:
>          (1) the client passed in a complete path, and matching
> revocation status data,
>         (2) the client called the DPD server first, then passed on
> the result to the DPV server
>         (3) or that a DPV server called a DPD server in support of discovery.

As I see it, a DPV client would provide a complete path and other inputs
required by RFC 2459 (such as acceptable certificate policies). The
client could supply some revocation status information, but I would not
expect this to be common. The DPV server would be responsible for
performing the validation algorithm described in RFC 2459 (or its
successors), including checking revocation. This could involve
consulting CRLs or OCSP servers.

> What simplifications to the overall architecture arise if we split
> responsibility this way? Certainly if we expect one server to do
> both, i.e., to have DPV piggyback on DPD but with slightly different
> interfaces, this isn't all that helpful. I'm not rejecting this
> approach, but I want to understand it's benefits in more detail.

One benefit of this definition is that such a DPV server would be
substantially easier than a DPD server (which may have to try many
possible paths). In many cases, such a DPV server will be sufficient.

Here's an analysis of use cases for S/MIME and TLS/SSL:

  A TLS/SSL client could pass the certification path supplied
  by a TLS/SSL server to its trusted DPV server (along with any
  necessary parameters, such as the client's list of trust anchors) and
  the DPV server would determine whether the path was valid. If mutual
  authentication is in use, a TLS/SSL server could do the same thing to
  validate a certification path supplied by the TLS/SSL client. A DPD
  server could also be used in either of these cases. It would increase
  the probability of finding a successful path, but with a considerably
  higher cost.

  With S/MIME, a DPD server will probably be required, in general. A
  signed email comes with a bag of certificates. In order to form a
  chain from one of the recipient's trust anchors to the signer,
  certificates must be selected from this bag (and perhaps from other
  sources). Simple validation is not usually sufficient. When attempting
  to determine the public key of a previously unknown party in order to
  send them an encrypted email, discovery is also required.

To summarize, DPV (as I defined it) is a subset of DPD. In some
circumstances, DPV is sufficient. But not always. We could simplify the
model by eliminating DPV and adding a flag so the client can say "don't
add any certs to this chain".

---

It seems to me that others on this list consider it perfectly OK for a
DPV server to add or remove intermediate certificates to/from the
certification path supplied by the client. In that case, the only
distinction between a DPV server and a DPD server is that the DPD server
is expected to return the validated certification path to the client.

Is that what you had in mind, Steve? Mike? If so, I agree with Steve
that there's little distinction between a DPV server and a DPD server
(as so defined). Let's just add a few flags to say "don't add any certs
to this chain" and "return the completed path to me" and call the whole
thing a DPD server (or whatever we want to call it).

> >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.
> 
> No argument that discovery is harder, and it subsumes validation.
> But, what is the basis for arguing that validation, based on
> supplying complete cert chains and revocation status data, will be
> the more common case and thus we should optimize for it? Several
> protocols allow for transmission of certs and CRLs, but some allow
> transmission only for certs, perhaps because that it static data that
> is easier to configure into the client.

As I described above, I agree that clients will rarely have revocation
status data. Providing a DPV function that can validate a certification
path without including the extra complexity of path discovery would be
nice. But since path discovery is also important and usually more
desirable, perhaps we should just focus on that.

-Steve