Post-Quantum OpenPGP & S/MIME: Sovereign Email Security Guide

Post-quantum OpenPGP and S/MIME represent the convergence of two long-established email security standards with a new generation of cryptographic algorithms designed to remain secure against both classical and quantum adversaries. For European public-sector bodies, financial institutions, healthcare providers and legal firms, this convergence is not an abstract future concern: the harvest-now-decrypt-later threat means that email encrypted today with RSA or elliptic-curve Diffie-Hellman can already be collected and stored by sophisticated adversaries, waiting for the quantum hardware that will eventually break it.

The IETF Draft That Defines the Migration Path

IETF draft-ietf-openpgp-pqc is the specification that formally extends the OpenPGP message format to carry post-quantum algorithm identifiers. It defines composite public-key and signature packets that combine a classical algorithm (ECDH or ECDSA) with a post-quantum counterpart, specifically ML-KEM (standardised as FIPS 203) for key encapsulation and ML-DSA (FIPS 204) for digital signatures. A secondary construction accommodates SLH-DSA (FIPS 205, formerly known as SPHINCS+) for signing use cases that demand conservative, hash-only security assumptions.

The draft has progressed through the IETF OpenPGP working group and, as of late 2024, was in active last-call review. The working group’s published timeline anticipates publication as an RFC in 2025, contingent on resolution of outstanding technical comments on algorithm agility and composite key encoding. Sovereign deployers should track the IETF Datatracker at datatracker.ietf.org directly rather than waiting for distribution-level packaging, because the final RFC text governs which algorithm OIDs are canonical.

The sovereign deployment path implied by the draft is straightforward in principle: a Nextcloud-based email infrastructure or a self-hosted mail server running Postfix with OpenPGP gateway plugins issues composite key pairs to users. Internal correspondents exchange post-quantum-protected email immediately, while the gateway falls back to classical algorithms for external recipients who have not yet migrated. This hybrid approach is explicitly anticipated by the draft’s composite construction.

Integrating ML-KEM and ML-DSA into S/MIME Certificate Profiles

S/MIME v4, defined in RFC 8551, specifies how certificates and cryptographic algorithms are used for email signing and encryption within the X.509 PKI framework. Integrating ML-KEM and ML-DSA into this framework requires changes at three layers: the CA software, the certificate profile, and the mail client.

At the CA layer, the software must support FIPS 203 and FIPS 204 key generation and must be capable of embedding the corresponding algorithm OIDs in the SubjectPublicKeyInfo field of issued certificates. For organisations running internal PKI software such as EJBCA or OpenCA, this means upgrading to a version that has implemented the new OIDs and testing issuance workflows before rolling out to end users. The CA’s own signing key and certificate chain should also be migrated to ML-DSA or a composite classical/PQC algorithm so that the chain of trust is quantum-resistant end to end.

At the certificate profile level, the S/MIME baseline requirements published by the CA/Browser Forum will eventually mandate or permit PQC algorithms, but regulated organisations with internal PKIs do not need to wait for that mandate. They can issue ML-DSA end-entity certificates for signing and ML-KEM key-encapsulation certificates for encryption under their own policy, provided the policy document is updated and auditors are briefed on the new algorithm identifiers.

At the mail client layer, support is the current bottleneck. Most enterprise mail clients as of 2024 do not natively handle ML-DSA or ML-KEM certificates in S/MIME flows. Gateway-level cryptographic processing, where the gateway handles PQC operations and presents classical S/MIME to the desktop client, is the practical interim architecture for regulated deployments that cannot wait for client vendors.

SLH-DSA Versus ML-DSA: Operational Realities for High-Volume Email

The choice between SLH-DSA (FIPS 205) and ML-DSA (FIPS 204) for email signing is primarily a question of operational cost versus security assumption conservatism. ML-DSA is a lattice-based scheme producing signatures of approximately 2.4 KB at the Level 2 security parameter set, with signing times measured in microseconds on modern server hardware. SLH-DSA at its smallest parameter set (SLH-DSA-SHA2-128s) produces signatures of roughly 8 KB and is significantly slower to sign, while its largest recommended parameter sets produce signatures exceeding 40 KB.

For a regulated organisation processing tens of thousands of signed emails per day, ML-DSA is the operationally viable choice. The 2.4 KB signature overhead per message is modest relative to typical email body sizes and attachment volumes. Capacity planning should account for the additional storage in email archives: a 10-million-message archive will accumulate roughly 24 GB of additional signature data at Level 2, which is significant but manageable. SLH-DSA should be reserved for the CA’s own root signing operations, where its conservative hash-only security assumption justifies the size and speed penalty because signing frequency is low.

Managing the Hybrid Transition Window

External correspondents, including government agencies, law firms and banks that a regulated organisation communicates with, will not all migrate to post-quantum email simultaneously. The transition window, during which a sovereign email gateway must support both classical and post-quantum key exchange, may last five to ten years.

A well-architected sovereign gateway handles this by advertising composite capabilities in its OpenPGP key material and S/MIME certificates. When sending to a recipient who publishes only an RSA or ECDH public key, the gateway encrypts with that classical algorithm. When the recipient publishes a composite or post-quantum key, the gateway uses the strongest algorithm both parties support. Inbound, the gateway decrypts whatever the sender used. This is not a compromise: the classical encryption for external correspondents is the best available option given their capability, and the sovereign organisation’s own message store and internal email are protected by full post-quantum encryption regardless.

The IBM Cost of a Data Breach Report 2024 recorded the average cost of a data breach at USD 4.88 million, the highest figure in the series. For organisations in regulated sectors, the reputational and regulatory penalty on top of that figure can be substantially higher, making the infrastructure investment in hybrid gateways straightforward to justify in risk terms.

Regulatory Drivers: Why Archived Email Creates Immediate Compliance Pressure

NIS-2 Directive Article 21 (Directive (EU) 2022/2555) requires essential and important entities to implement cryptographic measures proportionate to the risk they face. The transposition deadline was October 2024. ENISA’s guidance on post-quantum cryptography states clearly: “Organisations that rely on long-term confidentiality of communications, such as those in finance, healthcare and legal services, face immediate risk from harvest-now-decrypt-later attacks and should treat PQC migration as a present-day compliance obligation.”

Under GDPR, Article 32 requires appropriate technical measures to ensure a level of security appropriate to the risk for personal data. For email archives containing patient records, legal correspondence or financial transaction data, a supervisory authority examining a breach in 2030 will scrutinise whether the organisation took reasonable steps in 2024 and 2025 to protect that data against foreseeable quantum threats. DORA, which applies to financial entities and their ICT service providers, similarly requires ICT risk management frameworks to address emerging threats, and quantum risk is explicitly discussed in DORA’s accompanying regulatory technical standards.

Dustin Moody, the NIST post-quantum cryptography project lead, has stated: “The threat is not merely theoretical. Adversaries are collecting encrypted data today with the explicit intent of decrypting it once sufficiently powerful quantum computers become available.” This assessment, from the agency that standardised the algorithms, should anchor any compliance officer’s risk assessment of archived email.

Open-Source Components: Current State and Evaluation for Sovereign Deployment

Sovereign deployers cannot rely on commercial email vendors to manage the post-quantum migration on their behalf without introducing dependency on foreign supply chains. The open-source ecosystem is the practical foundation for a sovereign stack, and the relevant components are at different stages of PQC readiness.

GnuPG, the most widely deployed OpenPGP implementation, is tracking draft-ietf-openpgp-pqc but had not shipped production ML-KEM or ML-DSA support as of late 2024. The development mailing list and git repository at gnupg.org are the authoritative sources for progress. Sequoia-PGP, a modern Rust-based OpenPGP implementation, has been more actively engaged with the PQC draft and its modular architecture makes algorithm additions more tractable; sovereign deployers should monitor its changelog at sequoia-pgp.org.

Thunderbird’s built-in OpenPGP implementation uses the RNP library rather than GnuPG. RNP’s PQC support is similarly in progress. For S/MIME, the OpenSSL library (version 3.x) is beginning to integrate FIPS 203 and 204 support, which will eventually flow into mail transfer agents and gateway software that depend on it.

For a sovereign deployment, the evaluation process should include: reviewing the specific commit or release that introduces PQC support, verifying that the algorithm OIDs match the final FIPS standards and the draft-ietf-openpgp-pqc identifiers, running the NIST Known Answer Tests against the local build, and pinning the verified build hash in the organisation’s software inventory. Automatic updates from distribution package managers should be disabled for cryptographic components and replaced with a controlled update process that includes re-verification. This is not optional: a subtle implementation error in a PQC algorithm is far harder to detect than a classical one, and the consequences for a regulated organisation are the same.

FAQ

Can ML-KEM and RSA coexist in the same email gateway during migration?

Yes. The hybrid construction defined in draft-ietf-openpgp-pqc and the emerging S/MIME composite certificate profiles allow gateways to advertise both classical and post-quantum capabilities simultaneously. The gateway encrypts with whichever algorithm the recipient’s certificate or public key supports, falling back to RSA or ECDH for external correspondents who have not yet migrated.

Why does NIS-2 Article 21 create urgency for post-quantum email migration today rather than when quantum computers arrive?

Article 21 requires proportionate cryptographic measures based on risk. The harvest-now-decrypt-later threat means that email encrypted today with RSA-2048 or ECDH is already at risk if retained in an adversary’s storage for future decryption. Regulators and ENISA guidance both treat this as a present-day risk that proportionate measures must address.

What is the practical difference between ML-DSA and SLH-DSA for high-volume email signing?

ML-DSA (FIPS 204) produces signatures of roughly 2.4 to 4.6 KB depending on the security level, with fast key generation and signing measured in fractions of a millisecond. SLH-DSA (FIPS 205) produces signatures of 8 to 50 KB depending on the parameter set and is slower, but relies only on hash-function security assumptions with no algebraic structure. For regulated email at scale, ML-DSA is the operationally practical choice; SLH-DSA is reserved for high-assurance root signing where volume is low.

Does Thunderbird already support post-quantum OpenPGP?

As of late 2024, Thunderbird’s built-in OpenPGP implementation, based on the RNP library rather than GnuPG, does not yet ship ML-KEM or ML-DSA support. The Sequoia-PGP project and GnuPG development branches are tracking draft-ietf-openpgp-pqc, but sovereign deployers should monitor upstream release notes and pin verified builds rather than relying on distribution package managers, which may lag behind.

What sovereign CA infrastructure changes are needed to issue ML-DSA S/MIME certificates?

The CA must support FIPS 204 key generation and signature algorithms in its certificate issuance pipeline. For organisations running an internal PKI using software such as EJBCA or OpenCA, this means updating to a version that supports the new algorithm OIDs, updating certificate profiles to allow ML-DSA in the SubjectPublicKeyInfo field, and reissuing end-entity certificates. CRL and OCSP infrastructure must also handle the larger certificate and signature sizes associated with post-quantum algorithms.