Zusammenfassung

  • Die privaten und öffentlich prüfbaren Verfahren aus RFC 9578 bestätigen die Beziehung zwischen Authentikator, Token-Eingabe und Ausstellerschlüssel. Mehr Aussagekraft entsteht dadurch nicht.
  • Challenge, Einlösestatus, Zugriffsregel und Anwendungsergebnis werden von anderen Stellen verantwortet und benötigen jeweils einen eigenen Nachweis.

Je reibungsloser eine Maschine „gültig“ meldet, desto leichter verschwindet die Frage, wer daraus „zulassen“ gemacht hat. Genau diese Lücke ist bei Privacy Pass keine Kleinigkeit, sondern die zentrale Governance-Frage.

RFC 9578 zieht die Grenze selbst: Ein Privacy-Pass-Token beweist nichts außer seiner früheren Erzeugung durch einen bestimmten Server. Der RFC-Editor-Eintrag, der Datatracker-Datensatz, die Dokumenthistorie und die Errata-Suche belegen Identität und Status des Standards. Eine konkrete Ausgabe, Implementierung oder Freigabe belegen sie nicht.

Welcher Schlüssel gilt, wird vorher entschieden

Die Ausgabe setzt eine Konfiguration voraus: Tokentyp, Name des Ausstellers, Anforderungsendpunkt und gegebenenfalls öffentlicher Prüfschlüssel. Herkunft, Zeitpunkt und Hash dieser Konfiguration bestimmen, welcher Autorität der spätere Prüfer vertraut.

Das privat prüfbare Verfahren verwendet ein VOPRF über P-384 und SHA-384. Nur der Aussteller mit dem privaten Schlüssel kann den fertigen Token prüfen. Das öffentlich prüfbare Verfahren nutzt blindes RSA mit einem 2048-Bit-Modulus und erlaubt die Prüfung mit dem öffentlichen Schlüssel. RFC 9497 definiert das VOPRF, RFC 9474 die blinde RSA-Signatur.

Der Client erzeugt einen frischen 32-Byte-Nonce, bildet SHA-256 über eine undurchsichtige Challenge, ergänzt die Schlüsselkennung und blendet die Token-Eingabe. Der Aussteller prüft Aufbau und unterstützten Typ, wertet das verdeckte Element aus oder signiert es und sendet die Antwort. Der Client stellt daraus den Authentikator fertig.

Der Aussteller muss den später vorgelegten Token bei der Ausgabe nicht direkt sehen. Netzwerkzeit, Kontokontext, Attester-Signale, Konfigurationsabruf, Origin-Metadaten und gemeinsame organisatorische Kontrolle liegen jedoch außerhalb des verdeckten Elements. Blindheit im Nachrichtenaustausch ist kein Messwert für die Unverknüpfbarkeit einer gesamten Installation.

Ein gebundener Challenge-Hash ist noch kein erfülltes Kriterium

RFC 9578 behandelt die Challenge als undurchsichtige Eingabe. Sie kann aus dem HTTP-Authentifizierungs- und Einlöseablauf von RFC 9577 stammen. Der Hash bindet Bytes an den Token. Er bestätigt weder deren behauptete Bedeutung noch die tatsächliche Erfüllung einer Bedingung.

Soll die Challenge für ein gelöstes CAPTCHA, eine Geräteattestierung oder ein bezahltes Kontingent stehen, muss das jeweils zuständige System einen eigenen Beleg liefern. Der Aussteller kann zeigen, dass er das Protokoll auf der gelieferten Eingabe ausgeführt hat. Er kann einen fehlenden vorgelagerten Nachweis nicht nachträglich erzeugen.

Die Privacy-Pass-Architektur in RFC 9576 trennt Client, Origin, Attester und Issuer und behandelt Metadaten sowie Kollusion. Das ist eine Entwurfsgrundlage, kein Auditbericht über die tatsächliche Rollentrennung eines Betreibers. Die bestehende BTW-Arbeit zu RFC 9614 behält ihren eigenen Fokus auf Architekturtrennung und Unverknüpfbarkeit; hier geht es um die Kette von Ausgabe bis Ergebnis.

Nach der Prüfung bleiben Einlösung, Freigabe und Lieferung

Im privaten Verfahren berechnet der Aussteller den VOPRF-Wert mit seinem Geheimnis neu. Im öffentlichen Verfahren prüft ein Verifizierer die Signatur mit dem öffentlichen Schlüssel. Erfolg bedeutet, dass Authentikator, Eingabe und gewählter Schlüssel zusammenpassen. Er bedeutet nicht, dass alle Clients denselben Schlüssel sahen, der Token frisch oder unverbraucht ist oder die angeforderte Handlung erlaubt werden soll.

Dafür braucht es einen Einlösespeicher und die Richtlinie des Origin. Das IANA-Register für Privacy Pass koordiniert Token- und Medientypen, dokumentiert aber weder Einführung noch Freigabe. Die laufenden Entwürfe zur Konsistenz von Ausstellerschlüsseln und zu Rate-Limit-Tokens zeigen zwei eigenständige Probleme: konsistente Schlüsselansichten und Kontingentsemantik. Es sind aktuelle Entwürfe, kein RFC-Konsens und kein Betriebsnachweis.

Eine prüfbare Kette verbindet Abrufquelle und Hash der Konfiguration, Schlüssel-ID, Challenge-Bytes und Richtlinienversion, Nonce und Eingabe-Hash, Ausstellerantwort, Client-Finalisierung, Verifizierer und Schlüsselwahl, Entscheidung des Einlösespeichers, Replay-Status, Freigabegrund, Antwortstatus und Anwendungsergebnis. Datenschutz verlangt sparsame Verknüpfung. Er verlangt nicht, unterschiedliche Zuständigkeiten in einem grünen Haken verschwinden zu lassen.

Heng Lus Text über Realitätsebenen verhindert, dass kryptografische Gültigkeit politische Autorität übernimmt. Running-Code Primacy verortet betriebliche Wahrheit im beobachteten Verhalten. Warum BTW Media existiert liefert die redaktionelle Regel: den genauen Beleg berichten, nicht die beruhigende Gesamtgeschichte, die ihm nachträglich zugeschrieben wird.

Quellen