Re: [IETF-PKIX] Multiple Certificates

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

I have permission from the author to post the following private message:



> From: "Balluffi, Frank" <BalluffiF@CertCo.com>
>
> David,
>
> It seems to me that this whole multiple certificates per public key
> dicussion is moving in the direction of technology for technology's
> sake.


Funny, that's what I think about proposals to have multiple certificates
with a single key :-).  Existing technology (Netscape or MSIE pointed
at VeriSign) results in a new key for every cert requested, except in
the case of cross-certification, as pointed out previously.  You
have to go out of your way to make up cert requests with a shared
key.


> What is the foundation or context for this discussion: WHAT ATTACKS ARE
> WE CONCERNED ABOUT?


Key compromise.

If some other person gets a copy of my private key, that is a key compromise.
If I have a keypair certified for one purpose, and I take that private key
and request that it be certified for a different purpose, that is a key
compromise from one of my schizophrenic personalities to another :-).

More realistically, if one CA's Certification Practices Statement says
that subscribers will be required to keep their private keys in a
FIPS-140 rated module, and another CA allows subscribers to keep them
in unencrypted hard disk files, then if I happen to request certification
of two keys which happen to have the same bit pattern from the two CAs,
one of the CA's policies may have been violated.

That is an extreme example, but it applies anytime there are differences
in the purposes for which a certificate is issued. To be less extreme,
say the FPKI profile says that certs shall not contain keyUsage bits
set which allow both signature and encryption.  If the same key is certified
twice, once for each purpose, then both certs are compliant with the
policy but the end result is not.

It is impossible to analyze the interactions of all possible combinations
of certification practices and certificate attributes to determine whether
any two pairs result in unintended consequences.  Therefore, the safe
thing to do is to not multiply-certify a single key unless you have
analyzed and understand the results.


> For the life of me, I am unable to identify any attacks that result from
> replacing certificates other than denial of service.
>
> For example, suppose I sign and send a message and someone replaces my
> certificate with one they dynamically generate that contains "do not
> trust this certificate", the recipient will surely not trust my message.
> I, the sender, will still be able to resend my original message via
> other means.
>
> No one has identified an attack that warrants changing the existing
> standard to not allow multiple certificates per public key (which is
> most probably not enforcable anyway).
>
> Unless someone can identify an attack that warrants changing the
> standard, the standard should not be changed.


I don't think anyone has proposed modifying any standard to prohibit
multiple certification.  We're just pointing out security considerations
that should lead to the Generally Accepted Practice of not doing it.