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

[Bill Burr <william.burr@xxxxxxxx>]

At 09:42 AM 3/4/98 -0500, you wrote:
>> 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.
>
>
Dave,

Keypairs may not exactly be a scarce commodity, but perhaps the protected
storage for private keys is.  If you think that you should keep your
private keys in a hardware token, you may not be able to have dozens of
private keys.

If I have 50 or 100 certificates, each with some particular attributes
bound with my keys, one for the auto club, one for the New York Times
on-line, one for every pay site I subscribe to, etc., and I want to carry
them around on my token and use them at home and at work, etc., maybe I've
got a problem.

Is does seem to me to simplify my life to use one key to sign everything;
after all, I don't sign my name differently when I use my AMEX card than
when I use my Visa.   This makes sense if we separate attributes from
identity and use X9 style attribute certificates, that don't contain a key.
 I'm far from convinced that such attribute certificates are practical.

But if, as you -I think correctly- suggest, we're actually binding a lot of
attributes into X.509 certificates, then I suspect that we're each
individually going wind up with a lot of x.509 public key certificates.  If
each of them has a different private key, then we've got a lot of private
keys to store, manage and protect.  I think that the fewer private keys I
have to manage, store and protect, the better.
Regards,

Bill Burr