Bob,
Gee, talk about embarassed! I reviewed 1422 and it fails to
stipulate the requirement for display of the PCA ID. I recall
reworking the internet draft back in 1992 to transform it from TLCA
references to IPRA, and add in PCAs. I remember making the specific
section that addresses display of certificat validation data to make
it more liberal in terms of not requiring the originator or recipient
DN to be displayed, but rather to allow the display of local aliases.
Somehow, in the switch from a single TLCA to multiple PCAs I omitted
the requirement! This was not the result of a design change but
purely an oversight. I can find slide presentations and papers
published about PEM stating that requirement for PCA display since mid
1992 (looking at the slide copies I have!). This is clearly an
oversight for which I an solely responsible (as the RFC author) and
I'll work to get it fixed when the RFC comes up for advancement. It
just requires editing a couple of sentences and it has been an
"obvious" requirement ever since we introduced PCAs, since otherwise
the user is not being notified of the authentication context in which
the certification took place. I apologize for this omission having
gone unnoticed by me for so long and promise to get it fixed as soon
as practical.
As for your second point, I think there may have been some
miscommunicatin here. The IPRA residential user database check that a
residential PCA must employ is just a means of catching duplicates.
It is then up to the PCAs to "duke it out" to resolve the conflict
and, hopefully, get the right user bound to the right address. So,
the IPRA, per se, doesn't enter into deciding who has the right to the
residential DN in dispute, it just ensures that the PCAs live up to
their responsibility and resolve the conflcit before issuing the
second certificate. So your concern about the PCA/CA being ultimately
responsible for verification is consistent with what is supposed to
happen.
I think your suggestion about the permanance of OUs is quite
reasonable, but it is probably a matter of PCA (if not CA) policy and
thus outside the scope fo what we can specify as common certification
policy. But is might be a good thing to push for in your favorite PCA
policy statement.
I don't think that a residential PCA merely endorses a user's
"discovered" DN as you suggest. Maybe Steve Dusse's tongue-in-cheek
comment along those lines was misunderstood. I think Steve used the
term to emphasize that the PCA is not a naming authority. I expect a
residential PCA should be helpful, maybe publish guidleines to aide
users, and offer individual support. Even though the PCA is not the
official naming authority, it is an entity that verifies the
legitimacy of the claimed right to use a name. This latter
requirement is the essence of any PCA (residential or organizational),
just with differing levels of assurance.
Your extended discussion of the subtleties of postal addresses
is impressive, Bob! I especially liked the post office box example.
I vote for the "where you get your postal mail" as the appropriate
address info, irresepctive of the poshness (or lack thereof) of the
locality name. Maybe a good residential PCA/CA requires the user to
supply a cancelled envelope with his name and postal address as one
piece of proof of right to use the postal address as part of the
registration procedure. ( I hope a responsible resdiential PCA/CA
probably will refuse to register "occupant" or "postal patron"!)
Maybe the address info on a driver's license is sufficient in most
cases, but I agree that it is not necessairily current. Te precise
requirements are up to the folks who run residential PCAs, along with
their tolerance for forwarding after a move, etc. Maybe the USPS will
come along soon and do this for us!)
Well, Bob, you and I (and Steve Dusse) really do differ over
having a state represented as a CA along the path. I agree that it
would be nicer if states would step up to the task and perform this
function, but I am not holding my breath. I argue that with suitable
disclaimers in the PCA policy statement, nobody will confuse a
residential CA with a state government organization. The idea is that
even though your "I. M. Somebody in Beantown" example is exactly what
1422 requires from a certification path standpoint, what would be
displayed is just the PCA DN (or local alisas thereof) and the user Dn
(or local alias thereof). The state CA need not be displayed and I
recommend against displaying it on a regular basis, for fear of
overwhelming the user. (There is a requirement that the user be able
to request a full path display, but that should be done rarely.)
The second example you cite, {C=US, S=MA, O="Massachusetts
Residential CA"} is not a contender, I think, as it would require
users to have that Org component in their residential names, and I
don't think anyone really wants that!
A resdiential PCA is distinct from an organizational PCA, in
that the form of the DNs that each certifies is syntactically
disjoint. If a resdiential CA operating at the state level were to
sign a certificate that had an organizational component under it, that
would violate the specs established in 1422 (where there is a specific
reference to residential CAs signing certificates that conform to the
residential person object class attributes in X.521) , and it would be
an obvious violation. Also, BBN would be an obvious candidate for
getting nailed by the state government, having generated a certificate
that purports to represent a state official and having affixed its
signature (to make sure everyone knows who did this silly thing!).
Bob, Matthew and I spoke on the phone yesterday and he now
understands that object classes do not yield subordinate directiory
entries in the fashion he thought. His suggestion was based on a
misunderstanding of the structure of the DIT and its relation to
object clases. I wouldn't base proposals to change how we do
resindetial users based on that misunderstanding.
I'm a candidate for a residential user and I don't want my DN
to contain the name of my resdiential PCA. That would be inconsistent
with my real DN, and thus violates one of the goals of certificates
issued under this system, i.e., to not yield certificates that are
unsuitable for storage in real X.500 DSAs. (Matthew's suggestion also
had this problem). As you observed, one problem with issuing
residential user certifictes directly under PCAs is that the system
assumes that CAs come directly under PCAs. If we make an exception
for residential PCAs, how does software distinguish between
residential and organizational PCAs? Hint: the answer should not be
magic new fields added to X.509. Do you want to establish name
constraints on resdiential PCAs to make them syntactically
identifiable? How long shall we argue over what those constraints
shall be, and by the way, let's make sure that work in all languages,
not just English!
I'm open to suggestions on how to make the system better, but
I am not enthusiastic about suggestions that tinker with one part of
the system, whiel ignoring the implications for the rest of the
system. If we make changes, they need to be thoroughly articulated
and we need to understand all of the implications of the changes,
e.g., in terms of semantics, certificate processing, scaleability of
the system, omposition of constraints on user and organization
selection of DNs, etc.
As to your footnote, you are right that the question never got
answered. The possibility of different people with the same full name
being employees at the same company over time is certainly a valid
example. For very large organizations, using one or more OU or L RDNs
may be a reasonable way to provide some increased name
differentiation. However, there is always the possibility that
reasonable (vs artifical) DN structure will result in a collision.
This argues for making the final RDN be a sequence consisting of a
common name followed by an employee number. Most companies know how
to assign unique employee numbers or the equivalent and already do
this to avoid conflcits in payroll systems. The downside is that this
added qualification is not very descriptive for folks external to the
company, but its the best suggestion I've seen so far. However, one
should be careful not to use this as an excuse for using less that
appropriately qualified common names, since the employee number
attribute could be a crutch to avoid reasonable name differentiation
options that would be more descriptive! By the way, this rollover
concern is a large part of the motivation for the UUID field added to
the 1993 certificate format. That addition allows DN rollover while
making certificates distinguishable. However, this solution does not
allow ACLs based on DNs to work, i.e., you have to include the UUID as
well, to avoid being fooled by a new certificate with the same DNs but
a new UUID.
Steve