Warwick,
There is nothing like trying to use something to make you
understand the problems better.
A member of my staff, Leonard D'Alotto, and I are presently
trying to define what kind of a Directory Information Tree
would be suitable for our X.500 inplementation within GTE Labs,
and we immediately ran into the problem you have been pointing
out. You're right!
Proceeding from primarily an X.500 background, Len proposed
setting up a DIT that would mirror our organizational structure.
He argued that if there is a name collision or even
a name ambiguity, the user is more likely to make the right
choice if he knows which organization he works for. (At least if
he is an internal user.)
Under this proposed DIT, my directory DN would be
C=US, O=GTE Laboratories Incorporated,
OU=Wireless and Secure Systems Laboratory
OU=Secure Systems Department,
CN=Robert R. Jueneman
Without arguing whether or not this would be an efficient or
user-friendly way of organizing our employee information for
searching purposes, I pointed out that if we apply the existing
name subordination rules, this would require the creation of a
Certification Authority at the level of each department --
something which I most assuredly do not want to do.
We then talked about using a flatter name space, such as my
previous example of C=US, O=GTEL, OU=Employee, CN=RRJ,
but Len argued that if for example the Secure Systems department
moved from the Wireless Lab to the Computer and Information Systems
Lab, with his scheme only a single entry in the directory DIT had to
change, whereas otherwise the organizational affiliation of every
member of the department would have to be altered manually.
I countered with the argument that under that his scheme, all
of the user's certificates would have to change, and that would
be an even bigger hit. We were therefore at an impass, because
the objectives themselves were incompatible.
But as has been pointed out before, the DNs in the certificate
do not have to be real DNs -- they can be aliases. So we began to
consider two parallel structures -- one being the primary DIT used in
the directory, which would be organized exactly along organization
chart lines, and the other DIT being a set of aliases used within the
X.509 certificates.
Trying to avoid having to create and use a new attribute, we
recognized that if the DN in the certificate is just an alias,
creating a new dummy OU is no big deal and it doesn't impact the
organizational structure. So the name of the CA could be
C=US, O=GTE Laboratories Incorporated,
OU=RSA Commercial Hierarchy CA
Then my X.509 certificate DN could be
C=US, O=GTE Laboratories Incorporated,
OU=RSA Commercial Hierarchy CA,
{CN=Robert Jueneman+serial=22934}
I could also have several other certificates:
C=US,O=GTE Laboratories Incorporated,
OU=RSA Low Assurance CA,
CN=Bob Jueneman
C=US, O=GTE Laboratories,
OU=Certificates 'R' Us CA,
emailAddress=Jueneman(_at_)GTE(_dot_)COM
All of these various X.509 DNs would be aliases of my "real"
DN, which might contain other entires such as my (multiply-signed)
MPEG video and the various X.509 certificates themselves:
C=US, O=GTE Laboratories Incorporated,
OU=Wireless and Secure Systems Laboratory
OU=Secure Systems Department,
{CN=Robert R. Jueneman+serial=22934}
Although perhaps not quite as architecturally and esthetically
tidy as using a unique attribute such as caName, this
approach would be fully compatible with existing PEM
implementations and with existing DUAs. Calling a PCA/CA
hierarchy an organizational unit strains the unspecified but
implicit semantics a little bit, but so does any kind of a
matrixed organization.
I would welcome any comments or suggestions you might have
regarding setting up appropriate DIT structures to support
organizational users independent of the certificate DN issue,
and also on the appropriateness of this kind of an alias scheme.
(The only potential problem with this approach is that aliases
are not controlled or signed by the CA, so this mapping is not
necessarily trustworthy.)
(In particular, if the user subscribes to Bob's Bargain Basement
Directory and Septic Tank Services, BBBDSTS might map the
above certificate DN to
C=US, O=GTE Lavatories,
CN=Robert J. "Jueneman is my middle name" Bork
or vice versa, and all sorts of mischief might ensue upon
dereferencing.)
(Therefore, and I almost hate to say it, if we really need to RELY on
the use of an alias for any reason, we may need a seeAlso
(nondistinguished) attribute in the certificate, or at least in a
certificate extension, that would be signed by the CA and
would be a trustworthy pointer to the user's "real" or primary
DN, and all of the other associated entries.)
On a slightly different note, if we want to go to the trouble of
creating and implementing a new attribute,
it might be worth considering a caDistinguishedName (CD)
attribute, whose value would be an entire DN.
This would allow the creation of stand-alone certification
authorities that are not part of, much less subordinate to,
the organization whose organizational person that is being
certified. It would also simplify the semantics of Persona and
Residential Person certificates.
We could have something like the following:
C=CA, CD=(C=US,O=RSA Data Security, Inc., OU=RSA Low Assurance CA),
EA=wford(_at_)bnr(_dot_)ca, CN="Warwick Ford"
Both the strength and the weakness of this approach is that the
CA is not bound to the user's organization, so the possibility of
a rogue CA issuing bogus certificates to people without their
knowledge is a real one.
On the other hand, presumably no one is going to take a low
assurance PCA or CA-endorsed message very seriously anyway,
so this may not be a problem. And if a high assurance PCA
wanted to offer such a service, presumably they would take the
necessary steps to assure that the user really had a right to use
that name, and the PCA would protect the other users from a rogue
CA.
Bob