[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DPD & DPV Basics

Steve,

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.

If a DPV client is not PKI aware, then I don't expect it to be able to have a complete path in many cases, and I would rarely ex[ect it to have all the relevant revocation status info. In S/MIME or in IPsec, where there is a good chance that the peers have different CAs, it is not necessarily feasible to send a complete path to the other party, because you may not know enough about that party's PKI context.

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

Yes, it would be simplier, but I worry that in making it simple, we have over burdened the client. A PKI-ignorant client can't even go to a DPD server to get the data to pass on to a DPV server.

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.

For a client, given the common multi-root CA mode of operation for browsers, none of this seems applicable, so I'm having trouble seeing the utility for clients here. In either case you cite above, the apps are PKI aware already and thus capable of calling a DPD sever, as you noted. Maybe the root of our disagreement is the assumption of what the common requirement is for a DPV client. My strawman cites PKI-ignorant (to use Denis' term) clients as a major motivation for DPV, which seems incompatible with a DPV server that requires perfect inputs.

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

---

See comments above re client capability assumptions.

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.

My proposal requires the DPV server to be able to do the same, though as an opaque blob.

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

I think the request/response formats for both servers could be almost identical, and with the right control flags one could cause the relevant subset of operations to occur, yes.

Steve