Re: The new (GPG/PGP)-LDAP interface

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

Mostly food for thought...

At 01:04 AM 10/19/00 +0200, Shaun Savage wrote:
>here is my idea on getting LDAP interface into GPG
>
>
>             /------------ LDAP ------------ Directory    (search path)
>    gpgClient


Let's look at this half first.

I assume any entry in the DIT can have a gpg key associated
with it simply by augmented the entry through use of an auxiliary
object class that allows addition of an attribute which contains
the gpg key.

Also note that besides gpgKeys, information regarding the
key management service can be stored in the directory.  For
example:

  dn: uid=joe,dc=example,dc=net
  objectClass: inetOrgPerson
  objectClass: gpgKeyObject
  uid: joe
  cn: joe blow
  sn: blow
  userCertificate: <joe's X.500 cert>
  SMIMECertificate: <joe's SMIME cert>
  gpgKey: <key>
  gpgKeyManager: gpg://gpg.example.net/params

detailing the client known who (and how) it should talk to
request an update of the gpgkey.  This means that two entries
within the same naming context could have two different key
managers.  It also allows one entry to have multiple key
managers.  The use of a URI provides a great deal of flexibility
and helps decouple the directory from key management.


>    gpgClient
>             \- LDAP -tmpdir-ldap- KeyMaintAPP - LDAP      (key
>maintance path)


>The tmpdir is not seperate from 'the directory' but just a different
>objectclass

This would open the directory to significant DoS attack.
First, adds are expensive.  Two, an add of an entry requires
locking the entry's parent.  This means that a client can
easy deny access to other clients INCLUDING the keyMaintAPP.

Depending on the access control model of the directory server
holding this container, it also may not be possible to key
one client from deleting or modifying the input of other clients.

I believe it best if the gpgClient talk directly to the
gpgKeyManager.  

 gpgClient <------------==---------ldap---> The
           <----> gpgKeyManager <--ldap--->   Directory

The gpgKeyManager can choose from whom it accepts
connections from and which updates it cares to honor and then
updates the key stored in the directory (which it must, of course,
be authorized to do).

As the gpgClient / gpgKeyManager need to communicate, a protocol
needs to be prescribed.  This protocol could be LDAP-based, but
likely there are operational semantics which LDAP doesn't provide.
My point here is that gpgManager is not a general purpose LDAP
server.  One would just be using LDAP as a framework to construct
another application protocol, the PGP Key Update Protocol.
If designed well, one could implement this on-top of of an
LDAP server as 1) a custom backend and/or 2) a set of extended
operations.

>DN: seq=xxxx,id=XXXXXXXXXXXXXXXX,$(basekeymaint)
>objectclass: keyMaint
>function:  NEWKEY|ADDSIG|DISABL|ENABLE|REVOKE|.....
>pgpData: The normal pgp key packet
>the ID in the DN is the signature ID of the pgp/gpg armor encoded packet

You could implement something like this using a custom backend.
The backend would only implement ADD and then would use contact
the directory server hosting the particular key using LDAP.  You
would not have to muck with the server's frontend.

I think use of an object to represent an operation is artificial.
An alternative is to use an extended operation.

pgpKeyOperation ::= SEQUENCE {
  id    INTEGER,
  uri   URI OPTIONAL,
  fn    ENUMERATED { NEWKEY, ADDSIG, ... },
  data  pgpData
}

Note that the URI is optional.  If provided, it tells the
keyManager where to find the key.  If not provided, then the
keyManager just use a priori knowledge to locate the key.
Use of a URI means that keys don't need necessarily have to
be stored in an LDAP directory... more decoupling.

As extended operations are independent of backend, this
avoid many of the architectural limitations of the ADD
approach.

Kurt