1. Introduzione

HTTP non definisce i mezzi per proteggere l'integrità dei dati del contenuto o delle rappresentazioni. Quando i messaggi HTTP vengono trasferiti tra endpoint, le funzionalità o le proprietà di livello inferiore come i checksum TCP o i record TLS [TLS] possono fornire una certa protezione dell'integrità. Tuttavia, l'integrità orientata al trasporto offre un'utilità limitata perché è opaca al livello dell'applicazione e copre solo l'estensione di una singola connessione. I messaggi HTTP viaggiano spesso su una catena di connessioni separate. Tra le connessioni, c'è la possibilità di corruzione dei dati. Un meccanismo di integrità HTTP può fornire i mezzi per gli endpoint, o le applicazioni che utilizzano HTTP, per rilevare la corruzione dei dati e fare una scelta su come agire su di essa. Un caso d'uso di esempio è aiutare il rilevamento e la diagnosi dei guasti attraverso i confini del sistema.

Questo documento definisce due meccanismi di integrità digest per HTTP. Primo, l'integrità del contenuto, che agisce sul contenuto trasmesso (Sezione 6.4 di [HTTP]). Secondo, l'integrità dei dati di rappresentazione, che agisce sui dati di rappresentazione (Sezione 8.1 di [HTTP]). Ciò supporta casi d'uso avanzati, come la convalida dell'integrità di una risorsa che è stata ricostruita da parti recuperate utilizzando più richieste o connessioni.

Questo documento rende obsoleto [RFC3230] e quindi i campi HTTP Digest e Want-Digest; vedere la Sezione 1.3.

1.1. Struttura del documento

Questo documento è strutturato come segue:

• Nuove definizioni di campi di intestazione e trailer di richiesta e risposta.

  • Sezione 2 (Content-Digest),
  • Sezione 3 (Repr-Digest), e
  • Sezione 4 (Want-Content-Digest e Want-Repr-Digest).

• Considerazioni specifiche per l'integrità dei dati di rappresentazione.

  • Sezione 3.1 (Richieste che cambiano stato),
  • Sezione 3.2 (Content-Location),
  • L'Appendice A contiene esempi elaborati di dati di rappresentazione negli scambi di messaggi, e
  • Le Appendici B e C contengono esempi elaborati di campi Repr-Digest e Want-Repr-Digest negli scambi di messaggi.

• La Sezione 5 presenta considerazioni sull'algoritmo hash e definisce le procedure di registrazione per le voci future.

1.2. Panoramica del concetto

I campi HTTP definiti in questo documento possono essere utilizzati per l'integrità HTTP. I mittenti scelgono un algoritmo di hashing e calcolano un digest da un input relativo al messaggio HTTP. L'identificatore dell'algoritmo e il digest vengono trasmessi in un campo HTTP. I destinatari possono convalidare il digest a fini di integrità. Gli algoritmi di hashing sono registrati nel registro "Hash Algorithms for HTTP Digest Fields" (vedere la Sezione 7.2).

La selezione dei dati su cui vengono calcolati i digest dipende dal caso d'uso dei messaggi HTTP. Questo documento fornisce campi diversi per i dati di rappresentazione HTTP e il contenuto HTTP.

Ci sono casi d'uso in cui è richiesto un semplice digest dei byte del contenuto HTTP. Il campo di intestazione e trailer di richiesta e risposta Content-Digest è definito per supportare i digest del contenuto (Sezione 6.4 di [HTTP]); vedere la Sezione 2.

Per casi d'uso più avanzati, è definito il campo di intestazione e trailer di richiesta e risposta Repr-Digest (Sezione 3). Contiene un valore di digest calcolato applicando un algoritmo di hashing ai dati di rappresentazione selezionati (Sezione 8.1 di [HTTP]). Basare Repr-Digest sulla rappresentazione selezionata rende semplice applicarlo a casi d'uso in cui il contenuto del messaggio richiede un qualche tipo di manipolazione per essere considerato come rappresentazione della risorsa o il contenuto trasmette una rappresentazione parziale di una risorsa, come le richieste di intervallo (vedere la Sezione 14 di [HTTP]).

Content-Digest e Repr-Digest supportano l'agilità dell'algoritmo di hashing. I campi Want-Content-Digest e Want-Repr-Digest consentono agli endpoint di esprimere interesse rispettivamente per Content-Digest e Repr-Digest e di esprimere preferenze di algoritmo in entrambi.

Content-Digest e Repr-Digest sono collettivamente definiti "Campi di integrità" (Integrity fields). Want-Content-Digest e Want-Repr-Digest sono collettivamente definiti "Campi di preferenza di integrità" (Integrity preference fields).

I campi di integrità sono legati ai campi di intestazione Content-Encoding e Content-Type. Pertanto, una determinata risorsa può avere più valori di digest diversi quando trasferita con HTTP.

I campi di integrità si applicano al contenuto del messaggio HTTP o alle rappresentazioni HTTP. Non si applicano ai messaggi o ai campi HTTP. Tuttavia, possono essere combinati con altri meccanismi che proteggono i metadati, come le firme digitali, al fine di proteggere le fasi di uno scambio HTTP in tutto o in parte. Ad esempio, le firme dei messaggi HTTP [SIGNATURES] potrebbero essere utilizzate per firmare i campi di integrità, fornendo così copertura per il contenuto HTTP o i dati di rappresentazione.

Questa specifica non definisce mezzi per l'autenticazione, l'autorizzazione o la privacy.

1.3. Obsolescenza della RFC 3230

[RFC3230] ha definito i campi HTTP Digest e Want-Digest per l'integrità HTTP. Ha anche coniato i termini "istanza" (instance) e "manipolazione dell'istanza" (instance manipulation) per spiegare concetti, come i dati di rappresentazione selezionati (Sezione 8.1 di [HTTP]), che sono ora definiti e implementati in modo più universale come semantica HTTP.

L'esperienza ha dimostrato che le implementazioni di [RFC3230] hanno interpretato il significato di "istanza" in modo incoerente, portando a problemi di interoperabilità. Il problema più comune riguarda l'errore di calcolare il digest utilizzando (quello che ora chiamiamo) contenuto del messaggio, piuttosto che utilizzare (quelli che ora chiamiamo) dati di rappresentazione come era originariamente previsto. È interessante notare che il tempo ha anche dimostrato che un digest del contenuto del messaggio può essere vantaggioso per alcuni casi d'uso, quindi è difficile rilevare se la non conformità a [RFC3230] sia intenzionale o involontaria.

Al fine di affrontare potenziali incoerenze e ambiguità tra le implementazioni di Digest e Want-Digest, questo documento rende obsoleto [RFC3230]. I campi di integrità (Sezioni 2 e 3) e i campi di preferenza di integrità (Sezione 4) definiti in questo documento sono meglio allineati con l'attuale semantica HTTP e hanno nomi che articolano più chiaramente gli usi previsti.

1.4. Convenzioni di notazione

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nel BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

Questo documento utilizza l'Augmented BNF definito in [RFC5234] e aggiornato da [RFC7405]. Ciò include le regole CR (ritorno a capo), LF (avanzamento riga) e CRLF (CR LF).

Questo documento utilizza la seguente terminologia dalla Sezione 3 di [STRUCTURED-FIELDS] per specificare la sintassi e l'analisi: Booleano (Boolean), Sequenza di byte (Byte Sequence), Dizionario (Dictionary), Intero (Integer) ed Elenco (List).

Le definizioni "rappresentazione" (representation), "rappresentazione selezionata" (selected representation), "dati di rappresentazione" (representation data), "metadati di rappresentazione" (representation metadata), "agente utente" (user agent) e "contenuto" (content) in questo documento devono essere interpretate come descritto in [HTTP].

Questo documento utilizza le strategie di piegatura delle righe descritte in [FOLDING].

I nomi degli algoritmi di hashing rispettano le maiuscole/minuscole utilizzate nel loro documento di definizione (ad esempio, SHA-1, CRC32c).

I messaggi HTTP indicano gli algoritmi di hashing utilizzando una chiave algoritmo (Algorithm Key) (algoritmi). Laddove il documento si riferisce a una chiave algoritmo in prosa, viene citata (ad esempio, "sha", "crc32c").

Il termine "checksum" descrive l'output dell'applicazione di un algoritmo a una sequenza di byte, mentre "digest" viene utilizzato solo in relazione al valore contenuto nei campi.

"Campi di integrità" (Integrity fields) è il termine collettivo per Content-Digest e Repr-Digest.

"Campi di preferenza di integrità" (Integrity preference fields) è il termine collettivo per Want-Repr-Digest e Want-Content-Digest.