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

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

> From: Bill Burr <william.burr@NIST.GOV>
>
> I can leave my certificates stored on a directory somewhere and access them
> over the net when I want them.  I can have my file of certificates on the
> disk of my machine at work, on my machine at home, on my laptop, carry it
> around on a floppy disk, paste them on the wall, put them on my web site,
> and so on. I can have 100 copies and leave them anywhere I want.
>
> But, the key or keys I must protect.  I may want to carry them around on a
> chip card in my wallet.  It may be more important to use that silicon to do
> digital signatures and key agreement on the chip, so that the private key
> never leaves the chip, than to store a large number of certificates and
> separate keys.

Certainly certificates don't need to be carried in protected storage,
and keys do.  But the question is: does your token carry one private
key, period, or one private key per role.

The number of roles you want to manage is probably limited by
ergonomics; if all your certs are stored on floppies or directories, or
web servers, you still have to pick the cert to use for a particular
transaction.  I have trouble leafing through the 20 cards in my wallet
(drivers lic, MasterCard, AMEX, library, Red Cross, health insurance,
warehouse club memberships, etc).  In an electronic transaction,
selecting from 20 or 50 bookmarked URLs, desktop icons, address-book
entries, etc. to pull the cert to use may be practical; selecting from
1000 certs probably is not.

So if a token has the storage capacity for 20 or 50 or 100 private keys,
it probably meets the needs and organizational capabilities of most
human users.  100 private keys (12.8 KBytes) is not an outrageous number
to expect a token to support.  How much cheaper is a 128 byte token than
a 16 KB token?

And if you have application software that can handle pulling public
certificates from a directory/web server/floppy while pulling private
keys from a token, then it is unrealistic to expect that the software
would not be capable of correlating private keys with certs. Managing
100 certs with 100 keys is no more difficult for the user than managing
100 certs with 1 key.


> I don't accept that the pin on my token is analogous to a handwritten
> signature.  The AMEX card is analogous to the certificate, and my selecting
> a particular certificate for use in a protocol, is apanages to picking my
> AMEX rather than my VISA.  But, when I sign my transaction slip, I don't
> sign differently for Amex than for Visa.  It's the same signature.

The actions that the user must perform are analogous: open your wallet,
pick a card, sign a transaction slip.  Unlock your token with a PIN,
pick a personality (cert), click on the Go button.  The user authentication
happens at step 3 in the physical process and step 1 in the electronic
process, but so what?  (If you really want to emulate the physical
world, the app could wait until step 3 before asking for the PIN or
database password).

Why are you concerned whether the signature computed as a result of
clicking the Go button comes from the same private key or different
private keys for different certs?  Even if you always use the same
private key, the signature will be totally different every time if
you're using DSS.  And even if you use the same private key and a
deterministic signature algorithm (RSA), every signature will be
different if the content being signed is different.  It's not the same
signature, regardless of whether you have 1 private key or 100.

That's the danger of reasoning by analogy - you can't look too deep
or things fall apart.

Regards,
Dave Kemp