Zusammenfassung

  • Die Signatur schützt die aus einer geordneten Komponentenliste und ihren Parametern gebildete Basis. Nicht aufgeführte Methoden, Ziele, Authorities, Berechtigungsnachweise oder Inhalte lassen sich ändern, ohne diese Rechnung zu brechen.
  • Der Verifier bestimmt die relevante Signatur, den zulässigen Schlüssel, die Frische, den Replay-Status, den Inhaltsabgleich und die heutige Berechtigung des Principals. Kein Parameter vollzieht diese Entscheidungen selbst.
  • Prüft und verändert ein Proxy die Nachricht und signiert anschließend neu, entsteht ein eigener Verwahrungsnachweis. Seine Signatur erweitert nicht die frühere Erklärung des Clients.

Ein gültiger Körper ohne gebundenes Ziel

Eine Verwaltungs-API erhält einen korrekt signierten JSON-Körper. Der Schlüssel ist bekannt, der Algorithmus erlaubt, created liegt im Zeitfenster und Content-Digest stimmt. Das System meldet Erfolg.

In Signature-Input stehen jedoch nur date und content-digest. @method, @authority, @target-uri, die Berechtigung und ein Einmalwert fehlen. Der Schlüsselinhaber mag diese Bytes bestätigt haben. Nicht bestätigt ist, dass sie per POST auf diesem Host, in diesem Mandanten und genau einmal ausgeführt werden dürfen.

Ein Vermittler kann denselben Körper zu einer wirksameren Route tragen. Eine aufgezeichnete Anfrage kann erneut eintreffen. Eine öffentliche Authority kann in einen anderen internen Dienst übersetzt werden. Die Signatur bleibt gültig, weil die geänderte Bedeutung außerhalb ihrer Basis lag.

Das ist kein kryptographischer Defekt. Die Organisation hat eine begrenzte Aussage in einen umfassenden Auftrag verwandelt.

RFC 9421 rekonstruiert Semantik statt Leitungsbytes

HTTP-Nachrichten durchlaufen Zwischenstellen. Feldzeilen werden kombiniert, Protokollversionen übersetzt und Kodierungen geändert. Eine Signatur des rohen Bytebildes würde legitime Vermittlung als Manipulation behandeln.

RFC 9421 definiert deshalb eine deterministische Signaturbasis. Der Signer wählt HTTP-Felder oder abgeleitete Komponenten wie @method, @authority, @target-uri und @status. Reihenfolge und Parameter erscheinen in Signature-Input; @signature-params bindet Liste, created, expires, keyid, nonce und tag mit ein.

Der Empfänger baut die Basis aus seiner Nachricht neu. Eine erfolgreiche Prüfung belegt semantische Gleichheit nur bezüglich der abgedeckten Teilmenge. Sie schützt weder Nachbarfelder noch den gesamten Vorgang.

Eine Signatur über zwei Komponenten und eine über zehn Komponenten sprechen daher über unterschiedliche Objekte.

Die Coverage ist die eigentliche Betriebsrichtlinie

Für eine Leseanfrage können Methode, Authority und Ziel genügen. Eine Netzänderung braucht womöglich zusätzlich Inhaltsdigest, Kontokontext, Ressourcenversion, Idempotenzschlüssel und Challenge. Ein Quittungsprofil bindet Status und Teile der ursprünglichen Anfrage.

Der Dienst braucht Profile pro Operation. Nur nach Signature zu suchen, ignoriert die wichtigste Information: was tatsächlich geschützt wurde.

Fehlt @method, kann eine Erklärung für eine Abfrage an eine Mutation gehängt werden. Ohne @authority und @target-uri wandert sie über Dienst- oder Tenantgrenzen. Bleibt die Berechtigung ungeschützt, lässt sich eine intakte Beweiskette mit einer anderen Identitätsbehauptung verbinden.

Alle Felder pauschal zu signieren ist ebenso falsch. Via und Forwarded verändern Proxys absichtlich. Ein sicheres Profil deckt alles ab, dessen Änderung Befugnis oder Wirkung verändert, und benennt die zugelassenen Transformationen.

Heng Lus Minimum Initial Specification passt zu dieser Trennung: Die gemeinsame Schicht macht Konstruktion und Validierung streng und lokal prüfbar. Spätere Auswahl von Komponenten, Schlüsseln und Ablehnung bleibt bei den laufenden Teilnehmern.

Inhalt braucht einen geschützten und geprüften Digest

RFC 9421 nimmt den beliebigen Body nicht direkt in die Basis auf. RFC 9530 liefert Content-Digest. Sicher ist die Kette nur, wenn das Feld berechnet, signiert und sein Wert nach Empfang gegen den tatsächlichen Inhalt neu berechnet wird.

Ein ungeschützter Digest kann mit dem Body ersetzt werden. Ein signierter, aber nicht nachgerechneter Digest kann stehen bleiben, während der Body ausgetauscht wird. Die Signatur bestätigt die Digest-Aussage; der zweite Vergleich bestätigt ihre Übereinstimmung mit der Wirklichkeit.

Auch Content-Type und Content-Encoding können entscheidend sein. Gleiche Bytes unter einem anderen Parser erhalten andere Bedeutung, und eine Kodierungsänderung verschiebt den Berechnungsbereich.

Trailer kommen spät und dürfen verschwinden. Verarbeitet eine Anwendung den Stream vor dem Trailer, liegt die Wirkung vor dem Abschluss der Prüfung. Für irreversible Befehle braucht es Pufferung oder eine Transaktionsgrenze.

Die BTW-Abhandlung zu Digest Fields untersucht, welche Bytes ein Digest benennt. Hier geht es um denjenigen, der diese Aussage zusammen mit Methode, Ziel und Identität schützt. Das ist kein doppelter Gegenstand.

keyid ist ein Wegweiser, kein Ausweis

Der Signer liefert keyid. Die Zeichenfolge authentifiziert sich nicht. RFC 9421 überlässt Key Discovery, Algorithmen und Identitätsbindung der Anwendung.

Nimmt ein Verifier jeden mitgelieferten öffentlichen Schlüssel an, signiert der Angreifer den eigenen Befehl mit dem eigenen Schlüssel und besteht. Die Mathematik beweist Besitz; die lokale Trust Policy muss Principal, Rolle, Zeitraum und Operationsklasse belegen.

Für die spätere Rekonstruktion gehören aufgelöste Schlüsselversion, Trust-Quelle, Policy-Version, Algorithmus, Aktivierungs- und Rückzugszeit sowie Scope in den Nachweis. keyid allein verliert seine Bedeutung bei Rotation.

Doppelte Signaturen können einen Wechsel begleiten. Ohne benannten Austritt wird Rückwärtskompatibilität zur dauerhaften Erweiterung der Angriffsfläche.

Eine IANA-Registrierung schafft gemeinsame Namen. Sie billigt keinen Algorithmus für jede Schadensklasse.

Frische verbraucht keinen Auftrag

created und expires ermöglichen eine Zeitentscheidung. Der Verifier legt Alter und Uhrtoleranz fest. Eine mathematisch richtige Signatur kann betrieblich zu alt sein.

Ein kurzes Fenster verhindert jedoch keine Wiederholung. Derselbe Auftrag kann innerhalb des Fensters mehrfach ausgeführt werden.

nonce trägt einen Einmalwert, aber der Verifier muss ihn atomar verbrauchen. Zwei Regionen können gleichzeitig „unbenutzt“ lesen und zwei Commits erzeugen. Replay-Schutz ist verteilte Zustandsführung.

tag hilft bei der Auswahl eines Signaturprofils. Der öffentliche Wert kann kopiert werden und verleiht keine Autorität.

Proxy-Signatur und Client-Mandat sind zwei Aussagen

RFC 9110 macht Vermittlung zu einem normalen HTTP-Bestandteil. Ein Gateway kann die Client-Signatur prüfen, private Felder entfernen, das interne Ziel umschreiben und die neue Form signieren.

Diese Signatur beschreibt die Aussage des Gateways. Sie beweist nicht, dass der Client später ergänzte Felder gebilligt hat. Der Origin muss wissen, ob das Gateway nur eine Prüfung attestieren oder als interner Principal Befehle erteilen darf.

Ein letztes Boolean löscht die Kette. Erhalten bleiben sollten externer Kontext, ausgewählte Client-Signatur, angewandtes Profil, Transformation und intern signierte Form.

Bei der Übersetzung von HTTP/1.1 zu HTTP/2 kann Authority als Host oder :authority erscheinen. @authority bildet den semantischen Wert ab. Wer nur die Drahtform signiert, riskiert legitime Ausfälle oder unterschiedliche Authorities in Prüfung und Autorisierung.

Mehrere gültige Signaturen brauchen Auswahlregeln

Client, Gateway und Genehmiger können dieselbe Nachricht signieren. Während einer Migration kommen zwei Algorithmen hinzu. Alle Signaturen können gültig und dennoch für den aktuellen Auftrag unzureichend sein.

Die erste gültige Signatur zu akzeptieren verwechselt Relevanz mit Rechenbarkeit. Eine Logging-Signatur ist kein Löschmandat, eine Proxy-Quittung nicht immer eine Nutzeranweisung. Label, tag, Rolle, Coverage und Schlüsselpolicy müssen zusammenpassen.

Bei Responses kann req Komponenten der zugehörigen Request abdecken. Ohne genau diesen Request-Kontext ist eine signierte Quittung nicht einer bestimmten Anweisung zuzuordnen.

TLS und Business Authorization bleiben eigenständig

TLS 1.3 schützt einen Kanal und bietet Vertraulichkeit. HTTP Message Signatures erhält ausgewählte Semantik über Verbindungen oder Vermittler hinweg. Sie verschlüsselt nicht und ersetzt TLS nicht.

HTTP Authentication liefert Credentials; die Anwendung prüft weiterhin Principal, Ressource, Aktion und Zustand. Eine signierte Response ist auch nicht automatisch cachefähig. Dafür gilt RFC 9111.

In Heng Lus Reality Layers ist die Signaturbasis ein Koordinationsartefakt, die Prüfung ein kryptographisches Faktum, Key Mapping eine Identitätsbehauptung, Autorisierung eine lokale Entscheidung und der Commit die operative Realität. Keine frühere Ebene darf sich die Macht der späteren aneignen.

Quellen und Grenzen

Die Quellen belegen Formate und Grenzen, nicht heutige Verbreitung, Herstellerverhalten, menschliche Identität, Rechtswillen, Nichtabstreitbarkeit oder geschäftliche Richtigkeit.