Zusammenfassung

  • Seit dem 11. September 2026 ist draft-ietf-ocm-mls-federated-groups-00 ein Arbeitsdokument der Open Cloud Mesh Working Group. Es bleibt ein veränderlicher Internet-Draft, weder RFC noch Nachweis einer produktiven Einführung.
  • Ein Remove Commit schließt das Mitglied aus dem neuen MLS-Epoch aus. Im optionalen Key-Reuse-Modus bleiben Dateischlüssel und Ciphertext jedoch unverändert; der Ressourcenzugriff folgt der Mitgliedschaft dann aufgrund organisatorischen Vertrauens.
  • Ein serverbezogener Transportzugang wird separat widerrufen. Daniel Kade schlägt einen geschützten Folgenbeleg vor, der Mitgliedschaft, Dateischlüssel und Transport einzeln ausweist; er ist keine IETF- oder OCM-Vorgabe.

Die WG übernimmt einen Entwurf mit offenen Entscheidungen

Die Datatracker-Historie datiert die erste WG-Version auf den 11. September und ordnet ihr den ersetzten individuellen Entwurf zu. In der Mitteilung zum Annahmeergebnis nennen die Vorsitzenden beide Dokumente Ausgangspunkte, die durch weitere Diskussion wachsen sollen. Die OCM Working Group trägt nun die Textarbeit; eine endgültige IETF-Entscheidung ist das nicht.

Der aktuelle Datatracker-Eintrag nennt Standards Track als Ziel und März 2027 als Ablaufdatum. Revision 00 führt noch Streaming-Entschlüsselung, das Bündeln von Schlüsselmeldungen und die erneute Übertragung verpasster Commits als offene Punkte. Die beantragten Namen ocm-group-key und ocm_federated_group stehen im gesicherten IANA-MLS-Register nicht; der Erweiterungswert lautet im Entwurf noch TBD. Eine IANA-Consideration ist keine bereits vollzogene Registrierung.

Der WG-Entwurf 00 macht eine über mehrere OCM-Server verteilte Gruppe zum Empfänger einer Freigabe. Jeder Nutzer besitzt ein MLS-Blatt. Admin-Clients bauen Commits; der Group Owner Server akzeptiert einen pro Epoch; jeder Member Server prüft die Adminstellung des Unterzeichners im einschlägigen Zustand. Der individuelle Vorgänger 02 enthielt die zentrale Alternative zwischen Rotation und Wiederverwendung bereits. Die WG-Annahme macht sie überprüfbar, nicht erledigt.

Der Remove Commit beendet die aktuelle Mitgliedschaft

Nach RFC 9420 bringt ein Remove Commit neue Entropie in den Folge-Epoch, die das entfernte Mitglied nicht erhält. Welche Person eine andere entfernen darf, bestimmt die Anwendung. OCM verlangt für das Hinzufügen oder Entfernen eines anderen Nutzers eine ausdrückliche Adminfreigabe. Selbstaustritt und identitätserhaltender Rejoin haben engere Sonderregeln.

Nach Annahme des Commits fehlt das betreffende Blatt im aktuellen Baum und kann die neuen Geheimnisse nicht ableiten. Jeder Member Server wertet nach einem Commit neu aus, welche lokalen Nutzer eine an die Gruppe gerichtete Freigabe erhalten. „Mitglied entfernt“ beschreibt damit einen realen Zustandswechsel.

Eine Datei folgt einer anderen Schlüsselkette. Ein zufälliger File Key, FK, verschlüsselt die Ressource. Der aus MLS abgeleitete Group Key umhüllt den FK für die Verteilung. Ein neuer Epoch verlangt eine neue Umhüllung, aber nicht in jedem Fall einen neuen Dateischlüssel.

Eine neue Hülle kann denselben FK enthalten

Beim Re-Wrap wird der bestehende FK lediglich unter dem aktuellen Group Key verpackt. Bei der Rotation erzeugt der sendende Server einen neuen FK, verschlüsselt die Ressource erneut, verpackt den neuen Schlüssel für alle weiterhin berechtigten Gruppen und verteilt die Hüllen. Ein erfolgreicher Mitgliedswechsel kann also neben unverändertem Ciphertext stehen.

Revision 00 empfiehlt mit SHOULD eine FK-Rotation, wenn ein Mitglied aus einer berechtigten Gruppe entfernt wird. Die Regel ist nicht bedingungslos. Mehrere Gruppen können denselben Ciphertext und FK nutzen, während jede ihre eigene Hülle erhält. Ändert sich der FK, benötigen alle verbleibenden Gruppen ihre neue Hülle. Sonst scheitert der Zugriff legitimer Nutzer auf die aktuelle Fassung.

Außerdem kann die entfernte Person weiterhin einer zweiten Gruppe angehören, die dieselbe Ressource sehen darf. Der fortbestehende Zugang über diese Gruppe ist beabsichtigt. Der sendende Server darf die eindeutige Nutzermenge vor und nach dem Wechsel vergleichen und die Rotation überspringen, wenn sie gleich bleibt. Gruppenaustritt und Ressourcenentzug sind deshalb verschiedene Aussagen.

Key Reuse ersetzt Kryptografie durch eine Vertrauenspflicht

Bei großen, häufig veränderten Dateien kann Neuverschlüsselung unpraktisch sein. Eine formale Föderation mit ausdrücklicher Governance und gegenseitigem Vertrauen darf den optionalen Key-Reuse-Modus wählen. Der Epoch wechselt, die verbleibenden Mitglieder erhalten eine neue Hülle, doch FK und Ciphertext bleiben bestehen.

Der frühere Member Server kann den alten Group Key und die alte FK-Hülle gespeichert haben. Ein natives Gerät kann schon den unverpackten FK besitzen. Dieses Material entschlüsselt den unveränderten Ciphertext weiterhin. Access-follows-membership wird hier durch die Pflicht getragen, nicht mehr zustehende Schlüssel zu löschen, und nicht durch kryptografische Unbrauchbarkeit.

Der Text beschränkt diese Annahme auf formale Vertrauensbeziehungen und rät von ihr in offenen oder spontanen Freigaben ab. Er hält ebenso fest, dass der sendende Server den Modus als eigene Policy wählt und ihn im Protokoll nicht signalisiert. Wer den neuen MLS-Epoch sieht, kann daraus keine FK-Rotation ableiten.

Das ist kein Verdacht, ehemalige Server würden Schlüssel absichtlich behalten. Es ist die vom Entwurf benannte Beweisart. Eine Statusanzeige darf die korrekte Mitgliedschaftsaussage nicht zu einem kryptografischen Ergebnis ausweiten, das sie nie beobachtet hat.

Der Transportzugang hat einen eigenen Widerruf

Bei einer verschlüsselten Freigabe kontrolliert eine serverbezogene Transportberechtigung den Abruf des Ciphertexts. MLS und FK kontrollieren seine Entschlüsselung. Wird der letzte Nutzer eines Member Servers entfernt, soll der sendende Server dessen Berechtigung widerrufen und SHARE_UNSHARED senden. Der Remove Commit führt diese Schritte nicht automatisch aus.

Bis zum Transportwiderruf kann ein aus dem neuen Epoch ausgeschlossener Server den Ciphertext weiter laden. Nach dem Widerruf kann er frühere Kopien und Schlüssel behalten. Beide Schutzschichten sind sinnvoll; der Nachweis der einen ist kein Nachweis der anderen.

Bei unverschlüsselten Freigaben ist die Transportberechtigung die einzige Zugangskontrolle auf Senderseite. Dann tragen die erneute lokale Gruppenauflösung und der zügige Widerruf die gesamte Durchsetzung. Der OCM-Basisentwurf 06 liefert Freigaben und Benachrichtigungen. Die MLS-Erweiterung fügt den Gruppenlebenszyklus hinzu, ohne alles atomar zu machen.

Bereits ausgelieferte Kopien lassen sich nicht zurückholen

Eine Grenze gilt auch nach vollständiger Rotation. MLS kann ein berechtigtes Mitglied nicht daran hindern, rechtmäßig empfangenen Klartext, Group Keys oder FKs zu behalten oder weiterzugeben. Ein neuer FK schützt den neu verschlüsselten aktuellen Ciphertext vor altem Schlüsselmaterial. Er löscht weder einen früheren Export noch ein offline gespeichertes Paar aus altem Ciphertext und Schlüssel.

Die MLS-Architektur in RFC 9750 trennt das kryptografische Protokoll von Anwendungsentscheidungen und unterstützenden Diensten. MLS Virtual Clients 01 lässt mehrere Geräte einen logischen Client bilden und geheime Zustände teilen. Onboarding, Übertragung und Löschung dieses Zustands bleiben betriebliche Aufgaben an mehreren Orten.

Rotation bleibt wertvoll: Sie zieht eine Vorwärtsgrenze um die nun bereitgestellte Ressourcenversion. Die öffentliche Behauptung muss bei diesem Ergebnis bleiben und darf daraus keine rückwirkende Löschung machen.

Ein Beleg mit drei getrennten Ergebnissen

Daniel Kade schlägt einen zugriffsgeschützten Beleg der Entfernungsfolgen vor. Sein Kopf verbindet Gruppenadresse, alten und neuen Epoch, entfernte OCM-Adresse, Adminfreigabe, akzeptierten Commit und Wirksamkeitszeit. Danach folgen betroffene Ressourcen und sämtliche Gruppen, die weiterhin berechtigt sind.

Für jede Ressource hält er Rotation oder Wiederverwendung, undurchsichtige FK-Versionskennungen, Abschluss der Neuverschlüsselung, Ciphertext-Version und Zustellung der neuen Hüllen fest. Ein gesonderter Abschnitt erfasst Transportberechtigung, Widerruf und SHARE_UNSHARED. Im Key-Reuse-Modus bleibt eine Löschbestätigung eine organisatorische Attestierung und wird nicht als kryptografischer Beweis ausgegeben.

Der Beleg trägt dauerhaft den Hinweis, dass bereits ausgelieferter Klartext und Offlinekopien nicht zurückgerufen werden. Er speichert keine geheimen Schlüssel und erteilt keine Rechte. Öffentlich könnten eine undurchsichtige Kennung, Folgenklassen, Zeiten und geprüfte Resultate erscheinen; Identitäten und Topologie bleiben geschützt.

Der Beleg stammt als redaktionelle Idee von Daniel Kade; IETF, MLS und OCM schreiben ihn nicht vor. Aus Heng Lus Policy Mirror folgt, dass Zuständigkeit, Norm und Nachweis getrennt lesbar bleiben müssen. Die Minimum Initial Specification lässt einen schlanken gemeinsamen Kern zu, den stärkere lokale Aufzeichnungen ergänzen. Why BTW Media Exists verlangt, den beschriebenen Kompromiss weder anzuklagen noch zu bewerben, sondern in seinem wirklichen Umfang zu zeigen.

Quellen

  1. OCM MLS Federated Groups, WG-Version 00
  2. Aktueller Datatracker-Eintrag
  3. Datatracker-Dokumenthistorie
  4. Individueller Vorgänger, Version 02
  5. Mitteilung zum Annahmeergebnis
  6. Open Cloud Mesh Working Group
  7. RFC 9420 — Messaging Layer Security
  8. RFC 9750 — MLS-Architektur
  9. MLS Virtual Clients, Version 01
  10. Open-Cloud-Mesh-Basisprotokoll, WG-Version 06
  11. IANA-Register für Messaging Layer Security
  12. Heng Lu — The Policy Mirror
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Why BTW Media Exists