Email & Document Signing (S/MIME, CMS)

Cryptographic Message Syntax (CMS), defined in RFC 5652, is the foundational format for digitally signing and encrypting arbitrary data. It powers S/MIME (Secure/Multipurpose Internet Mail Extensions), the standard for end-to-end email security used by enterprises, governments, and military organizations worldwide.

The IETF LAMPS working group has published a series of RFCs that bring post-quantum cryptography into CMS. These standards define how PQC algorithms integrate with existing S/MIME infrastructure.

Together, these RFCs provide a complete PQC story for CMS: ML-DSA for signing (RFC 9882), KEM-based encryption via KEMRecipientInfo (RFC 9629), RSA-KEM as a transitional KEM option (RFC 9690), and HSS/LMS for hash-based firmware and long-lived signatures (RFC 9708). See the References tab for full details on each standard.

Classical S/MIME encryption uses RSA key transport: the sender encrypts the CEK directly with the recipient's RSA public key. PQC replaces this with a Key Encapsulation Mechanism (KEM) — a fundamentally different approach.

S/MIME certificates carry specific extensions that bind an email address to a key pair and declare the permitted operations (signing vs encryption). PQC introduces new considerations for key usage and algorithm negotiation.

In practice, users often have separate key pairs for signing and encryption. This is especially true for PQC migration, where signing keys (ML-DSA) and encryption keys (ML-KEM) use fundamentally different algorithms. The smimeCapabilities attribute in signed messages advertises supported algorithms, enabling gradual PQC rollout.

S/MIME is not the only way mail and files get signed and encrypted. OpenPGP (RFC 9580, the 2024 revision that introduced version 6 keys) has no X.509 certificates and no CA: keys carry their own identities and are trusted through signatures from other keys. Its PQC migration therefore arrives as new algorithm IDs inside keys and packets, not as new certificate profiles — and it is already a Proposed Standard: RFC 9980, Post-Quantum Cryptography in OpenPGP.

RFC 9980 takes a different line from the CMS RFCs above. Because lattice schemes are new, ML-KEM and ML-DSA are used only as PQ/T composites — each one is bound to an elliptic-curve partner so that, in the RFC's words, security is retained even if all schemes but one in the combination are broken. The one exception is SLH-DSA, whose hash-based security assumptions the RFC considers well enough understood to stand alone.

A conformant implementation MUST implement ML-DSA-65+Ed25519 and ML-KEM-768+X25519; the 1024/448 pair is SHOULD. Deployment detail that bites: the PQ algorithms are for v6 keys only, with one exception — ML-KEM-768+X25519 (ID 35) is also allowed in v4 encryption-capable subkeys, so an existing v4 key can gain a post-quantum encryption subkey without a full key rollover, while PQ signing waits for a v6 primary key.

Compare with S/MIME: same primitives (ML-KEM, ML-DSA, SLH-DSA), same key-exchange → signature split, but OpenPGP mandates the hybrid pairing that LAMPS leaves to the deployment, and it has no certificate-profile work to do because it never had certificates. The Industry Landscape tracks this as the cross-industry use case “OpenPGP email & file encryption”.

Migrating email security to PQC is uniquely challenging because S/MIME requires bidirectional compatibility — both sender and recipient must support the same algorithms. This creates a chicken-and-egg problem that doesn't exist in TLS (where servers can unilaterally upgrade).