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.

Certificate Requirements

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.

Signing Certificate

• keyUsage: digitalSignature, nonRepudiation
• extKeyUsage: id-kp-emailProtection
• subjectAltName: rfc822Name (email)
• Algorithm: -65 or P-256

Encryption Certificate

• keyUsage: keyEncipherment (RSA) or keyAgreement (). KEM keyUsage is still being standardized
• extKeyUsage: id-kp-emailProtection
• subjectAltName: rfc822Name (email)
• Algorithm: ML-KEM-768 or RSA-2048

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.

Migration Challenges

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).

Dual-Algorithm Certificates

During transition, organizations must issue both classical and PQC certificates for each user. Certificate management complexity doubles.

Recipient Capability Discovery

Senders must discover which algorithms each recipient supports before encrypting. The smimeCapabilities attribute and LDAP directory lookups become critical.

Message Size Impact

ML-DSA-65 signatures are ~3.3 KB (vs ~72 bytes DER-encoded for ECDSA). Signed emails with certificate chains can grow by 10-15 KB, impacting mobile clients and constrained networks.

Archival & Long-Term Validation

Signed emails must remain verifiable for years or decades. Organizations need both classical and PQC signatures during the transition to ensure long-term validation.

Gateway & Relay Compatibility

Email gateways, DLP systems, and archival solutions must understand PQC-signed CMS structures to avoid stripping or corrupting S/MIME attachments.