6. Verifica dell'identità del servizio (Verifying Service Identity)

Questa sezione fornisce regole e linee guida per gli implementatori di software client applicativo riguardo agli algoritmi per la verifica dell'identità del servizio applicativo.

6.1. Panoramica (Overview)

Ad alto livello, il client verifica l'identità del servizio applicativo eseguendo le seguenti operazioni (queste operazioni sono definite nelle successive sottosezioni di questo documento):

Il client costruisce una lista di identificatori di riferimento accettabili basati sul dominio sorgente (source domain) e, opzionalmente, sul tipo di servizio a cui il client si sta connettendo.
Il server presenta i suoi identificatori sotto forma di un certificato PKIX.
Il client controlla ciascuno dei suoi identificatori di riferimento rispetto agli identificatori presentati allo scopo di trovare una corrispondenza.
Quando si controlla un identificatore di riferimento rispetto a un identificatore presentato, il client confronta il dominio sorgente degli identificatori e, opzionalmente, il loro tipo di servizio applicativo.

Naturalmente, oltre a verificare gli identificatori, il client potrebbe dover eseguire ulteriori controlli per garantire che il server sia autorizzato a fornire il servizio richiesto; tuttavia, tali controlli non riguardano la verifica dell'identità del servizio applicativo presentata in un certificato e i metodi per farlo (ad esempio, consultare informazioni sui criteri locali) sono quindi fuori dall'ambito di questo documento.

6.2. Costruzione di una lista di identificatori di riferimento (Constructing a List of Reference Identifiers)

6.2.1. Regole (Rules)

Il client DEVE (MUST) costruire una lista di identificatori di riferimento accettabili, e DEVE (MUST) farlo indipendentemente dagli identificatori presentati dal servizio.

Gli input che il client utilizza per costruire la sua lista di identificatori di riferimento potrebbero essere un URI digitato da un utente in un'interfaccia (ad esempio, un URL HTTPS per un sito web), informazioni sull'account configurate (ad esempio, il nome di dominio di un host o URI specifico utilizzato per recuperare informazioni o connettersi a una rete, che potrebbe essere diverso dalla porzione del nome di dominio DNS di un nome utente), un collegamento ipertestuale in una pagina web che attiva un browser per recuperare un oggetto multimediale o uno script, o altre combinazioni di informazioni che possono fornire un dominio sorgente e un tipo di servizio applicativo.

Il client potrebbe dover estrarre il dominio sorgente e il tipo di servizio applicativo dall'input che ha ricevuto. I dati estratti tuttavia DEVONO (MUST) includere solo informazioni che possono essere analizzate in modo sicuro dall'input (ad esempio, un nome di dominio DNS completamente qualificato analizzato dal componente "host" (o equivalente) di un URI, o un tipo di servizio applicativo derivato dallo schema di un URI) o informazioni derivate in un modo che non sia soggetto a corruzione da parte di attaccanti di rete (ad esempio, dati estratti da un dominio di delega stabilito esplicitamente tramite configurazione client o di sistema, dati risolti tramite [DNSSEC], o dati ottenuti da un servizio di mappatura domini di terze parti in cui un utente umano ha esplicitamente riposto fiducia e con cui il client comunica tramite una connessione o associazione che fornisce autenticazione reciproca e controllo dell'integrità). Queste considerazioni si applicano solo all'estrazione del dominio sorgente dall'input; naturalmente, se l'input stesso è non valido o corrotto (ad esempio se un utente clicca su un collegamento fornito da un'entità malevola in un attacco di phishing), il client potrebbe finire per comunicare con un servizio applicativo non intenzionale.

Esempio: Dato l'URI di input <sips:[email protected]>, un client deriverebbe il tipo di servizio applicativo "sip" dallo "schema" e analizzerebbe il nome di dominio "example.net" dal componente "host" (o il suo equivalente).

Ogni identificatore di riferimento nella lista DOVREBBE (SHOULD) essere basato sul dominio sorgente e NON DOVREBBE (SHOULD NOT) essere basato su un dominio derivato (ad esempio, un nome host o un nome di dominio scoperto come risultato di una risoluzione DNS del dominio sorgente). Questa regola è importante perché solo una corrispondenza tra l'input dell'utente e l'identificatore presentato può dare al client una certa garanzia che il certificato possa essere legittimamente utilizzato per proteggere la comunicazione tra il client e il server. C'è solo un caso in cui un client interattivo può ignorare la raccomandazione di questa regola e comunicare con un nome di dominio diverso dal dominio sorgente: se un utente umano ha "associato" (pinned) il certificato del servizio applicativo a un nome di dominio alternativo, come discusso più avanti nelle Sezioni 6.6.4 e 7.1. In questo caso, l'input che il client utilizza per costruire la sua lista di identificatori di riferimento potrebbe contenere più di un nome di dominio DNS completamente qualificato: (a) il dominio sorgente e (b) il dominio alternativo contenuto nel certificato associato.

Utilizzando la combinazione di uno o più nomi di dominio DNS completamente qualificati e un tipo di servizio applicativo, il client costruisce una lista di identificatori di riferimento in conformità alle seguenti regole:

La lista DOVREBBE (SHOULD) includere un DNS-ID costruito direttamente da (a) il nome di dominio DNS completamente qualificato contenuto o derivato in modo sicuro dall'input (cioè, il dominio sorgente) o (b) il nome di dominio DNS completamente qualificato esplicitamente associato al dominio sorgente tramite configurazione dell'utente (cioè, un dominio derivato).
Se un server per il tipo di servizio applicativo viene tipicamente localizzato tramite record DNS SRV, la lista DOVREBBE (SHOULD) includere un SRV-ID.
Se un server per il tipo di servizio applicativo è tipicamente associato a un URI per scopi di sicurezza (cioè, se un documento di protocollo formale specifica l'uso di URI nei certificati server), la lista DOVREBBE (SHOULD) includere un URI-ID.
La lista PUÒ (MAY) includere un CN-ID, principalmente per retrocompatibilità con l'infrastruttura installata.

Quali tipi di identificatori un client include nella sua lista di identificatori di riferimento è una questione di politica locale. Ad esempio, potrebbe esserci un ambiente di distribuzione in cui i client costruiti per connettersi a un certo tipo di servizio (diciamo, solo un servizio IM) sono configurati per accettare come validi solo i certificati contenenti un SRV-ID per quel tipo di servizio applicativo; in tal caso, il client includerebbe solo un SRV-ID per il tipo di servizio applicativo corrispondente nella sua lista di identificatori di riferimento (e non, ad esempio, un DNS-ID). Al contrario, un client più indulgente (anche uno costruito per connettersi solo a un certo tipo di servizio) potrebbe includere sia un SRV-ID che un DNS-ID nella sua lista di identificatori di riferimento.

Nota di implementazione: A causa della prevalenza di certificati contenenti CN-ID, è molto probabile che gli implementatori di software client dovranno supportare i CN-ID per il prossimo futuro. Gli implementatori sono incoraggiati a monitorare lo stato dell'arte delle politiche di emissione dei certificati e a eliminare gradualmente il supporto per i CN-ID in futuro, se possibile.

Nota di implementazione: Un client non ha bisogno di costruire gli identificatori sopra menzionati nella forma effettiva trovata in un certificato (ad esempio, come tipi ASN.1); è sufficiente costruire equivalenti funzionali di tali identificatori a fini di confronto.

Avviso di sicurezza: Un client NON DEVE (MUST NOT) costruire un identificatore di riferimento corrispondente a un Relative Distinguished Name (RDN) diverso da quelli di tipo Common Name, e un client NON DEVE (MUST NOT) verificare un RDN diverso da quelli di tipo Common Name in un identificatore presentato.

6.2.2. Esempi (Examples)

Un browser web che si connette a un sito web "www.example.com" tramite HTTPS potrebbe avere due identificatori di riferimento: un DNS-ID di "www.example.com" e, come ripiego, un CN-ID di "www.example.com".

Uno user agent di posta elettronica che si connette a un servizio di posta "example.net" (che si risolve in "mail.example.net") tramite IMAPS potrebbe avere cinque identificatori di riferimento: un SRV-ID di "_imaps.example.net" (vedere [EMAIL-SRV]), DNS-ID di "example.net" e "mail.example.net", e, come ripieghi, CN-ID di "example.net" e "mail.example.net". (Uno user agent più vecchio che non supporta [EMAIL-SRV] potrebbe essere esplicitamente configurato per connettersi a "mail.example.net", mentre uno user agent abilitato per SRV deriverebbe "example.net" da un indirizzo email della forma "[email protected]" ma potrebbe anche accettare "mail.example.net" come porzione del nome di dominio DNS di un identificatore di riferimento per il servizio.)

Uno user agent Voice over IP (VoIP) che si connette a un servizio vocale "voice.example.edu" tramite SIP potrebbe avere un solo identificatore di riferimento: un URI-ID di "sip:voice.example.edu" (vedere [SIP-CERTS]).

Un client di Instant Messaging (IM) che si connette a un servizio IM "im.example.org" tramite XMPP potrebbe avere tre identificatori di riferimento: un SRV-ID di "_xmpp-client.im.example.org" (vedere [XMPP]), un DNS-ID di "im.example.org", e una "XmppAddr" specifica per XMPP (vedere [XMPP]) di "im.example.org".

6.3. Preparazione alla ricerca di una corrispondenza (Preparing to Seek a Match)

Una volta che il client ha costruito la sua lista di identificatori di riferimento e ha ricevuto gli identificatori del server sotto forma di un certificato PKIX, il client controlla i suoi identificatori di riferimento rispetto agli identificatori presentati allo scopo di trovare una corrispondenza. La ricerca fallisce se il client esaurisce la sua lista di identificatori di riferimento senza trovare una corrispondenza. La ricerca ha successo se uno qualsiasi degli identificatori presentati corrisponde a uno degli identificatori di riferimento, a quel punto il client DOVREBBE (SHOULD) interrompere la ricerca.

Nota di implementazione: Un client potrebbe essere configurato per eseguire più ricerche, cioè per trovare corrispondenza con più di un identificatore di riferimento. Sebbene questa specifica non proibisca tale comportamento, le regole per la corrispondenza con più identificatori di riferimento sono una questione per future implementazioni o specifiche.

Avviso di sicurezza: Se un identificatore presentato contiene un DNS-ID, SRV-ID, URI-ID, o qualsiasi tipo di identificatore specifico dell'applicazione supportato dal client, il client NON DEVE (MUST NOT) cercare una corrispondenza con un identificatore di riferimento CN-ID.

Prima di applicare le regole di confronto fornite nelle sezioni seguenti, il client potrebbe dover dividere un identificatore di riferimento in una porzione di nome di dominio DNS e una porzione di tipo di servizio applicativo, come segue:

Un identificatore di riferimento di tipo DNS-ID non contiene una porzione di tipo di servizio applicativo e può essere utilizzato direttamente come nome di dominio DNS per il confronto. Ad esempio, un DNS-ID di "www.example.com" risulta in una porzione di nome di dominio DNS di "www.example.com".
Un identificatore di riferimento di tipo CN-ID non contiene anch'esso una porzione di tipo di servizio applicativo e può essere utilizzato direttamente come nome di dominio DNS per il confronto. Come notato, questo documento stabilisce che un CN-ID contiene sempre una stringa conforme al formato di un nome di dominio DNS (distinguendo così un CN-ID da un Common Name contenente un nome amichevole).
Per un identificatore di riferimento di tipo SRV-ID, la porzione di nome di dominio DNS è il Nome e la porzione di tipo di servizio applicativo è il Servizio. Ad esempio, un SRV-ID di "_imaps.example.net" si divide in una porzione di nome di dominio DNS di "example.net" e una porzione di tipo di servizio applicativo di "imaps" (che corrisponde al protocollo applicativo IMAP come spiegato in [EMAIL-SRV]).
Per un identificatore di riferimento di tipo URI-ID, la porzione di nome di dominio DNS è la parte "reg-name" del componente "host" (o il suo equivalente) e la porzione di tipo di servizio applicativo è il tipo di servizio applicativo associato al nome dello schema corrispondente alla regola [ABNF] "scheme" di [URI] (meno il carattere separatore ':'). Come notato, questo documento stabilisce che un URI-ID contiene sempre un URI contenente un componente "host" (o equivalente) che contiene un "reg-name". (La corrispondenza solo con la regola "reg-name" di [URI] limita la verifica ai nomi di dominio DNS, consentendo la differenziazione tra un URI-ID e una voce uniformResourceIdentifier contenente un indirizzo IP o un semplice nome host, o nessun componente "host" affatto). Inoltre, si noti che l'estrazione del "reg-name" potrebbe richiedere la normalizzazione dell'URI (come spiegato in [URI]). Ad esempio, un URI-ID di "sip:voice.example.edu" si divide in una porzione di nome di dominio DNS di "voice.example.edu" e un tipo di servizio applicativo di "sip" (che è associato al protocollo applicativo SIP come spiegato in [SIP-CERTS]).

Le sezioni seguenti forniscono regole di confronto dettagliate per la corrispondenza della porzione di nome di dominio DNS e della porzione di tipo di servizio applicativo degli identificatori di riferimento.

6.4. Corrispondenza della porzione del nome di dominio DNS (Matching the DNS Domain Name Portion)

Il client DEVE (MUST) far corrispondere la porzione del nome di dominio DNS di un identificatore di riferimento secondo le seguenti regole, e DOVREBBE (SHOULD) verificare simultaneamente il tipo di servizio applicativo, come descritto nella Sezione 6.5. Le regole differiscono a seconda se il dominio da verificare è un "nome di dominio tradizionale" o un "nome di dominio internazionalizzato" (come definito nella Sezione 2.2). Inoltre, definiamo regole aggiuntive per i cosiddetti "certificati wildcard" per soddisfare le esigenze dei client che supportano identificatori presentati contenenti il carattere jolly '*', e stabiliamo le circostanze in cui è accettabile verificare il tipo di identificatore "CN-ID" come ultima risorsa.

6.4.1. Verifica dei nomi di dominio tradizionali (Checking of Traditional Domain Names)

Se la porzione del nome di dominio DNS di un identificatore di riferimento è un "nome di dominio tradizionale", allora la corrispondenza dell'identificatore di riferimento rispetto all'identificatore presentato viene eseguita confrontando l'insieme di etichette del nome di dominio utilizzando un confronto ASCII insensibile alle maiuscole/minuscole, come chiarito da [DNS-CASE] (ad esempio, "WWW.Example.Com" sarebbe in minuscolo "www.example.com" per il confronto). Ogni etichetta DEVE (MUST) corrispondere affinché sia considerata una corrispondenza, a meno che non sia integrata dalle regole per la verifica delle etichette wildcard (Sezione 6.4.3).

6.4.2. Verifica dei nomi di dominio internazionalizzati (Checking of Internationalized Domain Names)

Se la porzione del nome di dominio DNS di un identificatore di riferimento è un nome di dominio internazionalizzato, l'implementazione DEVE (MUST) convertire qualsiasi U-label [IDNA-DEFS] nel nome di dominio in un'A-label prima di verificare il nome di dominio. In conformità con [IDNA-PROTO], le A-label DEVONO (MUST) essere confrontate come ASCII insensibile alle maiuscole/minuscole. Ogni etichetta DEVE (MUST) corrispondere affinché sia considerata una corrispondenza, a meno che non sia integrata dalle regole per la verifica delle etichette wildcard (Sezione 6.4.3; tuttavia, vedere anche Sezione 7.2 riguardante i wildcard nei nomi di dominio internazionalizzati).

6.4.3. Verifica dei certificati wildcard (Checking of Wildcard Certificates)

Un client che impiega le regole di questa specifica PUÒ (MAY) far corrispondere un identificatore di riferimento a un identificatore presentato la cui porzione di nome di dominio DNS contiene il carattere jolly '*' come parte o intero di un'etichetta (secondo la descrizione di etichette e nomi di dominio in [DNS-CONCEPTS]).

Per informazioni sulle caratteristiche di sicurezza dei certificati wildcard, vedere la Sezione 7.2.

Se un client fa corrispondere un identificatore di riferimento a un identificatore presentato la cui porzione di nome di dominio DNS contiene il carattere jolly '*', si applicano le seguenti regole:

Il client NON DOVREBBE (SHOULD NOT) tentare di far corrispondere un identificatore presentato in cui il carattere jolly comprende un'etichetta diversa dall'etichetta più a sinistra (ad esempio, non corrispondere bar.*.example.net).
Se il carattere jolly è l'unico carattere dell'etichetta più a sinistra dell'identificatore presentato, il client NON DOVREBBE (SHOULD NOT) corrispondere a nient'altro che l'etichetta più a sinistra dell'identificatore di riferimento (ad esempio, *.example.com corrisponderebbe a foo.example.com ma non a bar.foo.example.com o example.com).
Il client PUÒ (MAY) corrispondere a un identificatore presentato in cui il carattere jolly non è l'unico carattere dell'etichetta (ad esempio, baz*.example.net e baz.example.net e bz.example.net sarebbero presi come corrispondenti a baz1.example.net, foobaz.example.net, e buzz.example.net, rispettivamente). Tuttavia, il client NON DOVREBBE (SHOULD NOT) tentare di corrispondere a un identificatore presentato in cui il carattere jolly è incorporato in un'A-label o U-label [IDNA-DEFS] di un nome di dominio internazionalizzato [IDNA-PROTO].

6.4.4. Verifica dei Common Names (Checking of Common Names)

Come notato, un client NON DEVE (MUST NOT) cercare una corrispondenza con un identificatore di riferimento CN-ID se un identificatore presentato contiene un DNS-ID, SRV-ID, URI-ID, o un tipo di identificatore specifico dell'applicazione supportato dal client.

Pertanto, se e solo se l'identificatore presentato non contiene un DNS-ID, SRV-ID, URI-ID, o un tipo di identificatore specifico dell'applicazione supportato dal client, il client PUÒ (MAY) come ultima risorsa verificare la stringa trovata nel campo Common Name del campo Subject (cioè, il CN-ID) se corrisponde al formato di un nome di dominio DNS completamente qualificato. Se il client sceglie di confrontare un identificatore di riferimento di tipo CN-ID con questa stringa, DEVE (MUST) seguire le regole di confronto per la porzione del nome di dominio DNS di un identificatore di tipo DNS-ID, SRV-ID, o URI-ID, come descritto nelle Sezioni 6.4.1, 6.4.2, e 6.4.3.

6.5. Corrispondenza della porzione del tipo di servizio applicativo (Matching the Application Service Type Portion)

Se il client verifica un identificatore di tipo SRV-ID e URI-ID, DEVE (MUST) verificare la porzione del tipo di servizio applicativo dell'identificatore insieme alla porzione del nome di dominio DNS. Il client lo fa dividendo l'identificatore in una porzione di nome di dominio DNS e una porzione di tipo di servizio applicativo (come raccomandato nella Sezione 6.3) e quindi verificando la porzione del nome di dominio DNS (come descritto nella Sezione 6.4) e la porzione del tipo di servizio applicativo (come descritto nelle sottosezioni seguenti).

Nota di implementazione: Un identificatore di tipo SRV-ID o URI-ID fornisce una porzione di tipo di servizio applicativo da verificare, ma questa porzione è combinata solo con la porzione di nome di dominio DNS dell'SRV-ID o URI-ID stesso. Ad esempio, se la lista di identificatori di riferimento di un client contiene un SRV-ID di "_xmpp-client.im.example.org" e un DNS-ID di "apps.example.net", il client verificherebbe (a) la combinazione di un tipo di servizio applicativo di "xmpp-client" e un nome di dominio DNS di "im.example.org" e (b) la combinazione di un nome di dominio DNS di "apps.example.net"; tuttavia, il client non verificherebbe (c) la combinazione di un tipo di servizio applicativo di "xmpp-client" e un nome di dominio DNS di "apps.example.net" perché non ha un SRV-ID di "_xmpp-client.apps.example.net" nella sua lista di identificatori di riferimento.

6.5.1. SRV-ID

La porzione del nome del servizio di un SRV-ID (ad esempio, "imaps") DEVE (MUST) essere confrontata in modo insensibile alle maiuscole/minuscole, secondo [DNS-SRV]. Si noti che il carattere "_" è anteposto agli identificatori di servizio nei record DNS SRV e negli SRV-ID (secondo [SRVNAME]) e non ha bisogno di essere incluso nel confronto.

6.5.2. URI-ID

La porzione del nome dello schema di un URI-ID (ad esempio, "sip") DEVE (MUST) essere confrontata in modo insensibile alle maiuscole/minuscole, secondo [URI]. Si noti che il carattere ":" è un separatore tra il nome dello schema e il resto dell'URI e non ha bisogno di essere incluso nel confronto.

6.6. Esito (Outcome)

L'esito del processo di corrispondenza sarà uno dei seguenti casi.

6.6.1. Caso #1: Corrispondenza trovata (Case #1: Match Found)

Se il client ha trovato un identificatore presentato che corrisponde a un identificatore di riferimento, allora la verifica dell'identità del servizio ha avuto successo. In questo caso, il client DEVE (MUST) utilizzare l'identificatore di riferimento corrispondente come identità autenticata del servizio applicativo.

6.6.2. Caso #2: Nessuna corrispondenza trovata, certificato associato (Case #2: No Match Found, Pinned Certificate)

Se il client non ha trovato un identificatore presentato corrispondente a uno degli identificatori di riferimento ma il client ha precedentemente associato (pinned) il certificato del servizio applicativo a uno degli identificatori di riferimento nella lista costruita per questo tentativo di comunicazione ("associazione" o "pinning" è descritto nella Sezione 1.8) e il certificato presentato corrisponde al certificato associato (incluso il contesto descritto nella Sezione 7.1), allora la verifica dell'identità del servizio ha avuto successo.

6.6.3. Caso #3: Nessuna corrispondenza trovata, nessun certificato associato (Case #3: No Match Found, No Pinned Certificate)

Se il client non ha trovato un identificatore presentato corrispondente a uno degli identificatori di riferimento e il client non ha precedentemente associato il certificato a uno degli identificatori di riferimento nella lista costruita per questo tentativo di comunicazione, allora il client DEVE (MUST) procedere come descritto nella Sezione 6.6.4.

6.6.4. Fallback

Se il client è un client interattivo controllato direttamente da un utente umano, DOVREBBE (SHOULD) informare l'utente della mancata corrispondenza dell'identità e può terminare automaticamente il tentativo di comunicazione con un errore di certificato errato. Questo comportamento è preferibile perché può impedire a un utente di aggirare inavvertitamente le protezioni di sicurezza in situazioni ostili.

Avviso di sicurezza: Alcuni client interattivi danno agli utenti avanzati l'opzione di procedere con l'accettazione nonostante la mancata corrispondenza dell'identità, "associando" (pinning) così effettivamente il certificato a uno degli identificatori di riferimento nella lista che il client ha costruito per questo tentativo di comunicazione. Sebbene tale comportamento possa essere appropriato in determinate circostanze specializzate, dovrebbe generalmente essere esposto solo agli utenti avanzati; anche in quel caso deve essere gestito con estrema cautela, ad esempio incoraggiando prima anche un utente avanzato a terminare il tentativo di comunicazione, costringendo l'utente a visualizzare l'intero percorso di certificazione se l'utente sceglie di procedere comunque, e solo allora permettendo all'utente di associare il certificato (temporaneamente o permanentemente, a scelta dell'utente).

Altrimenti, se il client è un'applicazione automatizzata non controllata direttamente da un utente umano, DOVREBBE (SHOULD) terminare il tentativo di comunicazione con un errore di certificato errato e registrare l'errore in modo appropriato. L'applicazione automatizzata PUÒ (MAY) fornire un'impostazione di configurazione per disabilitare questo comportamento, ma DEVE (MUST) abilitare questo comportamento per impostazione predefinita.