keyserver

[David Shaw]

On Mon, Nov 06, 2006 at 09:13:30PM -0700, Joseph Oreste Bruni wrote:
> 
> On Nov 6, 2006, at 1:14 PM, David Shaw wrote:
> 
> >If you are not planning to sync with the outside world, then may I
> >suggest using LDAP?
> 
> 
> I considered the use of LDAP since I just recently built an OpenLDAP  
> server for us to use for centralized user authentication and it would  
> fit right in. But, from what I understand about using LDAP as a  
> keyserver, one would lack the key-data merging capability since LDAP  
> servers don't know about OpenPGP-specific data.
> 
> When GnuPG submits key data to an LDAP server, does it perform  
> merging (read-modify-write) or does it just submit the local copy of  
> the key, overwriting the previous key?

LDAP overwrites.  SKS or PKS merges.  It's an interesting question
which behavior is better, but (as in many things) the answer comes
down to the behavior that is "better" is the one that you like
more. :)

Personally, I think that LDAP is better for key populations that have
a distinct boundary: a company, for example.  In a company, key
merging isn't really that useful or desirable, as generally there
isn't much back-and-forth key signing.  Rather, the company signs each
key with the authoritative company key.

Since you already have a running LDAP setup, it seems like an obvious
solution to use it rather than have to maintain a whole second server
(with backups, etc).

LDAP has another side benefit if you choose to make it visible outside
the company: people who use PGP will automatically find keys for your
employees and encrypt their mail.  When encrypting to
user at example.com, PGP universal looks for ldap://keys.example.com and
asks it for the user at example.com key.  Put "auto-key-locate ldap" in
your gpg.conf, and GnuPG will do the same.

> I was able to get PKS to compile on Linux and it works. My problem  
> was initially with trying to build on OS X since the db2 configure  
> script is so old that it doesn't recognize Darwin. I pulled the pks- 
> current code which uses the DB4.1 database and got it working on  
> Linux. But it doesn't support some of the more recent OpenPGP  
> features (attributes). (I'm not sure that that is a show-stopper,  
> though.)

I wouldn't use PKS at this point.  It is unmaintained code, and has
many known bugs.  It is simply not an option any longer.

> SKS seems good but the use of yet another oddball language (ocaml) is  
> annoying and I ran into problems with it trying to compile on SuSE  
> Linux -- I'll bring those issues up on the SKS list if anyone there  
> is still participating.

SKS has a good user population on their list.  They can very likely
help you.

> I noticed, David, that your name is one of the contributers to the  
> PKS project. I was hoping that the GnuPG project might "adopt" the  
> idea of a keyserver and run with it, keeping it up to date. Has the  
> idea of public keyservers run out of steam?

My involvement with PKS was really that of desperation.  PKS was the
main and only keyserver software for years, and worked great.  As
OpenPGP grew, though, the keyserver wasn't really grown to match, and
so had serious key-mangling problems with the the more modern OpenPGP
features.  I couldn't persuade many people to stop running it and move
to SKS, so I got involved long enough to fix the worst of the bugs.
The current state of PKS is that it still doesn't work with modern
keys, but at least it doesn't destroy them any longer.

The SKS developer (Yaron Minsky) has done an excellent job with SKS,
and virtually all the public keyservers run SKS these days.

David