OpenTLS : Rationale

OpenSSL is a great package in many ways. It, as well as the predecessor SSLeay, has provided crypto algorithms, PKI routines and the SSL/TLS protocol family, along with a large number of related utility routines for a long time. I believe that the world owes Eric A. Young quite a lot of gratitude for making SSLeay and the OpenSSL team for the continued and still ongoing work on OpenSSL.

[note: the following was written during Christmas 2003]
In the last few years (I'm writing this around Christmas 2003), a few flaws with the design of OpenSSL have become increasingly apparent:

1. All structures are publically defined. This is probably really nice for those that want to understand the inner parts of OpenSSL without having to read the full source. Unfortunately, this also leads to programming where individual structure members are manipulated directly, with all the weird errors that may lead to. Additionally, it becomes impossible to extend or change structures without introducing binary incompatibilities.

   Basically, for different x in 0.9.x, the different versions of OpenSSL are not compatible at a binary level, and usually not at a source level either, because of changes in structures and more.

2. In SSLeay and OpenSSL, it's possible to have parts of the crypto algorithms, as well as other stuff, removed entirely. Of course, that's a good thing to avoid patent infringment and other legal trouble. Unfortunately, this also introduces binary incompatibilities between distributions that only differ in the amount of supported algorithms.

3. OpenSSL is really a package that covers everything it can. However, some programs may only really need the crypto algorithms, and what's worse, other parts of OpenSSL may become dependent on said program.

   There's an example that hasn't occured yet but may any time: Heimdal, the swedish Kerberos 5 implementation, uses OpenSSL's libcrypto to get it's crypto algorithms. OpenSSL's libssl supports authentication with Kerberos 5 tickets, and therefore needs to be linked with a Kerberos 5 implementation. As I write, only MIT KRB5 is supported, but there exist options to build OpenSSL against Heimdal instead. The only question is, which would you build first, OpenSSL or Heimdal?

4. The SSLeay/OpenSSL license has an advertisement clause, which leads to trouble for those who want to use it in a GPLd program.

There are more issues, I just don't remember them right now.

Several things need to happen to resolve all those issues:

1. Create three packages. The choice has already been made, and the three packages have been named NetCrypto, NetPKI and NetTLS. Some time in the future, Heimdal might get it's crypto algorithms from NetCrypto, and NetTLS would be able to use Heimdal to implement authentication with Kerberos 5 tickets.

2. All structures are hidden unless they really need to be public.

3. As much as possible, libraries are built in such a way that they can be easily extended, and if some parts need to vary depending on patent issues, those parts will be implemented as dynamically loadable libraries (i.e. plugins). When an API has been designed, it should be written in stone, as much as possible.

4. A more modern license will be used. For a while, the Academic Free License, version 2.0 was the chosen one, but because there were some unresolved issues with it, I switched to the simple 2-point BSD license.