Peter,
The problem of your model is you presume two things that don't exist:
uniformity in data store behind the directory and uniformity in access
control. LDAP exists, as does DAP (the OSI heavier Directory Access
Protocol which LDAP somewhat replaced) to provide uniformity in data access
when you know nothing about the data store, but you know what you want.
Under your model, you would have to write different HTTP applets for each
different backend. They would need to authenticate with the back end, using
a mechanism which is proprietary. LDAP handles the authentication, makes it
as strong (need a cert to bind) or as week (anonymous bind) as you need, and
returns the same set of data from no matter how it is stored in no matter
what database. LDAP is not all things for all people, but it does allow
email systems to quickly access data regarding people including but not
limited to their public key. It also allows the users to quickly find a
person's email alias and their public key and Use it to create a encrypted
or just signed message.
By the way, I can retrieve a user's certificate and any other relevant data
in about 10 lines of properly written LDAP code in either C, Perl, or Java.
Why you keep on talking about megabytes of code, I don't know. I would
recommend you to read up on the standard and its API. Coding LDAP is as
simple as coding HTTP. Perhaps you are confusing the LDAP Protocol with
SLAPD, the LDAP based Directory. While the directory is indeed megabytes of
code, the API is rather small, the relevant .JAR files for java take up a
cumulative 60 kb or so, I can't imagine the C libraries are any bigger, if
anything I would imagine that they are smaller.
I would recommend that if you feel that what you propose is so superior that
you write up some IETF Drafts and try to productize your ideas. See how
well they sell. If you're right, you'll make a fortune. Lets kill this
thread as it is getting us no where. The initial questions have nothing to
do with the use of LDAP as an API or directory access mechanism, and you
seem to be a little misinformed about what LDAP is and how it is used.
Walt Williams
TSD-Systems
Senior IT Analyst
Genuity
www.genuity.com
Please note: GTE Internetworking is now Genuity.
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Peter
Gutmann
Sent: Friday, May 12, 2000 7:23 AM
To: ietf-smime(_at_)imc(_dot_)org; pbaker(_at_)verisign(_dot_)com;
pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz;
walter(_dot_)williams(_at_)genuity(_dot_)com
Subject: RE: Border directories
"Walter Williams" <walter(_dot_)williams(_at_)genuity(_dot_)com> writes:
And LDAP is already built into the client to do exactly what you
are asking
some one to write code to do. Yes it can be done. Yes it will
be done.
But most are doing this through LDAP for very good reasons.
Keep in mind
that many email clients do not do HTTP, so then you would have a
flow path
of: to create s/mime email, don't create a new email in client,
open browser,
browse to proper link, run query, have email aware http
application you have
to now write create your email. This application should idealy
call your
default email package, but how will it tell Outlook as an
example about the
certificate it just found? I can't see that as a natural flow of work.
Yes, if you are using an web based email service such as
hotmail. No if you
are using a corporate solution.
Just because it's possible to push a pea up a mountain with your
nose doesn't
mean that that's the best way to get it there. Certainly if you
go with this
amazing inverted world view in which 10 lines of code added to an
existing
TCP/IP-aware app is more work than integrating a multimegabyte LDAP client
library with its enormously complex programming interface and config
requirements, then LDAP is simpler and easier than HTTP. In my
world however,
doing it via HTTP from the email client would be the easier
option (although
it's certainly possible to invent arbitrarily awkward scenarios
for HTTP if
your goal is to make LDAP look good in comparison).
Peter.
Walter B Williams.vcf
Description: Vcard