Zusammenfassung

  • Revision 07 bindet den in einem Workload Identity Token bestätigten cnf.jwk-Schlüssel an Methode, Pfad, Query, Zielgruppe, ausgewählte Header, Content-Digest und Signaturparameter. Das authentifiziert eine abgedeckte Request-Darstellung, erteilt aber keine Operationsberechtigung.
  • Ein lokaler Cache-Miss beweist keine clusterweite Neuheit. Das Entfernen einer Response-Signatur wird nur erkennbar, wenn der Client die Signatur in seinem eigenen signierten Request verlangt hat. Identität, Replay, Autorisierung, Ausführung und Ergebnis brauchen getrennte Belege.

Derselbe Nonce an zwei Knoten

Validator A erhält einen Request. Der WIT ist gültig, der in cnf.jwk gebundene Schlüssel verifiziert die Signatur, Content-Digest stimmt mit dem empfangenen Body überein, wimse-aud bezeichnet den vorgesehenen Empfänger und der Nonce fehlt im lokalen Cache. A akzeptiert und speichert ihn.

Sekunden später erreicht der identische Request Validator B. expires ist noch nicht abgelaufen, doch B teilt As Cache nicht. Die Signatur bleibt korrekt und der Nonce ist für B unbekannt. Beide Aussagen sind wahr, weil sie verschiedene Zustände beschreiben.

Danach folgen zwei andere Fragen: Darf dieser Principal diese Operation an dieser Ressource ausführen? Hat die Anwendung den Zustandswechsel tatsächlich committed? Wer alle Fragen in authenticated=true verdichtet, macht aus einem begrenzten Nachweis eine Autorität, die das Protokoll nie verliehen hat.

draft-ietf-wimse-http-signature-07 wurde am 20. September 2026 eingereicht. Der Kopf nennt Standards Track als Ziel und den 24. März 2027 als Ablaufdatum. Es ist kein RFC. Es ist ein aktiver Working-Group Internet-Draft, keine Produktionsvorgabe, kein Adoptionsmaß und kein Beleg für ein bestimmtes Produkt. Der Implementierungsanhang zeigt frühe Arbeit, keine Einsatzstatistik.

Die Signatur hat einen definierten Rand

WIMSE profiliert RFC 9421. Der Request deckt zwingend @method, @path und @query ab. Falls vorhanden, müssen auch Content-Type, Content-Digest, Authorization, Txn-Token und Workload-Identity-Token enthalten sein. Bei einem Body berechnet der Empfänger Content-Digest über die tatsächlich empfangenen Bytes neu.

Nur die Zeichen eines Digest-Feldes zu signieren würde dessen Verbindung zum Inhalt nicht beweisen. RFC 9530 gibt dem Feld seine Semantik; die Neuberechnung schließt die Beweiskette. Ein brauchbarer Nachweis speichert deshalb rekonstruierte Signaturbasis, Komponentenliste, Digest-Berechnung und Prüfergebnis.

Zu den Parametern gehören created, ein kurzes expires, ein zufälliger nonce und der Tag wimse-workload-to-workload; Requests tragen zusätzlich wimse-aud. keyid und alg aus HTTP Message Signatures werden nicht verwendet, weil Schlüssel und Algorithmus aus dem WIT-cnf.jwk kommen. Die lokale Richtlinie muss den Algorithmus trotzdem für die jeweilige Vertrauensdomäne akzeptieren.

Mehr als eine Signatur mit WIMSE-Tag führt zur Ablehnung. Eine stille Auswahl würde Sender, Proxy und Anwendung erlauben, unterschiedliche Darstellungen als „den signierten Request“ zu behandeln.

Nicht abgedeckte Felder bleiben veränderbar. Signiert ein Proxy neu, entsteht eine neue Aussage eines neuen Principals; die erste Signatur erhält dadurch rückwirkend keinen größeren Umfang.

Das logische Ziel statt einer stabilen authority

@authority ist nicht verpflichtend, weil TLS-terminierende Proxys und Load Balancer den Wert umschreiben. Die Empfängerbindung liegt stattdessen im signierten Parameter wimse-aud.

Damit werden drei Nachweise getrennt: die nach RFC 9525 geprüfte TLS-Serviceidentität, die an einem HTTP-Hop sichtbare authority und die logische WIMSE-Zielgruppe. Der Kanal kann korrekt sein, während die Zielgruppenregel zu breit ist. Die Signatur kann korrekt sein, während der Empfänger das Ziel ablehnt.

Der Trace sollte erwarteten Servicenamen, präsentierte Identität, TLS-Endpunkt, gesendete Zielgruppe, Empfängerinterpretation und endgültigen Dienst enthalten. Das Wort „authentifiziert“ allein verbirgt, an welchem Übergang Bedeutung verändert wurde.

Schlüsselbesitz ist kein Mandat

Der Empfänger prüft zuerst den WIT, dann die Signatur mit dem gebundenen Schlüssel. Erfolgreich bedeutet: Ein Besitzer des zugehörigen privaten Schlüssels hat die abgedeckte Darstellung unter den akzeptierten Bedingungen erzeugt.

Das beweist weder Absicht noch exklusive Verwahrung in genau einer laufenden Instanz. Es verleiht keine Geschäftsrolle. Vor allem autorisiert es die Operation nicht. Revision 07 erklärt das gesamte Autorisierungssystem für außerhalb des Geltungsbereichs und setzt es als vertrauenswürdige Voraussetzung voraus.

Daraus folgt eine Arbeitsgrenze. Authentifizierung liefert Principal und Request. Die erste Komponente, die die aufgelöste Aktion und Ressource kennt und den Effekt noch verhindern kann, vergleicht Principal, Aktion, Ressource, Kontext und Richtlinienversion.

Der Autorisierungsnachweis enthält Regel, Entscheidung, Auflagen, Ausnahme und Zeitpunkt. Ordnet ein Gateway allen gültigen WITs einer Vertrauensdomäne eine breite Rolle zu, stammt diese Macht aus der Gateway-Konfiguration. Deren Genehmigung und Historie sind entscheidend.

Replay-Schutz ist eine Topologie, kein Schalter

created und expires verkleinern das Zeitfenster, verhindern aber keine zweite Vorlage darin. Der Nonce hilft nur, wenn ein Zustand sein erstes Auftreten erinnert. Der Draft erlaubt einen Replay-Cache und empfiehlt die Ablehnung bekannter Werte. Er verlangt keine Synchronisierung zwischen Validatoren und garantiert strikten Replay-Schutz wegen der Schwierigkeit verteilter Synchronisation nicht als Protokollziel.

Ein Miss bedeutet daher nur: Dieser Speicher kennt den Wert in seinem Umfang und seiner Aufbewahrungszeit nicht. Er beweist nicht, dass ein anderer Knoten oder eine Ausweichregion ihn nie akzeptiert hat, ein alter Eintrag nicht ablief oder die Anwendung dieselbe Wirkung nicht unter einer anderen ID ausgeführt hat.

Für einen idempotenten Lesezugriff kann das angemessen sein. Für Abbuchung, Ausstellung, Löschung oder Steuerbefehl ist oft eine zweite Barriere nötig: Idempotenzschlüssel, transaktionale Eindeutigkeit oder Commit-Ledger. „Replay-Schutz aktiv“ ohne Cache-Umfang, Retention, Failover und Verhältnis zu expires ist keine belastbare Aussage.

Eine belastbare Response-Signatur beginnt beim Client

Der Server darf Responses signieren. Die stärkere Garantie entsteht, wenn der Client wimse-sign-response=true in seinen signierten Request aufnimmt. Kann der Server nicht signieren, darf er keinen gewöhnlichen erfolgreichen Unsigned-Response liefern; der Client muss einen solchen Response ablehnen.

Jeder signierte Response enthält wimse-req-nonce, gleich dem Request-Nonce. Damit wird die abgedeckte Antwort an diesen konkreten Request gebunden.

Ohne Client-Anforderung reicht eine interne Serverrichtlinie nicht. Ein Middlebox kann die Signatur entfernen, und der Client muss die normale Antwort akzeptieren. „Der Server signiert“ beschreibt Fähigkeit. „Der Client verlangte und verifizierte einen an seinen Nonce gebundenen Response“ beschreibt eine Transaktion.

Auch das ist noch kein Geschäftsergebnis. Eine authentische Antwort kann nur die Annahme eines asynchronen Auftrags bestätigen, der später scheitert.

Nach der letzten Bedeutungsänderung autorisieren

Middleboxes terminieren TLS, normalisieren, routen, dekodieren und signieren unter Umständen neu. Eine Änderung abgedeckter Felder bricht die Signatur; nicht abgedeckte Werte können sich ändern. Autorisiert das Gateway nur POST /jobs, während ein unsigned Header später das betroffene Konto bestimmt, lag die Entscheidung zu früh.

Ein belastbarer Verlauf verknüpft eingehende Verifikation, Transformationsregel, Identität der neuen Signatur, Unterschiede im Umfang und nachgelagerte Autorisierung. Nicht jedes HTTP-Byte muss eingefroren werden. Feststehen muss, wer die wirkungsbestimmenden Werte verändern darf.

So entstehen sechs Belege: WIT und Schlüsselfingerprint; Signaturbasis und neu berechneter Digest; Nonce, Validator und Cache-Umfang; Principal, Aktion, Ressource und Richtlinie; Idempotenz und Commit; unabhängige Ergebnisbeobachtung. Sie dürfen auseinanderfallen. Eine gültige Signatur kann ein Replay sein, ein neuer Request unzulässig, eine erlaubte Operation erfolglos und ein Commit später kompensiert.

Diese Differenzierbarkeit schafft Verantwortlichkeit. Ein Implementierungsanhang oder Konformitätsversprechen ist ein Fähigkeitsnachweis. Laufenden Code bewertet man mit Capture, rekonstruierter Basis, WIT-Entscheidung, Cache-Topologie, Autorisierungslog und Zustandsübergang. Da der Draft sich ändern kann, gehören Revision und lokale Abweichungen in die Architekturakte.

Quellen