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.
https://www.openssl.org/blog/blog/2020/10/20/OpenSSL3.0Alpha7/
