Re: SASL, TLS and SSLv3

[patl@phoenix.volant.org]

> > Forgive me if this is not the place for this question, but I am trying
> > to find out at what stage the work is at to implement SASL and TLS/SSLv3
> > into OpenLDAP.
> > 
> > If someone is already working on this aspect then I'd be more than keen
> > to lend my assistance; if it's been done already, thewn I'd appreciate
> > pointers to where I can find it.
>
> As a non-US citizen (a.k.a. a potential terrorist according to the US
> gov.), I am not sure if I could still download the software if it has
> encryption support. I don't really mind lying about whether I am in the
> US or not, but I guess somebody owning some server would be doing
> illegal things if he allows me to download.
> 
> It seems a good idea to me to resolve any legal issues before
> incorporating encryption into openldap. Otherwise openldap wouldn't be
> open anymore.

It is my understanding that SASL is not an issue since it involves
only authentication, not encryption.

As to the TSL/SSLv3 support, ideally, it would be developed and
distributed from a source outside the US; in the same way that
various other open source strong-encryption packages are handled.

Note also that it is not necessary to actually include the encryption
code itself - the TLS/SSLv3 support could be a build-time option which
depends upon the presence of SSLeay; which should be obtained and
installed separately.  (This probably still falls under the US export
restrictions; but it does simplify things a bit.)

There are a few things that could be done to the architecture of
the base non-restricted server code which would make it easier to
integrate additional capabilities.  For example, it could be designed
to make it easy to integrate external code to provide additional
'verbs' to the protocol.  (Either standard optional commands that
aren't supported in the base distribution or experimental commands
that may someday be proposed as extensions.)

The I/O system could also be designed to make it easy to dynamically
re-direct the open protocol stream to another channel or insert
additional transport level operations.  Or, a separate I/O library
could be designed with an abstracted API such that the main body
of the code would never directly call an OS or libc-provided I/O
function for the protocol stream.  If it also provides an abstract
method of passing in optional authentication information at any
point, the TLS/SSLv3 support could consist of a replacement for that
library, along with the higher-level recognition of the authentication
request.

These would be useful design features which extend the flexability of
the package without -explicitly- supporting encryption; so they should
not cause export problems.



-Pat