LDAP KeyServer Schemas

[alan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guys

Thanks for the feedback so far.

I now have an array of much more informed questions as (i) there is
quite an amount of non-apparent stuff; (ii) some stuff is just plain wrong.

I am using GPG-1.2.2rc1 and OpenLDAP-2.0.21 (sorry my openldap is a bit
old, but I'm tied to python-ldap/Zope with much of this...)

Firstly, with the previously posted schema, new context, and appropriate
anonymous permissions, I manage to get the PGPServerInfo structure out
of the LDAP server, and into gpgkey_ldap.

However, on the gpg --send-keys, it then fails dismally with a 'no
objectClass' error.  I am loath to remove any schema checking from the
LDAP server - so this is a fairly terminal error.

It seems that a banal dn of 'pgpCertid=virtual,...' is being sent with
only a pgpKey field (unless with my tracedump, eyeballing gpgkey_ldap.c
and slapd with max debug I've missed something...).

The prime reason this IS banal is that when one sends consequent
send_key requests, this dn already exists.  There is a possibility of a
strange MOD_ADD going on under this 'existing dn' - but then there would
have to be another objectclass defintion with maybe 'groupofnames'
support for this dn to be meaningful.  I think this is much too
complicated to conjecture from the sources I currently have available.

Since I haven't successfully added a key, I haven't been able to test
any of the extraction methods.

Also, the schema definition is only one side of the story - the
slapd.conf definition of the database is also important.  It would seem
obvious that there should be an index on the pgpKeyId.  It would also
seem that either there should be associated cn/mail attributes to query
upon, or the pgpUserId should be indexed (with possibility of bad
searches confusing text from cn, comment, and email).  However, I
haven't at all figured out how a search string maps to LDAP attributes.

I am interested in participating in this development and really need
some more information to be transparent.  I am surprised that the
current ldap schema that is being developed to is not available.  I have
an IANA number to publish a definitive schema if this would be useful.

It seems to me a trivial application for a standard LDAP server - please
enlighten me as to the details!

Cheers, Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2rc1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+h3DzCfroLk4EZpkRAtqyAKDRuRz8eEzfR139K+5VHl6n5IzVawCfTLpg
lyoSDm6623capn7qhv5RXFM=
=Riu4
-----END PGP SIGNATURE-----