IETF draft to fix S/MIME algorithm protection enters Last Call
News
Published 12 Nov 2026
Updated 12 Nov 2026
7 min read
Summarize with
The IETF has opened Last Call on a draft correcting an identifier error in CMS algorithm protection, a message-security mechanism relevant to S/MIME. The official announcement was issued on November 12, 2026, at 00:49:11 UTC. Comments are requested by December 2. The active LAMPS working-group document, draft-ietf-lamps-rfc6211-update-04, addresses an interoperability failure involving two implementations that used different object identifiers for the same attribute.
On November 13 in Australia/Sydney, the document remains a draft. It is not final or approved, and it is not current production guidance. Proposed Standard is its intended publication status. The immediate task is to review library definitions and test interoperability against the existing IANA registration. December 2 is a review deadline, not a deployment or enforcement deadline. Ordinary SPF, DKIM, and DMARC DNS settings are unchanged.
Last Call is a review window
The document is titled "Update to the Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute" and is authored by Russ Housley and Sean Turner. Its versioned draft identifies the intended update to RFC 6211. IETF Last Call invites broader review before the publication decision; entering that stage does not mean the IESG has approved the document.
The news event is the November 12 Last Call announcement. Revision 04 was published on October 4, and the referenced RFC errata were reported on August 19. Those dates describe different steps. Treating the draft revision date or the errata date as the announcement date would obscure what has changed now: the document is open for IETF-wide Last Call review.
|
|
|---|---|
August 19 | Errata reported |
October 4 | Revision 04 published |
November 12 | IETF Last Call opens |
December 2 | Review comments due |
The Last Call deadline concerns review comments.
Review comments should go to last-call@ietf.org, with spasm@ietf.org copied. Identify the draft and revision so reviewers can connect feedback to the exact text. Nothing in the announcement establishes a date on which mail providers will begin rejecting messages or organizations must change their S/MIME configuration.
The OID error behind the interoperability failure
An ASN.1 object identifier, or OID, identifies a particular structure or attribute. Here, it identifies the CMS algorithm protection attribute. An implementation has to recognize that identifier before it can interpret the attribute and apply the relevant checks. Two implementations using different identifiers do not have a reliable shared reference, even when their developers intended to implement the same RFC.
The correct identifier for id-aa-cmsAlgorithmProtect is 1.2.840.113549.1.9.16.2.52. The erroneous RFC 6211 definition gives 1.2.840.113549.1.9.52 because it leaves out the smime(16) and aa(2) branches. The draft corrects the RFC definitions to match the IANA registry, which has always contained the correct registration. No new allocation or registry repair is proposed.
Compare the registered identifier with the RFC errortext
Correct IANA OID: 1.2.840.113549.1.9.16.2.52 Erroneous RFC OID: 1.2.840.113549.1.9.52 Missing RFC branches: smime(16) aa(2)
The authors report two implementations that failed to interoperate: one followed the RFC definition and the other followed the IANA registry. That is specific evidence of a compatibility problem. It does not establish how many deployed systems use either definition, and it does not establish that every S/MIME deployment includes this attribute.
The security purpose explains why the identifier matters. The attribute protects against algorithm substitution, where a message is altered so that the validator uses a different algorithm than the originator used. Implementations need a shared OID to recognize the protection. The draft addresses that shared identifier; it does not announce a new cryptographic algorithm.
What COUNTS MAX 1 actually changes
The proposal also adds COUNTS MAX 1 to the ASN.1 attribute definition. That addition needs careful reading. RFC 6211 already requires only one algorithm protection attribute in the relevant attribute set and exactly one AttributeValue within that attribute. The draft adds guidance to the formal definition rather than introducing those restrictions for the first time.
The draft explicitly explains that these requirements are not automatically enforced by the definition. A schema annotation does not prove that a parser or verifier checks every relevant condition. I would inspect the implementation and its tests before treating the annotation as evidence of enforcement.
Existing RFC requirements
When used, the algorithm protection attribute appears only once in the relevant attribute set and contains exactly one AttributeValue. These restrictions already exist in the RFC text.
Proposed ASN.1 guidance
COUNTS MAX 1 adds guidance to the attribute definition. It does not install runtime validation or make automatic enforcement a new consequence of publication.
Keep the two checks distinct during review: counting attribute instances and counting values inside an instance concern different parts of the structure. A test that exercises only a valid single-value message does not show what happens with duplicate attributes or an invalid number of values.
What S/MIME maintainers should check now
The closest operational audience is S/MIME/CMS library maintainers, PKI teams, and email security teams responsible for S/MIME verification. Start with the components that generate or consume CMS structures. A domain administrator who only manages outbound sender authorization has a different responsibility and does not need to rewrite DNS because of this announcement.
I would start with the ASN.1 definitions and OID constants in the actual library version being shipped. Check generated code as well as source modules: changing an input definition does not establish that deployed binaries use it. Confirm the value against the existing IANA registry, then investigate what the implementation does when it encounters the attribute.
- Inspect definitions: Find id-aa-cmsAlgorithmProtect and related attribute definitions. Record the numeric OID used when generating messages and the OID recognized during verification.
- Check the registry: Compare that value with the existing IANA registration. Separate the RFC transcription error from any local naming or code-generation differences.
- Test real paths: Use a lab with the clients and gateways your organization actually operates. Record library versions and inspect the encoded attribute, not only the displayed verification result.
- Review validation: Exercise duplicate attributes and zero or multiple values under controlled conditions. Document observed behavior against the existing RFC requirements and the proposed ASN.1 guidance.
- Submit evidence: Send a focused review comment describing the revision, OID, software versions, and reproducible behavior. Explain whether the proposed text resolves the observed interoperability problem.
Use controlled test messages and record whether the attribute is present at all. Include an otherwise comparable message without it so results do not assume universal use. Where two implementations are available, test messages generated by each in the other verifier. Distinguish an unrecognized attribute from certificate validation failure or an unsupported algorithm.
These are review and diagnostic steps, not a proposed production acceptance policy. Do not silently accept both identifiers, disable checks, or patch a live verifier merely because a draft has entered Last Call. Any implementation change needs its own compatibility assessment and normal release testing.
What this changes for email operations
This update concerns CMS message security used by S/MIME. SPF checks sending authorization, DKIM verifies a domain signature on email, and DMARC evaluates domain authentication against the visible From domain. Those controls answer different questions. Their DNS records and sender-reputation settings are not changed by this draft.
It is also separate from draft-ietf-lamps-cms-euf-cma-signeddata, covered in Suped's October report on CMS signature protections. Similar terminology does not make the proposals interchangeable. Track their document names separately when assigning review work or discussing implementation changes.
Keep the impact claim specific
The announcement and draft do not establish an active exploit, a universal signature bypass, a CVE, or a provider rollout. They document an identifier mismatch and a proposed interoperability correction.
For a separate check of an ordinary message, Suped's email tester analyzes authentication and delivery-related results. Its domain health checker audits domain authentication DNS. Neither substitutes for inspecting this CMS attribute or testing S/MIME interoperability.
Suped is our DMARC and email authentication platform. Its aggregate-report workflows help teams investigate sending sources and authentication failures. Keep that domain-level investigation separate from the S/MIME library review, with the latter assigned to whoever owns CMS generation and verification.
Send implementation evidence before December 2
Reviewers have until December 2, 2026, to comment on this Last Call. A useful submission identifies the exact ASN.1 definition or encoded OID involved, shows reproducible behavior, and explains whether revision 04 removes the ambiguity. Send it to last-call@ietf.org and copy spasm@ietf.org.
I would give the S/MIME maintainer ownership of that review now and attach the lab results to the implementation issue. Track later draft revisions and the publication decision before describing proposed text as an approved update. The open review window is the immediate reason to act.
Frequency asked questions
No. It is an active LAMPS Internet-Draft in IETF Last Call. Proposed Standard is the intended publication status, not an approval already granted. Its proposed changes are not current production guidance.
The existing IANA registration is 1.2.840.113549.1.9.16.2.52. RFC 6211 incorrectly gives 1.2.840.113549.1.9.52 by omitting smime(16) and aa(2). The draft corrects the RFC definitions; the registry needs no change.
No. It adds ASN.1 guidance. RFC 6211 already restricts the attribute to one instance with one AttributeValue. Implementations still need appropriate validation; the annotation does not establish that runtime checks occur.
No. December 2, 2026, is the Last Call comment deadline. It is not a deployment or enforcement deadline. Focus on implementation review and lab interoperability testing, with SPF, DKIM, and DMARC administration handled separately.
