Oooooh Keyservers! Fun topic. I have a lot of seperate thoughts on this, none of which relate to the massive leak of social graph information ;)
First off, I think Trevor started off by pointing out the most common situation one uses a keyserver for: I have an email address, and I want to get the key associated to that address. I start with [email protected], not 'Bob Jones' which is a much harder problem. Email addresses are unique and that greatly simplifies things. (Like Trevor said) example.com is authoritative for that email, so anything that shows that [whatever] is a key for bob, coming from example.com, is trustworthy for _most_ definitions of 'trustworthy'. [Implement Me] And since there happens to be a global PKI heirarchy, why can't I stick a DNSSEC chain into my OpenPGP signature, and let people validate my key that way? Likewise, email-based verification systems (like some sort of auto-responder) put a slightly different spin on this by asserting that someone who can receive and send email at this email address serts this key. That's also trustworthy for _most_ definitions of trustworthy. But auto-responders require infrastructure, let's outsource this - the PGP Global Directory, Bruce's Nyms, and Keybase.io. They all verify that a key corresponds to an email, and if you trust the certifier OR you trust the user-to-provider and provider-to-provider link encryption that's good enough. If you don't trust certifier A, you need a certifier you do trust both technically (e.g. Google) and ideologically (e.g. the EFF, ACLU, or just Trevor Perrin) or you need a collective of certifiers you do trust thus-wise, as well as not to collaborate or hack each other. That's more or less Nyms, I think. How those certifiers communicate their certification is infrastructure. And it could work with our existing infrastructure. If they agreed with me :-p https://github.com/keybase/keybase-issues/issues/900 [Implement Me] Someone should go take Keybase.io's code, and modify it to sign keys and publish to the Web of Trust if that's they keyowner's desire. On 18 August 2014 02:09, Trevor Perrin <[email protected]> wrote: > * Query a "central authority" where everyone registers their public > key. To mitigate availability and monopoly risk there could be > several such authorities, and users just have to register with one. > But multiple authorities increases the risk of "misissuance", and > mitigating that risk is difficult. A central authority can't act maliciously if it doesn't act with any intelligence or verification at all. And thus we have the SKS keyservers. > But there's still a coordination problem - what if Bob registers his > key someplace, and Alice checks somewhere else? It's unclear how this > would play out at scale - fragment into islands? centralize around one > authority? What we have is a network of linked keyservers who replicate each other. They're all interconnected for the benefit and disadvantage. > Or maybe keyservers could be made more trustworthy via auditing. If > keyservers support lookup over Tor then it's hard for them to deliver > targeted wrong answers. Keyservers could also support "transparency" > similar to CT, e.g. periodically snapshot their directory so that > 3rd-party monitors can fetch the delta of new/deleted entries. These > monitors could notify Bob if his key changes, and send Alice a root > hash that she uses to check that keyserver responses have been > published [1]. [Implement Me] One can very easily make CT for keyservers today, by running a keyserver, adding to the SKS pool, and then adding a function on _top_ of it to publish things in a CT-style way. Or blockchain. (AIUI) The idea of using the blockchain is more-or-less the same as EFF's Sovereign Keys: first come first serve to an identifier (like 'greg') and that maps to a key. Its strength is its weakness: it's irrevocable. With Nyms/Keybase, I can't revoke a PGP key I lose my key & revocation certificate for, but I can make a new key that can be certified by some authority(ies), and my old key loses its certification. In namecoin, would I not need a new identifier? And since we're starting with an email address, a new identifier is waaaaaaay more painful. And, since we start with an email address, you'd want your identifier in namecoin to be your email address, which you either leave open to landgrab (terrible idea) or you need _some sort of email certifier that operates outside the blockchain_. Sovereign Keys made an attempt to be namecoin for companies (not just crypto-anarchists debating mesh communication fabrics). It piled on the hacks to do so, and still wasn't feasible. And that's not even counting the fact that to 'run this securely' I need a copy of the blockchain. I've been really impressed by the effort you've put into DNSChain, Greg, and I may have gotten some details wrong - but I'm still not sold on its feasibly. -tom _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
