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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 02:23 PM 5/10/00 -0700, Eric Rescorla wrote:
>Once again, if you can't trust you're CAs, you're absolutely hosed.

I'm sorry I let myself go off on that tangent.  As one other correspondent 
(not copying the list) pointed out, a valid chain will validate back to the 
proper root key no matter how the issuer was identified.  My wording for 
that is that if you have no issuer identification at all in a certificate, 
you can take each certificate and try verifying its signature by each public 
key you have.  If the verification works, then you have found the issuer 
public key.  As long as ridiculously weak signature keys aren't allowed (so 
that one certificate might validate by more than one public key), this is 
all you need.  Therefore, the branching to multiple parent certs is not a 
security issue.  It's a design methodology issue.  It is very bad design to 
use something as an identifier when it is not an identifier, even though it 
was going to be an identifier at the time the original design was done.
So, you don't get security problems this way, but you might get false
negatives (a denial-of-service attack).

The places where use of a DN as if it were an identifier creates a security
problem are where this information is being used to make a security decision.
When you have resolved a certificate chain to a DN and then look that DN up
in an ACL (or a human's wet-ware version of an ACL), in order to make a
security decision, you're wide open to attack because of the failure of
the assumption that the DN is a unique and meaningful identifier.
That failure can be exploited even if all CAs are honest and trustworthy.

		------------------

Of course, it is true that if you can't trust your CAs, you're hosed.  
That's also the situation today -- not because the CAs are untrustworthy 
necessarily, but rather because of what applications do with certificates.

The applications we have available to use today are such that if a 
certificate chain validates, then no warning is issued -- and users are such 
that unless warnings are issued, everything is assumed to be OK.  Therefore, 
if the certificate chain validates, users take that to mean that the given 
action is OK (has been authorized).  

This leads to my favorite Matt Blaze quote (from RSA this year): "A 
commercial CA will protect you against anyone whose money it refuses to take."

The CA that issued those certificates might not be one that should be 
empowered to grant any authorization.  When you have W2K with 100+ baked-in 
CA keys, it's a sure bet that not all should be authorized to grant any 
particular access.  To some ways of thinking, none of them should be 
authorized. ..that should be only a local user's or company's CA.

The assumption on the other side of this argument is that a CA never claimed 
to grant authorizations -- only to bind names to keys -- and the users were 
assumed to use those names appropriately.  If the user doesn't use the name 
properly, that's not the CA's fault -- right?  To me, it is the fault of the 
overall system design (including the CA) if we make an unreasonable 
assumption and the system breaks down because of that assumption.  In this 
case, we have three unreasonable assumptions: that a DN is unique, that a 
DN is meaningful to a human being and that the DN will be used properly by 
that human.

- - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQA/AwUBORnpzsxqBGb+WvJAEQKWKwCgt9Bp2nxPIAYNJ4rbH62Pt6fiWv0An33P
b5oeXd2SctpUTzmmxCOXYhNR
=Ag4W
-----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 18:59:54 UTC