Zusammenfassung

  • In draft-ietf-keytrans-architecture-09 leitet ein Tombstone im alten Log die Label-Suche zum neuen Log und verhindert, dass dessen Nichterreichbarkeit einen veralteten Wert reaktiviert.
  • Derselbe Entwurf verlangt die getrennte Überwachung beider Logs und den Weiterbetrieb des alten Logs, bis auch länger offline gewesene Nutzer ihre Überwachung abschließen konnten.
  • Eine Stilllegung braucht deshalb einen Log-Ausmusterungsbeleg: finaler Head, Verteilung, Client-Kohorten, Abschlussnachweise, Ausnahmen, Entscheidungsbefugnis und Wiederherstellungsbedingung. Dieser Beleg ist ein Vorschlag des Artikels, keine KEYTRANS-Vorgabe.

Ein selten genutztes Gerät kehrt nach Monaten zurück. Es besitzt noch einen Tree Head von vor der Migration. Inzwischen wurden die aktuellen Schlüsselbindungen in ein neues Log übertragen, im alten Log Tombstones gesetzt und der alte Endpunkt nach einer scheinbar erfolgreichen Umstellung entfernt. Der Client kennt das neue Ziel. Was ihm fehlt, ist der überprüfbare Weg von seinem gespeicherten Zustand zum letzten Zustand des alten Logs.

Der Architekturentwurf benennt den Schaden: Wird das alte Log beendet, bevor ein Nutzer seine Überwachung abschließen kann, kann dieser Nutzer bestimmte Formen von Fehlverhalten des alten Logs nicht mehr erkennen. Eine erfolgreiche Datenübernahme beendet also nicht automatisch die Beweispflicht.

Der Tombstone ordnet Suchpfade. Er ist kein Stilllegungsbeschluss.

Schutz vor dem Rückfall auf einen alten Schlüssel

Auch Ende-zu-Ende-verschlüsselte Dienste lassen die Zuordnung von Identität und öffentlichem Schlüssel häufig vom Anbieter verteilen. Ein kompromittierter Anbieter könnte Schlüssel ersetzen oder Gruppen unterschiedliche Ansichten zeigen. Key Transparency soll diese Zuordnungen in einem durch Kryptografie geschützten, durchsuchbaren Log überprüfbar machen.

Die KEYTRANS-Charta zieht eine wichtige Grenze. Der Mechanismus ist ein Baustein und keine vollständige Nachrichtenanwendung. Kontowiederherstellung, Client-Lebensdauer, Authentisierung und Dienstinteroperabilität liegen außerhalb dieses einen Standards. Gerade deshalb muss ein Betreiber selbst erklären, wie lange er alte Client-Zustände unterstützt.

Ein Log-Wechsel kann durch neue Schlüssel, Cipher Suites, Betriebsmodelle, Skalierung oder Fehlerbehebung notwendig werden. Der Entwurf empfiehlt Clients, mehrere unabhängige Logs behandeln zu können. Für Search, Update und Monitor brauchen alle Nutzer eine konsistente Zuordnungsregel.

Bei schrittweiser Migration fragt Search zuerst das alte Log. Nur wenn dessen jüngste Label-Version ein anwendungsspezifischer Tombstone ist, folgt die Suche dem neuen Log. Normale Updates gehen ins neue; das alte erhält noch den fehlenden Tombstone. Ist das neue Log nicht erreichbar, darf der Client deshalb nicht auf den Wert vor der Migration zurückfallen.

Der Marker belegt den Ort der jüngsten Version. Er bestätigt nicht die inhaltliche Richtigkeit, die Prüfung durch den Label-Inhaber, die Zustellung an alle Clients oder den Abschluss der alten Überwachung.

Zwei Logs erzeugen zwei offene Abschlüsse

Beide Logs sollen wie unabhängige Systeme überwacht werden. Das alte beendet Änderungen zu einem festgelegten Zeitpunkt und bleibt erreichbar, damit Clients ihren gespeicherten Zustand mit dem finalen Head verbinden. Im neuen Log müssen die migrierten Versionen erscheinen und von ihren Inhabern über ein Update geprüft werden.

Eine Installationsquote verschleiert diese Zustände. Installiert heißt nicht gestartet. Ein Kontakt mit dem neuen Log heißt nicht, dass das eigene Label geprüft wurde. Ein Hauptgerät kann fertig sein, während ein altes Backup später einen früheren Head zurückbringt. Inaktivität eines Kontos ist nicht automatisch Verzicht.

Der Entwurf nennt bewusst keine universelle Tageszahl. Er verlangt ausreichend Zeit und berücksichtigt längere Offline-Phasen. Unternehmenskommunikation, Verbraucherdienste und kurzlebige Web-Clients haben unterschiedliche Wiederkehr- und Zustandsverlustmuster. Eine Protokollkonstante könnte diese institutionelle Zusage nicht ehrlich ersetzen.

Auch der Überwachungsmodus zählt. Drittprüfer, Drittmanager, anonyme Anfragen und Peer-Austausch beruhen jeweils auf anderen Annahmen zu Kollusion, Häufigkeit und lokalem Zustand. Ein grüner Verfügbarkeitswert beweist nicht, dass die Erkennungsbedingungen erfüllt sind.

Ein finaler Head vollstreckt sich nicht selbst

Für die sofortige Migration soll die finale Baumgröße samt Root Hash über einen vertrauenswürdigen Kanal verteilt werden. Nutzer führen bis dorthin ihre letzten Monitor-Anfragen aus. Label-Inhaber initialisieren die Überwachung im neuen Log, indem sie ein Update für die migrierte Version verarbeiten und diese prüfen.

Der Endpunkt kann über ein bekanntes Label im neuen Log oder mit dem Anwendungscode verteilt werden. Beides schafft eine gemeinsame kryptografische Grenze. Beides beantwortet nicht, welche unterstützten Versionen sie erhalten haben, wer den Termin bestimmte oder wie ein später Client mit älterem Head behandelt wird.

Der Protokollentwurf kennt max_ahead, max_behind, das verpflichtende reasonable_monitoring_window und eine optionale maximum_lifetime. Das Überwachungsfenster beschreibt die übliche Prüffrequenz und strukturiert gemeinsame Kontrollpunkte. Es ist keine Messung realer Nutzung. Die maximale Lebensdauer begrenzt Speicher, nicht automatisch die Dienstverpflichtung.

Inhalt des Ausmusterungsbelegs

Der Beleg muss keine Nutzerdaten veröffentlichen.

Alte Grenze. Konfiguration, Signaturidentität, Ende der Änderungen, finale Größe und Root, Zeit, Betriebsmodus und Konsistenz mit dem zuvor bekannten Head.

Migrationsregel. Identitäten beider Logs, Zuordnung von Search, Update und Monitor, Tombstone-Semantik und implementierende Client-Versionen. Weiterleitung und Beweisvernichtung bleiben getrennt.

Verteilung. Authentisierte Kanäle des finalen Heads und Zustellung nach Version, Plattform, verwalteter Flotte, ruhendem Konto und Backup-Rückkehr. Gesamtdownloads genügen nicht.

Abschluss. Kontakt zum neuen Log, Prüfung des migrierten Labels, finaler Monitor des alten Logs und Wiederherstellungstest werden einzeln ausgewiesen.

Offline-Regel. Unterstützte Rückkehrdauer, Neuinstallation, mehrere Geräte, Backup-Alter, unzugängliche Konten und Ausnahmeweg; Schätzung und Messung werden markiert.

Befugnis und Rückweg. Sicherheit bestätigt den kryptografischen Abschluss, der Dienstverantwortliche akzeptiert Verfügbarkeitsrisiko, Datenschutz oder Recht begrenzen Aufbewahrung, eine benannte Rolle genehmigt die Abschaltung. Widersprüchliche Heads oder nicht überbrückbare Clients lösen Verlängerung, Wiederherstellung oder Untersuchung aus.

Der fortgeschrittene Entwurf bleibt ein Entwurf

Revision 09 ist ein Internet-Draft mit beabsichtigtem Informational-Status und beim IESG zur Veröffentlichung eingereicht. Der Shepherd-Bericht dokumentiert Konsens und keine erheblichen Einwände in einer relativ kleinen Fachgemeinschaft. Das ist Prozessreife, aber weder ein veröffentlichter RFC noch ein Implementierungsnachweis.

Das Begleitprotokoll verändert sich weiter. Das IETF-126-Protokoll hält den Vorschlag eines neuen UpdateRequest-Formats fest, weil die vorige Form nicht implementierbar gewesen sei. Ein Implementierer warnte zudem vor Nichtinteroperabilität durch frei wählbare Wire-Formate. Die Diskussion ist kein normativer Beschluss. Sie zeigt, warum Architektur, Protokollstand, laufender Code und lokale Stilllegung je einen eigenen Nachweis brauchen.

Die gemeinsame Mindestregel ist klein: Ausfall des neuen Logs darf keinen alten Schlüssel reaktivieren; Entfernung des alten Logs darf den historischen Prüfpfad nicht unbegründet zerstören. Die konkrete Dauer verantwortet eine benannte Institution, nicht der Tombstone.

Quellen

  1. KEYTRANS-Architektur, Revision 09
  2. Dokumenthistorie und Shepherd-Bericht
  3. KEYTRANS-Protokoll, Revision 05
  4. KEYTRANS-Charta
  5. KEYTRANS-Sitzungsprotokoll vom IETF 126
  6. Lu Heng, „Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption“
  7. Lu Heng, „Running Code Primary“