1.4. Applicazione delle firme dei messaggi HTTP (Application of HTTP Message Signatures)

1.4. Applicazione delle firme dei messaggi HTTP (Application of HTTP Message Signatures)

Le firme dei messaggi HTTP sono progettate come strumento di uso generale applicabile in molteplici circostanze e applicazioni. Per applicare correttamente e in sicurezza le firme dei messaggi HTTP, un'applicazione o un profilo di questa specifica DEVE specificare, come minimo, tutti gli elementi seguenti:

• L'insieme di identificatori di componente (Sezione 2) e parametri di firma (Sezione 2.3) che si attende e che è RICHIESTO siano inclusi nell'elenco dei componenti coperti. Ad esempio, un protocollo di autorizzazione potrebbe imporre che il campo Authorization sia coperto per proteggere le credenziali di autorizzazione e che i parametri di firma contengano un parametro created (Sezione 2.3), mentre un'API che si attende contenuto HTTP semanticamente rilevante potrebbe richiedere che il campo Content-Digest definito in [DIGEST] sia presente e coperto e che sia imposto un valore per il parametro tag (Sezione 2.3) specifico dell'API protetta.

• I tipi Structured Field [STRUCTURED-FIELDS] attesi di eventuali campi o parametri coperti richiesti o attesi.

• Un mezzo per recuperare il materiale di chiave usato per verificare la firma. Un'applicazione userà di solito il parametro keyid dei parametri di firma (Sezione 2.3) e definirà regole per risolvere una chiave a partire da esso, sebbene la chiave appropriata possa essere nota per altre vie, come la preregistrazione della chiave del firmatario.

• L'insieme di algoritmi di firma consentiti da usare per i firmatari e da accettare per i verificatori.

• Un mezzo per stabilire che l'algoritmo di firma usato per verificare la firma è appropriato per il materiale di chiave e il contesto del messaggio. Ad esempio, il processo potrebbe usare il parametro alg dei parametri di firma (Sezione 2.3) per dichiarare esplicitamente l'algoritmo, derivare l'algoritmo dal materiale di chiave o usare un algoritmo preconfigurato concordato tra firmatario e verificatore.

• Un mezzo per stabilire che una data chiave e un dato algoritmo usati per una firma sono appropriati per il contesto del messaggio. Ad esempio, un server che si attende solo firme ECDSA dovrebbe sapere di rifiutare firme RSA, o un server che si attende crittografia asimmetrica dovrebbe sapere di rifiutare crittografia simmetrica.

• Un mezzo per determinare il contesto per la derivazione dei componenti del messaggio da un messaggio HTTP e dal suo contesto applicativo. Di norma questo è il messaggio HTTP di destinazione stesso, ma il contesto può includere informazioni aggiuntive note all'applicazione tramite configurazione, come un hostname esterno.

• Se è necessario un legame tra richiesta e risposta usando il meccanismo fornito nella Sezione 2.4, tutti gli elementi del messaggio di richiesta e del messaggio di risposta che sarebbero necessari per fornire proprietà di tale legame.

• I messaggi di errore e i codici restituiti dal verificatore al firmatario quando la firma non è valida, il materiale di chiave non è appropriato, la finestra di validità temporale è fuori specifica, un valore di componente non può essere calcolato o si verificano altri errori durante la verifica della firma. Ad esempio, se una firma è usata come meccanismo di autenticazione, un codice di stato HTTP 401 (Unauthorized) o 403 (Forbidden) può essere appropriato. Se la risposta proviene da un'API HTTP, una risposta con un codice di stato HTTP come 400 (Bad Request) può includere maggiori dettagli [RFC7807] [RFC9457], come un indicatore che è stato usato materiale di chiave errato.

Scegliendo questi parametri, un'applicazione delle firme dei messaggi HTTP deve garantire che il verificatore abbia accesso a tutte le informazioni richieste per ricreare la base della firma. Ad esempio, un server dietro un reverse proxy dovrebbe conoscere l'URI di richiesta originale per usare il componente derivato @target-uri, sebbene l'URI di destinazione apparente sia modificato dal reverse proxy (si veda anche la Sezione 7.4.3). Inoltre, un'applicazione che usa firme nelle risposte dovrebbe garantire che i client che ricevono risposte firmate abbiano accesso a tutte le porzioni firmate del messaggio, incluse eventuali porzioni della richiesta firmate dal server con il parametro req ("request-response") (Sezione 2.4).

I dettagli su questo tipo di profilazione rientrano nell'ambito dell'applicazione e sono fuori dall'ambito di questa specifica; tuttavia, ulteriori considerazioni sono discusse nella Sezione 7. In particolare, scegliendo l'insieme richiesto di identificatori di componente, occorre fare attenzione a garantire che la copertura sia sufficiente per l'applicazione, come discusso nelle Sezioni 7.2.1 e 7.2.8. Questa specifica definisce solo parte di un sistema di sicurezza completo per un'applicazione. Costruendo un sistema di sicurezza completo basato su questo strumento, è importante eseguire un'analisi di sicurezza dell'intero sistema, di cui le firme dei messaggi HTTP sono una parte. Sistemi storici, come AWS Signature Version 4 [AWS-SIGv4], possono fornire ispirazione ed esempi su come applicare meccanismi simili a un'applicazione, sebbene l'esame di tali sistemi storici non elimini la necessità di un'analisi di sicurezza di un'applicazione delle firme dei messaggi HTTP.