Tom Jones writes,
X.509 establishes names for the purposes of finding an individual in a
directory system. This is a useful function for a directory, but, as we
have seen, has limited value for a unique naming system. (Which it
never intended to be.)
X.509 merely establishes a binding between a public key and name (which
must be in the _form_ of of a DN, but is not specified as being checked as
actually existing or being unique). The CA adds the additional benefit
of confirming the mapping between the name and an individual (unlike
the case with self-signed certificates.)
NEITHER X.509, NOR X.520, NOR X.500 ITSELF CONSTRAIN THE SCHEMA
THAT IS TO BE USED FOR REPRESENTING THE DN.
Organizations such as the NADF and other pilot projects have recognized
that in the global OSI context it is important to be able to uniquely
name objects, and they have created a naming tree that is rooted with the ITU,
formerly the CCITT. THE ITU is an organization under the auspices of the
United Nations, and their results are subject to extensive diplomatic efforts by
our State Department. While not quite having the status of a treaty, the
agreement does represent the official position of the US government.
As a result of these negotiations, ANSI has been assigned the responsibility
of acting as the secretariat for the joint ISO/ITU naming arc within the
United States. They have established procedures for the naming of organizations
of various kinds, including provision for a national listing of an organization
immediately under one of the three arcs at the Country=US level. Below that
level they have not assigned any responsibility, to the best of my knowledge,
and in particular they have not imposed or created a state or local registration
system.
It is therefore not out of the question that some sponsoring organization
such as the IETF could go to ANSI, and petition that they be assigned
a role as a naming authority under the US arc (something other than as an
organization, which they could always do). It is even conceivable,
but perhaps somewhat less likely, that the IETF could petition the ITU
and create a name registration authority directly under the ITU root
(with no Country=). Either of these two approaches could be used to create
distinguished names using DNS machine names and/or rfc822 mailbox names.
Whether such an approach would be a good idea or not is another issue,
BUT IT HAS NOTING TO DO WITH X.500 or X.509.
The idea that seems to be failing is that some new organization (ITU)
can create a new naming scheme out of whole cloth and impose it on the
entire world by fiat. This just does not work. The X12 approach has
proven that it can work.
To the best of my knolwedge, the civil naming structure has been used by
the US Post Office for the last 200 years or so, and barring a few conspicous
failures by less than perfect mail carriers, the system itself works perfectly
well.
Nobody has to _create_ a name for anyone. People and organizations
already _have_ names, which they were assigned by the individuals who
created them (parents or sponsors).
The directory is simply a convenient way to refer to objects by their name, just
as we refer to a book by its title. We also have alternate ways of finding
objects (and books), for example by browsing under author's name, subject
matter, Library of Congress number, ISBN number, or even the old Dewey Decimal
system. The same is true of DNs -- we can have aliases, seeAlsos, and
approximate searches.
So we already have the ability to use the scheme that you describe,
depending on whether the naming authority has registered with ANSI or
with the ITU.
Planet=Earth, rfc822=Jueneman(_at_)gte(_dot_)com,
C=US, dun&Bradstreet=10002356765-01,
or C=US, SSN=123-45-6789
could all be perfectly valid DNs. They might or might not be aliases of
each other. If they are, then obviously they contain the same information,
but certificates could be listed in multiple places, and multiple certificates
could contain different DNs if necessary.
Far from being overconstrained, the number of degrees of freedom permited
application designers is really quite high.
However, we do have one important problem that we mustn't overlook, and
that is the problem of presenting the semantics of the information associated
with all these different kinds of attributes. That impacts the DUA, and also
the PEM certificate creation and validation code.
Two possible solutions to this problem occur to me:
1. Have the IETF (the IANA) decide precisely which attributes must be supported
in a core set, and let unfettered, snarling, free-enterprise determine the rest.
2. Adopt a technical solution along the lines of self-describing objects,
where the presentation syntax and semantics for each attribute are themselves
described in a selfDescribingAttribute type.
I prefer the second approach as the more general, but if we could come to some
sort of consensus as to what attributes must be supported that would be OK
as a start.
Bob