Re: [IETF-PKIX] Multiple certificates for same key?

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: Tony Bartoletti <azb@llnl.gov>
>
> The arguments put forth in deprecating multiple (independent) certification
> of a single keypair are reasonable, but I point out that they belie the
> purported nature of X.509 certificates as "identity certificates" (that is,
> to bind the key simply to a warm body able to appear court.)

I don't think X.509 certificates were ever purported to be "identity
certificates" with the meaning you suggest.  That is an interpretation
formulated by proponents of an alternative certificate format :-).

The original purpose of X.509 was to provide strong (as opposed to
password-based) authentication to X.500 directory servers.  Although
X.509 v1 did bind just an "identity" to a key, the meaning of "identity"
was concerned more with the privileges possessed by a warm body than
by the warm body itself.  If Joe Smith @ foo.com had a certificate and
the matching private key, he could get access to the directory if he
was on the access list.  It doesn't really matter if Joe got his job
under an assumed name to avoid child support, or how many Joe Smiths
there are in the world, it only matters that there is one person with
that userid at that company, and that that person is entitled to access.

MISSI expanded the use of X.509v1 certificates by cleverly stuffing
additional attributes (privileges, clearances, etc) into the
subjectPublicKeyInfo field, since there was nowhere else to put them.
Now that X.509v3 has extensions, privilege attributes can be included
in a more proper location.  But the role of X.509 certificates is still
the binding of privileges to keys, not the binding of warm bodies to keys.

For the purpose of electronic filing of tax returns, or getting access
to social security records, it would be convenient to have a "name"
(i.e. SSN) that attempted to be uniquely tied to a particular warm body.
But privacy advocates don't like that idea, so the binding between
identities and warm bodies is deliberately left vague.  That is a
political limitation, not a technical one.



> Allowing independent certifications on a single key can be compared to the
> use of both a "Diner's Club" card, and an "Auto Club" card.  If stranded
> in a broken car, the tow truck operator will be uninterested in my Diner's
> Club card, whether valid or not.  They want my Auto Club card, and want to
> be assured that it is considered to be in effect at the time of transaction.

This presumes that keypairs are somehow a scarce commodity.  What
possible benefit is there to having your Diners Club and Auto Club
certificates share the same key?  They're just bits; billions and
billions of combinations of them (apologies to the late A******
Astronomer :-).  Just use a new keypair for each distinct purpose
unless, as Bob Jueneman points out, there's a Very Good Reason not to.