Zusammenfassung

  • Am 28. September setzte die IETF Key Transparency Architecture auf AD Evaluation::Revised I-D Needed, nachdem die Security Area Director eine Trennung von Label-Eigentümer und vertrauender Partei verlangt hatte.
  • Eine gültige Suche oder signierte Baumspitze sagt nicht automatisch, wer die Bindung ändern durfte, welche Zugriffsentscheidung die Abfrage zuließ und wer weiter überwachen muss.
  • Nötig ist ein rollenqualifizierter Prüfbeleg mit Eigentümer, Rolle des Anfragenden, Autorisierung, Betriebsmodus, Unterzeichner, Zeitgrenzen, Vorzustand und offener Überwachungspflicht.

Der kryptografische Teil kann einwandfrei enden. Der Suchbeweis stimmt, die Signatur der Baumspitze ist gültig und die neue Sicht setzt die gespeicherte Sicht des Clients fort. Dennoch bleibt offen, wessen Entscheidung eigentlich bestätigt wurde.

War der Anfragende Eigentümer des Labels oder eine Partei, die den öffentlichen Schlüssel eines anderen für eine verschlüsselte Beziehung benötigt? Welche Regel erlaubte die Offenlegung? Wer durfte einen neuen Wert einstellen? Wer muss später prüfen, ob eine junge Version nicht verschwand, bevor ihr Eigentümer sie sehen konnte? Ein boolesches Ergebnis beantwortet das nicht.

Am 28. September 2026 veröffentlichte Deb Cooley als IETF Security Area Director ihre Kommentare zur Revision 09 der Key Transparency Architecture. Die Datatracker-Historie verzeichnet den Wechsel zu AD Evaluation::Revised I-D Needed. Das Dokument bleibt ein Internet-Draft mit Zielstatus Informational RFC; es ist weder veröffentlichter Standard noch Nachweis einer Implementierung.

Der wichtigste Kommentar wirkt wie Terminologiearbeit. Der Entwurf definiert User / Account, verteilt später aber verschiedene Pflichten an den „label owner“ und an einen Nutzer, der ein fremdes Label abfragt. Cooley schlägt vor, Letzteren als relying party zu benennen. Der Eigentümer ist Gegenstand der Bindung, die vertrauende Partei trifft auf ihrer Grundlage eine Entscheidung. Rechte und Folgeverantwortung unterscheiden sich.

Key Transparency schützt eine Schwachstelle verschlüsselter Kommunikation. Der Dienst verteilt häufig die öffentlichen Schlüssel der Teilnehmer. Ordnet er einem Konto unbemerkt einen vom Angreifer kontrollierten Schlüssel zu, kann Verschlüsselung technisch gelingen und trotzdem die falsche Beziehung schützen. Die Architektur legt Identitäts-Schlüssel-Bindungen deshalb in ein kryptografisch geschütztes Append-only-Protokoll. Search, Update und Monitor liefern Beweise; spätere Antworten müssen zur zuvor gesehenen Client-Sicht passen.

Eine Abspaltung bleibt erhalten, wird aber nicht von selbst entdeckt. Dafür braucht es zusätzlich einen vertrauenswürdigen Dritten, einen anonymen Abfrageweg oder Peer-to-Peer-Vergleich. Der Dritte signiert eine aktuelle Baumspitze; damit entsteht die Annahme, dass er nicht mit dem Log kolludiert. In den anderen Varianten sucht der Client selbst nach widersprüchlichen Sichten. Der Beweis ist Teil fortlaufender Beobachtung.

Die drei Betriebsmodi verteilen diese Aufgabe unterschiedlich.

Bei Contact Monitoring kontrolliert der Label-Eigentümer regelmäßig den neuesten Wert. Wer eine gerade eingefügte Version abgerufen hat, prüft später, ob sie lange genug sichtbar blieb. Der nötige Monitor-Aufruf muss auch dann erlaubt bleiben, wenn Search oder Update inzwischen gesperrt sind. Gegenwärtiger Entzug löscht keine Beweispflicht aus einer früher berechtigten Beobachtung.

Bei Third-Party Auditing betreibt das Log den Großteil des Systems; ein Auditor signiert periodisch seine Sicht. Aussagekraft hängt von Startposition und maximalem Rückstand ab. Eine echte Signatur kann für eine Entscheidung dennoch zu alt sein.

Bei Third-Party Management übernimmt ein Manager Speicherung und Betrieb, während der Dienstanbieter Zugriffskontrolle und Authentisierung neuer Label-Versionen behält. Das Modell setzt fehlende Kollusion voraus. Die Prüfung verlangt eine gültige Suche im Diagramm, damit nicht nur Alices Zugriffe auf den eigenen Eintrag, sondern auch der Weg einer vertrauenden Partei sichtbar wird.

Das Key Transparency Protocol macht die Unterschiede zu Konfigurationsdaten: Modus, Signatur- und VRF-Schlüssel, angemessenes Überwachungsfenster sowie gegebenenfalls Auditor-Schlüssel, Startposition und maximale Verzögerung. „Signatur gültig“ verliert ohne diese Angaben seinen institutionellen Gehalt.

Auch der Client-Zustand ist Sicherheitsbestandteil. Die alte Sicht bindet die neue. Geht sie verloren, sinkt die Fähigkeit, Abspaltungen oder später verdeckte Daten zu erkennen. Für kurzlebigen Zustand wie Webseiten oder adversativ auslösbaren Verlust empfiehlt der Entwurf Third-Party Management. Die Prüfung fordert Beispiele und eine klarere Beschreibung des „dauerhaft ungültigen Zustands“, dessen Erkennung noch begrenzte Online-Zeit erfordern kann.

Zugriffspolitik bleibt bei der Anwendung. Sie kann Suchen auf Kontakte beschränken, Anmeldung fordern oder Raten begrenzen. Der Log-Beweis bestätigt die Verarbeitung, nicht die Berechtigung zur Offenlegung gegenüber diesem Anfragenden. Deshalb soll der Text „Freunde“ und Zugriffssprache in eine konsistente ACL-Terminologie überführen.

Datenschutz und Löschung folgen einem weiteren Zeitplan. Nutzerdaten können nach Ablauf oder dauerhafter Unzugänglichkeit entfernt werden, während kryptografisches Material bis zur Höchstlebensdauer nötig bleibt. Eine verifizierbare Zufallsfunktion verbirgt Labels. Die Prüfung schlägt vor, RFC 9381 normativ zu machen, falls VRF-Verständnis erforderlich ist, und Datenschutzabschnitte zusammenzuführen.

Auch die Dokumentabhängigkeit zählt. Der Shepherd bezeichnet die Architektur als Grundlage des Protokolls. Soll sie zuerst erscheinen, müssen Protokollverweise Beispiele bleiben. Zu erklären ist außerdem der Bezug auf die implementierte Certificate-Transparency-Fassung RFC 6962 gegenüber RFC 9162. MLS liefert Nachrichtenkontext, aber keinen KT-Einsatznachweis.

Die betriebliche Antwort ist kein weiterer Hash, sondern ein rollenqualifizierter Beleg. Neben Beweis und Label-Version gehören Rolle, Eigentümer, Richtlinie und Version, Modus, Unterzeichner, Baumgröße und Zeit, zulässiger Rückstand, vorheriger Client-Zustand und offener Monitor-Schritt hinein. Damit lassen sich ungültiger Beweis, unberechtigte aber korrekt bewiesene Offenlegung, veraltete Auditorsicht, unterlassene Überwachung und Zustandsverlust unterscheiden.

Revision 10 kann andere Formulierungen wählen. Die Grenze bleibt: Ein Append-only-Verlauf macht Täuschung erkennbar; explizite Rollen bestimmen, wer sie erkennen muss.

Quellen