Summary

  • RFC 3185 let a CMS content-encryption key from one object supply key-encryption material for later objects, reducing repeated asymmetric work but creating state that outlived the first envelope.
  • If MSG1 reached recipient set S1 and MSG2 visibly named only a subset, every member of S1 could still derive the key needed for MSG2. Omission from the later list was not revocation of authority already delivered.

Call the first encrypted object MSG1. It goes to five recipients. Later, MSG2 goes to two. A viewer inspecting MSG2 might infer that the other three have been excluded. RFC 3185 makes that inference unsafe: when MSG2’s key-encryption key is derived from MSG1’s content-encryption key, all five holders of the old key can still obtain the new content key.

That boundary sat inside a compact Standards Track document published in October 2001, Reuse of CMS Content Encryption Keys. The RFC Editor lists it as Proposed Standard. Its purpose was efficiency. CMS EnvelopedData supported symmetric content encryption with symmetric or asymmetric key management, and asymmetric establishment could be expensive. A client might encrypt several fields separately in one transaction, or two servers might exchange protected objects frequently. Reusing established symmetric material could avoid repeating costly work.

The RFC did not describe a universal session protocol. It called its mechanism a “trick” that required a larger context. That context had to decide what happened when stored key state was lost. The cryptographic API had to expose or transform the needed key material. The content-encryption and key-encryption algorithms had to accept compatible key formats and strengths. The design was explicitly not general group-key management.

Its basic move linked two representations. MSG1 carried an unprotected CEKReference attribute: an identifier for the content-encryption key used in MSG1. MSG2 used the same value as its KEKIdentifier. The reference was not the secret. It let a recipient find the secret CEK already retained from MSG1 and derive the key-encryption key, or KEK, needed to unwrap MSG2’s new CEK.

When the key formats matched, the derivation was byte reversal. RFC 3185 did not choose that operation as a modern general-purpose key-derivation recommendation. It chose it to prevent a particular known-plaintext and ciphertext block from being used directly as MSG2’s encrypted key material. When the algorithms required different key lengths or formats, an optional attribute specified a PBKDF2 derivation using the earlier CEK as input instead of a password. Those 2001 algorithm choices belong to their historical context. Later CMS, PBKDF2 and key-wrap RFCs do not silently rewrite them.

The mechanism turned a message into a source of future authority. Whoever legitimately received MSG1 and retained its CEK acquired the ability to participate in the derivation chain. A later sender could alter MSG2’s recipient fields, but those fields did not erase earlier possession. The real decryption-capable population was determined by key-delivery history plus retention, not by the latest envelope alone.

This is the article’s term recipient-set persistence: the effective set can inherit members from a previous object even when the declared set contracts. It is not RFC terminology, and it is not a claim about every CMS exchange. It describes the explicit S1/subset consequence in RFC 3185. A member without the referenced CEK does not gain access merely by knowing the reference value.

The distinction resembles revocation without being a complete revocation protocol. Removing a name from a new representation is a decision about what the sender now declares. Revoking a previously delivered cryptographic capability requires new key material whose derivation excludes that holder, plus evidence that the old capability is no longer accepted. The RFC’s reuse path did the opposite for efficiency: it deliberately depended on old possession.

CEKMaxDecrypts added a lifetime hint. An originator could state how many later ciphertexts would reuse the referenced CEK. The originator had to honor the number; the recipient treated it as a hint, retaining the reference and CEK while expecting more messages and deleting the state after local time limits. If the attribute was absent, the parties behaved as if one reuse were planned.

The number was not a remote eraser. It did not prove that every recipient counted the same successful messages, that all copies were deleted after the limit, that storage had been wiped, or that an offline holder had forgotten the CEK. A very large value—or promised ciphertexts that never arrived—could make a recipient retain state and consume memory. RFC 3185 therefore left recipients to impose local size and time limits.

The security section drew two more boundaries that product language often loses. Encryption did not authenticate the originator. Anyone could construct an EnvelopedData object containing a known reference value; recognition of CEKReference proved neither who sent the object nor that the originator was genuine. Correct reference use also did not prevent replay or insertion. Separate authentication, integrity, ordering and freshness evidence remained necessary.

Successful decryption was equally bounded. It showed that a recipient located key material and parameters that yielded acceptable plaintext under the checks actually performed. It did not prove that the message was fresh, authorized, delivered to every intended recipient, unavailable to omitted recipients, safely handled after decryption or accepted by the application.

The default one-step reuse could form a rolling chain. MSG[n] used a KEK derived from MSG[n−1]’s CEK, while a fresh random CEK in MSG[n] could become the basis for MSG[n+1]. RFC 3185 warned against deriving a message CEK back from its own KEK in a way that could create an unexpected fixed key. The chain therefore had to preserve both provenance and independence: which earlier CEK authorized which later unwrap, and whether the new CEK was actually fresh.

Failure also needed vocabulary. An unsupported derivation attribute, a missing reference, locally expired state, an incompatible algorithm, wrong key material or altered parameters might all surface as “could not decrypt.” The RFC recommended signaling the particular reason to the calling application. Without that distinction, operators could mistake policy eviction for corruption, or an unsupported feature for an attack.

RFC 3185’s historical lesson is not that efficiency was a mistake. It is that cryptographic authority follows material already distributed, not the latest list displayed by software. The latest CMS object is one representation. The effective reader set is a claim about custody across time. To know who could read MSG2, an investigator needs MSG1’s delivery evidence, retained CEK state, derivation parameters, local expiry decisions and decryption observations—not merely MSG2’s visible recipients.