1.1. Convenzioni e terminologia (Conventions and Terminology)

1.1. Convenzioni e terminologia (Conventions and Terminology)

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento vanno interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, compaiono interamente in maiuscolo, come qui mostrato. Nella traduzione italiana di questo documento, questi concetti si rendono con: DEVE, NON DEVE, RICHIESTO, DOVREBBE, NON DOVREBBE, RACCOMANDATO, NON RACCOMANDATO, PUÒ e OPZIONALE, mantenendo la stessa forza normativa.

I termini "HTTP message (messaggio HTTP)", "HTTP request (richiesta HTTP)", "HTTP response (risposta HTTP)", "target URI (URI di destinazione)", "gateway", "header field (campo di intestazione)", "intermediary (intermediario)", "request target (obiettivo della richiesta)", "trailer field (campo trailer)", "sender (mittente)", "method (metodo)" e "recipient (destinatario)" sono usati come definiti in [HTTP].

Per brevità, il termine "signature (firma)" da solo indica in questo documento sia le firme digitali (che usano crittografia asimmetrica) sia i MAC con chiave (keyed MAC, che usano crittografia simmetrica). Analogamente, il verbo "sign (firmare)" indica la generazione di una firma digitale o di un MAC con chiave su una data base della firma (signature base). Il termine qualificato "digital signature (firma digitale)" si riferisce specificamente all'output di un'operazione di firma crittografica asimmetrica.

Questo documento usa la terminologia della Sezione 3 di [STRUCTURED-FIELDS] per specificare i tipi di dati: List, Inner List, Dictionary, Item, String, Integer, Byte Sequence e Boolean.

Questo documento definisce diverse costruzioni di stringa usando ABNF [ABNF] e usa le seguenti regole ABNF: VCHAR, SP, DQUOTE e LF. Usa le seguenti regole ABNF da [STRUCTURED-FIELDS]: sf-string, inner-list e parameters. Usa le seguenti regole ABNF da [HTTP] e [HTTP/1.1]: field-content, obs-fold e obs-text.

Oltre a quelle elencate sopra, questo documento usa i seguenti termini:

HTTP Message Signature (firma del messaggio HTTP): Una firma digitale o un MAC con chiave che copre una o più porzioni di un messaggio HTTP. Un dato messaggio HTTP può contenere più firme di messaggio HTTP.

Signer (firmatario): L'entità che genera o ha generato una firma del messaggio HTTP. Più entità possono agire come firmatari e applicare firme distinte a un dato messaggio HTTP.

Verifier (verificatore): Un'entità che verifica o ha verificato una firma del messaggio HTTP rispetto a un messaggio HTTP. Una firma può essere verificata più volte, potenzialmente da entità diverse.

HTTP Message Component (componente del messaggio HTTP): Una porzione di un messaggio HTTP che può essere coperta da una firma del messaggio HTTP.

Derived Component (componente derivato): Un componente del messaggio HTTP derivato dal messaggio HTTP mediante un algoritmo o processo specificato. Si veda la Sezione 2.2.

HTTP Message Component Name (nome del componente del messaggio HTTP): Una String che identifica l'origine di un componente del messaggio HTTP, ad esempio un nome di campo o un nome di componente derivato.

HTTP Message Component Identifier (identificatore del componente del messaggio HTTP): La combinazione di un nome di componente del messaggio HTTP e di eventuali parametri. Questa combinazione identifica in modo univoco un componente specifico del messaggio HTTP rispetto a una particolare firma del messaggio HTTP e al messaggio HTTP a cui si applica.

HTTP Message Component Value (valore del componente del messaggio HTTP): Il valore associato a un dato identificatore di componente nel contesto di un particolare messaggio HTTP. I valori dei componenti sono derivati dal messaggio HTTP e di solito sono soggetti a un processo di canonicalizzazione.

Covered Components (componenti coperti): Un insieme ordinato di identificatori di componenti del messaggio HTTP per campi (Sezione 2.1) e componenti derivati (Sezione 2.2) che indica l'insieme di componenti del messaggio coperti dalla firma, senza mai includere l'identificatore @signature-params stesso. L'ordine di questo insieme è preservato e comunicato tra firmatario e verificatore per facilitare la ricostruzione della base della firma.

Signature Base (base della firma): La sequenza di byte generata dal firmatario e dal verificatore usando l'insieme dei componenti coperti e il messaggio HTTP. La base della firma è elaborata dall'algoritmo crittografico per produrre o verificare la firma del messaggio HTTP.

HTTP Message Signature Algorithm (algoritmo della firma del messaggio HTTP): Un algoritmo crittografico che descrive il processo di firma e verifica per la firma, definito in termini delle primitive HTTP_SIGN e HTTP_VERIFY descritte nella Sezione 3.3.

Key Material (materiale di chiave): Il materiale di chiave richiesto per creare o verificare la firma. Il materiale di chiave è spesso identificato con un identificatore di chiave esplicito, consentendo al firmatario di indicare al verificatore quale chiave è stata usata.

Creation Time (istante di creazione): Un timestamp che rappresenta l'istante in cui la firma è stata generata, come asserito dal firmatario.

Expiration Time (istante di scadenza): Un timestamp che rappresenta l'istante dopo il quale la firma non dovrebbe più essere accettata dal verificatore, come asserito dal firmatario.

Target Message (messaggio di destinazione): Il messaggio HTTP a cui si applica una firma del messaggio HTTP.

Signature Context (contesto della firma): La sorgente dati da cui sono tratti i valori dei componenti del messaggio HTTP. Il contesto include il messaggio di destinazione e qualsiasi informazione aggiuntiva che il firmatario o il verificatore possano avere, come l'URI di destinazione completo di una richiesta o il messaggio di richiesta correlato per una risposta.

Il termine "UNIX timestamp" si riferisce a ciò che la Sezione 4.16 di [POSIX.1] chiama "seconds since the Epoch (secondi dall'Epoca)".

Questo documento contiene esempi non normativi di messaggi HTTP parziali e completi. Alcuni esempi usano un singolo backslash () finale per indicare l'andare a capo per valori lunghi, come da [RFC8792]. Il carattere \ e gli spazi iniziali sulle righe continuate non fanno parte del valore.