> I think that it is an oversimplification to argue that shorter chains > are necessarily less trustworthy than longer ones, and this seems > especially true in this context. indeed, I'd agree. but that's not quite what I said. I said it's a stretch to expect most apps to be able to make use of a long cert chain because of the natural difficulties in trusting so many other parties. the implication I was trying to make was that being able to look up missing certs in a long cert chain was only a weak justification for a cert lookup mechanism, rather than a strong one. it's not as if I'm opposed to a cert lookup mechanism, or that I think it's nearly useless - but I do think we need to be realistic about its limitations. > if one were to create a PKI paralleling the DNS, each CA would > correspond to a component of a DNS name and each of those points is > authoritative for the naming of the entities under it. this is not a > new notion introduced by making a PKI parallel to the DNS, but is an > intrinsic feature of the DNS design. if one chose to create such a > PKI, the CAs would not be trusted third parties in the common sense > of the term. they are precisely the entities that are responsible for > managing their parts of the DNS name space and are implicitly trusted > to do so. right, that doesn't mean they're trustworthy. e.g. but just because the maintainer of (say) COM presumably knows and can authoritatively state that FOO.COM has certain properties, doesn't mean that I am willing to trust this maintainer to not (accidentally or deliberately) return false information about some BAR.COM, or to (accidentally or deliberately) leak keying material with which a rogue other party could claim to make assertions about BAR.COM. actually history would cause me to seriously question the trustworthiness of certain TLD registries even though there is on doubt as to whether they are authoritative for those TLDs. > Those who have argued against a single root in general should note > that there are ways to have multiple entities act in a coordinated > fashion to sign on behalf of a root, which mitigates the security > concerns associated with what might appear to be a single root. But, > that does not diminish the problems noted earlier re increased > traffic for TLD DNS servers, etc. I'm just addressing tyhe security > aspects of a DNS-based PKI. Also even if one were to have a singly > rooted DNS, that does not make it the only game in town, i.e., there > should be lots of other PKIs, each with its own root and serving a > well defined constituency. I don't have an inherent problem with using DNS as part of a means to allow clients to find CERTs that bind properties to DNS names. (I do have some concerns about DNS being the entire mechanism - but the devil is in the details. I'm skeptical that everything can be worked out satisfactorily, but if it can, just using DNS might actually be okay.) OTOH the "single root" (or if you prefer, "distinguished root") is so fundamentally flawed that I would consider it unacceptable for standards-track. Keith