Introduce a TLS application library - a proposal on the overall OpenSSL code structure

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Introduce a TLS application library - a proposal on the overall OpenSSL code structure

David von Oheimb
Back on 13 May 2016 I had proposed by email to a couple of people including Rich Salz
a third library level (on top of crypto and ssl) with more high-level, application-oriented code.
His response was:
That is a really interesting idea.  Please bring this up on openssl-dev mailing list.

Then I posted that by mistake unfortunately not in the right forum but at:
https://groups.google.com/forum/#!topic/mailing.openssl.dev/FOL2afc3cb8
I quote my post here for convenience:
So far, the OpenSSL code has essentially a three-level structure with a hierarchy of two libraries and a command-line application at the top:

apps/openssl
libssl
libcrypto

In the apps/ directory there is various generally useful code like handling crypto-related files and messages, general TLS client/server and CA functionality, implementing parts of protocols like S/MIME, CRL, and OCSP, and certainly more to come.

While this code serves as a model for using the libraries and it can be used in a limited way by invoking the openssl application binary, it cannot be re-used directly. Other applications that need similar functionality need to copy/re-implement and then maintain portions of that code.

On the other hand, the libraries contain some code that is actually too high-level for them, for instance the minimal HTTP client as part of the crypto library (crypto/ocsp/ocsp_ht.c).

It would be very helpful to introduce a further level in the hierarchy consisting of a more application-oriented library:

apps/openssl
libtlsapps <-- new (with tentative name here)
libssl
libcrypto

Then all more high-level and application support functionality will go there. This would make much of the generally useful code that so far resides in the apps/ folder directly accessible to other
 applications at the programming level, i.e., in the form of a library/API, with all the re-usability advantages that this brings. It would also relieve libcrypto from more application-/high-level topics like HTTP.

This library would also form an ideal condensation point for further high-level uses of TLS that may in the future get integrated with OpenSSL, like CMP and EST implementations.

I recently learned that LibreSSL already/meanwhile has something in this direction:
  • libtls: a new TLS library, designed to make it easier to write foolproof applications
I believe this would be of great benefit also for OpenSSL itself.


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev