4.3. Firme multiple (Multiple Signatures)
4.3. Firme multiple (Multiple Signatures)
PIÙ firme distinte POSSONO essere incluse in un singolo messaggio. Ogni firma distinta DEVE avere un'etichetta univoca. Queste firme multiple possono essere tutte aggiunte dallo stesso firmatario, oppure possono provenire da diversi firmatari. Ad esempio, un firmatario può includere più firme sugli stessi componenti del messaggio con chiavi o algoritmi diversi per supportare verificatori con capacità diverse, o un reverse proxy può includere informazioni sul client in campi quando inoltra la richiesta a un host di servizio, inclusa una firma sui valori di firma originali del client.
Il seguente esempio non normativo inizia con una richiesta firmata dal client. Un reverse proxy prende questa richiesta e convalida la firma del client:
NOTA: a capo con '' secondo 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 quindi altera il messaggio prima di inoltrarlo al server di origine, cambiando l'host di destinazione e aggiungendo il campo di intestazione Forwarded definito in [RFC7239]:
NOTA: a capo con '' secondo 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 è in una posizione tale da convalidare la firma in arrivo del client e formulare la propria dichiarazione al server di origine sulla natura della richiesta che sta inoltrando aggiungendo la propria firma sul nuovo messaggio prima di passarlo al server di origine. Il proxy include anche tutti gli elementi dal messaggio originale rilevanti per l'elaborazione del server di origine. In molti casi, il proxy vorrà coprire tutti gli stessi componenti coperti dalla firma del client, come nel seguente esempio. Si noti che in questo esempio il proxy firma il nuovo valore di autorità, che ha modificato. Il proxy aggiunge anche il campo Forwarded al valore della propria firma. Il proxy identifica la propria chiave e algoritmo e, in questo esempio, include una scadenza per la firma per indicare ai sistemi a valle che il proxy non garantirà questo messaggio firmato oltre questa breve finestra temporale. Ciò produce una base della firma di:
NOTA: a capo con '' secondo 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 un valore di output della firma di:
NOTA: a capo con '' secondo RFC 8792
S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+JH+8XY1I6+8Cy
+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49GwiyUpZ10KHgOEe11s
x3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7LB5YAv0RAGhB8tmpv7sFn
Im9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtflzvZdXAsD3LH2TwevU+/PBPv0
B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbLVdp770I6VHR6WfgS9ddzirrswsE1w
5o0LV/g==
Questi valori sono aggiunti al messaggio di richiesta HTTP dal proxy. La firma originale è inclusa sotto l'etichetta sig1, e la firma del reverse proxy è inclusa sotto l'etichetta proxy_sig. Il proxy usa la chiave test-key-rsa per creare la propria firma con l'algoritmo di firma rsa-v1_5-sha256, mentre la firma originale del client era stata fatta con la chiave test-key-rsa-pss e un algoritmo di firma RSA-PSS:
NOTA: a capo con '' secondo 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"}
Sebbene il proxy potrebbe inoltre includere il valore del campo Signature del client e i campi Signature-Input dal messaggio originale nei componenti coperti della nuova firma, questa pratica NON È RACCOMANDATA a causa di debolezze note nel firmare valori di firma, come discusso nella Sezione 7.3.7. Il proxy è in una posizione tale da convalidare la firma del client; le modifiche che il proxy apporta al messaggio invalideranno la firma esistente quando il messaggio è visto dal server di origine. In questo esempio, è possibile che il server di origine abbia informazioni aggiuntive nel suo contesto della firma per tenere conto del cambiamento di autorità, sebbene questa pratica richieda configurazione aggiuntiva e maggiore cautela come discusso nella Sezione 7.4.4. In altre applicazioni, il server di origine non sarà in grado di verificare la firma originale stesso ma vorrà comunque verificare che il proxy abbia eseguito la convalida appropriata della firma del client. Un'applicazione che deve segnalare l'elaborazione o la ricezione con successo di una firma dovrebbe specificare con cura meccanismi alternativi per inviare tale segnale in modo sicuro.