Zum Hauptinhalt springen

2.4. Signing Request Components in a Response Message (Anfragekomponenten in einer Antwort signieren)

2.4. Signing Request Components in a Response Message (Anfragekomponenten in einer Antwort signieren)​

Führt eine Anfragenachricht zu einer signierten Antwortnachricht, kann der Signierende Teile der Anfragenachricht in die Signaturbasis aufnehmen, indem er den Parameter req am Komponenten-Identifier hinzufügt.

req Boolesches Flag: Der Komponentenwert wird aus der Anfrage abgeleitet, die diese Antwortnachricht ausgelöst hat, und nicht direkt aus der Antwortnachricht.

Der Parameter gilt für HTTP-Felder und abgeleitete Komponenten, die die Anfrage betreffen, mit derselben Semantik. Der Komponentenwert wird wie üblich berechnet, aber die Daten stammen aus der Anfragenachricht statt aus der Ziel-Antwortnachricht, auf die die Signatur angewendet wird.

Derselbe Komponentenname DARF mit und ohne den Parameter req in einer einzelnen Signaturbasis vorkommen und bezeichnet dann dieselbe benannte Komponente aus Anfrage- bzw. Antwortnachricht.

Der Parameter req DARF mit anderen Parametern kombiniert werden, die für den Komponenten-Identifier passen, z. B. dem Parameter key für ein Dictionary-Feld.

Beispiel: Für diese Anfrage wird eine Antwort ausgeliefert:

NOTE: '' Zeilenumbruch gemäß RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Type: application/json
Content-Length: 18

{"hello": "world"}

Daraus ergibt sich folgende unsignierte Antwortnachricht:

NOTE: '' Zeilenumbruch gemäß RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:

{"busy": true, "message": "Your call is very important to us"}

Der Server signiert die Antwort mit eigenem Schlüssel und schließt den Code @status sowie mehrere Header-Felder in die abgedeckten Komponenten ein. Zusätzlich nimmt er mehrere Komponenten aus der ursprünglichen Anfrage in die abgedeckten Komponenten der Antwort auf: Methode, Authority, Pfad und Content-Digest der Anfrage. Content-Digest von Anfrage und Antwort erscheint unter der Antwortsignatur. In diesem Beispiel gilt die Query für die Antwort als nicht relevant und wird nicht abgedeckt. Andere Anwendungen treffen andere Entscheidungen gemäß Abschnitt 1.4.

Die Signaturbasis für dieses Beispiel:

NOTE: '' Zeilenumbruch gemäß RFC 8792

"@status": 503
"content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\
  wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
"content-type": application/json
"@authority";req: example.com
"@method";req: POST
"@path";req: /foo
"content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A\
  2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"@signature-params": ("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "content-digest";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"

Die signierte Antwortnachricht:

NOTE: '' Zeilenumbruch gemäß RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
Signature-Input: reqres=("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "content-digest";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"
Signature: reqres=:dMT/A/76ehrdBTD/2Xx8QuKV6FoyzEP/I9hdzKN8LQJLNgzU\
  4W767HK05rx1i8meNQQgQPgQp8wq2ive3tV5Ag==:

{"busy": true, "message": "Your call is very important to us"}

Der hier verwendete ECDSA-Signaturalgorithmus ist nicht deterministisch; bei jedem Lauf entsteht ein anderer Signaturwert. Der angegebene Wert ist mit den Schlüsseln prüfbar; neu erzeugte Werte werden voraussichtlich nicht mit dem Beispiel übereinstimmen. Siehe Abschnitt 7.3.5.

Da die Komponentenwerte aus der Anfrage in der Antwort nicht wiederholt werden, MUSS der Anfragende die ursprünglichen Komponentenwerte so lange aufbewahren, bis die Signatur der Antwort verifiziert werden kann, die diesen Komponenten-Identifier-Parameter nutzt. Meist muss die ursprüngliche Anfragenachricht erhalten bleiben, da der Signierende beliebige Teile der Anfrage in die Antwort einbeziehen kann. Da ein Vermittler die Anfrage vor dem Server verändern kann, müssen Anwendungen darauf achten, solche veränderten Werte nicht zu signieren, wenn der Client die resultierende Signatur nicht verifizieren kann.

Ein Server kann auch eine signierte Antwort auf eine signierte Anfrage erzeugen. Beispiel einer signierten Anfrage:

NOTE: '' Zeilenumbruch gemäß RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Type: application/json
Content-Length: 18
Signature-Input: sig1=("@method" "@authority" "@path" "@query" \
  "content-digest" "content-type" "content-length")\
  ;created=1618884475;keyid="test-key-rsa-pss"
Signature: sig1=:e8UJ5wMiRaonlth5ERtE8GIiEH7Akcr493nQ07VPNo6y3qvjdK\
  t0fo8VHO8xXDjmtYoatGYBGJVlMfIp06eVMEyNW2I4vN7XDAz7m5v1108vGzaDljr\
  d0H8+SJ28g7bzn6h2xeL/8q+qUwahWA/JmC8aOC9iVnwbOKCc0WSrLgWQwTY6VLp4\
  2Qt7jjhYT5W7/wCvfK9A1VmHH1lJXsV873Z6hpxesd50PSmO+xaNeYvDLvVdZlhtw\
  5PCtUYzKjHqwmaQ6DEuM8udRjYsoNqp2xZKcuCO1nKc0V3RjpqMZLuuyVbHDAbCzr\
  0pg2d2VM/OC33JAU7meEjjaNz+d7LWPg==:

{"hello": "world"}

Der Server kann Teile dieser Antwort signieren, einschließlich mehrerer Teile der Anfrage, mit folgender Signaturbasis:

NOTE: '' Zeilenumbruch gemäß RFC 8792

"@status": 503
"content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\
  wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
"content-type": application/json
"@authority";req: example.com
"@method";req: POST
"@path";req: /foo
"@query";req: ?param=Value&Pet=dog
"content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A\
  2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-type";req: application/json
"content-length";req: 18
"@signature-params": ("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "@query";req \
  "content-digest";req "content-type";req "content-length";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"

und folgender signierter Antwort:

NOTE: '' Zeilenumbruch gemäß RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
Signature-Input: reqres=("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "@query";req \
  "content-digest";req "content-type";req "content-length";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"
Signature: reqres=:C73J41GVKc+TYXbSobvZf0CmNcptRiWN+NY1Or0A36ISg6ym\
  dRN6ZgR2QfrtopFNzqAyv+CeWrMsNbcV2Ojsgg==:

{"busy": true, "message": "Your call is very important to us"}

Wieder: ECDSA ist nicht deterministisch (Abschnitt 7.3.5).

Anwendungen, die eine Antwort auf eine signierte Anfrage signieren, SOLLEN alle Komponenten des Signaturwerts der Anfragesignatur abdecken, um ausreichend Schutz gegen eine Klasse von Kollisionsangriffen zu bieten (Abschnitt 7.3.7). Der Server in diesem Beispiel hat alle im Feld Signature-Input der Client-Signatur auf der Anfrage genannten Komponenten zusätzlich zu Antwortkomponenten in die Antwortsignatur aufgenommen.

Obwohl es syntaktisch möglich ist, die Felder Signature und Signature-Input der Anfrage in die Signaturkomponenten der Antwort aufzunehmen, wird diese Praxis NICHT EMPFOHLEN, da Signaturen über Signaturen keine transitive Abdeckung der abgedeckten Komponenten liefern und mehreren Angriffen ausgesetzt sind (Abschnitt 7.3.7). Für den sicheren Nachweis erfolgreicher Verarbeitung oder des Eingangs einer Signatur müssen alternative Mechanismen sorgfältig spezifiziert werden.

Mit diesem Flag kann die Antwortsignatur nur das abdecken, was in der Anfragenachricht enthalten ist. Soll der Nachrichteninhalt der Anfrage unter der Antwortsignatur fallen, muss der Client ein Mittel zum Abdecken dieses Inhalts mitsenden, z. B. ein Feld Content-Digest. Siehe Abschnitt 7.2.8.

Der Parameter req DARF NICHT für eine Komponente verwendet werden, wenn die Signatur eine Anfragenachricht zum Ziel hat.

Letztes Update am