1. Introduzione (Introduction)

1.1. Motivazione (Motivation)

Gran parte del volto visibile di Internet consiste in servizi che utilizzano un'architettura client-server in cui un client interattivo o automatizzato si connette a un servizio applicativo per recuperare o caricare informazioni, comunicare con altre entità o connettersi a una rete più ampia di servizi. Quando il client comunica con un servizio applicativo utilizzando il protocollo Transport Layer Security (TLS) [TLS] o il protocollo Datagram Transport Layer Security (DTLS) [DTLS], fa riferimento a qualche nozione dell'identità del server (ad esempio, "il sito web example.com") mentre tenta di stabilire una comunicazione sicura. Allo stesso modo, durante la negoziazione TLS il server presenta una nozione della sua identità di servizio sotto forma di un certificato a chiave pubblica emesso da una autorità di certificazione (CA) nel contesto di una infrastruttura a chiave pubblica Internet utilizzando X.509 [PKIX]. Informalmente, possiamo pensare a queste identità come all'"identità di riferimento" (reference identity) del client e all'"identità presentata" (presented identity) del server (queste idee approssimative sono definite più precisamente più avanti in questo documento attraverso il concetto di identificatori specifici). In generale, un client deve verificare che l'identità presentata dal server corrisponda alla sua identità di riferimento affinché possa autenticare la comunicazione.

Molte tecnologie applicative seguono il modello descritto. Tali protocolli hanno tradizionalmente specificato le proprie regole per rappresentare e verificare l'identità del servizio applicativo. Sfortunatamente, questa divergenza di approcci ha causato una certa confusione tra autorità di certificazione, sviluppatori di applicazioni e progettisti di protocolli.

Ad esempio, diversi protocolli applicativi rappresentano l'identità del servizio in modi diversi (ad esempio, alcuni usano i nomi di dominio DNS come identificatori generici dell'infrastruttura a chiave pubblica (PKI), mentre altri definiscono identificatori specifici dell'applicazione), e molti protocolli non forniscono regole chiare per la gestione dei nomi di dominio internazionalizzati, dei nomi di dominio wildcard o delle identità multiple per certificato. Ciò rende difficile per le autorità di certificazione emettere certificati che funzionano in modo coerente in un'ampia gamma di applicazioni, per gli sviluppatori di software creare codice di verifica degli indirizzi coerente e per i progettisti di protocolli decidere come gestire la verifica dell'identità nelle loro definizioni di protocollo.

Se esistesse un unico insieme coerente di regole per rappresentare e verificare l'identità del servizio applicativo, ciò potrebbe ridurre la confusione tra i vari partecipanti e anche migliorare la qualità del software consentendo alle implementazioni di utilizzare codice comune per l'autenticazione, invece di richiedere a ciascuna applicazione di reimplementare la logica di verifica ad hoc.

1.2. Pubblico (Audience)

Il pubblico di questo documento include:

Progettisti di protocolli che specificano protocolli che girano su TLS.
Sviluppatori di software applicativo che implementano tali protocolli.
Fornitori di servizi che distribuiscono tali servizi.
Autorità di certificazione che emettono certificati per l'uso in tali servizi.

1.3. Come leggere questo documento (How to Read This Document)

Questo documento è scritto principalmente per il riutilizzo da parte dei progettisti di protocolli applicativi; quindi, la maggior parte del linguaggio dei "requisiti" può essere interpretata come "una specifica del protocollo applicativo che riutilizza questo documento deve includere o fare riferimento ai seguenti requisiti".

Per gli sviluppatori di software applicativo, forniamo sezioni separate che trattano la verifica dell'identità del server (Sezione 6) e le relative considerazioni sulla sicurezza (Sezione 7).

Per i fornitori di servizi e le autorità di certificazione, forniamo sezioni separate che trattano la rappresentazione dell'identità del server (Sezione 4) e la richiesta di certificati server (Sezione 5).

1.4. Applicabilità (Applicability)

Questo documento non intende definire una politica di utilizzo generale per tutti i certificati PKIX. Il suo ambito è invece limitato ai client TLS che utilizzano certificati X.509 (PKIX) per autenticare i server. Non disciplina l'autenticazione rispetto a S/MIME, IPsec o altri protocolli (tranne come esplicitamente indicato nella specifica di tale protocollo che riutilizza questo documento). Sebbene i concetti definiti in questo documento possano essere utili in altri contesti, tali estensioni sono al di fuori dell'ambito di questo documento.

Questo documento è destinato principalmente all'adozione da parte di nuovi protocolli applicativi, sebbene si preveda che i protocolli applicativi esistenti (come quelli elencati nell'Appendice B) possano migrare gradualmente all'utilizzo di questo documento.

1.5. Panoramica delle raccomandazioni (Overview of Recommendations)

Riassumiamo le raccomandazioni di questo documento nella seguente tabella; i dettagli sono forniti nelle sezioni successive.

Entità	Ruolo	Raccomandazione
Progettista di protocollo	Specificare	Fare riferimento a questo documento se possibile; definire tipi di identificatori specifici.
Sviluppatore SW app	Implementare verifica	Seguire algos nella Sezione 6; gestire wildcard con cautela; supportare "pinning" (override dell'utente).
Fornitore di servizi	Distribuire servizio	Ottenere cert con DNS-ID; includere SRV-ID o URI-ID se necessario.
Autorità di certificazione	Emettere certificato	Includere DNS-ID in subjectAltName; includere Common Name nel soggetto solo per compatibilità.

1.6. Generalizzazione dalle tecnologie attuali (Generalization from Current Technologies)

Le raccomandazioni specificate in questo documento sono state generalizzate dalle regole di verifica dell'identità contenute in varie specifiche di protocolli applicativi (incluse quelle elencate nell'Appendice B). Il nostro approccio generale è stato che dovremmo seguire le pratiche esistenti a meno che non ci siano motivi impellenti per non farlo (ad esempio, per colmare lacune di sicurezza identificate nelle specifiche precedenti). Dopo un'analisi dettagliata delle pratiche attuali e un'ampia consultazione con la comunità di sviluppo dei protocolli, gli autori ritengono che le regole specificate in questo documento siano sostanzialmente in accordo con la maggioranza dell'utilizzo attualmente distribuito. Laddove ci siamo sforzati di massimizzare la compatibilità con l'uso corrente, come l'uso del "Common Name" X.509 per rappresentare le identità dei server, a volte abbiamo raccomandato di rafforzare le limitazioni esistenti per motivi di sicurezza (ad esempio, per proteggere dagli attacchi associati ai certificati wildcard).

1.7. Ambito (Scope)

1.7.1. Nell'ambito (In Scope)

Questa specifica si applica alle implementazioni software e alle distribuzioni in cui sono vere tutte le seguenti condizioni:

Un client desidera comunicare con un servizio identificato da un nome di dominio DNS.
Il client utilizza il DNS per risolvere il nome di dominio in un indirizzo di rete (ad esempio, un indirizzo IPv4 o IPv6).
Il client comunica con il server utilizzando il protocollo Transport Layer Security (TLS) [TLS] o il protocollo Datagram Transport Layer Security (DTLS) [DTLS] e le loro estensioni (ad esempio, l'estensione Server Name Indication da [TLS-EXT]).
Il server presenta la sua identità al client sotto forma di un certificato a chiave pubblica basato su X.509 [PKIX].
Il client utilizza il certificato presentato dal server nel corso della verifica dell'identità del server.

1.7.2. Fuori ambito (Out of Scope)

I seguenti argomenti sono fuori dall'ambito di questo documento:

Autenticazione client o server diversa dall'autenticazione del servizio applicativo (ad esempio, autenticazione client o autenticazione in protocolli basati su XML in cui i peer possono agire sia come client che come server).
Certificati nel contesto di profili PKI diversi da PKIX (ad esempio, OpenPGP [OPENPGP]).
Autenticazione di servizi che non sono identificati da nomi di dominio DNS (ad esempio, servizi identificati da indirizzi IP come indirizzi [IP] o [IPv6], o da altri tipi di identificatori come quelli utilizzati in [NAPTR]).
Risoluzione dei nomi di dominio DNS in indirizzi IP (sebbene questa sia una condizione preliminare necessaria per il funzionamento di questo documento).
Meccanismi per verificare la validità di un certificato (ad esempio, contro una lista di revoca dei certificati [PKIX] o tramite il protocollo OCSP [OCSP]).
Decisioni di autorizzazione (ad esempio, se un client dovrebbe fidarsi di una determinata autorità di certificazione o connettersi a un determinato server).
Come viene verificata un'identità se il certificato non contiene tipi di identificatori noti (ad esempio, solo tipi di identificatori proprietari che il client non comprende).
Dettagli dell'interfaccia utente (ad esempio, [WSC-UI]).

1.8. Terminologia (Terminology)

Poiché molti concetti relativi all'"identità" sono spesso troppo vaghi per essere attuabili nei protocolli applicativi, definiamo un insieme di termini più concreti da utilizzare in questa specifica.

Servizio applicativo (application service): Un servizio su Internet a cui un client interattivo o automatizzato si connette per recuperare o caricare informazioni, comunicare con altre entità o connettersi a una rete più ampia di servizi.

Fornitore di servizi applicativi (application service provider): Un'entità che ospita e gestisce un determinato servizio applicativo.

Tipo di servizio applicativo (application service type): Un identificatore che distingue lo specifico protocollo applicativo o la configurazione del protocollo che differenzia un servizio applicativo da un altro. I possibili valori includono un nome di servizio DNS SRV (ad esempio, "ldap", "imap", "xmpp-client") o un nome di schema URI (ad esempio, "http", "sip", "acap").

Tipo di attributo (attribute type): L'identificatore di oggetto per il tipo di informazioni contenute in un attributo X.500 [X.500]. Nel contesto di questo documento, si riferisce a specifici identificatori di oggetto (ad esempio, CN) utilizzati nelle asserzioni di valore dell'attributo (Attribute Value Assertions) [X.501].

Asserzione di valore dell'attributo (Attribute Value Assertion - AVA): Un'asserzione di un tipo di attributo e un valore corrispondente [X.501].

Autorità di certificazione (certification authority - CA): Un'entità che emette certificati (ad esempio, "Example CA").

CN-ID: Un attributo Common Name (cioè, un attributo di tipo 2.5.4.3 [X.520]) nel campo Subject di un certificato [PKIX] che contiene una stringa conforme alla sintassi di un nome di dominio DNS.

Common Name: Un attributo (cioè, un attributo di tipo 2.5.4.3 [X.520]) nel campo Subject di un certificato [PKIX]. Per motivi storici, è spesso necessario verificare il Common Name come identificatore, ma è comune che le autorità di certificazione inseriscano lì non solo nomi di dominio DNS ma anche altre stringhe (ad esempio, "John Doe" o "Simple Authority"). Dobbiamo quindi distinguere il Common Name come identificatore (vedi CN-ID) da altre forme del Common Name.

DNS-ID: Un identificatore di tipo dNSName nell'estensione subjectAltName (come definito in [PKIX]).

Identificatore (identifier): Una stringa utilizzata da un client o server per identificare una specifica entità applicativa.

Tipo di identificatore (identifier type): Una classe specifica di identificatori (ad esempio, DNS-ID, CN-ID, SRV-ID o URI-ID).

PKIX: Infrastruttura a Chiave Pubblica utilizzando X.509 (Public Key Infrastructure using X.509), come definito in [PKIX].

Identità presentata (presented identity): Un identificatore che viene presentato da un server a un client in un certificato PKIX.

Identità di riferimento (reference identity): Un identificatore che un client si aspetta che un server presenti in un certificato.

Dominio sorgente (source domain): Il nome di dominio DNS completamente qualificato [DNS-CONCEPTS] che un client estrae dal suo input ricevuto (input dell'utente, configurazione, ecc.). Il dominio sorgente è l'identificatore primario con cui viene stabilita una connessione sicura.

SRV-ID: Un identificatore di tipo otherName nell'estensione subjectAltName, nella forma di SRVName (come definito in [SRVNAME]).

URI-ID: Un identificatore di tipo uniformResourceIdentifier nell'estensione subjectAltName (come definito in [PKIX]).

Certificato wildcard (wildcard certificate): Un certificato contenente almeno un identificatore con un carattere wildcard ('*').

Associazione (pinning): L'atto di un utente di associare o "fissare" (pin) uno specifico certificato a un determinato servizio, tipicamente alla prima connessione o dopo una verifica manuale da parte dell'utente a seguito di un fallimento di validazione del certificato.

Le parole chiave "DEVE" (MUST), "NON DEVE" (MUST NOT), "RICHIESTO" (REQUIRED), "DOVRÀ" (SHALL), "NON DOVRÀ" (SHALL NOT), "DOVREBBE" (SHOULD), "NON DOVREBBE" (SHOULD NOT), "RACCOMANDATO" (RECOMMENDED), "PUÒ" (MAY) e "OPZIONALE" (OPTIONAL) in questo documento devono essere interpretate come descritto in [KEYWORDS].