Last I checked, as the information is stored in a directory to begin with,
LDAP is not a middleman, but is doing things rather directly. Doing an HTTP
Get presumes that this will find it in a Directory. Probably you will find
that your HTTP needs a perl cgi which actually talks LDAP behind the scenes.
Don't forget HTTP is not a Directory Access Protocol, LDAP is, and the certs
are stored in a Directory.
Walt
-----Original Message-----
From: pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz
[mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz]
Sent: Friday, May 12, 2000 6:06 AM
To: ietf-smime(_at_)imc(_dot_)org; pbaker(_at_)verisign(_dot_)com;
walter(_dot_)williams(_at_)genuity(_dot_)com
Subject: RE: Border directories
"Walter Williams" <walter(_dot_)williams(_at_)genuity(_dot_)com> writes:
The major problem I see with using HTML is the need for the
email client to
retrieve the public key. They are designed to do this over
LDAP. Not all
email clients are integrated with a HTML reader. The LDAP query is not
significant overhead and checks for public key data very transparently.
Uhh... anything which can talk TCP/IP can do an HTML GET in about 10 lines
of code and about 5 minutes of work. When used as a
cert-grabbing mechanism,
I'd estimate that LDAP has about four orders of magnitude more
overhead (in
terms of code complexity) than HTML (probably more like five or six, going
by the size of LDAP binaries). I'm not sure what the performance
overhead is
but I can imagine that'd also be vastly higher.
Given that in the end all you're doing is a 'SELECT cert WHERE
name = foo',
doing it via an HTTP GET makes much more sense than rewriting it into an
LDAP query in the client, communicating it via an enormously complex and
heavyweight protocol to the server, having the server rewrite it
back into
its original form so it can do something useful with it, and then
reversing
the process to return the result. Sure, you get to say "We're
using LDAP",
but wouldn't it make more sense to cut out the middleman and do things
directly?
Peter.