Subject: RE: Border directories

From: "Stuart Ross" <[email-masked]>
Date: Fri, 12 May 2000 10:42:28 +0100

Peter, 

I am with Walter on this one, whether LDAP is implemented at the client or
at the server you are going to need it in their somewhere, certificates are
stored in a directory that exposes its data via LDAP and some form of LDAP
interface will be required between the Directory and web server. Yes you can
use HTTP to retrieve certificates but this is not the way the market has
gone, all of the major SMIME clients available on the market today will
retrieve certificates using the LDAP protocol quickly and efficiently, off
course this has the added advantage that all directories should support
LDAP, not all companies that you will communicate with will have tied their
directory to a web server.

Stuart Ross
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 12, 2000 7:06 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Border directories

"Walter Williams" <[email-masked]> 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.

---

From: "Stuart Ross" <[email-masked]>
Date: Fri, 12 May 2000 11:09:25 +0100

Peter,

LDAP stands for LIGHTWEIGHT Directory Access protocol and is by its very
nature efficient with an extremely low footprint, for example we have
available an LDAP COM Automation server that can be used to tie an LDAP
directory to a web server and has a footprint of < 1 MB. This aside if you
had to code HTTP requests into an SMIME client that could do all of the
functions that an LDAP SMIME client can do then I suspect you would find the
HTTP code growing and growing.

Stuart Ross 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 12, 2000 8:23 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Border directories

"Walter Williams" <[email-masked]> 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.

---

From: Philip Hallam-Baker <[email-masked]>
Date: Fri, 12 May 2000 07:22:40 -0700

>>certificates are stored in a directory that exposes its data 
>>via LDAP and some form of LDAP interface will be required 

Dead wrong. Sometimes this is the case but it is neither necessarily
the case or even usually the case.

LDAP is simply an access protocol. There is no necessity that LDAP
be involved AT ALL in the Certificate repository.

Of course to interface to many PKI applications it is usefull to
support LDAP as one option, but the idea that it is impossible to
access data directly through a repository interface to HTTP, FTP
or even Gopher without converting the protocol to LDAP and back 
is simply incorrect.

>>we have available an LDAP COM Automation server that can be used 
>>to tie an LDAP directory to a web server and has a footprint of 
>> < 1 MB.

Yeah, LIGHTWEIGHT!

Try fitting that on a Palm VII! How about a smartcard?

I don't know quite how we got into this argument. I am certainly not
trying to dis LDAP, far from it, I was very involved in the VeriSign
LDAP strategy.

All I am trying to say is that the LDAP protocol did not close forever
the question of where certificates are to reside and the access protocols
by which they are to be retrieved. If companies cannot be persuaded to
deploy border directories that talk LDAP we can try them on HTTP. If
they won't take HTTP we can invent something else altogether.

		Phill

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 13 May 2000 05:22:53 (NZST)

"Walter Williams" <[email-masked]> writes:

>Lets kill this thread as it is getting us no where. 

I agree, any attempt at further debate seems pointless.  However, I'm willing 
to extend the following olive branch: I you can give me a 10-line RFC 1823-
compliant C program to fetch certificates from an LDAP directory as per your
previous message, then I'm prepared to admit that everything I've said is 
wrong and everything you've said (that all MTA's support LDAP and none of them
apparently support TCP/IP (which is what's required to do an HTTP GET), 
necessitating the use of an external web browser to fetch certs, etc etc) is 
right.  Deal?

(Incidentally, to the person who claimed that their <1MB LDAP client is
 "lightweight", you may have a future working for Oracle's marketing division,
 since their <1MB client is frequently criticised as being unnecessarily
 bloated and heavyweight.  I'd also recommend contacting the editors of the
 Oxford English Dictionary so they can correct their definition of 
 "lightweight", perhaps US dictionaries define this word differently than our 
 ones do).

Peter (exits, shaking head in disbelief).

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 13 May 2000 05:36:15 (NZST)

"David P. Kemp" <[email-masked]> 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.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 13 May 2000 05:43:42 (NZST)

Colin Robbins <[email-masked]> writes:

>If anyone is interested in the technical reasons why a RDBMS is bad news for
>directory performance, then there is a white paper " Use of OODB Technology
>for Directories" written by an independent expert on our web site
>(http://www.nexor.com/info/papers.htm) that describes these problems in
>detail.

And OpenDirectory claim the exact opposite on their site :-).  I'm actually
surprised Alan Lloyd hasn't chimed in with his perspective on LDAP yet.

Peter.

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 23 May 2000 10:26:31 -0400 (EDT)

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
everyone:
 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.

Dave

> From: [email-masked] (Peter Gutmann)
> Date: Sat, 13 May 2000 05:36:15 (NZST)
>
>   ...
>