[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