Summary

  • Revision 03 of a LAMPS Working Group draft, posted on 14 September, would update RFC 5652 and prohibit id-data for new uses of CMS SignedData.
  • It defines a new use by when a specification first defines the application—on or after publication of the future document—not by when software is implemented or deployed.
  • Existing uses receive migration and verification guidance rather than the same absolute prohibition, because an indiscriminate change can break interoperability with deployed senders.
  • The draft is active work with intended Best Current Practice status. It is not an RFC, an adopted rule, evidence of an exploit or proof that any product is vulnerable.

A boundary dated in the future

Revision 03 adds a direct proposition to both its header and abstract. If approved, it would update RFC 5652, the current Cryptographic Message Syntax standard, by prohibiting the id-data content type for new uses of CMS SignedData.

The new definition is unusually important. A new use is any specification that, from the publication date of the future document onward, first defines how SignedData is constructed or processed for an application. It does not matter whether that later specification is an RFC or registers a content-type identifier with IANA. A use that predates publication is an existing use.

That is a clear legalistic line for a technical community: before and after one publication event. It also means the line does not exist as an operative BCP today. The Datatracker record identifies an active Working Group Internet-Draft with intended BCP status. RFC 2026 is explicit that Internet-Drafts are working documents. Revision 03 can shape review now; it cannot amend STD 70 merely by being uploaded.

Specification time is not deployment time

The revision comparison introduces two clocks that should not be merged.

The definition classifies a use by the first specification date. A separate sentence says the prohibition for new uses does not retroactively affect the conformance of already deployed implementations. Those statements are compatible, but they describe different evidence. A protocol can be specified without broad deployment. An implementation can ship long after its defining text. A deployed sender can persist after a successor specification appears.

The draft does not publish a census joining those states. It does not claim to. Its appendices identify RFCs that use id-data and discuss applicability, but an RFC reference is not an installed-base measurement. Likewise, an IANA row can identify an object identifier and reference without proving which code paths accept it, whether recipients enforce signed attributes or whether one signing key crosses protocol boundaries.

This matters because the security issue turns on behaviour, not labels alone. RFC 5652 permits signedAttrs to be absent when the encapsulated content type is id-data. The draft describes how a signature can then verify over a structure the signer did not explicitly intend. It also explains important limits: some protocols mandate signed attributes; correct recipient enforcement can prevent the attack; message structure can constrain applicability; and other mitigations exist. “Existing” is therefore not a synonym for “vulnerable”, and “new” is not proof of secure implementation.

Compatibility is part of the rule

For a new use, revision 03 says id-data MUST NOT be used. When MIME is involved, the proposed mimeData content type SHOULD be used unless a more specific identifier is justified. The draft asks IANA to create module and content-type entries, but the values remain TBD. The current SMI registries and CMS Inner Content Types registry do not turn placeholders into assignments.

Existing uses follow a different route. When such a protocol is updated, it should deprecate id-data. If it retains the type, the revised text asks for a rationale so reviewers can assess the security trade-off. A backwards-compatible extension may be a poor moment to force a breaking migration; a major version or another already-breaking change may be the right moment.

That is not a loophole hidden from readers. It is the draft's stated interoperability judgment. Existing senders may not use signedAttrs as a newly tightened rule expects. A universal MUST could cause conforming new recipients to reject legitimate old traffic before a migration path exists. The governance problem is not that discretion remains. It is that future reviewers need a reproducible record of where the discretion was used and what evidence supported it.

One rule also depends on keys and applications

Revision 03 adds a section on key separation. Requiring signed attributes in one protocol is not enough if the same signing key is also used in another protocol or an older version where they are not required. The draft points to distinct keys or a mitigation applied uniformly to all signing operations with the key.

It also assigns a boundary to general-purpose CMS libraries. New uses must verify the expected content type and the required presence of signed attributes. A library that lacks protocol-specific enforcement must expose the received content type to the application layer so the application can decide.

The control surface therefore spans more than one standards sentence. Specification authors choose a content type and transition rule. Library maintainers preserve information and verification hooks. Application owners enforce the protocol-specific expectation. Key custodians determine whether one key crosses old and new contexts. IANA records identifiers. None of those actors, alone, can prove that a deployment has migrated safely.

A transition inventory, not a blanket verdict

A compact public inventory would make the publication boundary auditable. Each known CMS SignedData use could carry:

  1. the first specification and its date;
  2. the content type and the required signedAttrs state;
  3. the class of deployment evidence, without pretending to count what is unknown;
  4. whether signing keys may cross protocols or versions;
  5. the next plausible breaking-change or coordinated migration point;
  6. the reason to retain or replace id-data;
  7. the specification owner, next review date and correction history.

This is Daniel Kade's proposed record, not a requirement in the draft. It would not label every old use unsafe. It would let reviewers distinguish an old specification with enforced signed attributes from an old deployment whose behaviour is unknown, and both from a new specification that must follow the prospective rule.

The publication date can remain the formal line. The inventory supplies the operational map around it.

Sources