RE: DPD & DPV requirements

[Frank Balluffi <frankb@xxxxxxxxxxxx>]

Some thoughts ...

1. Purpose: Qualified Paths Only

To me, DPD/DPV should be a protocol for requesting one or more qualified
paths by value or by reference, period. By qualified path, I mean a path
that satisfies some PKIX-defined standard (e.g., section 6 of RFC 2459). I
do not see value in returning paths that the server can either not qualify
or qualify in some other manner. Because PKIX does not define a standard for
path discovery, I would argue that the only discovered paths allowable
should be valid paths. What is the value of a server responding with, "Gee,
I threw this path together, which might satisfy your needs."

2. Request

The client should supply some subset of each requested path which must
include the least significant certificate and optionally:

- one or more intermediate certificates
- one or more trusted certificates

For ASN.1 applications, certificates should be passed by value. For XML (by
which I mean PKI-unaware) applications, certificates should be passed by
reference (e.g., issuer + serial number + ...). Optionally, an XML
application could pass certificates as opaque elements.

The client should have the ability to provide PKIX-defined path validation
parameters by value or by reference (e.g., by OID). Since the only known
parameters are those defined in RFC 2459, I do not see value in allowing the
client to supply other parameters. By this, I am not implying that others do
not have a need for custom parameters.

Should the protocol allow a client to supply revocation information in its
request, the server should have the right to refuse using such information.
The server may not trust the supplier of the revocation information or in
the case of an OCSP response, the server may not trust the supposed nonce.

For ASN.1 applications, parameters and revocation information should be
passed by value or by reference. I do not see value in referring to an OCSP
response, but I do see value in referring to a CRL.

For XML applications, parameters and revocation information should be passed
by reference.

3. Response

Should the protocol allow a server to ignore the parameters in a request and
the server ignores the parameters, the server MUST return the parameters
that it used in its response. If the server does not return parameters in
its response, the client should be able to assume that the server used the
parameters in the request and the server should include a digest of the
request in its response.

I do not see a need to return parameters to an XML application unless it can
do so by reference, which I am having difficulty imagining.

For XML applications, each valid path should be returned by reference (e.g.,
as an ordered collection of issuer + serial number + ...) and optionally as
an opaque element (e.g., base-64 encoded SEQUENCE OF Certificate). As others
have pointed out, all paths should begin with the least-significant
certificate.

4. Time Stamping

Time stamping functionality should NOT be included in DPD/DPV. The client
should be free to send its own request to a TSA of its liking.