Warwick,
Your proposal requires more detailed thought than
I am able to give it on a Friday afternoon! Let
me think about it over th eweekend, and perhaps
get comments from others.
However, I will make a couple of observations.
I don't yet know how ugly/awkward the use of
aliases will be. William Green at UT Austin
thought it would be a terrible problem, but he
is running a X.500 directory with 80,000 entries!
I've also been rethinking our DIT structure based on
some of his comments, and may come back to something
like
C=US, O=GTE Laboratories Incorporated, OU=Employee,
{CN=Robert R. Jueneman+serial=22934},
emailAddress=<Jueneman(_at_)gte(_dot_)com>
for both the X.509 subject DN and the "normal" DN.
I am beginning to be convinced that organization details
should be carried as attribute entries under the user's rather
flat, simple DN, rather than being encoded into his DN,
but would appreciate any wisdom or experience you have
to offer here.
Regarding the use of seeAlso rather than a new
attribute, I suspect that none of the PEM certificate
creation software or the validation software currently
support seeAlso, so a new attribute would be no worse
than an unsupported attribute.
Although some of the DUAs may support seeAlso,
I suspect that few if any support X.509 yet, so
this may be another "so what".
I don't so much mind overloading DNs, but I am
becoming VERY concerned about the extent to which
existing X.520 attributes are lacking in any semantic
content other than the cryptic attribute name itself.
If we intend to apply the kind of semantics you are
discussing, and this may be a great idea, then we
should create an appropriate name for such an attribute.
Otherwise, someone else will use seeAlso, and we will
have no way to automate name subordination checking.
I also believe this opens up valuable flexibility for dealing with
residential CAs.
Can you say a little more about this? I don't see where you
are going here.
I get a headache every time I even think about residential
persons, much less their CAs. The existing scheme for
distributing knowledge about which DSA "has" the entry
for a particular organization is bad enough, but trying to
distribute that knowledge across a dozen ADDMDs for
say 300,000,000 users is simply NOT going to work.
We are either going to have to create a huge superdirectory,
or cede responsibility for residential persons to either the
Post Office or the state Department of Motor Vehicles,
or content ourseves with going out in parallel to all DSAs
everytime we want to find someone (until "our" DSA
"learns" where that individual is).
Actually, the parallel search may not be so bad, assuming that
individual DUAs and DSAs do some cacheing.
Bob