up:: In the Protocols MOC

PQC in S/MIME and CMS

Post-quantum S/MIME and CMS is the work of making signed and encrypted email quantum-safe by adding post-quantum algorithms to the Cryptographic Message Syntax that underlies MIME, the standard for end-to-end secure email in enterprise and government. The Cryptographic Message Syntax (CMS) is the container format that S/MIME uses to sign and encrypt a message, so the post-quantum question for secure email is really a question about CMS. The IETF LAMPS working group (Limited Additional Mechanisms for PKIX and SMIME) is where that migration is specified. Its two pillars are ML-DSA for signatures, standardized for CMS in RFC 9882 and for X.509 in RFC 9881, and ML-KEM for confidentiality, carried through the KEMRecipientInfo structure that RFC 9629 added to CMS so any key-encapsulation mechanism can wrap the content-encryption key.

Source: IETF LAMPS working group charter, datatracker.ietf.org.

The short version:

• S/MIME signs and encrypts email through CMS, so post-quantum email is a CMS migration, and the IETF LAMPS working group is the venue for it.
• Signatures move to ML-DSA. RFC 9882 (October 2025) specifies ML-DSA in CMS SignedData; RFC 9881 (October 2025) specifies the matching X.509 algorithm identifiers so certificates can carry ML-DSA public keys.
• Confidentiality moves to ML-KEM. RFC 9629 (August 2024) added KEMRecipientInfo to CMS, a structure that lets a KEM encapsulate a shared secret, derive a key, and wrap the content-encryption key for each recipient.
• The encrypted half of email is a harvest-now-decrypt-later target, because mail sits in archives and mailboxes for years while a classical key protected it, so recorded ciphertext is decryptable the day a quantum computer arrives.
• LAMPS also standardizes composite and hybrid variants, pairing a classical and a post-quantum algorithm in one certificate or one message, so old and new clients each validate what they understand during the long overlap.

Think of CMS as a shipping envelope with two features: a wax seal that proves who sent it, and an inner lockbox whose key is enclosed in a smaller sealed pouch addressed to the recipient. The post-quantum migration replaces the wax seal with one a quantum forger can’t copy (ML-DSA), and it replaces the mechanism inside the little pouch that hands over the lockbox key with a quantum-resistant one (ML-KEM through KEMRecipientInfo). The envelope, the lockbox, and the addressing all stay the same. Two specific cryptographic components inside get swapped.

Where does cryptography live in S/MIME and CMS?

Cryptography in S/MIME lives in two CMS content types, and each faces the quantum threat on a different clock. CMS is defined in RFC 5652, and S/MIME (RFC 8551) is the profile that applies it to email. The two jobs:

1. SignedData carries a digital signature over the message, proving origin and integrity. Classically this is RSA or ECDSA, both broken by Shor’s algorithm. A forged email signature only helps an attacker who can present it live, so this is a Non-HNDL exposure, real but slower on the clock.
2. EnvelopedData (and its authenticated variants) carries the encrypted message. The content is encrypted under a symmetric content-encryption key, and that key is itself protected for each recipient, classically by RSA key transport or an ECDH key agreement. This is the harvest-now-decrypt-later half: recorded ciphertext is decryptable retroactively once a quantum computer can recover that wrapped key.

The structure that carries per-recipient key material in EnvelopedData is RecipientInfo, and the classical variants are KeyTransRecipientInfo (RSA-style key transport) and KeyAgreeRecipientInfo (ECDH-style agreement). Neither cleanly fits a key-encapsulation mechanism, which is why post-quantum confidentiality in CMS needed a new RecipientInfo variant rather than a drop-in swap.

Source: R. Housley, “Cryptographic Message Syntax (CMS),” RFC 5652, rfc-editor.org.

How do email signatures go post-quantum?

Email signatures move to ML-DSA, NIST’s general-purpose lattice signature, and the IETF standardized the two pieces this needs in October 2025: the CMS conventions and the X.509 certificate conventions. Both landed as RFCs at once, because a signature is only usable if the certificate that carries the signer’s public key can be understood too.

1. ML-DSA in CMS (RFC 9882). This specifies how ML-DSA signatures appear in CMS SignedData, including the algorithm-identifier syntax and the object identifiers for the three parameter sets, ML-DSA-44, ML-DSA-65, and ML-DSA-87. It uses ML-DSA in its pure mode (the message is supplied directly, not pre-hashed), sets the context string to empty, and where signed attributes are present names SHA-512 as the mandatory digest with SHAKE256 recommended for interoperability.
2. ML-DSA algorithm identifiers in X.509 (RFC 9881). This defines the conventions for using ML-DSA public keys and signatures in X.509 certificates and certificate revocation lists, with three registered OIDs (id-ml-dsa-44, id-ml-dsa-65, id-ml-dsa-87) and the requirement that the algorithm-identifier parameters be absent.

Together these let a certificate authority issue an ML-DSA certificate and a mail client produce and verify an ML-DSA-signed message. The design deliberately mirrors how RSA and ECDSA already work in CMS, so the change is a new algorithm inside an unchanged message structure.

Sources: B. Salter, A. Raine, D. Van Geest, “Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS),” RFC 9882, October 2025, rfc-editor.org.

Source: “Internet X.509 Public Key Infrastructure: Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA),” RFC 9881, October 2025, rfc-editor.org.

How does encrypted email go post-quantum with KEMRecipientInfo?

Encrypted email goes post-quantum through KEMRecipientInfo, a CMS structure that RFC 9629 added in August 2024 specifically so a key-encapsulation mechanism can protect the content-encryption key. A KEM like ML-KEM does not fit the older key-transport or key-agreement recipient structures, so RFC 9629 defined a new one.

The mechanism, for each recipient, runs in a fixed sequence:

1. Encapsulate. The originator runs the KEM against the recipient’s public key, producing a ciphertext and a shared secret. For ML-KEM this is the standard encapsulation operation.
2. Derive. The shared secret is run through a key-derivation function to produce a key-encryption key.
3. Wrap. That key-encryption key wraps the message’s content-encryption key, and the wrapped key plus the KEM ciphertext travel in the KEMRecipientInfo structure to the recipient.

The recipient reverses it: decapsulate the ciphertext with its private key to recover the shared secret, derive the same key-encryption key, and unwrap the content-encryption key. RFC 9629 is algorithm-agnostic, so it carries any KEM, and the LAMPS companion draft “Use of ML-KEM in the Cryptographic Message Syntax (CMS)” pins down the ML-KEM specifics. Because RFC 9629 also updates RFC 5652, KEM support becomes a first-class part of CMS rather than a bolt-on.

Source: R. Housley, J. Gray, T. Okubo, “Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS),” RFC 9629, August 2024, rfc-editor.org.

What is the IETF LAMPS working group building for post-quantum?

LAMPS is the IETF working group that maintains the PKIX certificate standards and the S/MIME and CMS message standards, and its post-quantum charter is where the pieces above come from. The name expands to Limited Additional Mechanisms for PKIX and SMIME, and it took over the closed PKIX and S/MIME groups’ work. Its post-quantum program spans several tracks:

Track	What it defines	Representative output
PQC signatures in CMS	ML-DSA (and SLH-DSA) conventions in SignedData	RFC 9882 (ML-DSA in CMS)
PQC keys in X.509	ML-DSA algorithm identifiers for certificates and CRLs	RFC 9881 (ML-DSA in X.509)
PQC KEMs in CMS	ML-KEM carried by KEMRecipientInfo	RFC 9629 (KEM in CMS) plus the ML-KEM-in-CMS draft
Composite signatures	one certificate carrying a classical and a PQC signature	Composite ML-DSA drafts for PKIX and CMS
Composite KEMs	one recipient structure using a classical and a PQC KEM	Composite ML-KEM drafts for CMS

Source: IETF LAMPS working group charter, datatracker.ietf.org.

The composite tracks matter because email lives in a long overlap. A message signed or encrypted for a mixed audience, some clients ML-DSA-capable and some not, needs a way to satisfy both, and a composite structure that binds a classical and a post-quantum algorithm together lets each verifier or recipient use the half it understands. That is the same overlap strategy the TLS ecosystem uses, applied to stored messages instead of live sessions.

Why is encrypted email an urgent harvest-now-decrypt-later target?

Because email is stored as well as transmitted, its confidentiality has to hold for as long as the message stays sensitive, which is often years or decades. A TLS session that used classical key exchange is only exposed if someone recorded it in transit. An encrypted email is exposed if anyone ever captured the ciphertext, and encrypted mail routinely sits in server archives, backup tapes, compliance stores, and recipients’ mailboxes for the life of the record. Every one of those copies was protected by a classical RSA or ECDH wrapping of the content key, and every one becomes readable the day a capable quantum computer can break that wrapping.

That is why the confidentiality side (ML-KEM through KEMRecipientInfo) is the HNDL-urgent half, even though the signature side (ML-DSA) got its finished RFCs first. A forged signature on a new message needs a live quantum computer at the moment it is presented, so the signature migration protects future messages rather than past ones. The encryption migration is the one racing a clock that is already running, because the harvestable ciphertext of today’s confidential mail is being created and stored right now.

Source: R. Housley, J. Gray, T. Okubo, “Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS),” RFC 9629, August 2024, rfc-editor.org.

How does this relate to OpenPGP?

CMS-based S/MIME and OpenPGP are the two families of end-to-end secure email, and they run separate post-quantum tracks in separate venues. Everything above is the CMS and S/MIME path, standardized in LAMPS. OpenPGP’s post-quantum work happens in the IETF OpenPGP working group and defines its own way to carry ML-KEM and ML-DSA in the OpenPGP packet format, because OpenPGP is a different container than CMS with its own key and message structures. The underlying NIST algorithms are the same, ML-KEM for confidentiality and ML-DSA for signatures, so the cryptographic destination matches even though the encoding and the working groups differ. The S-MIME and OpenPGP note covers both families as a concept; this note is specifically about the CMS and S/MIME migration.

Source: IETF LAMPS working group charter, datatracker.ietf.org.

Common misconceptions

• “S/MIME and CMS are different migrations.” S/MIME is the email profile of CMS, so making CMS post-quantum makes S/MIME post-quantum. The signatures and the key establishment live in CMS content types, and that is where the RFCs apply.
• “The signature migration is the urgent one for email.” It is the reverse. A forged email signature needs a live quantum computer at presentation, so it is Non-HNDL. The encrypted content is the harvest-now-decrypt-later target, because stored ciphertext is decryptable retroactively.
• “ML-KEM just drops into the existing recipient structures.” It does not fit the classical key-transport or key-agreement RecipientInfo types, which is exactly why RFC 9629 defined the new KEMRecipientInfo structure to carry a KEM’s ciphertext and wrapped key.
• “Post-quantum email is years away from any standard.” The core RFCs exist. ML-DSA in CMS (RFC 9882) and X.509 (RFC 9881) published in October 2025, and KEM support in CMS (RFC 9629) published in August 2024. Client and CA deployment is the pacing item, not the specifications.
• “OpenPGP and S/MIME share one post-quantum spec.” They target the same NIST algorithms but through different working groups and different container formats, so their post-quantum encodings are specified separately.

Questions people ask

What actually changes in S/MIME for post-quantum? Two things inside CMS: the signature algorithm moves to ML-DSA (RFC 9882, with X.509 support in RFC 9881), and the per-recipient key protection for encrypted mail moves to a KEM like ML-KEM carried in the KEMRecipientInfo structure (RFC 9629). The message container and the symmetric content encryption stay the same.

Which part of encrypted email is urgent to migrate? The encryption, because it is harvestable. Mail sits in archives for years under a classical key, so recorded ciphertext is decryptable the day a quantum computer arrives. The signature side is real but slower, since a forged signature needs a live quantum computer.

Is there a finished standard for ML-DSA-signed email? Yes. RFC 9882 (October 2025) specifies ML-DSA in CMS SignedData, and RFC 9881 (October 2025) specifies the matching X.509 algorithm identifiers so a certificate can carry the signer’s ML-DSA public key.

What is KEMRecipientInfo? A CMS structure, added by RFC 9629 in August 2024, that lets a key-encapsulation mechanism protect the content-encryption key: it encapsulates a shared secret against the recipient’s public key, derives a key-encryption key, and wraps the content key. It is what makes ML-KEM usable in CMS.

Do S/MIME and OpenPGP use the same post-quantum specs? No. They use the same NIST algorithms (ML-KEM and ML-DSA) but through different IETF working groups and different container formats, so the encodings are specified separately. LAMPS covers the CMS and S/MIME side.

Why are composite signatures part of this? Because email lives in a long overlap where some clients understand ML-DSA and some don’t. A composite structure binds a classical and a post-quantum algorithm together, so each verifier or recipient uses the half it can process while the ecosystem transitions.

Does this require new certificates? Yes, for signatures. A signer needs an X.509 certificate that carries an ML-DSA public key, which RFC 9881 makes possible, and the issuing certificate authority has to support ML-DSA issuance. That CA and client rollout is the pacing constraint on deployment.

Go deeper

The two secure-email families as a concept live in S-MIME and OpenPGP. The container format underneath is Cryptographic Message Syntax, and the certificate that carries the signer’s key is the X.509 Certificate. The signature algorithm is ML-DSA and the key-establishment mechanism is ML-KEM, with the general KEM pattern explained separately. The overlap strategy is Composite Certificates. The hub that maps this into every other protocol is In the Protocols MOC.

---

Everything here is the map, given freely. When your team needs its secure-email estate, its S/MIME certificates and CMS-based archives, assessed for where the post-quantum signatures and key establishment actually have to land, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.