John,
I don't think you had seen my message before you sent yours
to Steve Crocker.
I think that Marshall's point is that the DIT entries may
constitute a many to one from a DN to a certificate,
and perhaps even a many to few mapping. Multiple DN
entries may all contain a common certificate. Alternately,
some of these entries may be aliases of a common DN,
but that DN could contain multiple certificates.
As I said before in our previous exchange, the name
in the DIT that is used for search purposes does not have
to correspond to the DN in the certificate. But that doesn't
mean that we can't have another DN in the DIT that DOES
correspond to the DN in the certificate, if that is required.
What this does is to free us from constraints on the directory
schema that might be decided independently by different
directory service providers, and allows us to place our own
constraints on the DN within the certificate without having
to worry that we might "break" X.500.
Can you name an application (present or future) which would
use these disjoint certificates and DNs ? I note that supplying
aliases in the DIT would preempt my objections, but I wonder if
there exists some other mechanism which would allow one to
perform Directory lookups ? i.e. Is there a way to construct
a certificatePath (and associated CRLs) when the entry DNs are
disjoint from the certificate DNs ?
That is a good question. An even more sharply focussed one would be to
ask whether ANYONE has any plans to integrate an X.500 Directory User
Agent, either one that provides a human-readable interface or an API
only interface, with ANY X.400, SMTP, EDI, or other application which
uses X.509?
At present I am not aware of a DUA which provides anything but the
most primative support for X.509, and I am not aware of any but the most
rudimentary plans to start developing such capabilities. In addition to the
PEM X.509 certificates there are various flavors of PKCS certificates,
AOCE certificates which are encoded with nonstandard string types
(i.e., Apple's proprietary version of unicode for non-Roman languages),
the DMS or MSP certificates, etc. somehow we have to identify which
one of these various formats apply, what protocols they are intended for,
what their purpose is, etc. Since we don't seem to be able to put this
information in the X.509 certificate itself, we may have to define a new
object class, perhaps the nadfStrongAuthenticationUser object class,
to contain this information. Unfortunately, like any other new attribute,
there will not be any support for this for some time to come.
I don't believe that it will be particularly difficult to provide support for
X.509 certificates within any of a number of the Directory Service Agents,
including the public domain and commercial DSAs, although some of the
attributes used in the certificate DN may require some harmonization with
some of the NADF attributes used in the DIT.
I am much more concerned about the prospect of having DUAs that will
adequately support both the PKC DN requirements (whatever they turn out
to be) and the NADF DIT requirements, together with whatever private
attributes may be required to make X.500 a system for distributing
useful information to people, i.e., that users will pay for.
I think X.500 is a great idea, and we intend to support this as aggressively
as we can with our limited resources. But until I see a reasonable business
plan that indicates that someone will be willing to pay for all this
infrastructure, I wouldn't bet the ranch on it happening just yet.
Fortunately, we do have other potential and actual mechanisms for
distributing both certificates and CRLs which do not require X.500.
But you don't seem to like any of them.