Summary

  • RFC 5275 separates membership administration from cryptographic possession: a removed member that retains the shared key can still decrypt obtainable traffic until the group is rekeyed.
  • A defensible exit therefore needs evidence for the effective roster generation, replacement-key scope, delivery, activation, old-key retirement and residual ciphertext exposure—not merely a successful delete request.

The easiest group-security report to misunderstand is the one with a green check beside “member deleted.” It answers a legitimate administrative question. It does not answer the operational one: can the former member still turn ciphertext into plaintext?

RFC 5275, the IETF’s Standards Track specification for CMS symmetric-key management and distribution, refuses to collapse those questions. Its security considerations say that when a member is removed from a closed or managed group list, the group needs to be rekeyed. If that does not happen, the former member still possesses the group key and can decrypt messages it can obtain. The sentence is small; the control consequence is large. A roster is an assertion about entitlement. A key is a capability.

The list has two kinds of state

RFC 5275 divides responsibility between a Group List Owner and a Group List Agent. The owner establishes the list, chooses whether it is unmanaged, managed or closed, and can govern membership and rekey policy. The agent performs group and key-management functions and signs the glKey objects that deliver shared key-encryption keys, or KEKs. Only the owner and agent can initiate a group rekey.

A signed glDeleteMember request can come from an owner, or from a member seeking its own removal where the administration model permits it. That signature proves an instruction attributable to an authorized party. The agent must still process it against the right list and subject. For managed and closed lists, the owner must also guard against the departing party appearing twice under different membership records. Otherwise one identifier can disappear while another continues receiving keys.

The standard’s procedure joins deletion and rekey for closed or managed lists. That pairing is not ceremonial. Deletion creates a new membership claim; rekey creates a new cryptographic generation for the remaining members. Neither operation proves the other completed.

A rekey has more than one finish line

The glKey structure carries the group name, a key identifier, a wrapped KEK, its algorithm and its validity interval. It is signed by the Group List Agent. When members must not learn one another’s identities, the agent sends separate key messages to each recipient. A rekey can also request that every outstanding group key be reissued through glRekeyAllGLKeys.

Those mechanics reveal at least six states that an operations report should keep separate:

  1. the deletion instruction was accepted;
  2. a membership generation excluding every identity of the subject became effective;
  3. replacement keys were generated for that generation;
  4. each continuing member received the right wrapped key object, while failed deliveries remained visible;
  5. senders and recipients activated the new generation at a defined cutover;
  6. old and pre-distributed keys were retired wherever the system could enforce retirement.

“Rekey sent” proves only a transition attempt. Even a signed success response from the agent is evidence about the agent’s processing, not universal proof that every endpoint accepted the new key, ceased using the old one or erased every stored copy. RFC 5275 does not supply a magical remote-erasure receipt. A serious control design must admit that limit.

Continuity stock is authority stock

The standard lets a list distribute more than one key in advance. generationCounter determines how many keys are distributed or kept outstanding, while duration determines their validity periods. At least two are initially delivered to support uninterrupted operation. This is excellent for continuity and dangerous for complacency.

RFC 5275 gives a deliberately stark example: a generation counter of 14 with one-year durations exposes the final key to at least a 13-year attack window. The observation changes how removal must be scoped. If a former member already holds keys for future periods, rotating only the currently active key may leave future authority intact. The revocation set is not “today’s key”; it is every current and pre-positioned key reachable from the member’s possession.

There is a second inheritance rule. A KEK can wrap another KEK, which can wrap another. If any key in that chain is compromised, the specification says every subsequent key in the chain must also be considered compromised. Rekeying is therefore a graph problem. The safe boundary closes over descendants, not merely the one identifier named in the incident ticket.

Signatures need context, and freshness needs memory

Members that store KEKs must associate them with the name of the agent that distributed them, so subsequent rekeys can be checked as coming from the same entity. That requirement is easy to understate. A mathematically valid signature does not establish that a message belongs to the correct group history. Group name, distributor identity, key identifier, validity interval and prior generation all form part of the acceptance context.

The same discipline applies to replay defense. RFC 5275 uses nonces and signingTime, but warns that they help only if participants retain enough state to compare messages. Clocks can drift, local policy sets the acceptable window, and implementations must handle timestamps that claim to be in the future. A timestamp without remembered history is formatted data, not freshness proof.

The ciphertext does not obey the roster

Changing the key for new traffic limits future use of the old capability. It does not recall ciphertext already copied from mail, repositories, queues or backups. Nor can it prove that a former member deleted plaintext or cached key material. Residual exposure is the intersection of two things: ciphertext the party can obtain and key material the party still possesses.

That distinction avoids two opposite errors. The first is declaring victory from the administrative record. The second is pretending that no useful containment is possible because perfect erasure cannot be proven. A defined cutover, a complete successor-key scope and the end of old-key use can sharply reduce prospective exposure even when historic copies remain outside control.

This is the reality-layer lesson in precise form. The list says who is recognized. Running systems determine who can still decrypt. The former is necessary evidence. It is not the latter.

What a removal receipt should contain

RFC 5275 does not prescribe a modern transparency ledger, endpoint attestation scheme or universal destruction proof. But its separations support a defensible evidence model. A removal receipt should bind the signed instruction to the exact subject and list; identify the effective roster generation; enumerate current, future and chained keys within revocation scope; record replacement generation and per-recipient distribution results; state the activation boundary; record old-key disablement where measurable; and disclose unresolved copies or ciphertext exposure.

That receipt should preserve failures rather than summarize them away. One unreachable continuing member creates a decision: delay cutover, exclude that endpoint, or accept a documented availability risk. One unknown duplicate identity keeps the roster state unresolved. One pre-distributed successor key reachable through an old wrapping chain keeps the cryptographic state unresolved.

The result is not bureaucratic thickness. It is a narrow proof of the transitions that running systems actually require.