[OT] New keyserver

[Bernd Eckenfels]

On Tue, Sep 17, 2002 at 09:08:28AM +0200, Jan-Benedict Glaw wrote:
> 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.

well, you can also just use only the database. There are nearly no
key-related functions you need to do. If you receive a new key you check out
the key from DB to temp file, work on it and commit the changes. No need to
eept that key file around.

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

multicast deos not work very well over internet to distinct servers,
especially if you want to minimice the setup. All sites in between would
have to be multicast enabled. And I dont see a need for that, it is not that
high traffic.

What you could do is to use a newsnet newsgroup for broadcasting the
changes, though.

> 3. What about the protocol?

I would at least support LDAP in Addition. Should be not much work to
interface open ldap to an database.

> 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 dont see the need for it, but yet again, it does not harm. On the other
hand, there are quite a few alternatives out there. A new Key server is
especially interesting if it can be bundled with the upcoming aegypten tools
in commercial usage for PKI.

Greetings
Bernd