8. User Agent Processing Model (Modello di Elaborazione dell'Agente Utente)

Questa sezione descrive il modello di elaborazione HTTP Strict Transport Security degli UA. Il modello ha diversi aspetti, enumerati dalle seguenti sottosezioni.

Questo modello di elaborazione presuppone che il UA implementi IDNA2008 [RFC5890], o possibilmente IDNA2003 [RFC3490], come discusso nella sezione 13 ("Internationalized Domain Names for Applications (IDNA): Dependency and Migration"). Presuppone anche che tutti i nomi di dominio operanti nel contesto di questa specifica siano stati canonizzati IDNA prima dell'elaborazione specificata in questa sezione, come descritto nella sezione 10 ("Domain Name IDNA-Canonicalization").

NOTA: Il riferimento a [RFC3490] è dovuto alla sua continua rilevanza per la distribuzione effettiva nel prossimo futuro.

Le assunzioni di cui sopra implicano anche che questo modello di elaborazione presuppone specificamente che un'appropriata validazione IDNA e Unicode e test di elenchi di caratteri siano stati eseguiti sui nomi di dominio prima dell'elaborazione specificata in questa sezione, nel contesto del processo di canonizzazione IDNA dei nomi di dominio. Vedere le considerazioni di sicurezza specifiche IDNA nella sezione 14.10 ("Internationalized Domain Names") per la motivazione e ulteriori dettagli.

8.1. Strict-Transport-Security Response Header Field Processing (Elaborazione del Campo di Intestazione di Risposta Strict-Transport-Security)

Se una risposta HTTP ricevuta tramite trasporto sicuro contiene un campo di intestazione STS conforme alla sintassi specificata nella sezione 6.1 ("Strict-Transport-Security HTTP Response Header Field"), e non ci sono errori o avvertimenti del trasporto sicuro sottostante (vedere la sezione 8.4), il UA deve (MUST):

• Annotare l'host come host HSTS conosciuto se non è ancora annotato (vedere la sezione 8.1.1 ("Noting an HSTS Host - Storage Model")),

oppure

• Aggiornare le informazioni memorizzate nella cache del UA per l'host HSTS conosciuto se una o entrambe le informazioni trasmesse nei token di valore del campo di intestazione max-age e includeSubDomains differiscono dalle informazioni che il UA già mantiene.

  Il valore max-age è essenzialmente un valore di "time to live" relativo al momento della ricezione del campo di intestazione STS.

  Se il valore del token di valore del campo di intestazione max-age è zero, il UA deve (MUST) eliminare le sue informazioni di politica HSTS memorizzate nella cache (inclusa la direttiva includeSubDomains, se asserita) se l'host HSTS è conosciuto, oppure il UA non deve (MUST NOT) annotare questo host HSTS se non è ancora conosciuto.

  Se il UA riceve più campi di intestazione STS in un messaggio di risposta HTTP tramite trasporto sicuro, il UA deve (MUST) elaborare solo il primo tale campo di intestazione.

Altrimenti:

• Se una risposta HTTP viene ricevuta tramite trasporto non sicuro, il UA deve (MUST) ignorare qualsiasi campo di intestazione STS presente.

• Il UA deve (MUST) ignorare qualsiasi campo di intestazione STS che non si conforma alla sintassi specificata nella sezione 6.1 ("Strict-Transport-Security HTTP Response Header Field").

8.1.1. Noting an HSTS Host - Storage Model (Annotazione di un Host HSTS - Modello di Memorizzazione)

Se la sottostringa che corrisponde alla produzione host nel Request-URI (il messaggio a cui l'host risponde) corrisponde sintatticamente alla produzione IP-literal o IPv4address nella sezione 3.2.2 di [RFC3986], allora il UA non deve (MUST NOT) annotare questo host come host HSTS conosciuto.

Altrimenti, se la sottostringa non corrisponde in modo congruente al nome di dominio di un host HSTS conosciuto secondo il processo di corrispondenza specificato nella sezione 8.2 ("Known HSTS Host Domain Name Matching"), allora il UA deve (MUST) annotare questo host come host HSTS conosciuto, memorizzare nella cache il nome di dominio dell'host HSTS, e annotare con esso il tempo di scadenza di queste informazioni, come effettivamente stabilito dal valore max-age dato, e se la direttiva includeSubDomains è asserita. Vedere anche la sezione 11.2 ("HSTS Policy Expiration Time Considerations").

Il UA non deve (MUST NOT) modificare il tempo di scadenza o la direttiva includeSubDomains di qualsiasi host HSTS conosciuto corrispondente al dominio padre.

Se la voce nella cache di un host HSTS conosciuto ha una data di scadenza nel passato, quell'host HSTS conosciuto è "scaduto (expired)". Se in qualsiasi momento esistono host HSTS conosciuti scaduti nella cache, il UA deve (MUST) rimuovere tutti gli host HSTS conosciuti scaduti dalla sua cache.

8.2. Known HSTS Host Domain Name Matching (Corrispondenza Nome di Dominio Host HSTS Conosciuto)

Un dato nome di dominio può corrispondere al nome di dominio di un host HSTS conosciuto in uno o entrambi i seguenti modi: corrispondenza congruente (congruent match) o corrispondenza di superdominio (superdomain match). Oppure, potrebbe non esserci corrispondenza.

I seguenti passaggi determinano se esiste una corrispondenza e, in caso affermativo, in quale modo:

Utilizzando un confronto ASCII case-insensitive, iniziando dall'etichetta più a destra e continuando da destra a sinistra, confrontare etichetta per etichetta (confrontando solo le etichette) il dato nome di dominio con il nome di dominio di ogni host HSTS conosciuto non scaduto del UA. Vedere anche la sezione 2.3.2.4 di [RFC5890].

• Corrispondenza di Superdominio (Superdomain Match)

  Se viene trovata una corrispondenza etichetta per etichetta tra l'intero nome di dominio dell'host HSTS conosciuto e la parte destra del dato nome di dominio, allora il nome di dominio di questo host HSTS conosciuto è una corrispondenza di superdominio del dato nome di dominio. Potrebbero esserci più corrispondenze di superdominio per un dato nome di dominio.

• Corrispondenza Congruente (Congruent Match)

  Se viene trovata una corrispondenza etichetta per etichetta tra il nome di dominio dell'host HSTS conosciuto e il dato nome di dominio -- cioè, non ci sono altre etichette da confrontare -- allora il dato nome di dominio corrisponde in modo congruente a questo host HSTS conosciuto.

8.3. URI Loading and Port Mapping (Caricamento URI e Mappatura Porte)

Durante il caricamento di un URI, se la politica HSTS si applica come descritto nella sezione 5.4, il UA deve (MUST) comportarsi come segue:

• Se l'URI non ha un componente porta, o se il componente porta è uguale alla porta non sicura predefinita 80, assegnare all'URI la porta di trasporto sicuro predefinita 443 come componente porta dell'URI di richiesta effettivo.

• Cambiare il componente schema dell'URI in "https".

• Non deve (MUST NOT) stabilire una connessione non sicura.

• Può (MAY) tentare di stabilire una connessione sicura all'URI di richiesta effettivo costruito.

8.4. Errors in Secure Transport Establishment (Errori nell'Instaurazione del Trasporto Sicuro)

Se si verifica un errore durante il tentativo di stabilire una connessione sicura a un host HSTS conosciuto, il UA non deve (MUST NOT) proseguire la connessione e non deve (MUST NOT) visualizzare un messaggio che avverta l'utente dell'errore. Il UA non deve (MUST NOT) consentire all'utente di continuare nonostante l'errore.

Questi errori includono (ma non sono limitati a):

• Certificato scaduto
• Certificato autofirmato
• Catena di certificati non affidabile
• Nome host non corrispondente
• Errori del protocollo TLS/SSL