[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Help with internal processing of add



At 10:13 PM 10/16/00 +0200, Shaun Savage wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> At 02:40 AM 10/16/00 +0200, Shaun Savage wrote:
>> >I have read the archives, the big issue is using pgpSDK whell I an using
>> >gnupg code base.
>> 
>> The big issue was/is architecture.  Which SDK you use only matters
>> if you plan to contribute code.
>I plan to submit all code to the openldap project!

Then be sure to read <http://www.openldap.org/devel/contributing.html>.

>> 
>> >I an new to the guts of openldap, where is the best place to start to
>> >make a subset of slapd for pgp using gnupg code?
>> 
>> I suggest reviewing the previous work in this area.  There
>> should be references to patches against 1.1 somewhere in the
>> archives of this list or -bugs or on the ITS pages.
>> 
>> I would really like to see someone design schema to hold PGP
>> keys in general purpose LDAP directory....
>
>
>I have a schema that works but the security of PGP lies in the fact the
>packet is sent as one object and to get the information from it it needs
>to be decoded and verified.

The directory server should just be repository for PGP keys.  The
schema should be modeled after the schema used to hold X.509 and
SMIME keys.  The only PGP specific smarts the directory server
should have is knowledge of the PGP key syntax and matching rules.
I would suggest defining an auxiliary object class (pGPSecurityObject)
which allowed one attribute type (pGPPublicKey) to be added to any
entry.  This attribute type would be of syntax pgpPublicKeySynax
with an appropriate equallity matching rule.  I suggest then defining
a number of extensible matching rules to allow match by id, e-mail,
etc..   This provides the ability for clients to add/delete keys from
the directory as well as the ability for clients to locate keys within
the directory.

However, the directory does not provides key management or key
authority functionality.  These functions should be preformed
by an appropriate authorized client.   PGP clients needing to
update a key (such as when signing a key), should talk to
a PGP key authority which in turn would update the directory
as needed.  Note that the PGP client could use information in
the directory to locate the PGP key authority.

The current (NAI) PGP keyserver design combined the functions of the
key authority and directory service which, IMO, is not terribly
smart.  It hinders implementation of proper security and disallows
the use of general-purpose directory services.

>I hope I have check all the archives but did not see any patches

'pgp;keyserver'... in the first listed message:
  http://www.openldap.org/lists/openldap-devel/199901/msg00022.html
  Windows NT version of pgp backend implemented as SLAPD server you can
  get on http://rednest.rosinter.ru/apps/pgpldapnt.zip

(and poking about on that site, I found:
  http://rednest.rosinter.ru/pgp_ldap_server.htm)

I concur with Kurt Spanier reply:
http://www.openldap.org/lists/openldap-devel/199901/msg00026.html