[dvanduzer]

This sounds very much like the directory system I want to build on top of Telehash.

The problem I still see is creating a global directory of Kerberos realms. There still needs to be a sneakernet component for private key distribution. (Maybe that would be a better use of the armored cars I see making regular stops at the banks around town.)

[einhverfr]

Ok, so suppose registering a domain also required registering a public key for the domain name. This would require a change for the root realm. Suppose we were to extend the DNS protocol so that when you do an NS lookup, you get the keys of the NS's as well (might require SRV records or the like in the root tree). You'd need a mechanism to revoke or rotate keys, but that could be done.

From there it should be quite possible to tie public keys to hosts all the way down since you now have a chain of trust. Should be trivial, but the problem is that I don't see how to get the root zone to publish domain keys.

Yes, that replaces CA's with domain registrars, but that is a healthy trade. Since you would get keys (all allowed keys!) all the way down with your query, you wouldn't need to check revocation because you'd know the keys before making the connection.

[dvanduzer]

What you're suggesting doesn't sound too far from DNSSEC as it is currently implemented to me (ignoring adoption rate). I'm questioning the need of an authoritative global naming system at all.

From a user's perspective, "my bank" and "your bank" might be the same thing, or they might be different. When I care about verifying the identity of these things, why not just go to the source? I can do key exchange every time I visit an ATM.

I can imagine using DNS with multiple contextual root namespaces, with the trust anchors being managed by more direct human relationships. This wasn't feasible when the systems were originally designed, but now we can put public keys in jewelry. Keychains on our literal keychain.