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 17:22:58 UTC