2. Comportamento del server e del client

2.1. Sintassi del campo di intestazione di risposta

Il campo di intestazione di risposta Expect-CT è un nuovo campo definito in questa specifica. Viene utilizzato da un server per indicare che gli UA dovrebbero valutare le connessioni all'host che emette il campo di intestazione per la conformità CT (Sezione 2.4).

Expect-CT           = 1#expect-ct-directive
expect-ct-directive = directive-name [ "=" directive-value ]
directive-name      = token
directive-value     = token / quoted-string

Le direttive definite in questa specifica sono descritte di seguito. I requisiti generali per le direttive sono:

1. L'ordine di apparizione delle direttive non è significativo.
2. Una data direttiva NON DEVE apparire più di una volta in un dato campo di intestazione.
3. I nomi delle direttive non sono sensibili alle maiuscole/minuscole.
4. Gli UA DEVONO ignorare qualsiasi campo di intestazione contenente direttive o altri dati di valore del campo di intestazione che non sono conformi alla sintassi definita in questa specifica.
5. Se un campo di intestazione contiene direttive che l'UA non riconosce, l'UA DEVE ignorare quelle direttive.

2.1.1. La direttiva report-uri

La direttiva OPZIONALE report-uri indica l'URI a cui l'UA DOVREBBE segnalare gli errori Expect-CT (Sezione 2.4).

2.1.2. La direttiva enforce

La direttiva OPZIONALE enforce è una direttiva senza valore che, se presente (cioè, è "affermata"), segnala all'UA che la conformità alla policy CT dovrebbe essere applicata (piuttosto che solo segnalare) e che l'UA dovrebbe rifiutare le connessioni future che violano la sua policy CT.

2.1.3. La direttiva max-age

La direttiva max-age specifica il numero di secondi dopo la ricezione del campo di intestazione Expect-CT durante i quali l'UA DOVREBBE considerare l'host da cui è stato ricevuto il messaggio come un host Expect-CT known.

max-age-value = delta-seconds
delta-seconds = 1*DIGIT

2.2. Modello di elaborazione dell'host

Questa sezione descrive il modello di elaborazione che gli host Expect-CT implementano.

2.2.1. Tipo di richiest HTTP-over-Secure-Transport

Un host Expect-CT include un campo di intestazione Expect-CT nella sua risposta. Il campo di intestazione DEVE soddisfare la grammatica specificata nella Sezione 2.1.

2.2.2. Tipo di richiesta HTTP

Gli host Expect-CT NON DOVREBBERO includere il campo di intestazione Expect-CT nelle risposte HTTP trasmesse su un trasporto non sicuro.

2.3. Modello di elaborazione dell'agente utente

Il modello di elaborazione dell'UA si basa sull'analisi dei nomi di dominio. Si noti che i nomi di dominio internazionalizzati DEVONO essere canonicalizzati dall'UA secondo lo schema nella Sezione 10 di [RFC6797].

L'UA memorizza gli host Expect-CT noti e le loro direttive Expect-CT associate. Questi dati sono collettivamente noti come "metadati Expect-CT" di un host.

2.3.1. Campi di intestazione Expect-CT mancanti o malformati

Se una risposta HTTP non include un campo di intestazione Expect-CT conforme alla grammatica specificata nella Sezione 2.1, allora l'UA NON DEVE aggiornare alcun metadato Expect-CT.

2.3.2. Elaborazione del campo di intestazione Expect-CT

Se l'UA riceve una risposta HTTP su un trasporto sicuro che include un campo di intestazione Expect-CT conforme alla grammatica specificata nella Sezione 2.1, l'UA DEVE valutare la connessione su cui è stato ricevuto il campo di intestazione per la conformità con la policy CT dell'UA, quindi elaborare il campo di intestazione Expect-CT come segue.

Se la connessione non è conforme alla policy CT dell'UA (cioè, la connessione non è CT qualificata), allora l'UA NON DEVE aggiornare alcun metadato Expect-CT. Se il campo di intestazione include una direttiva report-uri, l'UA DOVREBBE inviare un rapporto al report-uri specificato (Sezione 2.3.3).

Se la connessione è conforme alla policy CT dell'UA (cioè, la connessione è CT qualificata), allora l'UA DEVE:

• Annotare l'host come un host Expect-CT noto se non è già così annotato (vedere Sezione 2.3.2.1) o
• Aggiornare le informazioni memorizzate nella cache dell'UA per l'host Expect-CT noto se le direttive di valore del campo di intestazione enforce, max-age o report-uri trasmettono informazioni diverse da quelle già mantenute dall'UA.

2.3.2.1. Annotazione di Expect-CT

Alla ricezione del campo di intestazione di risposta Expect-CT su una connessione TLS senza errori (con validazione della catena di certificati X.509 come descritto in [RFC5280], nonché la validazione descritta nella Sezione 2.4 di questo documento), l'UA DEVE annotare l'host come un host Expect-CT noto, memorizzando il nome di dominio dell'host e le sue direttive Expect-CT associate in una memoria non volatile.

2.3.2.2. Modello di archiviazione

Se la sottostringa corrispondente alla produzione dell'host dall'Request-URI (del messaggio a cui l'host ha risposto) non corrisponde esattamente al nome di dominio di un host Expect-CT noto esistente, secondo la procedura di corrispondenza per una corrispondenza congruente specificata nella Sezione 8.2 di [RFC6797], allora l'UA DEVE aggiungere questo host alla cache degli host Expect-CT noti. L'UA memorizza nella cache:

• il nome di dominio dell'host Expect-CT.
• se la direttiva enforce è presente.
• la data di scadenza effettiva, che è la data Expect-CT effettiva più il valore della direttiva max-age.
• il valore della direttiva report-uri, se presente.

2.3.3. Segnalazione

Se l'UA riceve, su un trasporto sicuro, una risposta HTTP che include un campo di intestazione Expect-CT con una direttiva report-uri, e la connessione non è conforme alla policy CT dell'UA (cioè, la connessione non è CT qualificata), e l'UA non ha già inviato un rapporto Expect-CT per questa connessione, allora l'UA DOVREBBE inviare un rapporto al report-uri specificato come specificato nella Sezione 3.

2.4. Valutazione delle connessioni Expect-CT per la conformità CT

Quando un UA stabilisce una connessione TLS, l'UA determina se l'host è un host Expect-CT noto secondo la sua cache di host Expect-CT noti. Un host Expect-CT è "scaduto" se la data di scadenza effettiva fa riferimento a una data nel passato. L'UA DEVE ignorare qualsiasi host Expect-CT scaduto nella sua cache e non trattare tali host come host Expect-CT noti.

Quando un UA si connette a un host Expect-CT noto utilizzando una connessione TLS, se la connessione TLS non ha errori, allora l'UA applicherà un controllo di correttezza aggiuntivo: conformità con una policy CT. Un UA dovrebbe valutare la conformità con la sua policy CT ogni volta che si connette a un host Expect-CT noto.

Se una connessione a un host Expect-CT noto viola la policy CT dell'UA (cioè, la connessione non è CT qualificata), e se i metadati Expect-CT dell'host Expect-CT noto indicano una configurazione enforce, l'UA DEVE trattare il fallimento di conformità CT come un errore.

Se una connessione a un host Expect-CT noto viola la policy CT dell'UA, e se i metadati Expect-CT dell'host Expect-CT noto includono un report-uri, l'UA DOVREBBE inviare un rapporto Expect-CT a quel report-uri (Sezione 3).

2.4.1. Salto dei controlli di conformità CT

È accettabile per un UA saltare i controlli di conformità CT per alcuni host secondo la policy locale. Ad esempio, un UA PUÒ disabilitare i controlli di conformità CT per gli host la cui catena di certificati validata termina a un'ancora di fiducia definita dall'utente piuttosto che a un'ancora di fiducia integrata nell'UA (o nella piattaforma sottostante).

Se l'UA non valuta la conformità CT, ad esempio, perché l'utente ha scelto di disabilitarla, o perché una catena di certificati presentata si collega a un'ancora di fiducia definita dall'utente, gli UA NON DOVREBBERO inviare rapporti Expect-CT.