I understand clearly about chains of authority and about the lack of trust transitivity. What makes a DNS delegation of naming zone authority into a trust transitivity vehicle. Why should I trust VeriSign to vouch for my reasons to trust you? When you turn out to have a bogus CERT, after I have trusted you, and I go to VERISIGN seeking redress for trusting them and their breach of my trust, what do they offer me other than the simple statement that "Go away! You do not have a contract with us!" "Our contract is only with the CERT holder!" "And we have disclaimed all liability to him as well." And when I go to ICANN for redress, because they supposedly vouched for their delegated authority to run a DNS Zone, they say: "Sorry, this has nothing to do with us!" "We are not a party to any liability here!" "We only deal with DNS Zones, and do not Vouch for the data contained there-in, because we do not verify it in delegated zones!" So, what is it about DNS delegations that give you reason to inform this list that trust is transitive in the DNS? I see nothing in any part of this combined DNS and CA set up that offers transitivity of trust (of any kind), that was not already there (outside of the DNS zone data assertions) before DNS and the CA were somehow informally lined up by some kind of IETF (3rd party without direct participation) protocol declaration, which in no way bears any liability to any party relying in the DNS/CA information structures. The last time I saw any trust transitivity, it was in the SPOOK industry, where subordinates agree in contracts (sometimes verbal) to trust their handlers. that is, they overtly agreed to make trust transitive between themselves, even if it might cause their death. Apparently, the agent is paid to assume the risks. Now, where in the DNS does anyone assume that kind of liability? Thus, I want someone to explain why trust is transitive in the DNS/CA combination of Domain Naming Authority trees naming authorities and CA CERT issuers. Quite frankly, I find myself with little or no trust in any of the current PKI certs, except for my use of them in SSL/TSL connections which is one case where they work to provide a trusted channel between two parties, but do not do anything to induce trust between those parties. Any trust must derive from other channels of information flow. Remember that self assertion of trust is not reliable. \ Remember "Trust Me!" jokes! Tell me, why do you laugh when the car salesman says "Trust Me!". Now, please explain, with more than brief hand waving, how trust is transitive in your vouching for the transitivity of trust in a DNS/PKI marriage? What liability do you assume if I trust your advice? Enjoy;-)...\Stef At 9:47 AM -0400 6/13/02, Stephen Kent wrote: >At 10:42 PM -0700 6/12/02, Einar Stefferud wrote: >>May I suggest that someone do a little work on proving the trust is >>transitive, as that is what this is really all about, and if it >>turns out that trust in not transitive, then what was the point? >> >>Maybe if you ask Google about trust transitivity, you all might >>learn something;-)... >> >>Cheers..Stef >> >>PS: I trimmed the address list to just IETF;-)...\s >> > >Stef, > >Trust generally is not transitive, but cert chains are not about >transitive trust. The DNS is a hierarchy with clear lines of >authority for name spaces. A PKI modeled on the DNS would parallel >the existing hierarchy and merely codify the relationships expressed >by it in the form of public key certs. > >Steve