Francisco,
I think you have accurately summarized the basic reasons for the
RFC 1422 approach to name subordination, i.e., it is to ensure
that there is a reasonable affiliation between the issuer and
the subject.
Since a rogue CA could make up public-private key pairs and
assign them to anyone, without that individual's knowledge, it
is important to both limit the scope of the damage that could be
done, and of course to issue CA certificates to only trustworthy
CAs.
It was felt that by requiring the subject's DN to be subordinate
to the issuer's DN, the scope of the damage that could be caused
by a rogue CA would be limited to the CA's own organization. And
because there was at least a vague feeling that the organization
would have some kind of a deep pockets liability for the actions
taken or allegedly taken by individual's certified by that CA,
any damage would be a self-inflicted wound.
This was also the reason for another restriction that PEM
imposed that is not required by X.509, and that was to limit the
chain to at most four nodes -- the IPRA, the PCA, one and only
one CA, and the user. In particular, if the user were able to
certify other users, Bob Jueneman at GTE could make up a
certificate for the COM group at UPC, and then use that
certificate to sign Alicia's certificate. The feeling was that
the chain of certifications might slide by too quickly, and that
the user would only notice or read the last CA, and conclude
that the user's certificate was valid.
But although the requirement for name subordination was well
motivated, there were a number of problems from the very
beginning, and they are still there. The first was the obvious
fact that the CA can not have a name subordination relationship
to the PCA, yet the PCA is the most important CA of all.
(I think that the creation of the PCA concept was perhaps THE
most important development to come out of the PEM work, for it
identified a mechanism to provide some TRUST in the quality of
the identification associated with an individual. It also
allowed the amount of trust that was required to be variable,
depending on the user's needs.)
As you have correctly observed, a given organization may very
well need to participate in multiple hierarchies, because they
have a requirement for varying levels of trust. More correctly,
they can only AFFORD certain levels of trust for most of their
people, but can afford higher levels for some of their people.
The extremely cumbersome way that was supposed to be used to
solve this problem was to chain back through the certificates,
trying multiple keys if necessary until one was found that
worked, and then continue up the chain. Not only was this ugly
from an architectural point of view, it doesn't even work unless
the two key pairs are different.
(I don't like the idea of using the same pair of keys for two
different CA assurance hierarchies, primarily because of the
additional risk (too many eggs in one basket), but I suppose we
can't stop people from being stupid.)
In addition to the problem of having one organization with only
one DN acting as the CA for two different hierarchies, there is
the problem of residential persons, where the name subordination
doesn't work unless you artificially create a residential person
under an organization, and use semantic conventions (kludges) to
distinguish between the real and the phony organizational person.
Warwick also brought up the problem that using the name of the
organization as the CA name tends to either limit the ability of
the organization to associate other attributes with that name
(an argument which I don't completely accept), or it requires
the creation of an arbitrary OU just to anchor the CA. This in
turn may create a need for aliases in order to simplify the
naming, and that carrys it own set of problems.
You have brought up several additional issues, such as what
happens if a user is certified at multiple levels. Does he have
to change his name to reflect this fact?
Well, assuming the '93 version, he does not have to change his
DN, because the UniqueID can be used to differentiate the
certificates. However, since the UID is not human understandable
and doesn't have any defined semantics, MANAGING this problem
becomes very difficult, and as a practical matter the user may
very well have to add a lower level of qualification or a
multi-valued RDN to his name in order to solve the problem.
A couple of other problems to throw in the pot. Apple would like
to be able to certify their dealers, so that they can exchange
signed orders, etc. Now Apple either has to become a PCA (very
awkward, at least in part the Apple AOCE software hardcoded the
public key of the RSA Commercial Hierarchy), or they have to
violate the name subordination policy, or they have to abandon
what most people would consider a reasonable schema, and create
something like:
C=US, O=Apple, OU=Dealer Network, C=CA, O=ComputerLand,
OU=ComputerLand of Montreal, CN=Frere Jacques
This is just a different version of Rhys's problem -- the
dealers don't want to have to set up their own CA, because of
the problems that would entail.
A comment on one of your points:
If you are worried because company A may issue a certificate to
an employee of company B, why are you not worried that a high
assurance PCA can certify a low assurance CA (as Rhys noted),
or that several PCAs can sign the same key pair of a CA?
I don't recall Rhys saying that, and don't understand what this
would mean. I PARTICULARLY don't want to have to get into
reading different CAs policies. If there are different levels of
assurance, then there should be different PCAs, each with their
own policy stating the minimum requirements.
I might be able to put up with the same organization running
both a high and a low assurance CA and using the same keys,
although I think it is a bad idea. Two different PCAs could then
sign those keys, BUT THERE WOULD BE TWO SEPARATE CERTIFICATES
INVOLVED. If necessary, the subject UID would have to be
different.
CONCLUSIONS:
Name subordination solves some of the certification problems but
not all of them.
Just as it has been observed that trust does not necessarily
follow domain names, trust does not necessarily follow a
Directory Information Tree.
The problem is made significantly worse by the fact that the
X.509 certificate only allows for a DN, with no optional or
non-distinguishecd attributes.
There would appear to be four ways to deal with this problem:
1. Cram the necessary certification tree information into the
Unique ID field as you have proposed, although I confess that I
have not examined your suggestions along these lines in detail.
2. Overburden the existing DN structure with something like a
caName or caDistinguishedName attribute, along the lines that
Warwick and I have discussed.
3. Create a new X.509-like format which WOULD allow for
non-distinguished attributes.
4. Use an extended certificate type such as PKCS #6, where the
extensions would also be signed by the CA.
I believe that any of these four solutions would solve the basic
problem, so the issues become one of architectural design/taste,
the impact on existing applications, and our desire to have a
single common PKC infrastructure.
My inclination has been to try to get the entire standards
community, including PEM and X.509, to move in the direction of
modifying the existing X.509 certificate. To me, that seems to
be the overall wisest choice, as it results in one reasonably
compact certificate that ALL PKC applications should be able to
handle.
On the other hand, if adopting such a suggestion within the PEM
community would mean that we would be turning our back on other
PKC applications then I tend to recommend one of the other
suggestions, with my preference being first the PKCS extended
certificate format, then perhaps your expanded UID proposal, and
then the overburdened DN ideas.
Unfortunately, my preferences are close to being in the reverse
order of impact on existing applications, so there will be some
impact no matter which way we go.
I'd like to make sure that we have a reasonable consensus that
we have adequately stated the problem before we try to decide
which of the various alternatives to choose.
I'd also like to hear a summary of the discussion and any
resolution that might have been reached at the Working Group
meeting in Seattle.
Bob
PS. I'm trying to use Ami Pro to avoid the problem of overrunning
lines, at least until I get a new package. If anyone has a problem
reading this, please let me know.