OpenLDAP schema to store OpenPGP keys?

[David Shaw]

On Tue, Feb 21, 2006 at 12:21:42AM +0100, Walter Haidinger wrote:
> On Mon, 20 Feb 2006, David Shaw wrote:
> 
> > > TLS too? How to tell GnuPG to use TLS over port 389 (ldap://)?
> > 
> > Try for TLS, and do nothing if TLS can't start:
> >   keyserver-options tls=try
> > 
> > Try for TLS, and print a warning if TLS can't start:
> >   keyserver-options tls=warn
> > 
> > Try for TLS, and fail if TLS can't start:
> >   keyserver-options tls=require
> > 
> > If you want to use a particular certificate file:
> >   keyserver-options ca-cert-file=/path/to/the/file
> > 
> > If you don't want to check the certificate chain (default is to check
> > it):
> >   keyserver-options no-check-cert
> > 
> > (Incidentally, the new keyserver handlers in 1.4.3 can do SSL and TLS
> > for HTTP and FTP as well).
> 
> I'm still using 1.4.2 and the man page doesn't list any tls
> keyserver options. I guess I need to upgrade...

LDAP had TLS support back in 1.3.5.  HTTP and FTP just got TLS support
in 1.4.3.  At one point, I started documenting the new options and
stopped because the man page would be enormous.  At some point, I'll
probably make a "gpgkeys" man page so as to not grow the main "gpg"
page too much.

> >From the amount of traffic about LDAP on the mailing-list, I should
> have known this is bleeding edge anyways.
> 
> > > gpgkeys: error adding key 5802B67C to keyserver: Strong(er)
> > > authentication required
> > 
> > You could probably use a "allow update_anon" in slapd.conf.
> 
> Yes, definitely! ;-)
> 
> > > Also, will --passphrase-fd read the password for LDAP login?
> > 
> > No.  There isn't really a strong notion of authentication for
> > keyservers beyond IP restriction in the server at the moment.  In
> > fact, the current LDAP code doesn't explicitly bind at all.  The
> > assumption is that any server we're likely to run into is V3 (or that
> > odd NAI semi-LDAP keyserver that's not really used any longer), and
> > doesn't need a bind.
> 
> I see. As update_anon is a global options, this really calls for
> a dedicated OpenLDAP keyserver.
> 
> This might be acceptable in a closed environment, but how can you 
> operate a public LDAP keyserver having such an open configuration?
> That is, how do you prevent someone from deleting/modifying keys
> arbitrarily?

I don't know that LDAP is a good *public* keyserver as things stand.
By its nature, even if some sort of authentication was added, the
server would only carry keys that were explicitly submitted to it.
Most other keyservers synchronize with their peers automatically to
carry a global keyring.

A LDAP keyserver would be useful as a company keyserver where people
inside the company IP range or an administrator can add keys, and the
rest of the world can just read.  The PGP Universal product
automatically looks for keys to encrypt to at
ldap://keys.thedomain.com, so that fits nicely with this method.
Somewhere on my todo list is to do something similar to tie in with
the automatic key fetch features coming in 1.4.3.

Anyway, that is (more or less) how I was expecting LDAP to be used.  I
never added LDAP auth because I wasn't sure exactly what was needed,
and didn't want to implement it without some clear use case.

What is it that you're trying to set up?

David