[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IETF-PKIX] Multiple Certificates
>>>>> "David" == David P Kemp <dpkemp@missi.ncsc.mil> writes:
...
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.
David> That's a contrived example - requiring the subscriber to adopt
David> the Clintonesque attitude that there are really two keys.
David> (The two keys just happen to have the same bits.) They are
David> two different pieces of data stored in two different
David> locations. If key B is stored in the clear, that doesn't
David> technically violate CA A's restriction. But if key A and key
David> B happen to have the same value, the adverse effect on
David> security is the same as if key A were stored in the clear,
David> violating CA A's restriction.
I must be missing something very basic here.
You seem to be saying that I would store the *private* key in two
places because I have two certificates for that same key.
That doesn't compute. Clearly I would store the private key only
once. That after all was the reason I wanted it to be one key and not
two... And furthermore, given that I'm a good responsible person :-)
I'll store it in conformance with the strictest rules for protecting
secret keys that apply to me.
In the example, that would mean using a FIPS-140 module, which will
satisfy the requirements of both CAs.
paul