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

Indeed, this disucssion has wandered into areas with nothing to do
with XMLDSIG.  In my initial post, I was just trying to show the
fallacy in the theory that because a certificate has a signature in it
and an XML digital signature can have a KeyInfo in it and a KeyInfo
can have a certificate in it, that trying to use XMLDSIG for an XML
certificate necessarily leades to an infinite regress.  Since the
original question was asked with X.509ish references, I answer it that
way, but no certificates or KeyInfo at all are required by XMLDSIG,
let alone X.509ish certificates or KeyInfo.

Although I have my own opinions on the topic, I don't plan to give
them here and see no purpose to further discussion of these naming
questions on this list.

Thanks,
Donald, co-chair

From:  "Peter Lipp" <Peter.Lipp@iaik.at>
Resent-Date:  Thu, 11 May 2000 03:31:55 -0400 (EDT)
Resent-Message-Id:  <200005110731.DAA24638@www19.w3.org>
To:  "Carl Ellison" <cme@jf.intel.com>, <w3c-ietf-xmldsig@w3.org>
Date:  Thu, 11 May 2000 09:31:17 +0200
Message-ID:  <NDBBLDEHJKOODMJCNBNCCEJDDMAA.Peter.Lipp@iaik.at>
In-Reply-To:  <3.0.3.32.20000510155951.00ad9a70@ibeam.jf.intel.com>

>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 Friday, 12 May 2000 00:49:24 UTC