Matthew,
I agree with a number of your points. Although we should not capriciously
invent new object classes and attributes, I have argued for a long time that
the current X.509 certificate is simply not well thought out (it needs a place
to hold attributes that are not forced to be part of the Distinguished Name.)
Unambiguously specifying that a CA is a CA should help.
I should note that your TSI example would not conform to the recommendations
I listed yesterday, since "Trusted Information Systems PCA" is presumably
not incorporated within the state of Maryland.
Although Jeff Schiller apparently intends to list the name of the PCA at the
top
of the screen so that a user would know which PCA is the root of a given
chain, that is presumably a local matter, and not part of the RFC.
As a result, if an organization operates a CA under two or more PCAs, it
will be very difficult for the user to understand which policy is in effect,
because
the user agent only displays the user's name and the CA's name, and the CA's
name will be the same in both cases.
Steve Kent has suggested that the difference in the key length or
some other kind of more or less hidden indicia can be used to determine
which certificate is the "real" or appropriate certificate when both have an
identical DN. I have to say that I think this is an absolutely horrible hack
from an architectural standpoint. In addition, it leaves the user without
sufficient
information readily at hand (and guaranteed by the RFC) as to which PCA is in
effect for a given message. Finally, I am not sure how multiple certificates
with the same DN will be filed in an X.500 directory. Even if PEM is able to
decide which branch of the tree to follow back to the appropriate root, how does
the originating user know which certificate should be used under which
circumstances for purposes of encrypting a message?
Your proposed cAName attribute would effectively solve all of those
problems.
However, I am not certain why we are listing the name of the CA. Wouldn't the
name of the PCA be more meaninglful? I would suggest that your cAName idea be
modified to include the name of the PCA, instead. If GTE Labs were a CA, this
would look like
C=US, O=GTE Laboratories Incorporated, pcAName="RSA Commercial Hierachy"
and/or
C=US,O=GTE Laboratories Incorporated, pcAName="TIS-PCA"
In order to avoid confusion as to which PCA and CA I was certified under, I
would
suggest that the pcAName be incorporated in the name subordination roles, so
my DN would be
C=US,O=GTE Laboratories Incorporated, pcAName"RSA Commercial Hierarchy",
CN="Robert R. Jueneman" or
C=US,O=GTE Laboratories Incorporated, pcAName"RSA Low Assurance PCA ",
CN="Robert R. Jueneman"
With this simple change we can differentiate between different certificates
used
for different purposes, and the name of the appropriate hierarchy will be
immediately
obvious to the user who displays the certificate.
If we don't have name subordination, then two CA might create certificates for
the same person, leading to ambiguous names and resulting confusion.
The use of a separate pcAName attribute would effectively allow us to extend
name subordination all the way up to the PCA, yet it would not imply the kind
of potential deep pockets relationship between the user and the PCA or the CA
that strict name subordination might tend to imply.
Steve says " As a user, I want to be assured that there is only
Bob Jueneman in Acton, irrespective of which residential CA has
certified him, otherwise two legitimate CAs might issue certificates
to two users and not realize that an ambiguity exists that has the
potential to confuse."
This seems like an almost metaphysical point. If I have signed up under two
different PCA/CA chains, presumably for some valid reason, am I the same
"person" in both cases? How about if I sign up with one CA at my primary
residence and another at my vacation home. Does that make me two different
people then? If I get married and change my name, am I now a different person?
What if I am a married woman who uses her maiden name for professional purposes
and her married name for social purposes. What about a famous show-biz
personality who uses a well-known stage name or alias?
I continue to feel uneasy with the fundamental concept of "identity"
certificates,
for we are really NOT identifying the individual, but rather uniquely naming one
or more instantiations of that person's identity. Now if our master public key
were tattooed on our arms at birth or our fingerprints or DNA encoding were
included
in the certificate it might be different, but at present we cannot really
assert that
we are guaranteeing the identity of a person.
Maybe I am thinking too much like a lawyer, but I don't care who you "really"
are. I would be satisfied to know what name you are using at the moment, and
where I can send the sheriff to arrest you if you default on an obligation to
me.
I would therefore suggest that we make the inclusion of some form of a street
address in the DN the norm for any residential person, with the understanding
that
if the street address is not sufficient to unique identify someone with a given
name who
lives at that location, then an apartment number, room number, cell block, or
other
qualifier must be used to ensure global uniqueness. At that point I see little
remaining
reason for the IPRA residential person database -- the street address should be
a
sufficient level of qualification.
Bob