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

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

From: Brian M. Thomas <bt0008@sbc.com>
Date: Wed, 10 May 2000 17:04:43 -0500
Message-ID: <056301bfbacb$bf271440$1040c984@bt0008lt.sbc.com>
To: "Carl Ellison" <cme@jf.intel.com>, "Eric Rescorla" <ekr@rtfm.com>
Cc: <w3c-ietf-xmldsig@w3.org>
"Knock, knock..."
"Who's there?"
"Me."
"How do I know it's you?"
"You know me; would I lie?"


-----Original Message-----
From: Eric Rescorla <ekr@rtfm.com>
To: Carl Ellison <cme@jf.intel.com>
Cc: w3c-ietf-xmldsig@w3.org <w3c-ietf-xmldsig@w3.org>
Date: Wednesday, May 10, 2000 4:27 PM
Subject: Re: DN is not an identifier (was Re: XML certificate ...)


>> 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.
>It's hard to see how this situation is any worse than CA1 simply
>issuing false certificates. If you can't trust your CAs, you're lost.
>
>> 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.
>Once again, if you can't trust you're CAs, you're absolutely hosed.
>
>> Meanwhile, the general objection remains even there weren't a real
example.
>Which, apparently there isn't, since none of your examples really
qualifies.
>
>> 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.
>Many systems have such errors but somehow manage to continue to work.
>
>Like it or not, to the extent to which we have a certificate
>infrastructure, it's X.509. That's the kind of certificates that
>systems have and its the kind of certificates that software knows
>how to parse. Before we decide to junk all that, I'd like to be
>fairly sure that it has crippling flaws. Your argument so far
>isn't exactly convincing.
>
>-Ekr
>
>
Received on Wednesday, 10 May 2000 18:06:35 GMT

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