Summary

  • draft-ietf-ocm-mls-federated-groups-00 became an Open Cloud Mesh Working Group item on 11 September 2026. It is a developing Internet-Draft, not an RFC or proof of an operating service.
  • An MLS Remove Commit excludes a member from the new group epoch. The sending server may still keep the existing file key in the draft’s optional key-reuse mode, so cryptographic resource revocation has not occurred.
  • Transport credentials form a third control layer. Daniel Kade proposes a protected removal-consequence receipt that records membership, resource-key and transport outcomes separately; it is editorial analysis, not an IETF requirement.

The group adopted a problem, not a deployed answer

The Datatracker history dates the first Working Group version to 11 September and links it to the individual submission it replaces. The chair’s result message calls both adopted OCM documents starting points that will continue to change. That is the precise news boundary: the OCM Working Group now owns this work, while the text remains a proposal under review.

Revision 00 has a Standards Track intention, but intention is not approval. It expires in March 2027 unless it is refreshed, still has an open-issues section, and asks for registry entries that do not yet exist as finished assignments. The captured IANA MLS registries contain neither the proposed ocm-group-key exporter label nor an ocm_federated_group extension. The draft itself still marks the extension value TBD.

The mechanism is ambitious. The current WG draft uses Messaging Layer Security to let a group span OCM servers. Each user has one leaf in the MLS tree. Admin clients construct membership-changing Commits; a Group Owner Server chooses one Commit for an epoch; every Member Server verifies that its signer was an admin in the relevant group state. A stable group address names the receiving party even when members and the owner server change.

The individual revision 02 already contained the central resource-key trade-off. Becoming a WG document did not settle that trade-off. It brought it into the group’s revision process.

A Remove Commit closes one door

RFC 9420 gives a Remove Commit new entropy for the next epoch that is unavailable to the removed member. It deliberately leaves eviction authority to the application. The OCM draft supplies an application rule: adding or removing someone else requires explicit admin approval, whereas self-removal and an identity-preserving rejoin follow narrower paths.

Once the accepted Commit advances the epoch, the removed leaf is outside the current group key schedule. Receiving servers must re-evaluate which local users a group share resolves to after every Commit. At the membership layer, “removed” therefore has a concrete meaning: the user is absent from current group state and cannot derive new epoch secrets through that leaf.

That transition says nothing yet about the encryption key for an existing file. OCM gives a shared resource its own random file key, or FK. The FK encrypts the resource; the MLS-derived Group Key encrypts a wrapper around the FK. When the epoch changes, re-wrapping the same FK and rotating the FK are different acts.

Re-wrapping updates the envelope. Rotation creates a fresh FK, encrypts the resource again, wraps the new key for every group that still has access and distributes the new wrappers. A green MLS Commit can prove the roster moved forward while the current ciphertext and the key that opens it remain unchanged.

Key reuse turns revocation into a trust claim

The draft recommends FK rotation after a member is removed, but it does not make rotation unconditional. Where re-encryption is impractical and all participating servers belong to a formally governed, mutually trusted federation, a sending server may choose key-reuse mode. The old FK stays in service. Only its wrapper is refreshed under the new Group Key for the remaining members.

The document is unusually candid about the consequence. A former Member Server, or the former user’s native device, may retain an older Group Key and wrapped FK—or an already unwrapped FK. Any of those can still decrypt unchanged ciphertext. Access follows membership in this mode because the federation trusts participants to discard key material they no longer deserve, not because the old material has ceased to work.

Most importantly for governance, the sending server chooses between rotation and reuse as local policy, and the choice is not signalled in the protocol. A remote participant that sees a valid new epoch cannot infer which resource policy ran. Nor can a compliance dashboard derive cryptographic revocation from the absence of a user in the latest tree.

This is not a hidden flaw discovered outside the document. Revision 00 states the trade-off. The governance mistake would be to flatten two accurate statuses—“membership removed” and “file key reused”—into one ambiguous success badge.

One file can belong to several groups

Rotation also has a larger blast radius than the departing group. The draft permits one encrypted resource to be shared with several groups while using one ciphertext and one FK. Each group receives a different wrapper for that common file key. If the sending server rotates the FK, it must distribute a valid new wrapper to every group that retains access; otherwise those users hold wrappers that no longer open the current ciphertext.

A user removed from Group A may remain in Group B, and Group B may still be entitled to the same file. That continuing access is correct. The draft even permits skipping rotation when the unique set of authorised users did not change. Thus “removed from a group” is not automatically “removed from a resource.” The operator needs the group-to-resource map before it can state the latter.

This distinction protects both directions of the decision. It prevents an operator from claiming revocation where another valid group path remains. It also prevents an unnecessary global re-encryption from being reported as the only safe answer when the authorised user set is unchanged.

The transport credential has its own clock

An encrypted OCM federation share has two access controls. A per-server transport credential decides which Member Server can fetch ciphertext. MLS and the FK decide who can decrypt it. When the last user homed on a server leaves, the draft says the sending server should revoke that server’s transport credential and send SHARE_UNSHARED. Those acts are not the Remove Commit.

The separation matters because the layers can disagree temporarily. A departed server may be outside the new MLS epoch yet still be able to fetch ciphertext until its transport credential is withdrawn. Conversely, successful transport revocation does not prove that cached file keys disappeared. For an unencrypted share, transport and current local membership resolution are the only access boundary, so treating the transport outcome as optional evidence would miss the principal control.

The base OCM draft supplies the share and notification framework. The MLS extension layers a group lifecycle over it; it does not fuse all consequences into one transaction.

No removal can recall a received copy

The security limit is broader than key-reuse mode. The draft says MLS cannot stop an authorised member from keeping or disclosing plaintext, a Group Key or an FK that it legitimately received. A full FK rotation can stop old key material from opening the new current ciphertext. It cannot reach into an offline device and erase an old plaintext export or a saved ciphertext-key pair.

The MLS architecture separates the cryptographic group from the application and its supporting services. The Virtual Clients draft adds another custody reality: several devices can act as one MLS client, so onboarding, state transfer and deletion across those devices become application duties. “User removed” should never be presented as retrospective destruction of every copy.

That limit does not make rotation pointless. Rotation creates a useful forward boundary around the version the sending server now serves. It simply needs an honest verb: the current resource was re-encrypted under a new key, not the past was erased.

Record the three consequences

Daniel Kade proposes a protected removal-consequence receipt. It would bind the group address, old and new epoch, removed OCM Address, admin approval and accepted Commit to a list of affected resources. For each resource it would record whether the sending server selected FK rotation or reuse, whether re-encryption completed, which still-authorised groups received new wrappers and what current ciphertext version resulted.

A separate row would track the former Member Server’s transport-credential version, revocation outcome and SHARE_UNSHARED delivery. Where key reuse depends on organisational promises, a key-deletion attestation could be recorded as a trust statement—never promoted into cryptographic proof. Every receipt would carry the permanent caveat that previously delivered plaintext and offline copies cannot be recalled.

This is an editorial proposal, not text required by OCM, MLS or IETF. It must contain opaque key-version identifiers, not secret keys. A public summary could expose a receipt identifier, consequence classes, effective times and verified results; user identities, server topology and key material stay access controlled.

The separation follows Heng Lu’s Policy Mirror: the authorised actor, governing rule and observed evidence do different jobs. The Minimum Initial Specification allows a small common protocol to coexist with stronger local records. And Why BTW Media Exists supplies the editorial discipline here: report the key-reuse choice as the draft describes it, neither as a scandal nor as a guarantee.

Sources

  1. OCM MLS Federated Groups, WG revision 00
  2. Current Datatracker record
  3. Datatracker document history
  4. Individual predecessor, revision 02
  5. OCM chair adoption-result message
  6. Open Cloud Mesh Working Group
  7. RFC 9420 — Messaging Layer Security
  8. RFC 9750 — MLS Architecture
  9. MLS Virtual Clients, revision 01
  10. Open Cloud Mesh base protocol, WG revision 06
  11. IANA Messaging Layer Security registries
  12. Heng Lu — The Policy Mirror
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Why BTW Media Exists