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

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

From: Peter Lipp <Peter.Lipp@iaik.at>
Date: Thu, 11 May 2000 09:31:17 +0200
To: "Carl Ellison" <cme@jf.intel.com>, <w3c-ietf-xmldsig@w3.org>
Message-ID: <NDBBLDEHJKOODMJCNBNCCEJDDMAA.Peter.Lipp@iaik.at>
While I don't see any specific relation to xmldsig......

> 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.
You can, even if you have an issuer identification in there, and actually
the DN's are a hint only  which certs to try building the path to the root -
you should check the signatures anyway, shouldn't you? You can also use the
Subject/AuthorityKeyIdentifiers too, or so. So I don't see a problem here.

> 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.
Then you have a) designed that system badly because you still could have
used the (hash of the) public key as an entry to the ACL and b) must
apparently have given trust to two ca's using identical DN's without
looking.

> When you have W2K with  100+ baked-in CA keys,
This should be forbidden by law. Or so. Honestly. And is worse than the
misbehaviour of applications, which is also a problem.

> 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.
But that's not the DN's fault. You can have the same problems with any
systems. Agreed, if the user is forced to give the keys his own names, and
if he is forced to think about it, great. But I really doubt that this is a
solution you can sell to the enduser. Software-providers should take that
load of the end-user as much as possible - in a company policies can take
that role, and trust-settings can be precofigured in a meaningful way by
knowledgabel users. But the "home user" is always left helpless.
Preinstalling 100 CA's makes the system useable for this user, but makes
inclusion of public key technoligy (somewhat) meaningless....

Peter




Received on Thursday, 11 May 2000 03:31:44 GMT

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