Bob:
Using aliases to allow users to have both a regular name and a name for
use in certificates is perfectly legitimate, and provides one way
around the CA name problem. However, this is unwieldy, resource-
wasting and, I suspect, an administrative headache. I hope we can find
a better way out.
Your other suggestion, re a caDistinguishedName (CD) attribute, struck
me as particularly interesting as it seems to be approaching my
authorizedSubtree attribute proposal, without requiring any change to
the X.509 certificate format. Let me pursue this line a little
further.
What is actually important in establishing if a CA is authorized to
sign a certificate is information signed by the CA's superior CA, i.e.,
information in the certificate certifying the CA's key. Suppose we try
to add information to the subject name in that certificate, by adding
an attribute that takes the value of a set of DNs. Rather than create
a new attribute, let us use an existing X.520 attribute such as seeAlso
(SA).
For example, suppose BNR has a CA it wants to be able to sign any
certificate under C=CA, O=BNR. In the certificate for that CA issued,
say, by the RSA Commercial PCA, we might use the subject name:
C=CA, O=BNR, CN="BNR Corporate CA #1", SA=(C=CA, O=BNR).
We can say that when such a name appears in the subject field of a PEM
certificate, it has the following semantics: The certificate issuer
(RSA) is stating that this CA may legitimately sign any certificate
with a subject name subordinate to the name in the SA attribute, i.e.,
C=CA, O=BNR.
Now this also nicely solves another problem we have. In fact, we want
this CA to also sign certificates for users in C=CA, O="Northern
Telecom" and in C=US, O=BNR. Provided we can convince RSA that this is
quite legitimate (which we presumably can, given we are all part of the
same corporate group), they could issue a certificate for us with the
following subject name:
C=CA, O=BNR, CN="BNR Corporate CA #1", SA={(C=CA, O=BNR), (C=CA,
O="Northern Telecom"), (C=US, O=BNR)}.
I also believe this opens up valuable flexibility for dealing with
residential CAs.
We also need to introduce the rule that, for any CA other than a PCA,
any names included in the SA attributes of CA certificates it signs
must be subordinate to DNs (subtrees) for which it has itself inherited
authorization rights as indicated in its own certificate from its
superior.
We can maintain backward compatibility with current PEM, by having the
rule that, if the subject name in a CA's certificate does not include a
SA attribute, then the subject names for which it can certify must be
subordinate to the CA name itself. Hence, the new conventions will
migrate into use as PCAs decide to support them and to issue
certificates which include the SA attribute.
I guess we have two options as to what we consider the true name of a
CA (such as in my BNR example) for the purposes of issuer name to use
in certificates that CA signs, and name for use in retrieving a CRL
from the X.500 directory. We could say that name includes or excludes
the SA attribute (i.e., maybe it could be just C=CA, O=BNR, CN="BNR
Corporate CA #1".) Probably always using the full name is cleanest.
Of course, what I am suggesting is to overload the subject name field
in the certificates for CAs keys by having that field carry what I
previously called authorizedSubtree attribute. This may be
objectionable in principle, but it does seem to expeditiously solve
many practical problems.
The idea of overloading a user's DN with his EN (e.g., as Rhys and you
are discussing) can be considered completely independently, as it is
impacting different names. (I have no objections to doing that as
well.)
Warwick