2. Denominazione dei servizi applicativi (Naming of Application Services)

Questa sezione descrive la denominazione dei servizi applicativi su Internet e quindi descrive brevemente la denominazione dei soggetti in PKIX.

2.1. Denominazione dei servizi applicativi (Naming Application Services)

Questa specifica assume che il nome di un servizio applicativo sia (o sia basato su) un nome di dominio DNS (es. "example.com"), opzionalmente aumentato dal tipo di servizio applicativo (es. "il server IMAP su example.com").

Dalla prospettiva del client applicativo o dell'utente, alcuni nomi sono diretti perché sono forniti direttamente da un utente umano (es. tramite input in fase di esecuzione, pre-configurazione o accettazione esplicita di un tentativo di comunicazione del client); mentre altri nomi sono indiretti perché sono risolti automaticamente dal client sulla base dell'input dell'utente (es. risoluzione di un nome di destinazione da un nome sorgente utilizzando record DNS SRV o NAPTR). Questa dimensione è più importante per il consumo dei certificati, in particolare per la verifica come descritto in questo documento.

Dalla prospettiva del servizio applicativo, alcuni nomi sono non vincolati perché possono essere utilizzati per qualsiasi tipo di servizio (es. un certificato può essere riutilizzato sia per servizi HTTP che IMAP su example.com); mentre altri nomi sono vincolati perché possono essere utilizzati solo per un tipo di servizio (es. un certificato inteso solo per l'uso per servizi IMAP). Questa dimensione è più importante per l'emissione dei certificati.

Possiamo quindi categorizzare i tipi di identificatori di interesse come segue:

CN-ID è Diretto e Non Vincolato.
DNS-ID è Diretto e Non Vincolato.
SRV-ID è Diretto o (più comunemente) Indiretto, e Vincolato.
URI-ID è Diretto e Vincolato.

Questa categorizzazione è riassunta nella seguente tabella.

+-----------+-----------+---------------+
|           |  Diretto  |  Vincolato    |
|           |           |  (Restricted) |
+-----------+-----------+---------------+
|  CN-ID    |  Sì       |  No           |
+-----------+-----------+---------------+
|  DNS-ID   |  Sì       |  No           |
+-----------+-----------+---------------+
|  SRV-ID   | O l'uno   |  Sì           |
|           | o l'altro |               |
+-----------+-----------+---------------+
|  URI-ID   |  Sì       |  Sì           |
+-----------+-----------+---------------+

È importante tenere a mente queste distinzioni quando si implementa il software, si distribuiscono i servizi e si emettono i certificati, al fine di garantire un'autenticazione sicura basata su PKIX. In particolare, le migliori pratiche per l'implementazione di server applicativi, l'implementazione di client applicativi, i fornitori di servizi applicativi e le autorità di certificazione saranno leggermente diverse. Idealmente, una specifica di protocollo che fa riferimento a questo documento stipulerà quali identificatori devono essere obbligatoriamente implementati dai server e dai client, quali identificatori dovrebbero essere supportati dagli emittenti di certificati e quali identificatori dovrebbero essere richiesti dai fornitori di servizi applicativi. Questi requisiti varieranno da applicazione ad applicazione, quindi non si possono stabilire regole universali in modo categorico (ad esempio, che tutte le implementazioni software, tutti i fornitori di servizi e tutte le CA debbano utilizzare o supportare i DNS-ID come base per l'interoperabilità per tutti i protocolli applicativi).

Tuttavia, è desiderabile che ogni protocollo applicativo definisca almeno una base di riferimento che si applichi a tutta la comunità di sviluppatori software, fornitori di servizi applicativi e CA che utilizzano o supportano attivamente tale tecnologia (una di queste comunità, il CA/Browser Forum, ha già codificato tale base di riferimento per i "Certificati a Validazione Estesa" in [EV-CERTS]).

2.2. Nomi di dominio DNS (DNS Domain Names)

Ai fini di questa specifica, il nome di un servizio applicativo è (o si basa su) un nome di dominio DNS che è conforme a uno dei seguenti formati:

Un "nome di dominio tradizionale", cioè un nome di dominio DNS completamente qualificato o "FQDN" ([DNS-CONCEPTS]) che possiede solo etichette che sono "etichette LDH" come descritto in [IDNA-DEFS]. Informalmente, tali etichette sono limitate a lettere, cifre e il trattino meno [US-ASCII], con il trattino meno vietato nella prima posizione del carattere. Si applicano ulteriori qualifiche (vedere le specifiche citate sopra per i dettagli), ma non sono rilevanti per questa specifica.
Un "nome di dominio internazionalizzato", cioè un nome di dominio DNS che è conforme al formato generale di un nome di dominio (informalmente, etichette alfanumeriche separate da punti con trattini meno) ma contiene almeno un'etichetta con punti di codice Unicode al di fuori dell'intervallo US-ASCII tradizionale che sono codificati in modo appropriato. Cioè, contiene almeno una U-label o A-label, ma per il resto può contenere qualsiasi combinazione di NR-LDH labels, A-labels, o U-labels come descritto in [IDNA-DEFS] e documenti correlati.

2.3. Denominazione del soggetto nei certificati PKIX (Subject Naming in PKIX Certificates)

In teoria, l'infrastruttura a chiave pubblica Internet che utilizza X.509 [PKIX] impiega il modello di servizio di directory globale definito in [X.500] e [X.501]. In quel modello, le informazioni sono conservate in una Directory Information Base (DIB), e le voci in essa sono organizzate in una gerarchia chiamata Directory Information Tree (DIT). Le voci oggetto o alias in questa gerarchia sono composte da una raccolta di attributi (ciascuno con un tipo definito e uno o più valori) e sono identificate in modo univoco da un singolo Distinguished Name (DN). Il DN di una voce è costruito combinando il Relative Distinguished Name della sua voce genitore nell'albero (fino alla radice del DIT) e uno o più attributi appositamente designati della voce stessa (che insieme comprendono il Relative Distinguished Name o RDN della voce - così chiamato perché è relativo al Distinguished Name della sua voce genitore nell'albero). La voce più vicina alla radice è talvolta chiamata la voce "più significativa", e la voce più lontana dalla radice è talvolta chiamata la voce "meno significativa". L'RDN è un insieme (cioè, una raccolta non ordinata) di coppie tipo-e-valore di attributo (vedere anche [LDAP-DN]), ciascuna delle quali asserisce un determinato attributo riguardante la voce.

In pratica, i certificati utilizzati in [X.509] e [PKIX] prendono in prestito concetti chiave da X.500 e X.501 per identificare entità (come DN e RDN), sebbene tali certificati non facciano necessariamente parte di una Directory Information Base globale. In particolare, il campo Subject di un certificato PKIX è un nome di tipo X.501 che "identifica l'entità associata alla chiave pubblica memorizzata nel campo chiave pubblica del soggetto" (vedere la Sezione 4.1.2.6 di [PKIX]). Tuttavia, è perfettamente accettabile che il campo Subject sia vuoto, purché il certificato includa un'estensione subject alternative name ("subjectAltName") e che tale estensione includa almeno una voce subjectAltName, poiché l'estensione subjectAltName consente di legare varie identità al soggetto (vedere la Sezione 4.2.1.6 di [PKIX]). L'estensione subjectAltName è essa stessa un elenco di voci tipizzate, dove ogni tipo è un diverso tipo di identificatore.

Per i nostri scopi, un servizio applicativo può essere identificato da un nome nel campo Subject (cioè, un CN-ID) e/o da uno dei seguenti tipi di identificatore contenuti in una voce subjectAltName:

DNS-ID
SRV-ID
URI-ID

I certificati esistenti spesso utilizzano un CN-ID nel campo Subject per rappresentare un nome di dominio DNS completamente qualificato. Ad esempio, considera i seguenti tre nomi di soggetto in cui l'attributo di tipo Common Name contiene una stringa conforme al formato di un nome di dominio DNS completamente qualificato ("im.example.org", "mail.example.net", e "www.example.com" rispettivamente):

CN=im.example.org,O=Example Org,C=GB

C=CA,O=Example Internetworking,CN=mail.example.net

O=Examples-R-Us,CN=www.example.com,C=US

Tuttavia, poiché il Common Name non è fortemente tipizzato, è possibile che un Common Name contenga una stringa user-friendly invece di una stringa conforme al formato di un nome di dominio DNS completamente qualificato (spesso tale certificato con un singolo Common Name possiede anche almeno una voce subjectAltName che contiene un nome di dominio DNS completamente qualificato):

CN=A Free Chat Service,O=Example Org,C=GB

In alternativa, il soggetto di un certificato può contenere sia un CN-ID che un altro attributo Common Name contenente una stringa user-friendly:

CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB

In generale, questa specifica raccomanda e preferisce l'uso di voci subjectAltName (DNS-ID, SRV-ID, URI-ID, ecc.) rispetto all'uso del campo Subject (CN-ID) ove possibile, come discusso più dettagliatamente nelle sezioni seguenti. Tuttavia, una specifica che riutilizza questa specifica PUÒ legittimamente raccomandare il supporto continuato per il tipo di identificatore CN-ID se ci sono buone ragioni per farlo, come la retrocompatibilità con l'infrastruttura installata (vedere ad esempio [EV-CERTS]).

2.3.1. Note di implementazione (Implementation Notes)

La confusione può derivare dalle diverse rappresentazioni o codifiche delle informazioni gerarchiche contenute in un certificato.

Un certificato è un oggetto binario che è codificato utilizzando le Distinguished Encoding Rules (DER) specificate in [X.690]. Tuttavia, alcune implementazioni generano una rappresentazione visualizzabile (cioè, stampabile) dell'Emittente del certificato, del campo Subject e dell'estensione subjectAltName, e queste rappresentazioni convertono la sequenza codificata DER in una "rappresentazione stringa" prima della visualizzazione. Poiché il campo Subject del certificato (che è di tipo Name [X.509], uguale al Distinguished Name (DN) [X.501]) è una sequenza ordinata, l'ordine è generalmente conservato nella rappresentazione stringa del soggetto, sebbene le due rappresentazioni stringa più comuni di soggetti (e DN) differiscano nella loro assunzione di un ordinamento da sinistra a destra rispetto a uno da destra a sinistra. Tuttavia, i Relative Distinguished Names (RDN) sono insiemi non ordinati di coppie tipo-e-valore di attributo, quindi la rappresentazione stringa di un RDN può divergere dalla codifica DER canonica (e l'ordine delle coppie tipo-e-valore di attributo può variare a seconda della rappresentazione stringa o dell'ordine di visualizzazione fornito da diverse implementazioni). Inoltre, diverse specifiche utilizzano una terminologia che si riferisce implicitamente a una gerarchia di informazioni (che può o meno esistere effettivamente) per riferirsi all'ordine degli RDN in un DN o nel campo Subject del certificato; ad esempio, "più specifico" (most specific) vs "meno specifico" (least specific), "più a sinistra" (left-most) vs "più a destra" (right-most), "primo" (first) vs "ultimo" (last) o "più significativo" (most significant) vs "meno significativo" (least significant) (vedere ad esempio [LDAP-DN]).

Per ridurre la confusione, questa specifica evita l'uso di tali termini e utilizza invece la terminologia fornita nella Sezione 1.8. In particolare, anziché utilizzare il termine da [HTTP-TLS] "il campo Common Name (più specifico) nel campo Subject", un CN-ID viene dichiarato essere un Relative Distinguished Name (RDN) all'interno del soggetto del certificato che contiene esattamente una coppia tipo-e-valore di attributo di tipo Common Name (il che preclude la possibilità che un RDN contenga multipli AVA (Attribute Value Assertions) di tipo CN, uno dei quali potrebbe essere considerato "più specifico").

Infine, sebbene alcuni sostengano che l'ordinamento degli RDN nel campo Subject abbia un significato in teoria, questa regola non è generalmente osservata nella pratica. Un AVA di tipo CN è considerato valido indipendentemente dalla sua posizione nel campo Subject.