- From: Carl Ellison <cme@jf.intel.com>
- Date: Wed, 10 May 2000 14:14:11 -0700
- To: EKR <ekr@rtfm.com>
- Cc: w3c-ietf-xmldsig@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No, I have not encountered an actual example in practice that meets all of your qualifications. Certificate usage is rare enough today that such examples are not likely to occur at random and any that may have occurred by active attack have not been publicized and probably not even detected. Of course, it is not necessary for the same (issuer,serial) to come from two honest CAs. All you need is for CA1 to issue a CA certificate to some attacker with the DN of CA2. That attacker can then generate any serial number he wishes and pass his rogue certificates off as if they had come from CA2. If something in the protocol forced all serial numbers to be cryptographically long and random (e.g., 160 bits of random number), then we could completely rule out any accidental multiple hit of (issuer,serial) -- but the attacker-CA remains enabled. If, however, the identifier of the issuer were by the hash of the issuer's public key rather than some DN, the attacker-CA scenario above is ruled out as well. ----------- Back to DN collision, on its own....the worst example I have in mind is S/MIME under Microsoft Outlook on Windows 2000. W2K comes with over 100 baked in root keys, according to Barbara Fox (at the last RSA conference). Each of the root keys that is enabled to certify S/MIME users is free to assign names at will. This is an opening for an attacker. --------------- Of course, in the case of Outlook, it's even worse than that. Outlook is user-friendly enough that it doesn't display the certificate's DN to the user (unless the user begs to see it, which we can't count on for security purposees) - -- but rather the common name and, in some cases, an SMTP name that is usually ignored by the human user. I have seen many real world examples of this name collision through Outlook -- enough that it is interfering with our work as a company. ------------ Meanwhile, the general objection remains even there weren't a real example. This is a case of a system design that assumed one thing, valid at the time, but that was not re-engineered when the basic assumption changed. - Carl At 01:05 PM 5/10/00 -0700, EKR wrote: >Carl Ellison <cme@jf.intel.com> writes: >> (issuer,serial number) is from the X.509 world and is one of the ways X.509 >> is broken. >> >> "issuer" is a DN and might identify an issuer, if DN's were from a >> singly-rooted name space, as was the original plan in X.500. DN's are not >> singly-rooted and never will be -- so using a DN as an identifier is broken. >Carl, > >Can you cite any actual real world [0] scenario where two certificates >have had the same issuer/serial and been issued by different issuers? >If not, it's hard to take this objection very seriously. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.0.2 iQA/AwUBORnRIsxqBGb+WvJAEQJ0ywCgmACkVMUoH3pPlZLCarzM+qyr3kgAoJS0 gfaaSsFXbUzKnZt2Zb9h8aW7 =y2kb -----END PGP SIGNATURE----- +--------------------------------------------------------+ |Carl Ellison Intel E: cme@jf.intel.com | |2111 NE 25th Ave M/S JF3-212 T: +1-503-264-2900 | |Hillsboro OR 97124 F: +1-503-264-6225 | |PGP Key ID: 0xFE5AF240 C: +1-503-819-6618 | | 1FDB 2770 08D7 8540 E157 AAB4 CC6A 0466 FE5A F240 | +--------------------------------------------------------+
Received on Wednesday, 10 May 2000 17:14:31 UTC