Subject: RE: DPD & DPV requirements

From: Frank Balluffi <[email-masked]>
Date: Thu, 11 Jan 2001 08:47:41 -0800

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.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jan 2001 16:51:55 -0500

Frank,

>I threw this path together, which might satisfy your needs."

Yes, that's what the requirements spec already says.

>- one or more trusted certificates

An intermediate cert that is not trusted, but is not the end of a 
partial path?  Why?  This is getting complicated.

>application could pass certificates as opaque elements.

I can see a PKI-ignorant app passing a cert as a blob, but passing 
some other form of cert ID has to be motivated by the scenario that 
would cause this info to become available to the app. We do have an 
example that cited the issuer name and serial number for of cert 
reference elsewhere, but that was an app that is already ASN.1 aware, 
and so not a candidate for this discussion. I worry that once we move 
into the realm of other, nominally equivalent forms of cert ID, that 
we are entering a very iffy area, especially since we are talking 
about accommodating a growing set of apps that are, by definition, 
not ASN.1 aware.

>not have a need for custom parameters.

Since the spec already says this, why are you repeating it here? We 
started down a path of suggesting charges to my strawman spec. I'd 
like to continue in that fashion, to avoid duplicating existing text 
and confusing the discussion.  Please go back and cast you 
suggestions in the form of changes to the current requirements spec, 
so that where your suggestions agree with that spec there is no need 
to comment.

Thanks,

Steve