1. Introduzione

Questo documento definisce un nuovo campo di intestazione HTTP ([RFC9110], sezione 6.3) che consente agli UA di identificare gli host Web che si aspettano la presenza di timestamp di certificati firmati (SCT) [RFC9162] nelle successive connessioni Transport Layer Security (TLS) [RFC8446].

Gli host Web che forniscono il campo di intestazione Expect-CT vengono annotati dall'UA come "host Expect-CT noti". L'UA valuta ogni connessione a un host Expect-CT noto per la conformità con la politica di Certificate Transparency (CT) dell'UA. Se la connessione viola la politica CT, l'UA invia un report a un URI configurato dall'host Expect-CT e/o fa fallire la connessione, a seconda della configurazione scelta dall'host Expect-CT.

Se configurato in modo errato, Expect-CT può causare errori di connessione indesiderati. Si consiglia agli operatori di host Web di distribuire Expect-CT con precauzioni utilizzando la funzionalità di report e aumentando gradualmente l'intervallo di tempo durante il quale l'UA considera l'host come un host Expect-CT noto.

Expect-CT è un meccanismo di fiducia al primo utilizzo (TOFU). La prima volta che un UA si connette a un host, manca delle informazioni necessarie per richiedere SCT per la connessione. Tuttavia, Expect-CT fornisce valore consentendo: 1) agli UA di rilevare l'uso di certificati non registrati dopo la comunicazione iniziale, e 2) agli host Web di essere sicuri che gli UA si fidino solo di certificati pubblicamente verificabili.

Expect-CT è simile a HTTP Strict Transport Security (HSTS) [RFC6797] e HTTP Public Key Pinning (HPKP) [RFC7469]. HSTS consente ai siti Web di dichiararsi accessibili solo tramite connessioni sicure, e HPKP consente ai siti Web di dichiarare le loro identità crittografiche. Analogamente, Expect-CT consente ai siti Web di dichiararsi accessibili solo tramite connessioni conformi alla politica CT.

Questa specifica Expect-CT è compatibile con [RFC6962] e [RFC9162], ma non necessariamente con versioni future di Certificate Transparency.

1.1. Linguaggio dei requisiti

Le parole chiave "DEVE", "NON DEVE", "RICHIESTO", "DOVRÀ", "NON DOVRÀ", "DOVREBBE", "NON DOVREBBE", "RACCOMANDATO", "NON RACCOMANDATO", "PUÒ" e "OPZIONALE" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

1.2. Terminologia

"Politica di trasparenza dei certificati (Certificate Transparency Policy)"

Una politica definita dall'UA relativa al numero, alle fonti e ai meccanismi di consegna dei timestamp di certificati firmati associati alle connessioni TLS.

"Qualificato per la trasparenza dei certificati (Certificate Transparency Qualified)"

Descrive una connessione TLS per la quale l'UA ha determinato che è stata fornita una quantità e qualità sufficienti di timestamp di certificati firmati.

"Qualificato CT (CT Qualified)"

Un'abbreviazione per "Qualificato per la trasparenza dei certificati".

"Politica CT (CT Policy)"

Un'abbreviazione per "Politica di trasparenza dei certificati".

"Data Expect-CT effettiva (Effective Expect-CT Date)"

Il momento in cui un UA ha osservato un campo di intestazione Expect-CT valido per un determinato host.

"Host Expect-CT (Expect-CT Host)"

Un host conforme che implementa gli aspetti server HTTP di Expect-CT.

"Host Expect-CT noto (Known Expect-CT Host)"

Un host Expect-CT che l'UA ha annotato come tale. Vedere la sezione 2.3.2.1 per i dettagli.

"Agente utente (User Agent, UA)"

Ai fini di questa specifica, un UA è un'applicazione client HTTP tipicamente manipolata attivamente da un utente [RFC9110].

"Host Expect-CT sconosciuto (Unknown Expect-CT Host)"

Un host Expect-CT che l'UA non ha annotato.