Signierte HTTP-Anfrage prüfen (RFC 9421, mit IETF-Beispiel)

Das Wichtigste in Kürze

HTTP-Signaturen nach RFC 9421 sind die Grundlage von Web Bot Auth und dem Trusted Agent Protocol.
Das offizielle Beispiel aus Anhang B.2.6 ergibt in KYA unbestimmt, Stufe KYA-A1.
Eine Änderung am signierten Pfad macht die Signatur ungültig.
Eine gültige Signatur belegt die Herkunft, nicht die Befugnis zur Handlung.

Signierte Anfrage bereitlegen

Eine signierte Anfrage besteht aus Anfragezeile, Headern, einer Leerzeile und dem Inhalt. Die Header Signature-Input und Signature tragen die Signatur. Das Beispiel aus Anhang B.2.6 von RFC 9421 sieht so aus:

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18
Signature-Input: sig-b26=("date" "@method" "@path" "@authority" "content-type" "content-length");created=1618884473;keyid="test-key-ed25519"
Signature: sig-b26=:wqcAqbmYJ2ji2glfAMaRy4gruYYnx2nEFN2HN6jrnDnQCK1u02Gb04v9EDgwUPiu4A0w6vuQv5lIp5WPpBKRCw==:

{"hello": "world"}

Signiert sind hier Datum, Methode, Pfad, Host, Inhaltstyp und Inhaltslänge, mit einem Ed25519-Testschlüssel.

Öffentlichen Schlüssel als JWKS hinterlegen

Öffnen Sie auf der Prüfseite «Erweitert: Schlüssel, Statusliste, Zeitstempel-Anker» und fügen Sie unter «Vertrauenswürdige Schlüssel (JWK oder JWKS)» den öffentlichen Testschlüssel aus Anhang B.1.4 ein:

{"keys":[{"kty":"OKP","crv":"Ed25519","kid":"test-key-ed25519","x":"JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs"}]}

Die Kennung kid muss zum keyid in Signature-Input passen. In der Praxis stammt der Schlüssel aus dem veröffentlichten Verzeichnis des Betreibers.

Prüfen

Fügen Sie die Anfrage in das Eingabefeld ein und klicken Sie auf «Prüfen». Schneller geht es mit dem Beispiel «IETF RFC 9421 (Anhang B.2.6)» unter «Beispiele», das Anfrage und Schlüssel bereits enthält.

Das Ergebnis lautet «unbestimmt» mit Stufe KYA-A1: Die Signatur ist gültig, der Schlüssel stammt von der Prüfstelle, Identität und Auftrag sind belegt. Eine Befugnis enthält die Anfrage nicht.

Gegenprobe: Pfad ändern

Ändern Sie in der Anfragezeile nur den Pfad von /foo auf /bar und prüfen Sie erneut. Weil der Pfad Teil der Signaturbasis ist, passt die Signatur nicht mehr, und das Urteil lautet «ungültig».

Diese Gegenprobe zeigt, was HTTP-Signaturen leisten: Jede Änderung an einer signierten Komponente fällt auf. Nicht signierte Header könnten dagegen unbemerkt verändert werden; deshalb gehören alle relevanten Teile in die Signatur.

Ergebnis einordnen

Eine gültige HTTP-Signatur belegt, wessen Agent anfragt, nicht was er darf. Für Käufe und andere Handlungen mit Folgen braucht es zusätzlich einen Nachweis der Befugnis, etwa ein Mandat oder eine signierte Kaufabsicht nach Verifiable Intent.

Dieselbe Prüfung gilt für Anfragen nach Web Bot Auth und die Signaturebene des Trusted Agent Protocol.

Häufige Fragen

Welche Algorithmen prüft KYA bei HTTP-Signaturen?

Ed25519, ECDSA und RSA-PSS. Der Standard registriert zusätzlich HMAC, das für die öffentliche Prüfung durch Dritte nicht geeignet ist, weil es einen gemeinsamen Schlüssel voraussetzt.

Warum lautet das Ergebnis nicht gültig?

Weil eine Signatur nur die Herkunft der Anfrage belegt. Für «gültig» muss auch die Befugnis zur Handlung belegt sein, und die enthält eine reine HTTP-Signatur nicht.

Muss ich den Schlüssel selbst hinterlegen?

Ja. KYA stellt keine Netzwerkanfragen und lädt Schlüsselverzeichnisse nicht automatisch. So bleibt die Vertrauensentscheidung bei der Prüfstelle.

Kann ich eigene Signaturen mit OpenSSL erzeugen?

Ja. Bilden Sie die Signaturbasis nach RFC 9421, signieren Sie sie mit Ihrem privaten Schlüssel und setzen Sie die Header Signature-Input und Signature. Anhang B des Standards dient als Vorlage.

Quellen

RFC 9421, Anhang B.2.6: https://www.rfc-editor.org/rfc/rfc9421.html#appendix-B.2.6
RFC 9421, Anhang B.1.4 (Testschlüssel): https://www.rfc-editor.org/rfc/rfc9421.html#appendix-B.1.4