Re: PGP Backend design/implementation

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Alex wrote:
> First of all - pgp backend was designed with one main target - accept and
> process calls from PGP GUI by PGP Inc. All information about those calls was
> obtained by reverse engineering of PGP 5.5.x freeware source code and
> digging in ldap://certserver.pgp.com . All PGP-related procedures in pgp
> backend was written using PGP SDK from PGP Inc.

I will need to review the NAI licensing terms.  At first glance, it doesn't
look good.  It appears that we cannot distribute any code designed to use
the PGPsdk (even if we don't distributed the SDK itself).  Before any
changes are integrated, this will have to adequately resolved.

BTW, I guess you didn't read the "You may not reverse engineer, decompile,
disassemble or otherwise translate the Toolkit Software..." clause on the
license.

> Entries:

Anybody working on a rfc-draft for storing PGP keys in an LDAP directory?
I think it would be wise to have one, even if it's "informational" and only
documents existing practices.


> Search is usual ldap search request except for one thing:

What's the actual search filter?  What attributes are requested?

> All Add requests from PGP client comes with dn: "pgpcertid=virtual".

Is this the bindDN or the DN being added?

> There are two significant attributes of incoming entries:
> PGPKey - contain ASCII armored PGP key for storing on server, and
> PGPRequest - contain PGP-signed request to server.
> It can be only one attribute per incoming entry - PGPkey or PGPRequest.

Yiks!  I think I know the answer the my previous question.

> PGPRequest may contain one of 3 possible requests: delete, disable and add.
> The add request is implemented in pgpkeys, but never used for unknown reason
> (may be a simple bug in parsing errors from ldap_add).

> Implementation.

Basically, you have implemented a internal gateway (in side of slapd) between
PGP keyserver protocol (which runs on top of LDAP) our backend API.  I would
think it would be better to implement an external gateway that would accept
PGP keyserver operations (on top of LDAP) and translate them into direct
LDAP operations that would be relayed to normal LDAP server.

	    PGP key protocol      LDAP
	client -------- gateway ------- slapd
	         LDAP

This would also keep PGPsdk code out of slapd...

Of course, you could implement this gateway using slapd. (Don' be confused
yet)  That is, have a slapd "pgp" backend that translated the calls into
LDAP operations that were passed over the wire to another (or same) LDAP
server.  That is, instead of having the pgp_backend make ldbm_back API
calls it would make ldap API calls to another (or same server) server.

Of course, this wouldn't keep the PGPsdk code out of slapd.

> pgp backend implemented over SLAPD LDBM backend.

I'd prefer to keep backends independent from each other.  I would
prefer a pgp backend implementation that could be used with any
of the existing (or future) backends.

> PGP SDK is available for free from PGP corporate homepage
> http://www.pgpi.com and is free for all non-commercial projects.

s/is free for all non-commercial projects/is available for restricted non-commericial use/

Kurt