LDAP support w/ PGP 8.0 & iPlanet Directory Server

[David Shaw]

On Fri, Jan 10, 2003 at 03:19:01AM +0000, William Korb wrote:
> We recently purchased PGP 8.0 for our PC users, but would like to use 
> GnuPG 1.2.1 for our various Unix flavors (Solaris, Irix, Linux, AIX, 
> etc.). Because we already maintained a corporate LDAP infrastructure, we 
> decided that the most appropriate approach (i.e., the easiest to support) 
> would be to use our LDAP servers as our internal keyservers rather than 
> deploying the keyserver that came with PGP 8.0.
> 
> Herein lies the problem: PGP Corp. supplied the schema necessary to 
> support PGP keys storage in our iPlanet 5.1 LDAP server, but GnuPG 
> doesn't work with it (--send-keys reports "gpgkeys: error adding key 
> XXXXXXXX to keyserver: Object class violation") and --search-keys reports 
> "gpg: keyserver internal error"). However, the PGP 8.0 PC client works 
> just fine with our LDAP server.

The current GnuPG LDAP plugin is based on a black box reverse
engineering of the NAI (who owned PGP back then) LDAP keyserver.  I
was able to figure out enough by sending queries from the openldap
client tools to make a start, and then discovered
http://www.openldap.org/lists/openldap-devel/199901/msg00022.html,
which filled in the missing pieces.

Since there is no published standard for this, I'm not surprised that
the pgp.com folks changed it to add new features.  It's nice that they
support doing LDAP without the special keyserver now.  I believe
that's a new thing.

> I already figured out why the searches were failing: the algorithm used 
> to find the pgpBaseKeySpaceDN in gpg simply looks for a cn=PGPServerInfo 
> entry in the base scope, whereas the PGP client queries the base scope 
> for all of the servers namingContexts then looks for a cn=PGPServerInfo 
> entry relative to each namingContext. I was able to create the code that 
> does that fairly easily.

Interesting.  I don't think the LDAP keyserver supports this, so I
suspect the client is trying it, and falling back if it doesn't
succeed.

> The object class violation seems to be a result of gpgkeys_ldap trying to 
> send a simple entry as pgpCertid=virtual,ou=pgpKeySpace,o=cray.com, but 
> this simple entry is missing some required attributes. I also don't 
> understand the significance of the "pgpCertid=virtual" keyid - the keys 
> that the PGP client inserts have the full 16 digit keys.

The LDAP keyserver learns the pgpCertid by parsing the key itself, so
the client doesn't have to tell it.  This is good, actually, as if the
client was broken/compromised it could lie.  In the case of a
non-keyserver LDAP server, of course, the client has to be trusted to
send a valid pgpCertid.

> So what I'm asking is this: is anyone actively working on getting the 
> LDAP plug-in to work in this type of environment?

Not actively, but that doesn't mean "no".  I'd be interested in
updating gpgkeys_ldap to work in your environment, but I don't want to
raise any legal issues.  I am reluctant to look at the PGP 8 source
for obvious reasons.

David

-- 
   David Shaw  |  dshaw at jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson