[Top] [All Lists]

RE: Border directories

2000-05-23 07:22:37
I acknowledge that one can shift complexity around in any system,
and that by both eliminating options and shifting processing to
a server, one can make a small client that does just one thing, and
even succeeds in doing it some of the time.

But to eliminate the ESP that Bob referred to (given an email address,
how does the client devine which RDBMS to query for a cert?) one needs
a client that talks not only HTTP or SMTP but also BIND.  That's another
several lines to your 10 line client.  It also assumes that
 1) stands up an HTTP-accessible RDBMS to serve certificates,
   including populating the RDBMS when the directory backend
   is only usable through a directory interface, and
 2) populates SRV records in the DNS to point to the HTTP/RDBMS server.

The alternative, of course, is to talk to the directory directly.  I
couldn't accept the assertion that a "Lightweight" client is 1MB,
so last night I did an experiment of pruning out some unused code
from an OpenLDAP client.  The result is a 54KB executable that can
fetch any LDAP attribute (not just certificates) using any search
criteria (not just email address), including wildcards.
Code mailed on request.

54 KB is within the realm of what could be called Lightweight. With a
few more hours of surgery (which I have no intention of pursuing) it
might get down to half that, or less if the client already includes a
BER library (which it will if it actually uses the certificate for
anything :-).

The best part is that LDAP uses the infrastructure which is already
in place, rather than requiring everyone to stand up Something Else.


From: pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz (Peter Gutmann)
Date: Sat, 13 May 2000 05:36:15 (NZST)


Every RDBMS vendor on the planet either has or is making their database
web-aware (although for security purposes I'd prefer to stick my own stub in
front of it because I don't trust anyone to get things like this right :-).
The interface is incredibly trivial, using a speed-optimised database like
MySQL (which doesn't have a "lightweight" client like, say, Oracle), the 
server stub isn't more than a page or two of code (bind to a socket, read
requests, drop them into a line of SQL, then call mysql_query() and 
mysql_use_result()/fetch_row() and send the result back to the caller.  I'm
sure I could crank it out in a hour or so (although MySQL does have web glue
built in if you want to go that way and use the native capabilities).

Total extra overhead in the client (assuming it already speaks SMTP, which 
one can probably assume for a mail client): One read and one write call.

Total overhead in the server: An accept(), a read, the aforementioned RDBMS
glue code, and a write for the results.

You can even use the standard dictionary definition of lightweight to desribe 
that.  It makes for a very nice, simple "gimme a cert" protocol without the
bloat and overhead of other alternatives.


<Prev in Thread] Current Thread [Next in Thread>