4. Représenter l'identité du serveur (Representing Server Identity)

Cette section fournit des règles et des conseils pour les émetteurs de certificats.

4.1. Règles (Rules)

Lorsqu'une autorité de certification émet un certificat basé sur le nom de domaine DNS complet où le fournisseur de services d'application offrira le(s) service(s) pertinent(s), les règles suivantes s'appliquent à la représentation des identités de service d'application. Le lecteur doit noter que certaines de ces règles sont cumulatives et peuvent interagir de manière importante, comme discuté plus loin dans ce document.

Le certificat DEVRAIT (SHOULD) inclure un "DNS-ID" comme base de référence pour l'interopérabilité, si possible.
Si le service utilisant le certificat déploie une technologie pour laquelle la ou les spécifications pertinentes stipulent que le certificat DOIT (OUGHT TO) inclure un identifiant de type SRV-ID (par exemple, c'est vrai pour [XMPP]), alors le certificat DEVRAIT (SHOULD) inclure un SRV-ID.
Si le service utilisant le certificat déploie une technologie pour laquelle la ou les spécifications pertinentes stipulent que le certificat DOIT (OUGHT TO) inclure un identifiant de type URI-ID (par exemple, c'est vrai pour [SIP] selon [SIP-CERTS], mais pas pour [HTTP] car [HTTP-TLS] ne mentionne pas l'utilisation d'URI-IDs par les services HTTP), alors le certificat DEVRAIT (SHOULD) inclure un URI-ID. Le schéma DEVRA (SHALL) être celui associé au type de service d'application et le composant "host" (ou son équivalent) DEVRA (SHALL) être le nom de domaine DNS complet du service. Une spécification qui réutilise cette spécification DOIT (MUST) spécifier quels schémas URI sont acceptables dans les URI-IDs contenus dans les certificats PKIX pour ce protocole d'application (par exemple, "sip" mais pas "sips" ou "tel" pour SIP comme décrit dans [SIP-SIPS], ou peut-être http et https pour HTTP comme pourrait être décrit dans une future spécification).
Le certificat PEUT (MAY) inclure d'autres types d'identifiants spécifiques à l'application définis avant la publication de [SRVNAME] (tel que XmppAddr pour [XMPP]) ou pour lesquels il n'y a pas de nom de service ou de schéma URI ; cependant, de tels identifiants spécifiques à l'application ne s'appliquent pas à toutes les technologies d'application et sont donc hors de portée pour cette spécification.
Bien que de nombreux clients déployés vérifient encore le champ Sujet pour un CN-ID, il est encouragé que les autorités de certification migrent vers la non-inclusion du nom de domaine DNS complet du serveur dans un CN-ID. Par conséquent, le certificat NE DEVRAIT PAS (SHOULD NOT) inclure un CN-ID sauf si l'autorité de certification émet le certificat conformément à une spécification qui réutilise cette spécification et qui recommande explicitement le support continu du type d'identifiant CN-ID dans le contexte d'une technologie d'application donnée.
Le certificat PEUT (MAY) inclure plusieurs DNS-IDs, SRV-IDs, ou URI-IDs mais NE DEVRAIT PAS (SHOULD NOT) inclure plusieurs CN-IDs, comme discuté plus loin dans la Section 7.4.
Bien que l'utilisation du caractère générique '' soit autorisée dans les noms de domaine DNS, il NE DEVRAIT PAS (SHOULD NOT) être inclus dans la partie nom de domaine DNS d'un identifiant présenté, que ce soit comme l'étiquette complète la plus à gauche (par exemple, ".example.com" selon la description des étiquettes et des noms de domaine dans [DNS-CONCEPTS]) ou comme un fragment de celle-ci (par exemple, oo.example.com, fo.example.com, ou fo*.example.com), à moins qu'une spécification qui réutilise cette spécification ne permette explicitement le support continu du caractère générique. Une discussion plus détaillée des soi-disant "certificats wildcard" est fournie dans la Section 7.2.

4.2. Exemples (Examples)

Considérez un site web simple chez "www.example.com", qui n'est pas découvrable via les recherches DNS SRV. Parce que HTTP ne spécifie pas l'utilisation d'URIs dans les certificats serveur, un certificat pour le service pourrait inclure uniquement un DNS-ID de "www.example.com". Il pourrait aussi inclure un CN-ID de "www.example.com" pour la rétrocompatibilité avec l'infrastructure déployée.

Considérez un serveur de messagerie accessible par IMAP hébergé chez "mail.example.net" qui sert des adresses e-mail de la forme "[email protected]" et est découvrable via une recherche DNS SRV du nom de service d'application "example.net". Un certificat pour le service pourrait inclure des SRV-IDs de "_imap.example.net" et "_imaps.example.net" (voir [EMAIL-SRV]) ainsi que des DNS-IDs de "example.net" et "mail.example.net". Il pourrait aussi inclure des CN-IDs de "example.net" et "mail.example.net" pour la rétrocompatibilité avec l'infrastructure déployée.

Considérez un serveur Voix sur IP (VoIP) accessible par SIP hébergé chez "voice.example.edu" qui sert des adresses SIP de la forme "[email protected]" et est identifié par un URI de <sip:voice.example.edu>. Un certificat pour le service inclurait un URI-ID de "sip:voice.example.edu" (voir [SIP-CERTS]) et un DNS-ID de "voice.example.edu". Il pourrait aussi inclure un CN-ID de "voice.example.edu" pour la rétrocompatibilité avec l'infrastructure déployée.

Considérez un serveur de messagerie instantanée (IM) conforme à XMPP hébergé chez "im.example.org" qui sert des adresses IM de la forme "[email protected]" et est découvrable via une recherche DNS SRV sur le domaine "im.example.org". Un certificat pour le service pourrait inclure des SRV-IDs de "_xmpp-client.im.example.org" et "_xmpp-server.im.example.org" (voir [XMPP]), un DNS-ID de "im.example.org", et une "XmppAddr" spécifique à XMPP (voir [XMPP]) de "im.example.org". Il pourrait aussi inclure un CN-ID de "im.example.org" pour la rétrocompatibilité avec l'infrastructure déployée.