Bob,
It has always been the intent of PEM to require the PCA ID
(either the distinguished name or a local alias) to be displayed for a
user. Without such a display a user cannot make an infomred judgement
about the quality of the ceritfication invokved. I don't have the RFC
handy, but it should be an explicit requirement of the display of
certification information. It is because of this display requirement
that there is no need to make the PCA DN part of the user DN, and yet
still allow the user to see what PCA is involved.
I said that key length provides a "heuristic" for determining
which of multiple CAs (certified under different PCAs) was responsible
for signing a certificate. OK, I'll admit that "heuristic" is a fancy
word for "hack", but this is JUST AN EFFICIECY ISSUE! Contrary to
what you stated, the user is NEVER, in an ambiguous position with
regard to tracing the certification path to a single PCA. Checking
the signatures against multiple, possible ancestor CAs is a
deterministic means of identifying the right CA and with fast software
(e.g., Ray Lau's code) this is not a big deal unless there are many CA
choices. In practice, most CAs will have but a single PCA ancestor
and when there are multiple PCA ancestors the fanout is likely to be
quite small, e.g., 2-3. As for the how to store this in the
directory, the certificate attribute is allowed to contain multiple
values (all values are returned whenever the attribute is "read").
I won't comment on the rest of the message that deals with the
suggested PCAName attribute, because I think it really is the result
of a misunderdstanding of the relationship between object classes and
DIT structure. However, one thing to keep in mind is that we have
explicitly avoided extending name subordination all the way to the
PCAs for good reason! People are sensitive about their names and we
have strived to minimize constraints on name forms while retaining the
ability to minimize the damage that can arise due to errors or
malicious acts by CAs and users and while minimizing the information
that must be displayed for user perusal. The current design is
expressly carefully considered tradeoff along these dimensions.
Bob, you are two different residential persons (from an X.500
perspecitve) at the two different addresses represented by your
primary and vacation homes. And yes, a change of name that occurs
with a change of marital status (e.g., hyphenation) also makes you a
different residential person. As we discussed in Boston several weeks
ago, the identities we are trying to establish are descriptive
relative to some context. There is no perfect, single name that is
equally meaningful in all contexts and so some people may have
multiple names that provide the requisite descriptiveness in those
different contexts. I don't want to argue the more philosophical
aspects of identity; I'll settle for straightforward explanations in
which we claim to certify the accuracy of the binding between a DN and
a public key. In some instances two different DNs will correspond to
the same physical individual, and that's OK.
I agree that inclusion of the street address should be a part
of a residential user's DN, in order to provide uniqueness and
descriptiveness of the sort on often associates with "residential
users." This does NOT do away with the need for the IPRA database,
since part of the intent is to catch possible duplicates that arise
because of clerical errors, a failure of appreciate the required
degree of specificity (apt # etc.), or downright attempts at duplicity
that may not be caught by lower assurance PCAs.
Steve