Zusammenfassung

  • RFC 9420 beschreibt, wie authentisierte MLS-Clients durch Proposals und einen Commit in eine neue gemeinsame Epoche übergehen.
  • Dieser Übergang belegt einen begrenzten Protokollzustand, nicht menschliche Kenntnis, Zustimmung, institutionelle Befugnis, vollständige Zustellung oder ein eingetretenes Geschäftsergebnis.

„Die Gruppe hat entschieden“ klingt nach einem einzelnen Ereignis. In Wirklichkeit kann der Satz eine Nachricht, die Verarbeitung eines Endpunkts, eine erfüllte Anwendungsregel, bestätigte Verarbeitung, eine formale Freigabe oder eine bereits ausgelöste Außenwirkung meinen. Diese Aussagen haben verschiedene Beweisquellen. Es ist ein Fehler, die Präzision eines kryptografischen Artefakts als stillschweigenden Beweis für alle übrigen Aussagen zu benutzen.

Messaging Layer Security löst ein engeres Problem: die fortlaufende, authentisierte Aushandlung gemeinsamer Schlüssel durch eine Gruppe von Clients. Eine Gruppe ist in RFC 9420 eine logische Sammlung von Clients mit einem gemeinsamen Geheimnis. Ihre Geschichte bildet eine lineare Folge von Epochen. In jeder Epoche besitzt eine bestimmte Menge authentisierter Clients gemeinsamen kryptografischen Zustand.

„Client“ ist hier kein Synonym für Mensch oder Organisation. Der RFC definiert einen Client über die kryptografischen Schlüssel, die er hält. Er definiert ihn nicht als Mitarbeiter, Amtsträger, Abteilung oder Rechtssubjekt. Ein Authentication Service kann innerhalb seiner eigenen Richtlinie Credentials prüfen und eine Zuordnung für den Protokollkontext liefern. Daraus wird weder die Lektüre einer Proposal noch Vertretungsmacht noch eine wirksame Zustimmung.

Die technische Zustandsänderung ist klar. Eine Proposal schlägt eine Änderung der Gruppe vor, etwa Hinzufügen, Aktualisieren oder Entfernen eines Mitglieds. Ein Commit implementiert die in einer Menge von Proposals vorgeschlagenen Änderungen. Beim Erzeugen oder Verarbeiten eines Commit schreitet der Client mit Ratchet Tree und GroupContext vom alten Zustand zum Zustand der neuen Epoche fort. Der GroupContext enthält unter anderem Gruppen-ID, Epochenzahl, Tree Hash und bestätigten Transcript Hash.

Werden Clients hinzugefügt, erzeugt der Commit-Ersteller zugleich das passende Welcome, damit sie ihren Anteil am resultierenden Zustand aufbauen können.

Damit lässt sich präzise sagen: Unter den Validierungsregeln von MLS wurde ein bestimmter Zustandsübergang verarbeitet. Transcript und Confirmation verknüpfen die definierten Protokollmaterialien über Epochen hinweg. Der Schlüsselmechanismus schützt Gruppengeheimnisse unter den im RFC genannten Voraussetzungen. Ein Commit ist also mehr als eine bloße Anzeige. Aber er ist kein Sitzungsprotokoll, keine Abstimmung, kein Vertragsschluss, keine Budgetfreigabe und kein Nachweis dafür, dass eine Betriebsänderung ausgeführt wurde. Er schreibt Proposals in einen kryptografischen Gruppenstatus ein.

Das Zustellungsmodell des RFC macht diese Beschränkung praktisch relevant. MLS setzt einen vertrauenswürdigen Authentication Service zur Credential-Prüfung und einen Delivery Service zum Routen der Nachrichten voraus, der weitgehend nicht vertrauenswürdig ist. Ein kompromittierter Delivery Service kann keine gültigen MLS-Nachrichten fälschen. Er kann jedoch Nachrichten selektiv verzögern oder entfernen, den Verkehr eines Mitglieds dauerhaft blockieren und — wenn die Anwendung ihm die Auflösung gleichzeitiger Commits überlässt — beeinflussen, welcher Commit angewandt wird.

Ein gültiger Commit ist deshalb keine Quittung für vollständige Verteilung. Er kann einen Zustandsübergang zeigen, ohne zu zeigen, dass alle relevanten Clients die Informationen rechtzeitig erhielten. Abgesehen vom Senderdaten-Generationswert überlässt RFC 9420 die Verlustfeststellung der Anwendung. Wer Reichweite, Fristen und Lücken belegen muss, benötigt ein eigenes Zustellungs- und Anwendungsprotokoll. Das Ausbleiben einer Fälschung ist kein Beleg für flächendeckende Kenntnis.

Auch bei der Verarbeitungsbestätigung zieht der RFC bewusst eine Linie. In einer asynchronen Anwendung können die Mitglieder, die einen fehlerhaften Commit erkennen könnten, offline sein. Der entstandene Zustand kann Grundlage weiterer Commits werden; die betroffenen Clients können später nicht mehr aufschließen. Eine Anwendung kann vor der Annahme eines Commit erfolgreiche Verarbeitungsbestätigungen verlangen. MLS liefert für diesen Zweck jedoch keinen eingebauten Bestätigungsmechanismus.

Mindestens vier Dinge müssen daher getrennt bleiben: Der Commit existiert. Die Anwendung betrachtet ihn als akzeptiert. Die nach ihrer Regel nötigen Bestätigungen liegen vor. Eine zuständige Institution hat eine Entscheidung getroffen. Das Protokoll erfasst den ersten Sachverhalt in seinem Rahmen. Die Anwendung verantwortet den zweiten und dritten. Die Institution verantwortet die Entscheidung, die Ressourcen, Pflichten oder externe Wirkungen bindet.

Ein belastbares Kontrollprotokoll bewahrt diese Schichten: MLS-Gruppen-ID und Epoche, Commit und Proposals, Credential-Kontext, Zustellungsbeobachtungen, Bestätigungsregel mit Schwelle und Frist, lokale Entscheidung und ausgeführte Aktion. Dann kann eine spätere Prüfung getrennt klären, was sich im Protokoll änderte, was Endpunkte verarbeitet haben, was die Anwendung akzeptierte und was außerhalb des Systems tatsächlich geschah.

Lu Hengs Unterscheidung von Repräsentation, lokaler Entscheidung und ausgeführtem Ergebnis dient hier als Denkdisziplin. Die MLS-Epoche ist eine präzise technische Repräsentation. Ihre Genauigkeit bleibt nur erhalten, wenn sie nicht die Befugnis einer Entscheidung oder die Realität ihres Ergebnisses übernehmen muss.

Sources