Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

The OpenPGP Email Summit is an annual meeting for those who work on encrypted email and related topics. The tenth installment of this meeting took place in March 2026 and the minutes have now been published. As usual, a wide range of topics were discussed. Highlights included support for post-quantum cryptography (PQC) with multiple actors planning rollouts within this year, a promising new approach for making email signatures ubiquitous with the plan of making OpenPGP signed email a default, a new draft that brings reliable deletion (or "forward secrecy") features to OpenPGP, as well as a plan for transferring ownership of the OpenPGP.org domain.

The summit attendees represented many projects, providers, and other interested parties in the space including Delta Chat, FreePG, Hagrid, Hockeypuck, keys.openpgp.org (KOO), Proton, Ripasso, RNP, Sequoia-PGP, Signstar, Thunderbird, VOA, and others.

Governance and the openpgp.org Domain

Phil Zimmermann is the current owner of the OpenPGP.org domain. He was not at the summit, but he had communicated that he wants to hand off this digital asset to the community; the community would prefer to find a setup that doesn't require any individual to take on personal responsibility. The keys.openpgp.org (KOO) board is one existing governance body that could take over the domain. Its current mandate is narrowly focused on running the keys.openpgp.org keyserver.

It is exploring taking on responsibility for the domain, using the Wau Holland Foundation as a trustee. The foundation is loosely connected with the Chaos Computer Club (CCC) and has been the sponsor of the OpenPGP email summit over the past ten years. Its members are deeply invested in the proliferation of the OpenPGP ecosystem. As a next step, the KOO board has proposed a constitutional change to the voting body.

PQC in OpenPGP

PQC was one of the topics discussed at this summit. Throughout the industry, people are preparing for the eventuality that quantum computers might at some point be able to break the current crop of cryptographic algorithms. In such a scenario, an attacker could even collect today's encrypted messages to decrypt them later, once a sufficiently capable quantum computer is available. PQC algorithms are designed to be unbreakable even by potentially upcoming quantum computers. The IETF draft that specifies PQC support for OpenPGP has completed last call and is awaiting final approval by its authors. Formal ratification as an RFC is expected within the next few months. The format itself has been stable for about a year.

The draft specifies two composite algorithms for encryption, two composite algorithms for digital signatures and three PQC-only algorithms for digital signing. All seven algorithms are usable with the new OpenPGP key format, (specified in RFC 9580), commonly referred to as "v6". In addition, one of the composite encryption algorithms is designated for use with the currently common v4 keys (see below for more).

Proton, a company that provides OpenPGP encrypted mail services, already had a complete implementation of PQC support for its email service at the time of the summit. General availability has since been announced. The core parts of Proton's PQC implementation are available as free software in feature branches of the two OpenPGP libraries that Proton uses and maintains: GopenPGP and OpenPGP.js.

The Delta Chat secure-messaging project has all the building blocks for PQC support in place, and intends to roll it out in production later this year. Thunderbird has experimental support for sending and receiving v4 PQC-encrypted messages. Providing this feature in stable releases will still take some time, though. Thunderbird uses the RNP OpenPGP library; the library's maintainers are working on incorporating a sizeable PQC pull request that was developed as part of a project financed by Germany's Federal Office for Information Security (BSI). The Hockeypuck keyserver has also added support for composite PQC keys in its latest beta release.

PQC encryption for v4 keys

The v6 format supersedes the previous format (referred to as "v4", and specified in RFC 4880) The changes in the v6 key format itself are moderate. The main point of the new key version is that fingerprints for v6 keys use SHA2-256 hashes, while v4 keys use SHA1 hashes as fingerprints. Attacks on the SHA1 hash algorithm have become sufficiently serious that moving on from v4 keys seems to be the prudent long-term strategy.

However, transitioning the ecosystem to a new key version is a longer-term project. As the urgency of protecting communication against possible post-quantum attacks increases, allowing users to seamlessly upgrade their existing v4 keys to enable PQC encryption becomes more of a concern. To serve this need, the PQC draft explicitly designates ML-KEM-768+X25519 composites for use as v4 subkeys. Users can add a post-quantum encryption subkey with this algorithm to an existing v4 key, without requiring their correspondents to support the still nascent v6 key format.

Thunderbird plans to roll out PQC support for v4 keys with additional ML-KEM-768+X25519 encryption subkeys by the end of this year, presupposing an RNP release with support for the format. The availability of PQC in both v4 and v6 formats allows for a more flexible rollout of PQC support, depending on the needs and priorities of different projects. The two current OpenPGP modernization efforts—v6 key support and PQC support—can be tackled separately or in combination.

Since many libraries support the full range of formats, there should usually be a common denominator, even if projects upgrade their support on different timelines.

FreePG and PQC

FreePG is a patched version of GnuPG that is used partially or fully by many of the larger Linux distributions. Its main goal is adherence to the OpenPGP IETF standard to allow users of GnuPG to opt out of the upstream's increasing divergence from the OpenPGP standard. However, FreePG is designed as a temporary stopgap rather than a long-term fork.

Its maintainers clarified that adding support for the IETF PQC draft is non-trivial, and the available resources may be too limited to achieve support for it in FreePG in the short term. The group agreed that FreePG should at least be able to gracefully ignore v4 PQC encryption subkeys, even if it cannot use them. As long as GnuPG upstream doesn't support v6 keys, it's not feasible for FreePG to support any v6 formats, including v6 PQC keys.

Separate from FreePG, Hamming Quasi-Cyclic (HQC), a new post-quantum encryption algorithm, was discussed briefly. There is interest, but also consensus that it's too soon to start specifying use of the algorithm in OpenPGP.

Unobtrusive signatures

Unobtrusive signatures, as described in a new IETF draft, were also discussed this year. The idea was initially brainstormed during the previous (9th) email summit. Existing email signature schemes (which use a multipart/signed structure) are not handled gracefully by all email software. As a result, many users turn signature generation off, to avoid displaying harmless but confusing errors to the recipient.

The goal of unobtrusive signatures is to allow sending software to confidently enable signing by default, without risking complaints to its users from recipients with clients that do not support signatures. Unobtrusive signatures unblock this default because they are silently ignored by software that doesn't support them. Previously, OpenPGP signatures would confuse or even worry some email recipients, causing them to complain to senders. Thus, developers of email software were sometimes reluctant to enable signatures by default, since it could cause complaints from recipients who do not have support for signatures.

The new approach uses a multipart/mixed wrapper with an OpenPGP signature embedded as a header rather than an attachment. This construction allows unobtrusive signatures to fulfill their main goal, which is to never be displayed in a way that confuses recipients. Even legacy clients that do not understand the signature will render the rest of the email as normal, without displaying anything about the signature. On the other hand, clients that support unobtrusive signatures can verify the signature and signal success to the user.

At the time of the summit, an implementation of the scheme was available in development versions of Thunderbird, and has already seen some successful testing by users in the wild. Thunderbird Daily, a rolling release of the mail client that tracks development and includes bleeding-edge features, can already produce and consume unobtrusive signatures, though it currently requires users to enable a hidden preference. Kai Engert from Thunderbird estimates that production of unobtrusive signatures will start becoming the default later this year. Proton plans to implement support for incoming unobtrusive signatures soon as well.

Bart Butler from Proton observed that once both Thunderbird and Proton support unobtrusive signatures, it should be straightforward to bring other clients on board, making this effort one of the highest return-on-investment improvements for signed email.

Autocrypt v2 (AC2): Combining PQC and reliable deletion

Holger Krekel from Delta Chat presented Autocrypt v2 (AC2), a specification that was in part driven by Delta Chat project members (minutes of the discussion). AC2 deals with a separate concern than Autocrypt v1. While v1 handles exchange and update of OpenPGP keys between email peers, AC2 centrally introduces a scheme for clock-based rotation of key material. It doesn't concern itself with bindings between identities and key material.

The AC2 draft's introduction outlines the goals:

It offers defense against store-now-decrypt-later attacks from quantum computers through post-quantum hybrid cryptography. It also enables reliable deletion ("Forward Secrecy") of received messages even when adversaries capture encrypted messages in transit and later compromise the user's message archive and secret keys.

That is, if all participants in a chat don't retain decrypted message plaintext, and regularly destroy old private key material (as the scheme prescribes), then old plaintext becomes fundamentally unrecoverable over time by correspondents or attackers. Autocrypt v2 combines this clock-based key-rotation scheme with PQC encryption.

The key-rotation scheme combines a permanent fallback key with a short-lived encryption subkey (for example, valid for ten days). Communication usually relies only on the short-lived key, but can fall back to the long-lived encryption key in edge cases (for example when two peers have not communicated for a longer time). Senders regularly distribute new subkeys. Recipients merge their peers' encryption subkeys locally, while removing obsolete subkeys as they expire.

There was some discussion about the inherent tradeoffs of this scheme. Reliable deletion means that old messages are not readable anymore by anyone. This property is in tension with typical expectations of email, where messages are often stored indefinitely (e.g. on IMAP servers), and users expect to be able to decrypt and read them in the future. By contrast, if a client deletes its decryption subkey, but the ciphertext persists on a server, the user loses access to their old mail. Possible mitigations—re-encrypting messages to a long-term key, storing session keys separately—trade away some of the forward secrecy guarantee.

There was no conclusion, but it's clear that different use cases exist, and forward secrecy is not a good fit for all of them. The AC2 framework can be applied to realize different outcomes by choosing between the different tradeoffs.

Another question that was raised, but not resolved, was whether Autocrypt v2 certificates should be explicitly marked as such. This might be helpful as a hint, for example, to prompt keyservers to prune expired encryption subkeys rather than accumulating them indefinitely.

HKPv2: Modernized general key-server API

The OpenPGP ecosystem currently has three somewhat ad-hoc technologies for certificate distribution. The Hockeypuck servers implement the "Legacy HTTP Keyserver Protocol" (HKPv1). The Hagrid server at keys.openpgp.org uses the custom Verifying Key Server (VKS) API, but also implements a subset of HKPv1. A third scheme, named Web Key Directory (WKD) allows static serving of OpenPGP key material for lookup by email address.

HKPv2, which was discussed at this summit, is a proposal that aims to cover all use cases of these three key-distribution systems with one unified API. It is designed to cover both verifying and non-verifying key-server use cases, and also for serving certificates directly from a set of plain static files (akin to WKD, without requiring any specialized software on the server). This draft has arrived at a relatively stable state and is specifically designed to facilitate the ecosystem's shift from classic v4 keys to v6 and/or PQC keys.

The 2025 keys.openpgp.org board has discussed and worked on the HKPv2 draft, and arrived at the decision that keys.openpgp.org will implement support for the protocol (as soon as the limited development resources allow).

The Hockeypuck key-server software has since added preliminary support for the API. The 2025 keys.openpgp.org board also decided for the project to implement the API, but there is no clear timeline for this effort yet. The HKPv2 draft is currently waiting for adoption by the IETF OpenPGP working group.

Key migration and the key replacement draft

Upgrading from OpenPGP v4 keys to v6 keys, and/or PQC keys, was discussed briefly. In the near future, many OpenPGP users are going to consider upgrading from their current v4 keys to new v6 and/or PQC keys. Such key migrations have historically been a mostly manual process in OpenPGP: key holders created new keys, and issued various certifications between their certificates to mark them as linked. Their correspondents needed to manually determine if the new certificates were reliably linked to trusted previous certificates, and accept the new certificates in their OpenPGP software.

The key replacement draft defines a mechanism that formalizes key transitions, and enables software to handle them transparently, on behalf of users (both for key holders and for their correspondents).

Given good support in applications, this mechanism will make key transitions close to seamless—while at the same time being rigorously protected by cryptographic statements from the key holder. This draft was adopted by the OpenPGP working group, and has been textually mostly stable for a number of months, but is still waiting for implementations before entering "last call".

Looking Ahead

A number of concrete next steps were announced at this summit. Thunderbird and Proton announced plans to ship unobtrusive signatures in upcoming releases of their respective software. Thunderbird is also planning to add complete v4 PQC support in an upcoming stable release. Proton confirmed its intention to roll out v6 PQC support to all of its users, after successful internal testing. Delta Chat is planning to roll out v6 PQC and "reliable deletion" via Autocrypt v2 to its users in 2026. The support for HKPv2 in the Hockeypuck keyserver software will be finalized and rolled out to the relevant keyservers this year, alongside support for PQC keys. It was also confirmed that keys.openpgp.org intends to add HKPv2 support to the Hagrid keyserver, but no clear roadmap for implementation has been put forth yet.

A number of longer-term efforts remain under active development. Many participants said that this year's summit was extremely productive. The OpenPGP ecosystem is looking diverse and vibrant; many long-term projects are currently coming to fruition. In particular, the finalization of PQC support in OpenPGP (which was kicked off in 2021 by Germany's BSI), and the multitude of imminent related rollouts, appear to be timely.

A followup interim meeting is scheduled for October 21, 2026; the next in-person summit tentatively for the end of April 2027. Anyone interested in participating can subscribe to the IETF Open Specification for Pretty Good Privacy group's mailing list. Participation is open to anyone.

Note: you can avoid this step in the future by logging into your LWN account.