Re: PGP Backend design/implementation

["Alex Iliynsky" <starder@rosinter.ru>]

Hi there!



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

Nope. i read it. I never decompiled/disassemble the toolkit Software :) I
just look in code and wrote another code that accepts request from sdk
toolkit calls. How "reverse engineering" term can be applyed to source code
distribution?

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

Yep. There is a group that working on draft for storing PGP keys in LDAP
directory. I think, that my method (NAI method to be exact) can be changed
in any time without affecting the client software. Now, the main questions
(for me, not for entire community) is HOW TO implement server itself.

>
>
>> Search is usual ldap search request except for one thing:
>What's the actual search filter?  What attributes are requested?
(|(pgpdisabled=0)(objectclass=*)) [pgpkey]
>
>> All Add requests from PGP client comes with dn: "pgpcertid=virtual".
>Is this the bindDN or the DN being added?
No bind operation at all. There is a piece of code from oldest release,
where PGPLdapOpen uses bind operation.

>
>> 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.
yes. no authorization, except for PGPRequest.

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


Ok. AFAIU - you suggests two possible type of PGP server - PGP Gateway (may
be slapd core based?) and slapd backend with the same functions. Regardless
of it's type - it must be a some kind of ldap proxy - isn't it?


Ok. i'll think about it. Such implementation required redesign in entry
storage structure. Current structure will generate too much overhead because
of parent-child relation in PGPkey storage. Here is another questions - NAI
uses TWO entries to store pgpkey - small pgpuserid and large (relative to
pgpuserid) pgpcertificate. What you think about possible performance hit, if
two entries will be combined together (in search requests)?