IETF draft proposes FrodoKEM support for S/MIME encryption
News
The IETF's LAMPS working group published its first CMS FrodoKEM draft on October 30, 2026, at 13:44:10 UTC, which was October 31 at 12:44:10 a.m. in Sydney. The proposal describes FrodoKEM key establishment for the Cryptographic Message Syntax (CMS), the format underlying S/MIME encryption. This is an Internet-Draft, not a final RFC or current production guidance.
A companion certificate draft was published on October 29 at 16:37:09 UTC. Both are active LAMPS working-group documents. Neither creates a sender requirement, deployment mandate, rollout date, or migration deadline. I see the practical audience as S/MIME client implementers and certificate teams evaluating post-quantum encryption, rather than domain owners changing their email settings.
First working-group publication, with no deployment mandate
The new document is named draft-ietf-lamps-cms-frodokem-00, with the formal title "Use of FrodoKEM in the Cryptographic Message Syntax." The publication event records the completed first working-group publication, and the working-group approval event documents its approval. This has progressed beyond an adoption call or an individual submission.
FrodoKEM and earlier individual proposals already existed. The news is that LAMPS now has working-group drafts covering CMS integration and certificate formats. Publication under a working-group name does not mean the design has completed IETF review. The text remains open to revision, and its internal implementation requirements apply to the proposed design, not to every email sender.
A draft is not a deployment instruction
No DNS change follows from this publication. Ordinary domain owners do not need to change SPF, DKIM, DMARC, MX, or MTA-STS. The milestone also establishes no new NIST or completed ISO standardization event for FrodoKEM.
How the CMS proposal handles encryption
The CMS draft text proposes using FrodoKEM with KEMRecipientInfo, the CMS structure defined in RFC 9629. A key encapsulation mechanism establishes a shared secret between a sender and a recipient. It does not directly encrypt the entire email body. Symmetric encryption still protects the content.
In the proposed construction, the sender uses the recipient's public key to encapsulate a shared secret. A key derivation function produces a key-encryption key, which wraps the content-encryption key. The recipient decapsulates the secret with its private key and recovers the content key. KEMRecipientInfo carries the recipient-specific information needed for that process.
Proposed CMS flow: encapsulate a secret, derive a wrapping key, and wrap the content key.
That distinction matters when assessing the security claim. Replacing a public-key mechanism does not replace the content cipher, certificate validation, or private-key handling. A successful encapsulation test alone is insufficient evidence that an S/MIME message can be securely exchanged and read.
I would evaluate the complete message path in a research environment: certificate selection, encapsulation, key recovery, and content decryption. The first working-group publication gives implementers a shared proposal to examine; it does not demonstrate deployed mail-client support or universal interoperability.
Eight proposed variants and S/MIME announcements
The CMS proposal covers the 976 and 1344 parameter sets, corresponding to security levels 3 and 5. Each has AES and SHAKE variants, with standard FrodoKEM and ephemeral eFrodoKEM forms. That produces eight combinations. The AES or SHAKE suffix identifies a component of FrodoKEM, not the cipher selected to encrypt the email body.
Eight variants covered by the CMS drafttext
Security level 3 FrodoKEM-976-AES FrodoKEM-976-SHAKE eFrodoKEM-976-AES eFrodoKEM-976-SHAKE Security level 5 FrodoKEM-1344-AES FrodoKEM-1344-SHAKE eFrodoKEM-1344-AES eFrodoKEM-1344-SHAKE
Section 3.5 explicitly proposes SMIMECapabilities announcements. An implementation constructing CMS SignedData can advertise supported FrodoKEM algorithm identifiers. The proposed capability encoding includes the algorithm identifier with parameters absent. This is a defined announcement mechanism in the draft, rather than an assumption that recipients automatically understand FrodoKEM.
Capability handling also needs negative tests. In a lab, pair a sender that advertises one variant with a recipient that lacks it, and check that the software reports the unsupported combination clearly. Do not count an unencrypted fallback as a successful encrypted exchange. Record the exact unsupported identifier and message outcome so another team can reproduce the result without guessing which variant was used.
Security levels are comparison categories, not proof of NIST standardization or guaranteed quantum safety. Likewise, the ephemeral label does not establish forward secrecy for an entire email system. Review the key lifecycle and applicable security guidance before drawing that conclusion.
Why the certificate draft matters
The companion document, draft-ietf-lamps-frodokem-certificates-00, specifies X.509 algorithm identifiers and public-key encoding, plus private-key formats. The CMS message construction needs a usable recipient key; the certificate proposal addresses how that key is identified and carried. Implementers need compatible interpretations of both documents.
Its size figures also give test teams concrete inputs. The table below lists raw public-key and KEM ciphertext lengths in bytes. These are not complete certificate or message sizes, which include additional structure and encoding overhead.
|
|
|
|
|---|---|---|---|
FrodoKEM-976 | 3 | 15,632 | 15,792 |
eFrodoKEM-976 | 3 | 15,632 | 15,744 |
FrodoKEM-1344 | 5 | 21,520 | 21,696 |
eFrodoKEM-1344 | 5 | 21,520 | 21,632 |
Raw byte lengths listed in the companion certificate draft; AES and SHAKE share these sizes.
I would measure complete encoded messages rather than estimate compatibility using the raw key length alone. Include multiple recipients and attachments in the test cases. Record certificate import behavior, message size, and decryption results for each sender and recipient implementation.
For PKI testing, exercise certificate issuance and distribution as well as renewal and recovery. A recipient needs authorized access to the private keys required for older encrypted messages. Document how research keys are stored and retired so a successful initial exchange does not hide a recovery problem.
Keep algorithm identifiers and key formats tied to the exact draft revisions tested. A laboratory result with one certificate encoding does not establish compatibility with a different implementation or a later revision. Neither publication supplies evidence that existing production clients already accept these keys.
What implementers should test now
S/MIME client developers, PKI teams, and email security operators planning post-quantum cryptography have a concrete reason to follow these publications. The useful next step is a documented research plan with reproducible results.
My priority would be compatibility and key protection before any production decision. Keep the work in research or test environments, and distinguish conformance to a draft from approval to deploy it.
- Track revisions: Record both draft versions and review changes together. Recheck assumptions when identifiers, certificate formats, or capability announcements change.
- Compare encodings: Check algorithm identifiers, public-key serialization, and private-key import and export across independent implementations.
- Exercise interoperability: Test sender and recipient combinations, unsupported capabilities, certificate handling, and complete message decryption. Capture failures explicitly.
- Measure overhead: Test large keys and recipient-specific ciphertexts against message-size limits in the research mail path, including multi-recipient messages.
- Review key security: Assess randomness, private-key protection, temporary-key cleanup, and side-channel behavior against the drafts and their referenced security guidance.
The CMS security section warns that weak randomness undermines protection and that compromise of a recipient private key exposes messages protected with it. Those concerns remain relevant even when the underlying algorithm is designed to resist quantum attacks. Treat implementation quality as a separate review item.
Why SPF, DKIM, and DMARC stay separate
FrodoKEM here concerns encryption and key establishment. DKIM provides domain-based message signatures. SPF authorizes sending infrastructure, while DMARC evaluates authenticated domains against the visible From domain and applies domain policy. An S/MIME key-encapsulation proposal does not change those mechanisms.
The distinction also prevents misleading validation claims. Passing domain authentication does not prove content confidentiality. Decrypting an S/MIME message does not establish that the sending infrastructure passes DMARC. Each result answers a different operational question.
S/MIME research
Tests recipient keys, CMS encoding, capability announcements, and content-key recovery. Evidence comes from compatible implementations exchanging and decrypting test messages.
Domain authentication
Checks sending authorization and authenticated domain identity. Evidence comes from received-message authentication results and DMARC reports, rather than content decryption.
Suped is our DMARC and email authentication platform. Its DMARC monitoring helps teams inspect sending sources and diagnose authentication failures. That workflow remains separate from evaluating FrodoKEM certificates or CMS implementations.
Suped's email tester provides received-message authentication checks for routine email troubleshooting. It does not certify FrodoKEM support, S/MIME interoperability, or post-quantum confidentiality. No authentication or DNS change is required by these drafts.
Keep this on the research roadmap
For teams maintaining S/MIME implementations, assign an owner to follow both working-group drafts and preserve revision-specific interoperability results. A production decision needs a separate review of specifications, supported implementations, and key-management controls. For ordinary domain owners, this publication adds no migration task or deadline.
Frequently asked questions
No. The October 30 publication is the first LAMPS working-group CMS draft. It and the companion certificate draft remain work in progress, not final RFCs or production deployment guidance.
No. References to security levels 3 and 5 describe security categories. This working-group publication is not NIST standardization of FrodoKEM, and it does not establish a new ISO standardization event.
Yes. Section 3.5 proposes advertising supported FrodoKEM identifiers through SMIMECapabilities. That proposal does not demonstrate support in deployed mail clients.
No. The drafts concern CMS encryption and certificate formats. They create no requirement to change SPF, DKIM, DMARC, MX, or MTA-STS, and they specify no sender migration deadline.
