The OpenSSL Management Committee (OMC) and the OpenSSL Technical Committee (OTC) are glad to announce the seventh alpha release of OpenSSL 3.0.

Disclaimers

As any alpha release, the code is still experimental and things can still change before the feature and API freeze planned for the beta release. We are still in the process of reaching feature completeness, and polishing and improving the code, while fixing the issues that we consider blocking for beta.

We have been talking about the development of the next major release of OpenSSL for a while, and you can read more about it in previous blog posts and read more about the planned changes in our design document.

For more details on upgrading to OpenSSL 3.0 from previous versions, as well as known issues and the status of current development, we collected specific notes on the OpenSSL wiki. We strongly encourage consulting (and contributing to) this wiki entry, also to discover the most important changes in the upcoming OpenSSL 3.0 and how they might affect you and the code you maintain.

Why alpha7? / Where is beta1?

Let’s start by addressing the elephant in the room: according to our current release schedule we are long overdue a beta1 release, yet this post is about alpha7, which is four versions after what we originally envisioned for the alpha development stage.

The reality of things is that, at the moment, we are still not ready to transition into the next development stage, because of the high bar that the OpenSSL Release Strategy sets for this transition: I will talk more about this after the next section, as the discussions on this and related topics took definitely the lion’s share of the virtual face-to-face meetings.

For now let’s focus on what is in this release, rather than what is not yet there.

It has been quite some time…

The alpha7 release comes 10 weeks after alpha6, and this post is over 16 weeks since the last one I wrote about an alpha release: many things have happened since then, and I won’t even attempt to summarize all of them in this blog post.

For the lovers of statistics, let’s ask git how many things changed since alpha6: 651 commits from 258 PRs, 1374 files changed, with 76630 insertions and 71205 deletions. To put these numbers in perspective, since the alpha1 release, back on April 29th, up to alpha6, I count 766 commits from 363 PRs. Clearly, it was time to release a new alpha!

I will talk about the upcoming releases in the next section, and, as I mentioned, I will not even try to summarize all the things that became part of the codebase since alpha6: I rather intend to flesh out this section talking about three things I am personally excited about and that I hope can whet your appetites, enticing you to download and try out this new release and give us your feedback.

OSSL_ENCODER / OSSL_DECODER

In alpha6 they were known respectively as OSSL_SERIALIZER and OSSL_DESERIALIZER, but definitely the rename is not the only thing that changed about them!

Several PRs have been merged to make this new API flexible enough to let built-in and external OpenSSL Providers handle encoding/decoding of cryptographic objects to several formats.

Sidenote: In the rest of this post I’ll use capitalized “Provider” to clearly refer to the new OpenSSL Provider concept, illustrated in the 3.0 design document.

As a researcher I am very excited about the potential that these changes, together with the rest of the architecture redesign around Providers, will allow to study and deploy new algorithms, transparently for the whole software ecosystem built on top of OpenSSL 3.0.

KEM

As part of the requirements for the upcoming FIPS validation, we had to include support for RSASVE, RSA Secret-Value Encapsulation, from SP800-56Br2. While, technically, it may not qualify as a full-fledged Key Encapsulation Method (KEM), depending on the definition used and the expected cryptographic properties, its usage pattern from an API point of view fits the KEM API nicely and intuitively. This led to the decision of modeling a dedicated OSSL_OP_KEM operation that allows Providers to implement asymmetric KEM algorithms and make them available to applications via the API functions EVP_PKEY_encapsulate() and EVP_PKEY_decapsulate().

This means for example that, in the context of the ongoing NIST Post-Quantum Cryptography (PQC) Standardization Process, it is now possible for OpenSSL 3.0 Provider authors to provide KEM implementations without complicated workarounds (ab)using the public key encryption and key derivation APIs to make these primitives available to applications and without having to fork libcrypto to provide a custom API for these operations.

Fully Pluggable TLSv1.3 KEM

Building on the previous topic, and on top of the Fully Pluggable TLSv1.3 Key Exchnage announced as one of the big changes in alpha4, the existing functionality has been extended to allow Providers to plug-in custom TLSv1.3 groups modeled after the KEM scheme, rather than the typical Diffie-Hellman-like key exchange scheme (for brevity, I’ll refer with KEX to the latter kind).

One of the things possible with the new capability is for OpenSSL Providers to aid in testing the deployment of PQC or hybrid KEMs in TLSv1.3, while staying fully compatible with RFC8446, but doing so completely transparently for the software ecosystem built on top of libssl, and without having to fork the OpenSSL codebase.

It’s a great tool for the experts participating in the PQC standardization efforts, and ultimately for all users, even the ones not using OpenSSL, as I expect it will have a positive impact on the standardization effort even just by making it easier to test real world deployments of these algorithms for anyone.

Virtual face-to-face meetings, and the things to come

At the end of September, the OTC and the Committers finally managed to organize Virtual Face-to-Face meetings. We had the opportunity of discussing many things, show off our lockdown beards and hair, and in general discuss and harmonize our collective understanding of the requirements to finally reach the point in which we are ready to transition into the next stage of the development cycle of OpenSSL 3.0: the ever-shifting release of OpenSSL 3.0 beta1!

The longest (and most heated) discussions revolved around the definition of “beta” under the OpenSSL Release Strategy, and its implications in categorizing some of the remaining tasks between things that need to be done before beta, and things that can be done during the beta stage. According to the OpenSSL Release Strategy as issued by the OMC

• an alpha release means:
  • Not (necessarily) feature complete
  • Not necessarily all new APIs in place yet
• a beta release means:
  • Feature complete/Feature freeze
  • Bug fixes only

Starting from these, and with feedback from the larger Committers base, the OTC has since worked on a technical document to determine the tasks we still need to accomplish before the beta readiness check and on a checklist to ensure all the goals required for a beta release are accomplished, to then let the OMC approve the transition into the next stage of development towards OpenSSL 3.0.0. The first document has been finalized and approved, and we are using the GitHub milestone for 3.0.0 beta1 to share the progress towards this goal. The second document, the “beta readiness checklist”, is still a draft under OTC discussion, and the OTC decided to hold weekly OTC online meetings until beta1 release, to finalize these last details and timely steer development towards the completion of the remaining tasks.

Another important item that was discussed is the recommendation for the OMC to release the alpha7 release this post is all about, and adopt a 3-weekly schedule of alpha releases until the release of beta1: the recommendation has been ratified by the OMC with a vote that was closed this Tuesday.

While talking about releases, both within the OTC and the Committers meetings, we discussed how, for our Long Term Support (LTS) releases (that, like any other release, by our Release Strategy, are eligible to receive bug and security fixes only), it might be advisable to also plan “LTS+” releases, in lock-step with the parent LTS release, that would exceptionally allow the inclusion of some new features:

• support for additional platforms
• performance improvements.

The proposal to amend the Release Strategy was recently published, and is currently under consideration by the OMC. If it is accepted, it would be possible to revisit some OTC decision that prevented the merge of PRs to add platform support in the 1.1.1 branch, for example S390x backports, and schedule LTS+ releases alongside the future 1.1.1 releases. While regular releases would keep serving those users that require the extreme level of stability of our current policies, the addition of LTS+ releases would serve users and distributions that would welcome these specific classes of new features. In many cases it would benefit all users alike, because a considerable part of our Contributors working for distributions currently has to invest resources in maintaining such backport patches independently for their users. Once this effort is merged upstream, their maintenance workload would be reduced and “deduplicated”, allowing them to focus on other areas of the project and on novel contributions.

This is not an official announcement to report all the minutes of the meetings, so I’ll cut this section here: the members of the OpenSSL Project are well and very busy, giving their best to deliver a quality major release as soon as possible. For those interested in a more detailed account of the latest OTC activities, I remind you that the OTC strives for openness and transparency, so most of the discussions or the votes following the discussions are available on the openssl-project mailing list.

Last, but not least: Our Community

I like to conclude these posts with what I believe is the main message: the OpenSSL Project is what it is today thanks to its community of users. A large part of all the improvements so far has been possible thanks to the feedback and help from the community that is assisting during the alpha development stage. So we wish once more to reiterate our thanks for all the feedback and the contributions from the users and developers that are testing the pre-release versions of OpenSSL, which are vital to the development process of the next release.

We are always keen to see oldtimers and newcomers alike proposing issues, fixes and contributions, not only in the form of code, but also for manpages and wiki documentation. At this point, it is particularly important to also make sure that the documentation for the new architecture, for the new features, and for the new deprecations and their replacements is available, complete, up-to-date and sufficiently clear for external users. We prioritize GitHub issues and pull requests as the favourite channel for contributing to the OpenSSL 3.0 project, but any form of interaction, including on the openssl-users mailing list, is always welcome.

The feedback from the community, and your involvement in testing external applications and ENGINEs against the next version of OpenSSL and improving the documentation is crucial to the continued quality of the OpenSSL Project.