[OT] New keyserver

[Adrian 'Dagurashibanipal' von Bidder]

On Tue, 2002-09-17 at 09:08, Jan-Benedict Glaw wrote:
> Hi!
> 
> I know this is a bit offtopic, so feel free to flame me off:-)

You may want to include pgp-keyserver-folk in the discussion, where this
is more on-topic. Leave this to you, though.

> 1. I've read the theses behind the current pksd. On this basis, we
> thought about using gnupg as the working backend. Gpg shall work with a
> high number of keyring files (one keyring file per short KeyID), stored
> in a number of (sub)directories. We'll additionally need a traditional
> database to implement the search features.

You've read Bernds comments on this.

> 2. I thought about multicast (instead of emails) for replication, but
> this idea is in quite early stage...

Has been tried before, there are papers out by Michael Baumer and Marcel
Waldvogel. I suggest reading them. I'll start some thesis work on
keyserver synchronisation early in October, I'll discuss this on the
pgp-keyserver-folk mailing list, so perhaps you'll want to stay around
there.

> 3. What about the protocol? HKP seems to be quite simple (even the email
> interface could be build up with some shell scripts if we'd like to be
> compatible...). However, HKP seems to have some shortcomings (esp.
> handling of long KeyID), so the main question would be: Shall we
> implement a "new" transmission protocol (read: basically HKP plus some
> extensions), which would need to also be implemented in gnupg and other
> HKP-enabled software), or shall we simply stick at current HKP, silently
> also accepting fingerprints and long KeyIDs for GETs / searches?

I think HKP is not too bad - it's simple, you can also use a webbrowser,
it's widely supported.
 
> 4. Is a new keyserver really what folks around would like to see? Is
> anybody more like "It's my baby, go away and do something else?" Or
> should we take current pksd and send patches as long as it's not 100%
> what's needed?

I'm no keyserver operator, and I'm not attached to pksd in any way. But
as it's the most used keyserver I'll do my work on that one, with 90%
probability.
 - as I've said, it's widespread
 - It's improving. A 0.9.5 release will be announced shortly, with a
   0.9.6 probably following soon with improved key merging.
 - there are already too many other keyservers around (NOTE: I don't
   think having multiple keyserver implementations is bad. But I do
   think that multiple unfinished/half-finished/unsupported
   implementations are bad):
    - cks (cryptnet) - development seems quite slowed down.
    - opks on sourceforge (but nothing going on afaics)
    - sks on sourceforge (newly registered)
    - the java keyserver used in Waldvogel's synchronisation work.
      Dunno if this one is available, though.
    - the veridis OpenKeyServer (keyserver.net) - this one is not open 
      at all, though
    - the discontinued by the NAI - will this one be resurrected by the
      new PGP, Inc.? Or will they create a new one?

Summary: If you're going to pull it through and create a keyserver that
is better than pksd (especially from the maintenance and reliability
point of view, too), ok. But If you're not sure you can do that, I'd
advise you help with one of the existing keyserver projects.

(Note that I'm nowhere experienced enough to go on telling you what you
should do. It's just what I'm thinking.)

cheers
-- vbi

-- 
secure email with gpg                           http://fortytwo.ch/gpg

NOTICE: subkey signature! request key 92082481 from keyserver.kjsl.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 325 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020917/a98f98e9/attachment.bin