W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2000

DN is not an identifier (was Re: XML certificate ...)

From: Carl Ellison <cme@jf.intel.com>
Date: Wed, 10 May 2000 14:14:11 -0700
Message-Id: <3.0.3.32.20000510141411.00bcf330@ibeam.jf.intel.com>
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 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:09 GMT