Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

[Robert J. Hansen]

> 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 address@hidden 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 address@hidden 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.