Re: Help with internal processing of add

[Shaun Savage <ssavage@infomatec.de>]

So let me see if I understand (in layman terms)
for key modification/addition a ldap add is done to a temp objectclass.
this also sends a trigger to an other application the reads this temp
object class data and does the key managment stuff, then updates the
real data stuff.

searchs are done using the normal ldap search. 

BTW can there be a trigger (of some type) on some event in openldap?

*-----
the issue I see is that ALL pgp ldap changes use the same DN. there will
still have to be a small hack to uniqueize (new word) each add and stick
it into some temp objectclass, then notify the key managment app.

I can get the temp object hack done tonight and start on the key
managment app.  How do I create a trigger event for openldap?

Shaun 




"Kurt D. Zeilenga" wrote:
> 
> At 09:00 PM 10/16/00 +0200, Shaun Savage wrote:
> >I think my ignorance on ldap directory design is showing.  I don't
> >understand what is being said here.  I thought that NAI is using it as a
> >ldap search function.  you can search on name, email by sending a filter
> >on dn of pgpuserid, you can search for key numbers by using
> >pgpcertificate.
> 
> But the NAI (and the schema you attached) schema is designed to
> replace the LDAP "core" schema to create an application specific
> directory.  If you want that, you might as well use an embedded
> database technology and implement an application specific access
> protocol (or abuse an existing one).
> 
> However, I want more.  I want a general purpose directory holding
> entries associated with various objects and a common access
> protocol (and semantics) across all applications using the
> directory.  For objects which have associated public keys, I want
> to store the key as part of the entry.  Then an LDAP-enabled
> client can easily be extended to support the key from the entry
> they already obtained.
> 
> I see little reason why PGP Public Keys should be handled by the
> directory any differenly than any other application specific
> attribute I might to augment my entries with.  Excepting for
> syntax aware matching rules, I see little reason why the
> directory needs to PGP smart.  PGP keys should be handled in
> much the same way as X.509 or SMIME keys.  Yes, the trust models
> are different and there are other management issues, but such
> issues are not for the directory to resolve.  The Directory
> should be used for publishing of keys a long with other information.
> 
> Updating of keys in the directory may have to be delegated
> (as is done for other key forms) to trusted parties (applications).
> This is what I refer to as a key authority.  It's the application
> the directory trusts to update keys.  For example, when userX
> wants to sign userY key, userX likely doesn't have write permission
> to userY's entry.  However, userX can submit the key update to
> the key authority which update keys as authorized.
> 
> Kurt