5. Requesting Signatures (Richiesta di firme)

Un firmatario può allegare una firma senza sollecito, ma spesso il verificatore potenziale segnala di attendersi una firma con il campo Accept-Signature.

Se Accept-Signature è in una richiesta HTTP, indica che il client desidera che il server firmi la risposta con i parametri indicati; il messaggio di destinazione è la risposta a tale richiesta. Le risorse che supportano tale negoziazione DOVREBBERO rispondere non cacheabili o con Vary che elenca Accept-Signature, per evitare che una cache restituisca una firma destinata a un'altra richiesta.

Se Accept-Signature è in una risposta HTTP, indica che il server desidera che il client firmi la richiesta successiva con i parametri indicati; il messaggio di destinazione è la richiesta successiva del client. Il client può continuare a firmare richieste successive allo stesso modo.

Il messaggio di destinazione di Accept-Signature DEVE includere tutte le firme etichettate indicate nel campo, ciascuna che copre le stesse componenti identificate.

Il mittente di Accept-Signature DEVE includere solo identificatori appropriati al tipo di messaggio. Se il target è una richiesta, le componenti coperte non possono includere @status.

5.1. Il campo Accept-Signature

Accept-Signature è un Dictionary Structured Field con metadati per una o più firme richieste sul target. Ogni membro descrive una firma richiesta. La chiave è l'etichetta univoca nel contesto del target.

Il valore è la serializzazione delle componenti coperte desiderate, inclusi parametri di metadati consentiti, con il processo della Sezione 2.3:

NOTA: '\' per RFC 8792

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

L'elenco indica l'insieme esatto di identificatori, inclusi i parametri di componente applicabili.

La richiesta di firma PUÒ includere parametri di metadati che indicano comportamenti desiderati:

created: si chiede di generare e includere l'istante di creazione. Senza valore associato nella richiesta.

expires: si chiede di generare e includere la scadenza. Senza valore associato.

nonce: si chiede di usare il valore di questo parametro come nonce della firma nel target.

alg: si chiede di usare l'algoritmo indicato dal registro.

keyid: si chiede di usare il materiale di chiave indicato.

tag: si chiede di includere questo valore come tag della firma nel target.

5.2. Elaborazione di Accept-Signature

Il destinatario soddisfa il campo così:

Analizzare il valore come Dictionary.
Per ogni membro:

2.1. La chiave è l'etichetta dell'output come Sezione 4.1.

2.2. Analizzare il valore per ottenere l'insieme degli identificatori coperti.

2.3. Verificare che le componenti siano applicabili al target; altrimenti errore.

2.4. Elaborare i parametri richiesti (algoritmo, chiave, ecc.); se non soddisfacibili o in conflitto con il target, errore.

2.5. Selezionare e generare parametri aggiuntivi necessari.

2.6. Creare la firma sul target.

2.7. Creare i valori Signature-Input e Signature con l'etichetta.

Opzionalmente creare ulteriori coppie con etichette non presenti in Accept-Signature.
Combinare tutte le coppie etichettate e allegare entrambi i campi al target.

Con questo processo, una firma sul target DEVE avere la stessa etichetta, DEVE includere lo stesso insieme di componenti coperte, DEVE elaborare tutti i parametri richiesti e PUÒ avere parametri aggiuntivi.

Il destinatario PUÒ ignorare richieste che non rispettano i parametri dell'applicazione.

Il target PUÒ includere firme aggiuntive non specificate da Accept-Signature (es. seconda firma con più componenti e output della firma richiesta).