IETF opens Last Call on draft CMS signature protections for S/MIME
News
Published 27 Oct 2026
Updated 27 Oct 2026
7 min read
Summarize with
The IETF opened Last Call on October 27, 2026, for draft CMS signature protections relevant to S/MIME. The active LAMPS working-group document, draft-ietf-lamps-cms-euf-cma-signeddata-03, is titled "Best Practices for Signed Attributes in CMS SignedData." Comments close November 10, 2026. Its intended status is Best Current Practice, but it is not an approved BCP or RFC.
The draft addresses a potential existential forgery risk when CMS verification accepts different interpretations of signed attributes. It is not final and is not current production guidance. I see the immediate task as implementation review and standards feedback, particularly for teams maintaining S/MIME libraries or sharing signing keys across applications.
What entered Last Call on October 27
The official Last Call event records the announcement sent at 20:37:08 UTC on October 27. Revision -03 itself dates to September 14, 2026. The October event opened broader standards review; it did not publish a newly revised draft.
November 10 is the deadline for substantive comments on the proposal. The announcement requests comments to last-call@ietf.org, with spasm@ietf.org copied, retaining the beginning of the announcement subject line. Implementers can use that review window to identify ambiguous checks or migration problems.
A review deadline, not an enforcement date
November 10 is not a deployment, patching, provider-enforcement, or compliance deadline. The announcement does not instruct operators to reject existing S/MIME messages or make emergency DNS changes.
Why optional signed attributes create a risk
CMS, the Cryptographic Message Syntax used by S/MIME, supports two signing paths. Without signed attributes, the signature covers the content directly. With signed attributes, a message digest is placed inside an attribute collection, and the signature covers that encoded collection. The field is named signedAttrs within each SignerInfo.
For the id-data content type, signedAttrs can be present or absent. The issue is that the signature does not independently bind which interpretation applies. Under the conditions described in the versioned draft, restructuring the CMS object can preserve a mathematically valid signature while changing what the recipient treats as signed content.
Attributes become content
An existing signature over encoded signed attributes is reused with those attribute bytes presented as content. The resulting object has different content, although that content is constrained to the original encoded attributes.
Content becomes attributes
A signer is induced to sign crafted content without signedAttrs. If those bytes encode valid signed attributes, the signature can be reused in an object whose attributes refer to another message.
Existential forgery means producing a valid signature for a message the signer did not explicitly authorize. It does not necessarily mean forging arbitrary readable email. Practical impact depends on accepted formats and the signing operations available to an attacker.
The cited materials do not establish active exploitation, a victim count, or a CVE. They also do not establish that every S/MIME signature is forgeable or that the underlying signature algorithms were broken.
What the draft proposes for CMS implementations
The proposal introduces mimeData for MIME content and would prohibit id-data in new uses of CMS SignedData. For MIME data, it proposes mimeData unless a more specific content type is appropriate. This gives the signed content an explicit interpretation instead of relying on a generic data identifier.
For updated existing protocols retaining id-data, the draft recommends explicitly requiring signedAttrs or explicitly forbidding it. Recipients would enforce the selected rule. The distinction matters: the proposal is about consistent protocol behavior, rather than an unconditional instruction that every legacy message must contain attributes.
|
|
|
|---|---|---|
Avoid id-data | MUST NOT use | New uses |
Use mimeData | SHOULD use | New MIME uses |
Fix attribute rule | SHOULD specify | Updated id-data uses |
Recipient checks | MUST enforce | New uses |
Recipient checks | SHOULD enforce | Existing uses |
Proposed language in revision -03, not newly effective requirements.
Recipient checks cover both the expected encapsulated content type and the presence of signedAttrs when the type is not id-data. RFC 5652 already requires signedAttrs for non-id-data content. The draft adds explicit recipient-checking guidance, with stronger proposed requirements for new uses.
A general CMS library also needs to expose the received content type when the application must enforce protocol-specific expectations. A successful cryptographic verification result alone does not tell the application whether the object belongs to its expected protocol. These distinctions are set out in the proposed checks. Their MUST and SHOULD terms remain draft language.
Key reuse and legacy support need a migration design
Requiring attributes in one application is insufficient if the same key signs attacker-controlled id-data without attributes elsewhere. Review has to include other protocols and older application versions using that key. A stricter recipient does not remove a signing path available through another application.
The proposed approach calls attention to key separation across those contexts. Separate key pairs are one option; uniformly applied signing-side mitigations are another. I would inventory actual key use before treating an application-level setting as a complete fix.
Preserve interoperability deliberately
The draft does not retroactively make deployed id-data implementations nonconforming. A migration plan needs evidence about legacy senders and recipients before tightening acceptance rules. Globally rejecting every message without signedAttrs is not the proposed operational response.
A useful migration design identifies which clients understand a new content type, where compatibility exceptions remain, and how shared keys are handled during transition. Otherwise, updating one client while retaining older signing behavior elsewhere leaves an important part of the review unfinished.
What teams can review before November 10
S/MIME library maintainers should examine verification results and the application-facing API together. PKI and CMS implementers should trace signing-key reuse. Email security teams should identify the owner of S/MIME validation and establish whether gateways or endpoint clients perform the relevant checks.
My starting point would be a small lab matrix using controlled messages and test keys. Record observed behavior separately from the behavior proposed by the draft. That produces useful standards feedback without silently changing production acceptance policy.
- Read the proposal. Review revision -03 and the Last Call announcement, including the distinction between new uses and updated existing protocols.
- Inventory behavior. Document library versions, accepted content types, signedAttrs handling, and every application sharing each signing key.
- Test across contexts. Exercise attribute presence and absence, unexpected content types, and old/new protocol combinations with shared test keys.
- Submit concrete feedback. Report reproducible behavior, the relevant draft section, and any interoperability consequence by November 10 when appropriate.
For each test, keep the input object and the verification result, plus the library version and application policy. A test that fails in a standalone parser but succeeds through the deployed application deserves investigation. Run the same cases through each supported client path, because a common library dependency does not prove that every caller applies the same checks.
Include valid legacy messages as controls. Tests should distinguish a cryptographic signature failure from a protocol policy rejection. Also check whether callers receive enough information to enforce content-type expectations, rather than receiving only a signature-valid result.
Useful feedback describes a specific ambiguity or deployment constraint. For example, identify whether a library hides the encapsulated content type or whether a migration requires simultaneous changes across independently managed clients. Keep confidential message contents and production private keys out of submissions.
S/MIME signatures are separate from domain authentication
S/MIME uses CMS to protect message content with certificate-based signatures. DKIM signs selected email headers and body data under a domain identity. SPF checks authorization for the connecting sender, while DMARC evaluates SPF or DKIM results against the visible From domain. Changing those DNS policies does not repair CMS interpretation.
For routine email checks, Suped's email tester examines a real test message for authentication and other delivery signals. That workflow does not establish whether an S/MIME library passes the draft's CMS checks; those require implementation-specific testing.
Suped is our DMARC and email authentication platform. Its DMARC monitoring helps teams investigate sending sources and authentication failures while the separate S/MIME review proceeds. A DMARC pass rate is not evidence about signedAttrs handling or cross-context signing-key exposure.
Use the review window for implementation evidence
The practical next step is a documented CMS behavior review. Assign the library and PKI owners, preserve legacy compatibility tests, and submit substantive findings before November 10. Production changes should follow an assessed migration design, with the draft clearly identified as work in progress.
Frequently asked questions
No. On October 27, 2026, revision -03 was an active working-group draft entering IETF Last Call. Best Current Practice was its intended publication status, not an approval already granted.
No. Applicability depends on content-type acceptance, signed-attribute behavior, and signing-key use across contexts. The draft describes a CMS interpretation risk rather than a universal break of S/MIME or its signature algorithms.
No. The draft distinguishes new uses from existing protocols and discusses interoperability. Any tighter production acceptance policy needs a migration design based on the protocol and deployed implementations.
No. Those mechanisms address domain authentication. The draft concerns CMS message-signature construction and verification. Review the S/MIME implementation and signing-key contexts rather than making emergency DNS changes.
