[openssl-users] 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
<https://groups.google.com/forum/#%21topic/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 <https://www.libressl.org/>
already/meanwhile has something in this direction:

  * libtls <https://man.openbsd.org/?query=tls_init>: 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170905/70881f28/attachment.html>