[OT] New keyserver
jbglaw at lug-owl.de
Tue Sep 17 10:07:02 CEST 2002
I know this is a bit offtopic, so feel free to flame me off:-)
Meeting Werner (and others) in Borgholzhausen/Germany, we talked about
the current key servers (mainly original pksd one...). Seems there's
some need to have a new one, doing better key handling (merging seems to
be not that perfect in these days:-( and allowing some new features
(searching for long keyid of for fingerprint, which the pksd folks
currently are getting workarounds for).
Later on, we discussed the topic in the pub we met in. We've got some
nice ideas on implementing a new keyserver, but I'd before like to get
some feedback on this, mainly to some questions:
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.
2. I thought about multicast (instead of emails) for replication, but
this idea is in quite early stage...
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?
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%
*Please* comment on this!
Jan-Benedict Glaw . jbglaw at lug-owl.de . +49-172-7608481
-- New APT-Proxy written in shell script --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20020917/53647461/attachment.bin
More information about the Gnupg-devel