Bob:
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 would welcome hearing more of experiences using many aliases.
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.
I think this depends on the organization. Actually, at BNR, we do not
put OUs in the DN at all. We are currently using "C=CA, O=BNR,
Locality=Ottawa, {CN=Warwick Ford, SerialNo.= my employee no.}. The
reason for no OUs is that we do have a centrally-administered
directory. (I think if the administration was delegated, for example,
to divisions we would have a different picture.) The reason for the
locality level is to give us some scope for distributing DSAs and
making name resolution work reasonably efficiently. (We believe that
having too flat a structure can negatively impact overall performance.)
Our CAs are all logically at the O=BNR level, and assignment of users
to CAs does not break down along the locality line (or any naming-based
line); hence, some of my concerns.
I also work with other organizations that have multi-level-deep OU
structures, which happens to make the most sense for them.
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.
Have people really built products that manipulate X.500 names but that
do not include knowledge of the full set of attributes in X.520 (1988)?
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".
Certainly, any DUA that did not support the full set of X.520 (1988)
attributes would not be worthy of consideration.
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 do not think we have a problem. The rules I am suggesting only come
into play when a PEM-cognizant implementation is processing a
PEM-conformant certificate chain. The only way things can go wrong is
if some CA has generated a certificate that includes a seeAlso
attribute used in a way inconsistent with our rules. In such
circumstances, the chain verification will fail. This is no different
to now, where if a CA generates a certificate not conformant with the
name subordination rule the chain verification will fail.
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 am no sort of expert in the residential CA field, but I was under the
impression that the current approach of achieving multiple residential
CAs for different sub-communities of a geographical subtree, by reusing
the same CA name with different PCA names, was somewhat shaky. With my
proposal you could explicitly authorize any residential CA to issue
certificates for any subtree (or, maybe, any set of subtrees), without
restricting its own name form nor its PCA allegiance(s). For example,
in one geographical region you could have multiple residential CAs
(competing for business) all operating under the one PCA. I would
appreciate your views on whether such added flexibility is of any
practical importance.
I get a headache every time I even think about residential
persons, much less their CAs.....
You have my sympathy, but this is not my field.
Warwick Ford