OpenLDAP schema to store OpenPGP keys?

David Shaw dshaw at
Tue Feb 21 19:08:24 CET 2006

On Tue, Feb 21, 2006 at 01:15:08AM +0100, Walter Haidinger wrote:
> On Mon, 20 Feb 2006, David Shaw wrote:
> > 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.
> Well, at least some hints that tls support exists at all would have
> been useful! ;-)  (*)

It's in the NEWS file for 2004-02-26, but it's true there wasn't any
way to know how to turn it on without reading the source...

> > 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. 
> That eliminates tcp-wrapping. You'd have to grant write access by 
> using the peername statement in the access <who> field, right? 

Yes.  Something like peername.ip= to specify
the "inside the company" range for those who can write.

> > 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.
> Well, how about the following for a different usage scenario:
> It would be nice if all users could submit their keys, readable by 
> all but delete only their own submitted keys. Thus, no dedicated 
> administrator for key management would be required since the LDAP 
> server itself doesn't require much administration after setup.

The problem here is remote authentication.  Each user would need some
way to authenticate to the LDAP server to give them the delete
ability.  LDAP can do this, of course, and GPG doesn't care one way or
the other, but how would you handle password distribution for each


More information about the Gnupg-users mailing list