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

"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 UTC