[Top] [All Lists]

RE: Border directories

2000-05-12 16:31:00
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.


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 ---------\
 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.

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