Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

From: "Tom Gindin/Watson/IBM" <[email-masked]>
Date: Tue, 24 Oct 2000 13:54:29 -0400

By the way, a typical US driver's license is also a  Permanent
Identifier with an assignment authority of C=US, ST=xx, O=Division of Motor
Vehicles (or DMV).  The opaqueness and meaningless to outsiders of a
driver's license number (at least in those states which don't use SSN's)
are typical features of PI's.

          Tom Gindin

"David P. Kemp" <[email-masked]> on 10/23/2000 07:38:37 PM

Please respond to "David P. Kemp" <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt

> From: Polar Humenn <[email-masked]>
>
> If we take this model. You don't just check the attribute certificate
> (i.e. the drivers license). You check some identifying information on
that
> license that ties the certificate to the person giving it to you. A
> picture, some bio information, (age, height, weight, eye color) (however,
> incorrect, I might add :) that correlates the "certificate" to the
entity.
> Those are *identifying* attributes, not authorization attributes. In the
> PKI space, the *identifying* attribute is the public key.
>
> A drivers license has only has one authorization attribute. The privilege
> to drive a car.
>
> And that certificate is really issued to an entity that matches the
> *identifying* attributes. On that certificate, the entity may be given a
> name, an address, and possibly a number, for easy look up. That look up
is
> only relevant in the DMV's own directory, not in the post office's
> directory, or at the hospital.

It's always dangerous to use analogies, but in this example, the driver's
license is an identity certificate.  The bio information (picture, height
weight, hair color, hair presence :-) is, as you say, the "public key".
The date of birth is a certified attribute which can legitimately be
used, contrary to Aram's claim, for purposes other than the privilege
to drive a car.  The common name and the number are part of the DN, which
in full, might be: "c=US, st=CA, o=DMV, sn=S-678-109-876-432, cn=John
Smith".
One does not have to be very imaginative to suppose that VeriCertCo and
DigSigZone and PkiBoys could all issue certificates for each of the 50
states, or for each of the state agencies, or for each person licensed
to drive in the US, and that a compelling case for fraud or malfeasance
could be made if there were a single collision in names following the
"USDriverPerson" (analogous to InetOrgPerson :-) schema.

> The amusement park "would like to" include sufficient identifying
> information (such as a name and a driver license number), but, it cannot,
> because by the standard, it is limited to the DN given, "CN=John Smith,
> O=Smith". If attribute certificate adds anything else to the DN, then the
> correlation fails where it should succeed.
>
> If there is insufficient information to begin with (i.e. capability for
two
> John Smith's one with a driver's license, and a Bob Smith's 13 year old
> named John) then the correlation can succeed where it should fail.
>
> Isn't this called a hole?

As above, no.

The driver's license number doesn't have to be meaningful outside the
DMV's database, it only has to be a unique identifier which the DMV
will not issue to some other person.  I use the same authentication
credential to request a music download attribute cert (paid for with
e-cash or a regular credit card) and to perform the downloads; the
identifying information is irrelevant as long as its unique.  If
I get a new ID cert with a new public key from the DMV, I can still
use all my old attribute certs.  And if the relying parties ignore
the CN when matching ACs to PKCs, I can even change my name.

Dave

---

From: Paul Koning <[email-masked]>
Date: Tue, 24 Oct 2000 15:31:51 -0400 (EDT)

>>>>> "Tom" == Tom Gindin/Watson/IBM <[email-masked]> writes:

 Tom> By the way, a typical US driver's license is also a Permanent
 Tom> Identifier with an assignment authority of C=US, ST=xx,
 Tom> O=Division of Motor Vehicles (or DMV).  The opaqueness and
 Tom> meaningless to outsiders of a driver's license number (at least
 Tom> in those states which don't use SSN's) are typical features of
 Tom> PI's.

Clearly SSNs are neither opaque nor meaningless, but there are also
non-SSN examples where the same is true.

New Hampshire uses a simple and well-known algorithm to derive license
numbers; if you know a person's name and birthdate, you get the number
directly.  For example, assuming your birthdate is April 1, 1952,
you'd get 04TGN52011 (or, with low probability, 04TGN52012).

	paul