4. Rappresentazione dell'identità del server (Representing Server Identity)

Questa sezione fornisce regole e linee guida per gli emittenti di certificati.

4.1. Regole (Rules)

Quando una CA emette un certificato basato sul nome di dominio DNS completamente qualificato presso il quale il fornitore del servizio applicativo offrirà il/i servizio/i pertinente/i, si applicano le seguenti regole alla rappresentazione delle identità del servizio applicativo. Il lettore dovrebbe notare che alcune di queste regole sono cumulative e possono interagire in modi importanti, come discusso più avanti in questo documento.

Il certificato DOVREBBE (SHOULD) includere un "DNS-ID" come base per l'interoperabilità, ove possibile.
Se il servizio che utilizza il certificato impiega una tecnologia per la quale la/e specifica/he pertinente/i impone/engono che il certificato DOVREBBE (OUGHT TO) includere un identificatore di tipo SRV-ID (ad esempio, questo è vero per [XMPP]), allora il certificato DOVREBBE (SHOULD) includere un SRV-ID.
Se il servizio che utilizza il certificato impiega una tecnologia per la quale la/e specifica/he pertinente/i impone/engono che il certificato DOVREBBE (OUGHT TO) includere un identificatore di tipo URI-ID (ad esempio, questo è vero per [SIP] secondo [SIP-CERTS], ma non vero per [HTTP] perché [HTTP-TLS] non menziona l'uso di URI-ID da parte dei servizi HTTP), allora il certificato DOVREBBE (SHOULD) includere un URI-ID. Lo schema DOVRÀ (SHALL) essere quello associato al tipo di servizio applicativo e il componente "host" (o equivalente) DOVRÀ (SHALL) essere il nome di dominio DNS completamente qualificato del servizio. Una specifica che riutilizza questa specifica DEVE (MUST) specificare quali schemi URI sono consentiti negli URI-ID contenuti nei certificati PKIX per quel protocollo applicativo (ad esempio, "sip" ma non "sips" o "tel" per SIP come descritto in [SIP-SIPS], o forse http e https per HTTP come potrebbe essere descritto in una specifica futura).
Il certificato PUÒ (MAY) includere altri tipi di identificatori specifici dell'applicazione definiti prima della pubblicazione di [SRVNAME] (come XmppAddr per [XMPP]) o per i quali non esiste alcun nome di servizio o schema URI; tuttavia, tali identificatori specifici dell'applicazione non si applicano a tutte le tecnologie applicative e pertanto sono fuori dall'ambito di questa specifica.
Sebbene molti client installati controllino ancora il campo Subject per un CN-ID, le autorità di certificazione sono incoraggiate a migrare dall'inclusione del nome di dominio DNS completamente qualificato del server in un CN-ID. Pertanto il certificato NON DOVREBBE (SHOULD NOT) includere un CN-ID a meno che la CA non emetta il certificato in conformità con una specifica che riutilizza questa specifica e raccomanda esplicitamente il supporto continuato per il tipo di identificatore CN-ID nel contesto di una determinata tecnologia applicativa.
Il certificato PUÒ (MAY) includere più DNS-ID, SRV-ID o URI-ID, ma NON DOVREBBE (SHOULD NOT) includere più CN-ID, come discusso più avanti nella Sezione 7.4.
Sebbene l'uso del carattere jolly '' sia consentito nei nomi di dominio DNS, esso NON DOVREBBE (SHOULD NOT) essere incluso nella porzione del nome di dominio DNS di un identificatore presentato, sia come etichetta completa più a sinistra (ad esempio, ".example.com", come nella descrizione delle etichette e dei nomi di dominio in [DNS-CONCEPTS]) sia come frammento di essa (ad esempio, oo.example.com, fo.example.com, o fo*.example.com), a meno che una specifica che riutilizza questa specifica non consenta esplicitamente il supporto continuato del carattere jolly. Una discussione più dettagliata dei cosiddetti "certificati wildcard" è fornita nella Sezione 7.2.

4.2. Esempi (Examples)

Si consideri un semplice sito web su "www.example.com" che non è ricercabile tramite lookup DNS SRV. Poiché HTTP non specifica l'uso di URI nei certificati server, un certificato per il servizio potrebbe includere solo un DNS-ID di "www.example.com". Potrebbe anche includere un CN-ID di "www.example.com" per retrocompatibilità con l'infrastruttura installata.

Si consideri un server di posta elettronica accessibile via IMAP ospitato su "mail.example.net" che serve indirizzi email della forma "[email protected]" ed è ricercabile tramite un lookup DNS SRV del nome del servizio applicativo "example.net". Un certificato per il servizio potrebbe includere SRV-ID di "_imap.example.net" e "_imaps.example.net" (vedere [EMAIL-SRV]) e DNS-ID di "example.net" e "mail.example.net". Potrebbe anche includere CN-ID di "example.net" e "mail.example.net" per retrocompatibilità con l'infrastruttura installata.

Si consideri un server Voice over IP (VoIP) accessibile via SIP ospitato su "voice.example.edu" che serve indirizzi SIP della forma "[email protected]" ed è identificato da un URI di <sip:voice.example.edu>. Un certificato per il servizio includerebbe un URI-ID di "sip:voice.example.edu" (vedere [SIP-CERTS]) e un DNS-ID di "voice.example.edu". Potrebbe anche includere un CN-ID di "voice.example.edu" per retrocompatibilità con l'infrastruttura installata.

Si consideri un server di Instant Messaging (IM) conforme a XMPP ospitato su "im.example.org" che serve indirizzi IM della forma "[email protected]" ed è ricercabile tramite un lookup DNS SRV sul dominio "im.example.org". Un certificato per il servizio potrebbe includere SRV-ID di "_xmpp-client.im.example.org" e "_xmpp-server.im.example.org" (vedere [XMPP]), un DNS-ID di "im.example.org", e una "XmppAddr" specifica per XMPP (vedere [XMPP]) di "im.example.org". Potrebbe anche includere un CN-ID di "im.example.org" per retrocompatibilità con l'infrastruttura installata.