Re: [IETF-PKIX] Multiple Certificates

["Arsenault, Al W." <awarsen@xxxxxxxxxxxxxx>]

Sorry to jump in late, but I've been away at other jobs for a while, and
I'm just catching up :-)

>From one of Dave Kemp's messages:

>> 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 :-).

AWA comment:  it's only a "compromise" if it's unauthorized - against
the rules established by one or more CAs.
>
>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.

AWA comment:  if you the user do this intentionally, then you the user
are at fault for violating the CA's requirements.  (Danger: analogy
ahead)  If you the user give your hardware token and the PIN to it to
another carbon-based life form, and that carbon-based life form signs
something as you, you have likely also vioated the CA's requirements.
Same thing if you let another carbon-based life form log in to your
computer as you.  The CA can't ensure everything, which is why all CAs I
know of make users sign agreements stipulating the user
responsibilities.  If you violate your responsibilities, the CA
disclaims any liability for your actions.

(If the dual certification of the same key happens by
incredibly-unlikely random chance (your key generator generated the same
key pair twice), then there's nothing any system can do about it.)

>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.

AWA comment:  again, if the user does this intentionally to evade the
rules, the fault lies with the user vice the CA.

>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.

AWA comment:  I agree with what Mark Shuttleworth, Steve Kent, and a
couple of others have said:

        - certifying the same key in multiple certificates is a matter of
individual CA policy.  There are valid reasons for doing it.

        - it should not be deprecated in the PKIX documents, although it
wouldn't hurt to mention some of the dangers associated with it.

I would also point out the unwritten assumption here:  we're talking
about signature keys, only.  There are plenty of good reasons for
putting the same key-exchange/key-agreement key in multiple
certificates, and few if any of the authenticity problems that arise
with signature keys.

                Al Arsenault

-- speaking only for myself.  My views do not necessarily represent
those of my employer.