OpenLDAP schema to store OpenPGP keys?

[Walter Haidinger]

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...

>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?

Walter