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

Re: Help with internal processing of add

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