Passa al contenuto principale

2.4. Signing Request Components in a Response Message (Firma di componenti della richiesta in una risposta)

2.4. Signing Request Components in a Response Message (Firma di componenti della richiesta in una risposta)​

Quando una richiesta genera una risposta firmata, il firmatario può includere porzioni della richiesta nella base aggiungendo il parametro req all'identificatore di componente.

req — Flag booleano: il valore della componente è derivato dalla richiesta che ha generato questa risposta, non dalla risposta.

Il parametro si applica sia a campi HTTP sia a componenti derivate che puntano alla richiesta, con la stessa semantica. Il valore si calcola come di norma, ma i dati provengono dalla richiesta invece che dal messaggio di risposta di destinazione.

Lo stesso nome di componente PUÒ comparire con e senza req nella stessa base, indicando la stessa componente nominata sia dalla richiesta sia dalla risposta.

req PUÒ essere combinato con altri parametri appropriati, come key per un campo Dictionary.

Esempio: risposta alla richiesta seguente:

NOTA: '\' per 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"}

Risposta non firmata:

NOTA: '\' per 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"}

Il server firma la risposta con la propria chiave, includendo @status e diversi header nelle componenti coperte. Include anche componenti derivate dalla richiesta originale: metodo, authority, path e digest del contenuto. Content-Digest di richiesta e risposta è incluso sotto la firma della risposta. Per questa applicazione la query non è rilevante e non è coperta.

NOTA: '\' per 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"

Risposta firmata:

NOTA: '\' per 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"}

L'algoritmo ECDSA usato è non deterministico; valori diversi ad ogni esecuzione. Il valore mostrato è validabile con le chiavi indicate; nuove firme non coincideranno necessariamente. Vedere Sezione 7.3.5.

Poiché i valori dalla richiesta non sono ripetuti nella risposta, il richiedente DEVE conservare i valori originali abbastanza a lungo per validare la firma della risposta che usa questo parametro. Di solito serve tenere la richiesta originale. Poiché un intermediario può alterare la richiesta prima del server, le applicazioni devono evitare di firmare valori alterati che il client non potrebbe validare.

È possibile una risposta firmata a una richiesta firmata. Esempio di richiesta firmata:

NOTA: '\' per 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"}

Il server può scegliere di firmare porzioni di questa risposta, includendo porzioni della richiesta, ottenendo questa base:

NOTA: '\' per 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"

e la seguente risposta firmata:

NOTA: '\' per 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"}

Anche in questo caso l'ECDSA è non deterministico (Sezione 7.3.5).

Le applicazioni che firmano una risposta a una richiesta firmata DOVREBBERO firmare tutte le componenti del valore della firma della richiesta per copertura sufficiente e protezione contro attacchi di collisione (Sezione 7.3.7).

Includere i campi Signature e Signature-Input della richiesta nelle componenti della firma della risposta è sintatticamente possibile ma NON è RACCOMANDATO: le firme di firme non forniscono copertura transitiva come ci si potrebbe aspettare (Sezione 7.3.7). Per segnalare elaborazione o ricezione sicura servono meccanismi alternativi specificati con cura.

La firma della risposta può coprire solo ciò che è incluso nella richiesta con questo flag. Se serve coprire il contenuto della richiesta nella firma della risposta, il client deve includere un mezzo come Content-Digest (Sezione 7.2.8).

Il parametro req NON DEVE essere usato per alcuna componente in una firma che ha come destinazione un messaggio di richiesta.

Ultimo aggiornamento il