Three brief technical points:
1. At least with respect to Novell's 8th generation directory, NDS, LDAP is
an access protocol that is supported natively by the directory engine.
So you can use NDAP (Novell's variant of the standard X.500 DAP, for
reasons I won't go into), or you can use the not particularly light-weight,
but arguably light-functionality LDAP interface. It makes no difference to us,
as we support both.
2. NDS is based on a Novell-proprietary "arbitrarily-structured data base",
NOT on an RDBMS. That's why the directory is as small as it is, and yet
has the scalability and performance it does. Although other Novell applications
can use the same underlying database technology (the GroupWise message
server does), they do not share the same database.
So David's assumptions are incorrect, at least with respect to one major
DSA provider. That's not to say that you couldn't publish certificates in a
web server and access them via http, independent of any directory. You could.
You could even synchronize the web server and the directory using our
DirXML capability, if you chose to. But you don't access the underlying
database while it may be undergoing synchronization, replication, backup,
repair, etc., etc., under the control of the higher level application, about
which the other application would know nothing.
3. The much more significant point, unless I've overlooked a
"directoryCapabilities" attribute in the S/MIME spec somewhere , is that
both the originating and receiving application are completely clueless
as to where to find either the directory itself, or the http provider.
Once I use mental telephathy to figure out the DSN name of the server
where the user chose to publish his certificates(s), then I can start rummaging
around though either LDAP or HTTP, trying to guess the schema, and which
index to use to locate that user's certificate.
Those are the points we ought to be focussing on, IMHO.
Bob
Peter Gutmann <pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz> 05/13/00
05:36AM >>>
"David P. Kemp" <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil> writes:
(Phew, back to technical discussions at last)...
Aren't you leaving out both a block and an assumption in the HTTP path?
The assumptions are that the DSA not only is based on an RDBMS but that the
RDBMS interface is exposed to other applications. If these assumptions are
true, the paths would be more like:
client -> LDAP client -> LDAP server ---------\
\
RDBMS
/
client -> HTTP GET -> Apache w/mod_perl & DBI-/
Why would you need to run Apache? The model I was using was:
client -> socket read -> server stub -> RDBMS
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.
Peter.