Update from the OpenSSL F2F — Brno, May 2026
Here are some highlights from Brno. I have attached my own thoughts as well (not a single AI generated word) :-) I will post as a reply.
The short version: post-quantum is now the default path, release signing has been rebuilt on hardware security modules, official Windows binaries are coming, a 6–24 month public roadmap is being opened for community input — and each committee member is asked to carry one short brief to their community this week and bring follow-ups back.
Five days in Brno brought the OpenSSL Project, the OpenSSL Corporation, and collaborators from across the ecosystem around one table, and the result is one of the most consequential updates the communities have had in years. The through-line is simple: get ready for the post-quantum world, harden every link of the supply chain, and put the communities — the people who actually run this software — at the centre of the roadmap. Your community will hear about most of this eventually; the opportunity in front of this committee is to be the ones who bring it to them first.
Five days of roadmap, technical, and governance work — Brno, May 2026.
Post-quantum is now the default path — and the transition is designed to be gentle. ML-DSA (FIPS 204) has been added to the default signature set, with ML-KEM (FIPS 203) key exchange available as opt-in — nothing is switched on behind anyone's back. Incremental (streaming) signing moved to a new API in the OpenSSL Library 3.6, and migration guidance will follow before anyone is expected to move. The measured results so far are reassuring: side-channel testing found no ML-KEM timing leakage across Intel, ARM, Power, and S390X. Composite (hybrid) signatures were added to the default provider — deliberately not to TLS — as a bridge for legacy equipment that cannot be updated often, and low-memory implementations are in the works for constrained and embedded devices.
Release integrity has been rebuilt end to end. Signing now runs on two hardware security modules under a published key ceremony and signing policy: an RSA-4096 OpenPGP primary key with yearly-rotated subkeys and published fingerprints, ten-year evidence retention, and EV code-signing for Windows builds in the release pipeline. Looking further out, work has begun on how trust itself is managed — TLS Trust Anchor Identifiers, by which a server presents the smallest certificate that satisfies the handshake, and Merkle Tree Certificates, which build transparency in and shrink post-quantum certificate sizes. Both are open IETF drafts — worth a read for anyone who wants the primary sources.
On Rust: provider choice, not a rewrite. Nothing existing is being abandoned, and there is no forced migration away from C — the provider architecture will simply let applications choose C, Rust, Java, or other implementations underneath. Deliberately, public claims are being held until tested, working code exists; community requirements for any official Rust bindings are being gathered first, so this committee's input arrives before the design hardens, not after.
Getting closer to the people who run the software. Official Windows binaries are coming — MSI and executable installers, separate builds for developers and command-line users, Windows 10 and forward — ending years of reliance on third-party builds; the FIPS module ships in the box but stays off until enabled in config, so nobody's setup changes without their say. Discipline is tightening in parallel: Tier 3 community-supported architectures (Alpha, for example) will be dropped in the next major release, and a firm rule now holds that a change is only carried where the collective can test it, with CPU-specific optimisations validated on real hardware first. The exact Tier 3 list is being confirmed before community announcement — plenty of notice will be given.
Process, AI, and sustainability — the numbers behind it. AI-assisted contributions are welcome where the tool is disclosed and human review confirmed; CLA updates are being prepared. A preliminary analysis of the security mailing list — to be published with its full methodology — found roughly 13% of historical reports appear AI-generated, with the share rising in recent quarters; in response, vulnerability submissions now need a reproducible exploit to be prioritised. The headline compliance figure: a per-module compliance-review approach can cut FIPS certification time by roughly 95% compared with full-box validation. And the roadmap itself is being opened up — a 6–24 month plan assembled in public, seeded with recurring requests (iOS with FIPS, structured logging for Common Criteria, OpenTelemetry) and genuinely shaped by what communities feed in.
Community and academia. A lightweight OpenSSL Academic Network has launched — shared logos, zero financial commitment — and the university contribution model keeps proving itself: roughly 37 student pull requests in the latest course run, around 20 merged. Dedicated community space is booked at Open Source Summit Europe, with further presence planned around a December PKI event in Amsterdam and the April RSA/ICMC window. The Java ecosystem gets its own bridge in OpenSSL Jostle, a provider that brings the OpenSSL Library to Java while keeping the FIPS boundary where it already is.
Jeff Johnson ·Tue 16 Jun 2026 4:46PM
It's always an incredible time to spend with the OpenSSL community at a face-to-face (F2F)! The amount of thought provoking topics as well as the weighty conversations around AI, community engagement, memory safe languages and MTC's (Merkle Tree Certs) certainly proves that OpenSSL and the folks contributing there are serious about the work and their place in the fast paced technological world we live in. Here are a few of my highlights:
Memory Safe - OpenSSL seems to be on a committed journey to providing interfaces (using the provider framework) into memory safe language crypto. This was demonstrated by Mike Ounsworth (RUST) as well as Megan Woods (Java - JOSTLE). Both of these awesome folks were able to demonstrate their work and folks were jumping in with more ideas and constructive criticism (although there wasn't much to criticize frankly). Both Mike and Megan were able to explain in great detail their architecture and design decisions. Even in that tough crowd folks were impressed. Really excited to see this work and hopeful others can jump in and help! BTW, Nikola Tuveri was able to integrate Mike's RUST crypto work into an OpenSSL Provider a day or two later.
OpenSSL PR Resolutions - There were a lot of discussions on how to make OpenSSL PR's both faster as well as easier for contributors (especially new contributors). There is a lot of focus on increasing community contribution, so naturally there is focus on making the contributor experience much better. There were discussions on a PR "Wrangler" as well as component or code ownership and automation as well. There did seem to be a consensus that a PR wrangler should help keep PR's moving. Along these lines, code simplification was also discussed. Among the most popular ideas was the reduction or removal of macros. I expect that this will be explored and the first (next) chance for breaking changes will be OpenSSL5.0.
Academics - Dr. Brumley (RIT) gave an update on changes in applying for various grants, etc. OpenSSL is very committed to the next generation! This can be seen in their commitment to Brno as their home :). Dr. Brumley has a unique insider perspective on academia and I encourage anyone who wants to know more about how academia and industry meet and complement each other to check out anything he has written or any of the talks he has given. Well worth the time!
AI - I got my "AI" in :)..... There is a new CLA (or CCLA for corporations) that anyone who contributes to OpenSSL and uses AI to contribute code to OpenSSL will need to sign. As I understand it, if you don't use any AI tools you will not need to sign the new CLA. Basically, if you use AI to generate and contribute code to OpenSSL you will need to divulge the use of AI as well as the tools used (models, versions, etc). So please be on the lookout for the new CLA to sign.
Composite Signatures - There was a brief discussion on support of composite signatures in OpenSSL. David Hook (Bouncy Castle/BC) explained how there was a very compelling use case for supporting them. Most folks agreed that the use case demonstrated value in composite signatures. More to come here I'd bet.
AI Usage in BC - David Hook demonstrated and explained BC's position and usage of AI. It seems everyone in the room is using AI extensively these days.
JOSTLE - Megan woods gave a deep dive into BC3.0 and performance of JOSTLE which was pretty darn great! Megan noticed some JVM peculiarities as well as discussed some conversations about certifying as a hybrid module. Future work to be sure.
OpenSSL Performance - Work continues here as Neil Horman and Bob Beck are tackling additional performance optimizations. There are several PR's in flight that Neil and Bob are working that should have some significant increased performance in the area of provider locks, etc. Watch out for more here!
Distributions - Jaroslav Reznick, Simo Sorce, and others were in the meetings as gave input into all of these areas. Additionally, Jaroslav was able to give an update on the activities in the distro community. They are meeting at many conferences, etc. If you are part of this community or benefit from it (who doesn't?), then you can rest assured that Jaroslav has you covered and we are in good hands!
International Crypto - There was a brief discussion on how to handle the various country or region specific crypto algorithms. Nothing solid here but the smart folks in the meeting are giving this some thoughtful consideration.
Merkle Tree Certs - This was a fun one! Bob Beck did a deep dive into MTC's and then there was a very passionate discussion on MTC's with Mike Ounsworth. Really fun to listen and learn with these exchanges! Lots of discussions on how to deal with IETF and the real world deployment of MTC's. Definitely something to stay on top of here.
Individual Community - Aditya Koranga gave an update on what he is doing in the individuals community. Aditya is very active at conferences and loves to increase individual contributors by connecting personally. Stop by and see him... he usually has some swag! Aditya is also active in LF PQCA and leads the OQS work. Really great guy!
All-in-all, these F2F meetings are incredibly encouraging! Some of the greatest open source developers, business folks, individuals, etc all together discussing what matters most to the OpenSSL and the world. I cannot put in words how honored I am to even be in the room. Looking forward to the OpenSSL Conference 2026 in Prague!!