Passa al contenuto principale

4. Including a Message Signature in a Message (Inclusione della firma nel messaggio)

4. Including a Message Signature in a Message (Inclusione della firma nel messaggio)​

Le firme possono essere incluse tramite i campi Signature-Input e Signature definiti qui.

Signature-Input identifica le componenti coperte e i parametri; Signature contiene il valore. Ogni campo PUÒ contenere più valori etichettati.

Una firma è identificata da un'etichetta nel messaggio. L'etichetta DEVE essere univoca nel messaggio e DEVE comparire in entrambi i campi. È scelta dal firmatario salvo quanto dettato da negoziazione (Sezione 5).

Una firma DEVE usare entrambi i campi e ciascuno DEVE contenere le stesse etichette. Etichetta in un solo campo è errore.

4.1. Il campo HTTP Signature-Input​

Signature-Input è un Dictionary Structured Field ([STRUCTURED-FIELDS] 3.2) con metadati per una o più firme. Ogni membro descrive una firma. La chiave è l'etichetta univoca. Il valore è l'insieme ordinato coperto serializzato come Inner List con tutti i parametri di metadati:

NOTA: '\' per RFC 8792

Signature-Input: sig1=("@method" "@target-uri" "@authority" \ "content-digest" "cache-control");\ created=1618884475;keyid="test-key-rsa-pss"

Per facilitare la validazione, il valore di Signature-Input DEVE essere identico a quello usato nella @signature-params della base (Sezione 2.3). In un Structured Field, ordine di lista e parametri va preservato.

Il firmatario PUÒ mettere Signature-Input come trailer per firmare dopo l'elaborazione del contenuto. Poiché gli intermediari possono eliminare i trailer [HTTP], è RACCOMANDATO usare solo header per evitare che le firme vengano rimosse.

Più campi Signature-Input POSSONO comparire; le etichette DEVONO essere univoche tra tutti i valori.

4.2. Il campo HTTP Signature​

Signature è un Dictionary Structured Field: chiave = etichetta, valore = Byte Sequence del valore di firma:

NOTA: '\' per RFC 8792

Signature: sig1=:P0wLUszWQjoi54udOtydf9IWTfNhy+r53jGFj9XZuP4uKwxyJo\ 1RSHi+oEF1FuX6O29d+lbxwwBao1BAgadijW+7O/PyezlTnqAOVPWx9GlyntiCiHz\ C87qmSQjvu1CFyFuWSjdGa3qLYYlNm7pVaJFalQiKWnUaqfT4LyttaXyoyZW84jS8\ gyarxAiWI97mPXU+OVM64+HVBHmnEsS+lTeIsEQo36T3NFf2CujWARPQg53r58Rmp\ Z+J9eKR2CD6IJQvacn5A4Ix5BUAVGqlyp8JYm+S/CWJi31PNUjRRCusCVRj05NrxA\ BNFv3r5S9IXf2fYJK+eyW4AiGVMvMcOg==:

Il firmatario PUÒ usare trailer come sopra; è RACCOMANDATO l'header.

Più campi Signature POSSONO comparire; etichette univoche.

4.3. Firme multiple (Multiple Signatures)​

Più firme distinte POSSONO comparire in un singolo messaggio. Ciascuna DEVE avere etichetta univoca. Possono essere aggiunte dallo stesso firmatario o da firmatari diversi. Ad esempio un firmatario può includere più firme sulle stesse componenti con chiavi o algoritmi diversi; un reverse proxy può aggiungere informazioni sul client in campi inoltrando la richiesta, inclusa una firma sui valori di firma originali del client.

Il seguente esempio non normativo parte da una richiesta firmata dal client. Un reverse proxy valida la firma del client:

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-Type: application/json
Content-Length: 18
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
 aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
 "content-digest" "content-type" "content-length")\
 ;created=1618884475;keyid="test-key-ecc-p256"
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
 +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:

{"hello": "world"}

Il proxy altera il messaggio verso l'origine, cambiando l'host target e aggiungendo Forwarded [RFC7239]:

NOTA: '\' per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 18
Forwarded: for=192.0.2.123;host=example.com;proto=https
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
 aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
 "content-digest" "content-type" "content-length")\
 ;created=1618884475;keyid="test-key-ecc-p256"
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
 +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:

{"hello": "world"}

Il proxy può validare la firma in ingresso e aggiungere la propria firma sul nuovo messaggio verso l'origine, includendo gli elementi rilevanti. Spesso copre le stesse componenti del client; qui firma la nuova authority, aggiunge Forwarded, usa la chiave test-key-rsa e rsa-v1_5-sha256, con expires breve. La base è:

NOTA: '\' per RFC 8792

"@method": POST "@authority": origin.host.internal.example "@path": /foo "content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\ +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: "content-type": application/json "content-length": 18 "forwarded": for=192.0.2.123;host=example.com;proto=https "@signature-params": ("@method" "@authority" "@path" \ "content-digest" "content-type" "content-length" "forwarded")\ ;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"\ ;expires=1618884540

e il valore di firma in output:

NOTA: '\' per RFC 8792

S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+JH+8XY1I6+8Cy\ +CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49GwiyUpZ10KHgOEe11s\ x3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7LB5YAv0RAGhB8tmpv7sFn\ Im9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtflzvZdXAsD3LH2TwevU+/PBPv0\ B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbLVdp770I6VHR6WfgS9ddzirrswsE1w\ 5o0LV/g==

Aggiunti al messaggio: firma originale sotto sig1, firma del proxy sotto proxy_sig; il proxy usa test-key-rsa e rsa-v1_5-sha256, il client aveva usato test-key-ecc-p256:

NOTA: '\' per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 18
Forwarded: for=192.0.2.123;host=example.com;proto=https
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
 aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
 "content-digest" "content-type" "content-length")\
 ;created=1618884475;keyid="test-key-ecc-p256", \
 proxy_sig=("@method" "@authority" "@path" "content-digest" \
 "content-type" "content-length" "forwarded")\
 ;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"\
 ;expires=1618884540
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
 +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:, \
 proxy_sig=:S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+\
 JH+8XY1I6+8Cy+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49G\
 wiyUpZ10KHgOEe11sx3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7\
 LB5YAv0RAGhB8tmpv7sFnIm9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtf\
 lzvZdXAsD3LH2TwevU+/PBPv0B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbL\
 Vdp770I6VHR6WfgS9ddzirrswsE1w5o0LV/g==:

{"hello": "world"}

Il proxy potrebbe includere nella nuova firma i campi Signature e Signature-Input della richiesta originale, ma tale pratica NON è RACCOMANDATA per le debolezze di firmare valori di firma (Sezione 7.3.7). Il proxy può aver validato il client; le modifiche invalidano la firma esistente verso l'origine. L'origine può avere informazioni aggiuntive nel contesto (Sezione 7.4.4). In altre applicazioni l'origine non verifica la firma originale ma vuole verificare che il proxy abbia validato correttamente. Per segnalare elaborazione o ricezione sicura servono meccanismi alternativi ben specificati.

Ultimo aggiornamento il