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 _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
