> In the new era key owners have to proof their identity. Practically > speaking key servers accept only keys belonging to the strong set. > (At least in first step.)
Who says the next technology needs to be key servers? That seems like an assumption worth challenging. I'm not throwing this out as a completed idea. About twelve years ago I looked into something that could be used as a replacement keyserver technology; it went as far as me preparing a grant proposal to look into it further. Unfortunately, I no longer have the paper. :( Working off half-remembered memories: ===== Joke was the "Jabber-oriented key exchanger". The idea was to have an XMPP bot which could remember key submissions, respond to queries, and send notifications. Alice might start by telling Joke, "I control key 0xDEADBEEF, which I've enclosed in this message." Joke would send back a 128-bit base-64 random challenge for Alice to sign and send back. If Alice did, her public key would get entered into a database with indexes of both Alice's JabberID (JID), the key's fingerprint, the last time Alice connected, and so on. Alice could of course put additional user IDs on the key, and Joke was free to store as many or as few of them as it wished or apply whatever standards were necessary. Bob would then send a message to Joke. "When al...@example.org updates her cert, please send the update to this JID." So when later on Alice updates her key and sends it on to Joke, not only does Joke update its record in its database but it also informs b...@example.com about the change. When Bob's Jabber agent receives the message, it updates Bob's local keystore. Presto: we've solved the problem of ensuring key updates are distributed in a timely fashion (which SKS never solved, nor even attempted to). If a user doesn't connect to Joke for three years, the user's account (and keys) are deleted; this helps prevent cruft from building up on the servers. Joke servers can be kept in sync without resorting to special-case technology. Distributed database replication is a pretty well-established discipline. Two Joke servers with MySQL backends? Pretty easy. What this would destroy is *untrusted* federation. In a distributed MySQL database, nodes need to be able to trust that others aren't malicious. Federated Joke is possible, but requires trust between instances -- but that's manageable, really. I think you could imagine a federation of university-sponsored Joke servers that would have local points-of-presence on almost every continent. ===== Don't get me wrong: this is nowhere near a ready-for-implementation idea. (It was once upon a time, but once upon a time was a long time ago, and this outline is all I remember off the top of my head.) But it should hopefully go to show you that we don't *have* to repeat the architecture of the SKS network. We can do things differently. Any discussion about an SKS replacement that doesn't start from a completely blank sheet is, IMO, starting off wrong. _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
