3. Segnalazione di errori Expect-CT

Quando l'UA tenta di connettersi a un host Expect-CT noto e la connessione non è CT qualificata, l'UA DOVREBBE segnalare gli errori Expect-CT al report-uri, se presente, nei metadati Expect-CT dell'host Expect-CT noto.

Quando l'UA riceve un campo di intestazione di risposta Expect-CT su una connessione che non è CT qualificata, se l'UA non ha già inviato un rapporto Expect-CT per questa connessione, allora l'UA DOVREBBE segnalare gli errori Expect-CT al report-uri configurato, se presente.

3.1. Generazione di un rapporto di violazione

Per generare un oggetto rapporto di violazione, l'UA costruisce un oggetto JSON [RFC8259] con le seguenti chiavi e valori:

"date-time" - Il valore per questa chiave indica l'ora UTC in cui l'UA ha osservato l'errore di conformità CT. Il valore è una stringa formattata secondo la Sezione 5.6 di [RFC3339], "Internet Date/Time Format".

"hostname" - Il valore è il nome host a cui l'UA ha effettuato la richiesta originale che non ha superato il controllo di conformità CT. Il valore è fornito come stringa.

"port" - Il valore è la porta a cui l'UA ha effettuato la richiesta originale che non ha superato il controllo di conformità CT. Il valore è fornito come intero.

"scheme" - (opzionale) Il valore è lo schema con cui l'UA ha effettuato la richiesta originale che non ha superato il controllo di conformità CT. Il valore è fornito come stringa. Questa chiave è opzionale e si presume sia "https" se non presente.

"effective-expiration-date" - Il valore indica la data di scadenza effettiva (vedere Sezione 2.3.2.2) per l'host Expect-CT che non ha superato il controllo di conformità CT, in UTC. Il valore è fornito come stringa formattata secondo la Sezione 5.6 di [RFC3339], "Internet Date/Time Format".

"served-certificate-chain" - Il valore è la catena di certificati servita dall'host Expect-CT durante la configurazione della sessione TLS. Il valore è fornito come array di stringhe, che DEVE apparire nell'ordine in cui i certificati sono stati serviti; ogni stringa nell'array è la rappresentazione Privacy-Enhanced Mail (PEM) di ogni certificato X.509 come descritto in [RFC7468].

"validated-certificate-chain" - Il valore è la catena di certificati costruita dall'UA durante la validazione della catena di certificati. (Questo può differire dal valore della chiave "served-certificate-chain".) Il valore è fornito come array di stringhe, che DEVE apparire nell'ordine che corrisponde alla catena che l'UA ha validato.

"scts" - Il valore rappresenta gli SCT (se presenti) che l'UA ha ricevuto per l'host Expect-CT e i loro stati di validazione. Il valore è fornito come array di oggetti JSON. Gli SCT possono apparire in qualsiasi ordine. Ogni oggetto JSON nell'array ha le seguenti chiavi:

• Una chiave "version", con un valore intero. L'UA DEVE impostare questo valore a 1 se l'SCT è nel formato definito nella Sezione 3.2 di [RFC6962] o 2 se è nel formato definito nella Sezione 4.5 di [RFC9162].

• La chiave "status", con un valore stringa che l'UA DEVE impostare a uno dei seguenti valori: "unknown" (indicando che l'UA non ha o non si fida della chiave pubblica del log da cui è stato emesso l'SCT); "valid" (indicando che l'UA ha validato con successo l'SCT come descritto nella Sezione 5.2 di [RFC6962] o Sezione 8.1.3 di [RFC9162]); o "invalid" (indicando che la validazione dell'SCT è fallita a causa di una firma errata o un timestamp non valido).

• La chiave "source", con un valore stringa che indica da dove l'UA ha ottenuto l'SCT, come definito nella Sezione 3 di [RFC6962] e Sezione 6 di [RFC9162]. L'UA DEVE impostare il valore a uno dei seguenti: "tls-extension", "ocsp" o "embedded". Questi corrispondono ai tre metodi di consegna degli SCT nell'handshake TLS descritti nella Sezione 3.3 di [RFC6962].

• La chiave "serialized_sct", con un valore stringa. Se il valore della chiave "version" è 1, l'UA DEVE impostare questo valore alla struttura SignedCertificateTimestamp serializzata con codifica base64 [RFC4648] dalla Sezione 3.2 di [RFC6962]. La codifica base64 è definita nella Sezione 4 di [RFC4648]. Se il valore della chiave "version" è 2, l'UA DEVE impostare questo valore alla struttura TransItem serializzata con codifica base64 [RFC4648] che rappresenta l'SCT, come definito nella Sezione 4.5 di [RFC9162].

"failure-mode" - Il valore indica se il rapporto Expect-CT è stato attivato da una policy Expect-CT in modalità enforce o report-only. Il valore è fornito come stringa. L'UA DEVE impostare questo valore a "enforce" se i metadati Expect-CT indicano una configurazione enforce, e "report-only" altrimenti.

"test-report" - (opzionale) Il valore è impostato a true se il rapporto viene inviato da un client di test per verificare che il server di rapporto si comporti correttamente. Il valore è fornito come booleano e DEVE essere impostato a true se il rapporto serve a testare il comportamento del server e può essere scartato.

3.2. Invio di un rapporto di violazione

L'UA DOVREBBE segnalare gli errori Expect-CT per gli host Expect-CT noti: cioè, quando una connessione a un host Expect-CT noto non è conforme alla policy CT dell'UA e i metadati Expect-CT dell'host contengono un report-uri.

Inoltre, l'UA DOVREBBE segnalare gli errori Expect-CT per gli host per i quali non ha alcun metadato Expect-CT memorizzato: cioè, quando l'UA si connette a un host e riceve un campo di intestazione Expect-CT che contiene la direttiva report-uri, l'UA DOVREBBE segnalare un errore Expect-CT se la connessione non è conforme alla policy CT dell'UA.

I passaggi per segnalare un errore Expect-CT sono i seguenti.

1. Preparare un oggetto rapporto JSON con la singola chiave "expect-ct-report", il cui valore è il risultato della generazione di un oggetto rapporto di violazione come descritto nella Sezione 3.1.

2. Sia corpo del rapporto la stringificazione JSON dell'oggetto rapporto.

3. Sia report-uri il valore della direttiva report-uri nel campo di intestazione Expect-CT.

4. Inviare una richiesta HTTP POST a report-uri con un campo di intestazione Content-Type di application/expect-ct-report+json e un corpo dell'entità costituito dal corpo del rapporto.

L'UA PUÒ eseguire altre operazioni come parte dell'invio della richiesta HTTP POST, come l'invio di un preflight Cross-Origin Resource Sharing (CORS) come parte di [FETCH].

Le versioni future di questa specifica potrebbero dover modificare o estendere il formato del rapporto Expect-CT. Potrebbero farlo definendo una nuova chiave di livello superiore per contenere il rapporto, sostituendo la chiave "expect-ct-report". La Sezione 3.3 definisce come i server di rapporto dovrebbero gestire i formati di rapporto che non supportano.

3.3. Ricezione di un rapporto di violazione

Alla ricezione di un rapporto di violazione Expect-CT, il server di rapporto DEVE rispondere con un codice di stato 2xx (Riuscito) se può analizzare il corpo della richiesta come JSON valido, il rapporto è conforme al formato descritto nella Sezione 3.1, e riconosce lo schema, il nome host e la porta nei campi "scheme", "hostname" e "port" del rapporto. Se il corpo del rapporto non può essere analizzato o non è conforme al formato descritto nella Sezione 3.1, o il server di rapporto non si aspetta di ricevere rapporti per lo schema, il nome host o la porta nel rapporto, allora il server di rapporto DEVE rispondere con un codice di stato 400 Bad Request.

Come descritto nella Sezione 3.2, le versioni future di questa specifica potrebbero definire nuovi formati di rapporto che vengono inviati con una chiave di livello superiore diversa. Se il server di rapporto non riconosce il formato del rapporto, il server di rapporto DEVE rispondere con un codice di stato 501 Not Implemented.

Se la chiave "test-report" del rapporto è impostata a true, il server PUÒ scartare il rapporto senza ulteriore elaborazione ma DEVE comunque restituire un codice di stato 2xx (Riuscito). Se la chiave "test-report" è assente o impostata a false, il server DOVREBBE memorizzare il rapporto per l'elaborazione e l'analisi da parte del proprietario dell'host Expect-CT.