Summary

  • Der KEYTRANS-Suchnachweis authentisiert das Ergebnis einer bereits zugelassenen Operation und unterstützt die Prüfung der Log-Konsistenz. Die vorgelagerte Zulassungsentscheidung der Anwendung ist nicht Teil dieses Nachweises.
  • Der aktuelle Architekturentwurf überlässt Zugriffskontrollen wie Authentisierung, Eigentum, Beziehungsstatus und Ratenbegrenzung weitgehend dem jeweiligen Dienst. Das schützt Identitätsexistenz und Daten nach einem Rechteentzug, lässt aber eine wichtige Machtentscheidung außerhalb des Logs.
  • Daniel Kade schlägt einen datensparsamen Suchrichtlinienbeleg vor: Richtlinienversion, Operations-, Antragsteller- und Beziehungsklasse, Entscheidungscode, Log-Epoche, Ausnahme und Korrektur werden erfasst; Namen, Rohkennungen, öffentliche Schlüssel, Kontaktgraph und vollständige Suchhistorie bleiben ausgeschlossen. Das ist ein Governance-Vorschlag, keine IETF-Vorgabe.

Der transparente Baum steht hinter einem undurchsichtigen Tor

Alice sucht nach Bobs Schlüssel. Die Anwendung lässt die Anfrage zu, KEYTRANS liefert den Wert samt Beweispfad, und Alice prüft die Einbettung in den suchbaren Präfixbaum sowie den Bezug zum nur erweiterbaren Log. Ihre Antwort passt zum authentisierten Zustand. Das ist genau die Art von Nachprüfbarkeit, die das System schaffen soll.

Fred stellt dieselbe Anfrage. Die Anwendung erkennt keine erforderliche Beziehung und beendet sie auf der Transportschicht, bevor eine Protokolloperation entsteht. Fred erhält keinen falschen Nachweis; er erhält keinen KEYTRANS-Nachweis. Wer nur Log-Wurzeln, Einbettungsbeweise und Konsistenz betrachtet, sieht Alices Erfolg, nicht aber die Begründung von Freds Ausschluss.

Damit trennen sich zwei Fragen. Datenintegrität fragt, ob eine ausgegebene Antwort zum verpflichteten Zustand gehört. Zugangsgovernance fragt, ob das Tor nach einer stabilen, anwendbaren und korrigierbaren Regel entschieden hat. Eine präzise kryptografische Garantie darf nicht zum Gütesiegel für die unbeobachtete institutionelle Entscheidung aufgebläht werden.

Was KEYTRANS nachweisbar macht

Das zugrunde liegende Risiko ist real. In Ende-zu-Ende-verschlüsselten Systemen kann der Dienst, der öffentliche Schlüssel verteilt, einen Schlüssel austauschen und sich so in eine vermeintlich geschützte Kommunikation einschalten. KEYTRANS verbindet einen durchsuchbaren Präfixbaum mit einem Append-only-Logbaum, um Zuordnungen von Kennungen zu Werten, Aktualisierungen und Zustandsfolgen prüfbar zu machen.

Bei korrekter Verifikation und dem vorgesehenen Monitoring kann ein Client feststellen, ob der gelieferte Wert in der verpflichteten Struktur liegt, ob sich das Log entlang einer konsistenten Historie entwickelt und ob sein Blick ungefähr dem entspricht, was andere Beobachter sehen sollten. Die in RFC 6962 und RFC 9162 dokumentierte Certificate-Transparency-Erfahrung zeigt, wie Append-only-Strukturen versteckte Substitutionen in erkennbare Abweichungen verwandeln können.

Die betrachteten Texte sind dennoch keine fertigen Standards. draft-ietf-keytrans-architecture-09 vom 30. Juni 2026 ist ein Arbeitsgruppen-Internet-Draft mit beabsichtigtem Informational-Status und einem angegebenen Ablaufdatum am 1. Januar 2027. Auch draft-ietf-keytrans-protocol-05 ist ein laufender Entwurf. Die genehmigte Charta legt den Arbeitsauftrag fest, nicht die Implementierung eines benannten Dienstes.

Die Architektur beschreibt KEYTRANS ausdrücklich nicht als alleinstehendes System. Es muss in eine Anwendung eingebettet werden. Das Protokoll authentisiert Zuordnungen und Log-Zustände; die Anwendung entscheidet, wer Search, Update oder Monitor ausführen darf. Ein erfolgreicher SearchResponse belegt folglich nicht, dass vergleichbare Anfragen dieselbe Zulassungsentscheidung erhielten.

Ein geschlossenes Tor kann Privatsphäre schützen

Uneingeschränkte Suche wäre keine verantwortbare Alternative. Schon die Information, ob eine Identität in einem Dienst existiert, kann Mitgliedschaft, Beruf, politische Zugehörigkeit oder eine sensible Beziehung offenlegen. RFC 6973 strukturiert solche Datenschutzrisiken; RFC 7258 behandelt Beobachtung und Korrelation in großem Maßstab als technische Bedrohung. Ein öffentliches Verzeichnis aller Suchenden wäre keine Verbesserung.

Deshalb verlangt die aktive KEYTRANS-Charta, Identitätsexistenz und Kontodaten nur Clients zu zeigen, die fragen dürfen. Die Architektur gestattet, vorhandene Authentisierung und Zugriffskontrolle wiederzuverwenden. Abgesehen von wenigen Einschränkungen kann eine Anwendung eigene Regeln anwenden: Anmeldung, Eigentum, „Freundschaft“, Organisationsbezug, Ratenbegrenzung oder andere dienstspezifische Bedingungen.

Diese Offenheit ist sachgerecht, weil das Protokoll die soziale Bedeutung einer Beziehung nicht universell bestimmen kann. Sie hat aber eine Governance-Folge. Legitime Abwehr von Enumeration, eine kurzfristige Missbrauchssperre, eine abgelaufene Notfallausnahme, kommerzielle Differenzierung und ein technischer Fehler können außerhalb des Logs gleich aussehen: Es gibt keine Suchoperation.

Rechteentzug ist ein Zustandsübergang

Contact Monitoring macht deutlich, dass Berechtigung keine einfache Ja-Nein-Variable ist. Wer einen Kontakt früher erfolgreich gesucht hat, muss möglicherweise bestimmte Monitor-Operationen für bereits bekannte Versionen fortsetzen, obwohl die Erlaubnis für neue Search- oder Update-Vorgänge verloren ging. Der Protokollentwurf beschreibt dafür einen engen Fortsetzungsweg und erwägt die Öffnung eines Commitments als Nachweis früherer Berechtigung.

Das schützt bestehende Kommunikation. Würde jedes Monitoring beim Rechteentzug sofort enden, könnte eine spätere unberechtigte Schlüsseländerung für eine bestehende Beziehung unentdeckt bleiben. Würde der Client dagegen unbegrenzt neue Daten erhalten, wäre der Entzug wirkungslos. Auch die Sicherheitsarchitektur von MLS in RFC 9420, RFC 9458 und RFC 9614 ordnet Sicherheit zeitlichen Zuständen, Mitgliedschaft und Anmeldeinformationen zu.

Ein Governance-Datensatz muss deshalb Übergänge abbilden: Welche Richtlinienversion entzog Search, welche frühere Monitor-Pflicht blieb bestehen, welcher Beleg erlaubte sie, und wann endet sie? Ein bloßer Eintrag „abgelehnt“ wäre technisch und institutionell zu grob.

Dritte sehen jeweils nur einen Ausschnitt

Bei Third-Party Management bleibt der Dienstbetreiber Torwächter. Ein Manager kann akzeptierte Klartext-Kennungen und -Werte, Historie und Suchverkehr sehen. Was der Dienst vorher ablehnt, erreicht ihn möglicherweise nie. Der Manager kann die korrekte Bearbeitung des sichtbaren Bestands prüfen, aber aus Abwesenheit keine Vollständigkeit ableiten.

Third-Party Auditing schafft einen anderen Ausschnitt. Ein Prüfer kann Anzahl, Reihenfolge und Zeitpunkte von Änderungen beobachten, während Kennungen und Werte verdeckt bleiben. Das schützt Inhalte, erzeugt aber keine Statistik der vor dem Log abgewiesenen Anfragen. Betreiber, Manager und Prüfer können jeweils ehrlich handeln und gemeinsam eine unbeobachtete Naht behalten.

Für mehrere Dienste unter einer kontrollierenden Einheit betrachtet die Architektur Proxying zur Verringerung von Verknüpfbarkeit und warnt vor Spiegelung oder Zusammenführung, die dienstspezifische Richtlinien stört. Ein zentrales Archiv aller Ablehnungen würde diese Schutzabsicht unterlaufen, wenn es Beziehungen über Dienste hinweg rekonstruierbar macht.

Ein Richtlinienbeleg statt eines Suchdossiers

Die passende Ergänzung wäre kein öffentliches Suchregister, sondern ein minimaler Beleg über die Richtlinienentscheidung. Er entstünde, wenn die Anwendung zulässt oder ablehnt, wäre an die geltende Richtlinienversion gebunden und nur für eng definierte Prüfungen durch berechtigte Stellen zugänglich.

Sinnvolle Felder wären: Operationsklasse — Search, Update oder Monitor —, grobe Antragstellerklasse, Beziehungsklasse, mit rotierendem Schlüssel gebildeter Ziel-Digest, Entscheidungscode, zugehörige Log-Epoche, Regel- oder Evidenzklasse, Ausnahmestelle und Ablaufzeit, Korrekturstatus, Aufbewahrungsfrist und Kennung eines aggregierten Tests. Rotation verhindert, dass der Digest über Jahre zur stabilen Identität wird.

Nicht enthalten sein sollten Nutzernamen, rohe Labels, öffentliches Schlüsselmaterial, Zugangsdaten, Nachrichten, vollständige IP-Adressen, dauerhafte Gerätekennungen, Klartextbeziehungen oder der gesamte Suchverlauf einer Person. Zugriffstrennung, Bedrohungsmodell, Schlüsselverwaltung und Löschung sind Teil des Entwurfs. Der Beleg darf nicht zum neuen Überwachungsbestand werden.

Damit ließen sich begrenzte Fragen beantworten: Wurden gleich klassifizierte Anfragen unter derselben Richtlinienversion gleich behandelt? Blieben abgelaufene Ausnahmen aktiv? Bestand das notwendige Monitoring nach dem Entzug fort? Führte eine erfolgreiche Beschwerde zu einer Korrektur? Keine dieser Prüfungen verlangt die Veröffentlichung, wen Alice oder Fred gesucht haben.

Auch ein im Log verankerter Beleg-Hash beweist nicht automatisch die Vollständigkeit. Er beweist nur die Unverändertheit der vorhandenen Belege. Ob jede Entscheidung einen Beleg erzeugte, braucht Eingangszähler, Lückenprüfungen, unabhängige Stichproben oder stärker gebundene Ausführung. Integrität eines Bestands und Abdeckung aller Vorgänge sind verschiedene Eigenschaften.

Löschung bestätigt die Trennung der Ebenen

Die Architektur unterscheidet Werte, die nach Anwendungsrichtlinie dauerhaft unzugänglich und daher löschbar werden, von kryptografischem Material, das das Protokoll weiterhin benötigt. Das Log kennt die normative Begründung der Löschung nicht. Die Anwendung muss Zugriff, Aufbewahrung, Ausnahme und fortbestehendes Monitoring koordinieren.

Für Richtlinienbelege gilt dasselbe Prinzip. Kurze Fristen, rotierende Digests, Aggregation und kontrollierte Korrekturen können jüngere Entscheidungen prüfbar halten, ohne einen dauerhaften sozialen Graphen zu konservieren. Rechenschaftspflicht verlangt nicht, jedes Identitätsdetail für immer aufzubewahren.

Was die Quellen nicht belegen

Die eingefrorenen Quellen weisen keine Einführung der Entwürfe bei einem benannten Produkt nach. Sie liefern keine Ablehnungsquote, Fehlerhäufigkeit, Diskriminierungsfälle, Datenschutzvorfälle, Leistungswerte oder juristische Bewertung. Dieser Beitrag erhebt keinen Vorwurf gegen einen Betreiber und behandelt einen Arbeitsentwurf nicht als Marktbeobachtung.

Die Texte können sich ändern. Die Charta beschreibt Auftrag und erwartete Ergebnisse, garantiert aber weder endgültige Spezifikation noch Akzeptanz. Der hier vorgeschlagene Richtlinienbeleg ist eine Governance-Folgerung aus der dokumentierten Systemgrenze, keine normative Passage aus dem Entwurf.

Die belastbare Aussage bleibt schmal: KEYTRANS kann die Antwort auf eine zugelassene Suche authentisieren. Es authentisiert nicht die Entscheidung, wer suchen durfte. Privatsphäre braucht ein selektives Tor; Legitimität braucht einen Weg, dieses Tor zu prüfen, ohne die Menschen dahinter offenzulegen.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-09
  5. https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/
  6. https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/history/
  7. https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-protocol-05
  8. https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/
  9. https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/history/
  10. https://datatracker.ietf.org/doc/charter-ietf-keytrans/
  11. https://www.rfc-editor.org/rfc/rfc6962.html
  12. https://www.rfc-editor.org/rfc/rfc9162.html
  13. https://www.rfc-editor.org/rfc/rfc6973.html
  14. https://www.rfc-editor.org/rfc/rfc7258.html
  15. https://www.rfc-editor.org/rfc/rfc9420.html
  16. https://www.rfc-editor.org/rfc/rfc9458.html
  17. https://www.rfc-editor.org/rfc/rfc9614.html