pem-dev
[Top] [All Lists]

Re: Name subordination

1993-12-21 15:14:00
Bob,

        I agree that folks other than the UPSP could be in the
business of certifying residential users, although the USPS could be
viewed as a "natural" certifier for a vast population.  I'm not sure
that the record keeping of my electric, phone, or cable TV company
makes them any better or worse than the USPS as a residential
certifier.  The requirement here has to do with what the certificate
issuer does in the way of verifying an individual's identify and that
may be done via a variety of external documentation independent of the
records already maintained by the issuer.  After all, a landlord might
pay for utilities for an apartment complex and thus make the records
of the utilities not very accurate for residential certification.  I
agree that banks could serve this function too, independent of roles
as credit card issuers.  HOWEVER, in each case these entities might be
acting as PCAs, with different policies based on what records they use
for identofication, etc. and this means that they could create
"phantom" CAs to sign the residential user certificates, this
maintaining name subordination as currently specified.

        Thanks for writing up all of the examples we discussed a few
weeks ago.  I agree with each of the ones you cited as reasonable
examples of how to generate DNs under the various circumstances.

        The question of what a CA does to verify a user's accurate
residential identification is specified by the PCA policy under which
the CA operates.  A bank or a utility might use its records as a
basis, plus a driver's license.  A notarized statement indicating that
the notary checked several pieces of ID that confirm the user's
residential ID is what RSADSI proposes, right?  

        The purpose of the residential user database operated by the
IPRA, and accesible to PCAs, is to catch possible conflcits of the
sort you describe.  Every residential PCA is REQUIRED to use this
database to detect possible conflicts and then it is the
responsibility of the PCAs to resolve any actual conflicts, to avoid
duplicate registrations.

        Your exmaple about name subordination does not match the
schema described in 1422 for residential users and residential CAs.
The example you cited conforms to name subordination, but at the cost
of giving the user a DN that ties him in an "unnatiral" fashion to the
CA.  In the 1422 schema, your DN might be:{C=US, S=MA, L=Acton,
CN="Robert R. Jueneman"} and the CA would be: {C=US, S=MA}, but the
PCA would be {C=US, O="RSA Data Security, Inc.", OU="Residential High
Assurance CA"}.  Your DN under a TIS residential CA would be the same,
and the CA name would be the same, but the PCA name would be
different.  Yes, if one registered user names uder residential CAs
that incorporated certifying organization names, the conflict would be
avoided, but I don't think the resulting DNs would be better, e.g.,
more descriptive.  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 is just like the example of MIT being represented by two
CAs, one certified under the RSA high assurance PCA and the other
certified by a mediaum assurance PCA run by TIS.  Users at MIT can be
cerytified by either of these two MIT CAs, and their names don't
reflect any difference.  But, in tracing a certification path, pne can
always determine under which MIT CA, and thus under which policy, the
user was certified.  Admittedly, if we adopt 1993 certificates we can
make the determination evcen easier (through the use of the Issuer UID
field to better point to a specific instance of a CA when there are
multiple ones with the dsame DN), but even without that we can always
trace back unambiguously.  As we noted in our conversation, a simple
heuristic that will probably work in most cases os to look at the
length of the issuers public key.  Fast signature cehcking (e.g., as
implemented in Ray Lau's RIPEM for the Mac) makes it so quick to check
multiple CA candidates that I don't think anyone will care even if
this were done serially.

Steve

<Prev in Thread] Current Thread [Next in Thread>