Summary

  • draft-ietf-lamps-rfc6211-update-01 corrects the CMS algorithm-protection attribute OID in RFC 6211 from 1.2.840.113549.1.9.52 to the IANA-registered 1.2.840.113549.1.9.16.2.52. Its authors report that two implementations failed to interoperate because they chose different official sources.
  • The textual correction is necessary but not sufficient for deployed systems and stored objects. Operators need an identifier-precedence and compatibility-retirement register that separates recognition, production, remediation and eventual rejection of the legacy encoding.

The same name, two numbers

Imagine an integration test with two envelopes. Both claim to carry the CMS algorithm-protection attribute. Both are signed. Both were produced by software whose authors consulted an official publication. Yet the decoder recognizes one envelope and ignores or rejects the other because the attribute identifier is different.

The difference is not a whimsical vendor extension. RFC 6211 printed 1.2.840.113549.1.9.52 in its main definition and ASN.1 module. The IANA registry placed id-aa-cmsAlgorithmProtect beneath the S/MIME attributes branch, yielding 1.2.840.113549.1.9.16.2.52. The update draft says the registry has always been correct. It also says the authors know of two RFC 6211 implementations that did not interoperate: one used the RFC value, the other the registry value.

That compact account overturns an easy assumption about registries. A canonical register can state the right answer without causing every implementation to use it. Software consumes modules, copied constants, generated bindings, examples and test vectors. People may reasonably treat the numbered specification in front of them as more authoritative than a separate web registry. Once bytes have been emitted and stored, correctness in one institutional location does not rewrite them.

What the attribute was meant to protect

CMS, the Cryptographic Message Syntax, carries signed, authenticated and encrypted content. RFC 6211 added an attribute that binds the algorithm identifiers used in processing to the protected message. Its target is algorithm substitution: an adversary changes an algorithm or its parameters so that a validator processes the object differently from the originator's intention.

The attribute therefore exists to make a security choice unambiguous. But the protection itself needs an unambiguous identifier. If a producer encodes the attribute under one OID and a validator looks for another, the parties have not merely disagreed about a label in documentation. They may disagree about whether the protection attribute is present at all. The update's security section states the narrow point: the mechanism is not successful unless implementers use the same ASN.1 OID.

Nothing in the draft establishes a successful attack, an ecosystem-wide outage or a count of affected products. The disclosed evidence is smaller and still important: two implementations chose different values and failed to interoperate. Governance should preserve that boundary. A documented split is enough to demand a migration decision; it is not permission to invent exposure statistics.

The executable text carried unusual authority

Standards are read at several levels. A policy reader may absorb the prose. An engineer may copy the ASN.1 module. A toolchain may compile the module and never encounter the narrative sentence that was supposed to govern it. A test suite may freeze the resulting bytes. A vendor dependency may then preserve them for years after the document has been corrected.

RFC 6211's error lived in a place that could become executable input. The number appeared not only in explanatory text but in the module supplied for implementers. That makes “the registry was correct” an incomplete operational answer. The registry held semantic authority; the module had distribution and automation authority. In the two reported implementations, those authorities diverged.

Revision 01 of the update addresses a second version of the same problem. RFC 6211's prose says the attribute set includes only one instance of the algorithm-protection attribute. The new ASN.1 definition adds COUNTS MAX 1. A human requirement becomes a schema constraint that compatible tooling can enforce. This is more than editorial tidying. It reduces the chance that prose and executable artifacts develop different rules again.

The lesson is not that prose is weak and schemas are strong. A wrong schema can scale a mistake faster than prose. The lesson is that normative prose, registries, machine-readable modules, examples and conformance tests form one publication system. Their agreement must be checked as a release property.

An erratum is a signal, not a time machine

Errata 9144 and 9145 were reported on 19 August 2026 for Appendix A and Section 2 of RFC 6211. On 13 September they remained marked Reported. That label matters: a reported erratum is not yet the same institutional object as a verified correction, and the Internet-Draft is still work in progress. Revision 00 entered LAMPS Working Group Last Call on 1 September; revision 01 followed on 9 September UTC.

Even after a correction advances, none of these mechanisms can recall every copied module. They clarify the common record. They do not enumerate libraries compiled with the old constant, devices that cannot be upgraded, archived messages encoded under it, or validation policies that silently accept neither or both.

This is why publication status and migration status must be tracked separately. A document can be corrected while an installed base remains mixed. Conversely, an operator can mitigate a known split before the standards process finishes, provided the local action is explicit, reversible where possible and does not masquerade as final IETF consensus.

Recognition is not permission to produce

The first deployment question is tempting: should a decoder accept both OIDs? The answer depends on what “accept” means.

A forensic tool may need to recognize the legacy value so an archived object can be classified. A gateway may need to detect it and report which producer emitted it. A validator may be able to parse it but refuse to treat it as satisfying an algorithm-protection policy. A producer should generally stop creating new objects with the erroneous path once the correction is adopted locally. Those four behaviors—recognize, observe, honor and emit—are not one switch.

Blind dual acceptance can turn a temporary bridge into permanent ambiguity. Immediate rejection can make historical evidence unreadable or break a dependency that cannot be updated on the same day. The useful policy is asymmetric: broad enough to measure and migrate, narrow enough to stop reproducing the error.

That asymmetry also prevents a common audit failure. A dashboard that says “both OIDs supported” hides whether the old one is merely detected, actively trusted, or still generated. The same phrase can describe a safe archive reader and a new production system that perpetuates the split.

The identifier-precedence and retirement register

Each organisation handling CMS objects needs a compact register for this conflict. It should begin with the two exact OIDs, their documentary sources and the local precedence decision. The registered S/MIME attribute path should be identified as the target encoding; the RFC's shorter path should be labelled legacy or erroneous according to the organisation's reviewed policy, not silently aliased.

For every relevant component, the register should record version, owner and four separate capabilities: which identifiers it recognizes, which it regards as policy-satisfying, which it emits, and which it preserves when reserializing an existing object. Parsers, signers, mail-security gateways, archive readers, hardware modules, mobile clients and inspection tools may need different answers.

Evidence should come from corpus tests, not configuration claims alone. Include an object using each OID, an object with no protection attribute, an object with two instances, and cases in which the named digest or signature algorithm disagrees with the surrounding CMS structure. Record the exact result and software fingerprint. The new COUNTS MAX 1 constraint deserves a test because a library may compile the module without enforcing every constraint at runtime.

The register should then name a migration window. New production of the legacy OID stops first. Detection remains so the residual population can be measured. Owners remediate producers rather than normalizing every input invisibly. Archive policy states whether old signed objects are preserved byte-for-byte, wrapped with external metadata, or rejected for a particular use. Only after observed legacy production reaches the agreed threshold—and exceptions have accountable owners—does rejection become a defensible step.

No private key or message body belongs in this register. Hashes of test objects, component versions, validation outcomes, exception identifiers and decision dates are sufficient. The aim is to prove how authority moved from a conflicting publication state to a controlled operational state.

Correction should travel with provenance

An implementation receipt for the change should answer five questions. Which source established the target OID? Which module or constant changed? Which test proves the emitted bytes? What happened to previously stored objects? Who approved the compatibility deadline?

Without those answers, a vendor can claim “RFC 6211 fixed” while changing only its encoder, leaving its validator blind to historical objects. Another can accept both indefinitely without revealing that new objects still use the wrong value. A third can rewrite archived signed material and destroy the byte-level evidence that would explain an old signature or validation decision.

Provenance makes these differences visible. It also lets buyers and operators compare implementations without demanding that every product expose identical internals. The common claim can stay small: target identifier, behavior by operation, tested version and retirement state.

A small standard still needs a release system

The current draft can remain focused. It needs to correct the OID, align the ASN.1 definition with the one-instance requirement and document the security consequence. It need not dictate one migration window for every archive, mail system or regulated environment.

That division matches Heng Lu's minimum-specification principle. The shared layer should settle the minimum fact required for interoperability: one identifier and one cardinality rule. Later decisions about historical objects, compatibility duration and upgrade risk belong near the institutions that bear their costs, provided those decisions are visible and do not alter the common wire meaning.

The Policy Mirror supplies the corresponding language discipline. “The IANA registry is correct,” “this decoder recognizes the legacy OID,” “this validator treats the attribute as effective,” and “this producer emits the corrected OID” are different statements. Combining them into “RFC 6211 supported” makes an audit tidy at the price of making it false.

The most useful outcome of this correction is not merely a repaired line in an RFC successor. It is a publication habit: validate the registry, prose, executable module and test vectors together; issue corrections with machine-testable examples; and measure what deployed systems actually emit before declaring a discrepancy retired. A registry records authority. Interoperability begins only when that authority reaches code and bytes.

Sources