1.2. Terminology and Applicability (Terminologia e applicabilità)

1.2. Terminology and Applicability (Terminologia e applicabilità)

Questo documento utilizza la seguente terminologia dalla Sezione 3 di [STRUCTURED-FIELDS] per specificare sintassi e parsing: List (lista) e Byte Sequence (sequenza di byte).

Frasi come "autenticazione tramite certificato client TLS" o "TLS mutuamente autenticato" sono utilizzate in tutto questo documento per riferirsi al processo mediante il quale, oltre alla normale autenticazione del server TLS con un certificato, un client presenta il proprio certificato X.509 [RFC5280] e dimostra il possesso della corrispondente chiave privata a un server durante la negoziazione di una connessione TLS o la ripresa di tale connessione. Nelle versioni contemporanee di TLS [TLS] [TLS1.2], l'autenticazione reciproca richiede che il client invii i messaggi Certificate e CertificateVerify durante l'handshake e che il server verifichi i messaggi CertificateVerify e Finished.

HTTP/2 limita la rinegoziazione (renegotiation) TLS 1.2 (Sezione 9.2.1 di [HTTP/2]) e proibisce l'autenticazione post-handshake TLS 1.3 (Sezione 9.2.3 di [HTTP/2]). Tuttavia, vengono talvolta utilizzati per implementare l'autenticazione reattiva tramite certificato client in HTTP/1.1 [HTTP/1.1] dove il server decide se richiedere un certificato client in base alla richiesta HTTP. I dati dell'applicazione HTTP inviati su tale connessione dopo la ricezione e la verifica del certificato client sono anch'essi mutuamente autenticati e quindi adatti per i meccanismi descritti in questo documento. Con l'autenticazione post-handshake, esiste anche la possibilità, sebbene improbabile nella pratica, di più certificati e catene di certificati dal client su una connessione. In questo caso, solo il certificato e la catena dell'ultima autenticazione post-handshake devono essere utilizzati per i campi di intestazione descritti qui.