[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IETF-PKIX] Multiple Certificates
> David> If some other person gets a copy of my private key, that is a
> David> key compromise. If I have a keypair certified for one
> David> purpose, and I take that private key and request that it be
> David> certified for a different purpose, that is a key compromise
> David> from one of my schizophrenic personalities to another :-).
>
> I don't see the issue.
>
> If your private key is compromised, your private key is compromised,
> and the validity of all signatures made by that key is thrown in
> doubt. Whether the corresponding public key is attested by one or by
> a million certificates makes no difference.
Let me try to put it another way, make a different analogy that
might help, or might just confuse.
I like using Unix because it has multiple users. If I administer
a machine (say my own personal machine at home), I know the root
password and the passwords for any number of users. But I only
log in using the root password infrequently to do important stuff.
Most of the time I use my normal user account. And when I want
to do something especially dangerous, like running a program picked
up off the Internet, I log in as a different user with minimal privileges
so it can't read or write my normal files.
Do you agree that this is prudent?
Now say I have three certs, one for doing important stuff (signing
contracts), one for doing regular stuff (signing email), and one for
testing. I keep the important private key in a token that isn't normally
plugged in to the machine. I keep the normal key in a disk file, encrypted.
And the test key is kept in whatever form is most useful for testing
software, unencrypted.
If all three keys have the same value, then anyone who gets onto the
machine and gets a copy of the test key now has a copy of the key I am
very careful to store on a token.
Do you agree that this is a bad situation?
Do you agree that if I have a million certs, each with a different
key, then compromising one of them leaves the other 999,999 unaffected?
> David> More realistically, if one CA's Certification Practices
> David> Statement says that subscribers will be required to keep their
> David> private keys in a FIPS-140 rated module, and another CA allows
> David> subscribers to keep them in unencrypted hard disk files, then
> David> if I happen to request certification of two keys which happen
> David> to have the same bit pattern from the two CAs, one of the CA's
> David> policies may have been violated.
>
> That doesn't follow at all. You only get into trouble if the
> intersection of the requirements of the various CAs is null.
That's a contrived example - requiring the subscriber to adopt the
Clintonesque attitude that there are really two keys. (The two
keys just happen to have the same bits.) They are two different
pieces of data stored in two different locations. If key B is stored
in the clear, that doesn't technically violate CA A's restriction. But
if key A and key B happen to have the same value, the adverse effect
on security is the same as if key A were stored in the clear, violating
CA A's restriction.
> It seems to me that, given that many people view certificates as
> things that describe authority (roles) and not identity, you're going
> to have a pile of them. And if you do, there are good reasons to want
> to minimize the number of private keys.
What is one good reason to minimize the number of private keys?
You aren't going to save much money by skimping on memory to store
private keys. And you aren't going to gain any convenience; when you
pick a cert you get the private key that goes with it, whether that
is the same value or a different value than the keys for your other
certs.
> To apply one of the standard analogies again: while I have one
> identity, I have a lot of different authorizations (roles), and lots
> of different pieces of plastic and paper attesting to these. But my
> signature on all of them is the same scribble.
This is a meaningless analogy. If your digital signature was always
the same electronic scribble, it wouldn't be very hard for anyone
to forge your signature, would it.