Learn
0%
Build
0%

Email & Document Signing (S/MIME, CMS)

Master CMS structures for email signing and encryption — from classical S/MIME to post-quantum KEMs.

S/MIME & CMS Overview

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

“CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.”

— RFC 5652, Section 1

S/MIME Signing

Creates a CMS SignedData structure: the sender's private key signs a hash of the message, and recipients verify using the sender's certificate.

S/MIME Encryption

Creates a CMS AuthEnvelopedData structure (RFC 5083): the message is AEAD-encrypted (-GCM) with a random content-encryption key (CEK), which is then wrapped for each recipient.

Where CMS is used
• Email (S/MIME)• Document signing• Code signing• Timestamping• PDF signatures• SCEP / EST• Firmware updates• eIDAS signatures

PQC in CMS

The 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 for hash-based firmware and long-lived signatures (RFC 9708). See the References tab for full details on each standard.

KEM vs Key Transport

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

Classical: Key Transport
Generate random CEK
RSA-OAEP encrypt CEK with recipient's public key
Store encryptedKey in KeyTransRecipientInfo

The CEK is directly encrypted — vulnerable to .

PQC: KEM + Key Wrap
KEM Encapsulate → shared secret + ciphertext
KDF (-SHA256) → key-wrap key from shared secret
AES-WRAP the CEK with derived key
Store kemct + wrappedCEK in

No direct encryption of CEK — quantum-resistant shared secret derivation.

Why KEMs replace key transport

Post-quantum public-key encryption (like lattice-based encryption) is less efficient and harder to standardize than KEM + symmetric key wrap. standardized () as a KEM primitive, not a public-key encryption scheme. RFC 9629 bridges this gap by defining KEMRecipientInfo, a new CMS structure that replaces KeyTransRecipientInfo.

Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.