[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DPD & DPV requirements
Frank,
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."
Yes, that's what the requirements spec already says.
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
An intermediate cert that is not trusted, but is not the end of a
partial path? Why? This is getting complicated.
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.
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.
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.
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