2. Nommage des services d'application (Naming of Application Services)

Cette section décrit le nommage des services d'application sur Internet, puis décrit brièvement le nommage des sujets dans PKIX.

2.1. Nommer les services d'application (Naming Application Services)

Cette spécification suppose que le nom d'un service d'application est basé sur un nom de domaine DNS (par exemple, "example.com"), éventuellement complété par le type de service d'application (par exemple, "le serveur IMAP chez example.com").

Du point de vue du client d'application ou de l'utilisateur, certains noms sont directs car ils sont fournis directement par un utilisateur humain (par exemple, via une entrée à l'exécution, une pré-configuration, ou une acceptation explicite d'une tentative de communication client) ; alors que d'autres noms sont indirects car ils sont automatiquement résolus par le client sur la base de l'entrée utilisateur (par exemple, résolution d'un nom cible à partir d'un nom source en utilisant des enregistrements DNS SRV ou NAPTR). Cette dimension importe le plus pour la consommation de certificats, spécifiquement la vérification telle que décrite dans ce document.

Du point de vue du service d'application, certains noms sont non restreints car ils peuvent être utilisés pour tout type de service (par exemple, un certificat peut être réutilisé pour les services HTTP et IMAP chez example.com) ; alors que d'autres noms sont restreints car ils ne peuvent être utilisés que pour un type de service (par exemple, un certificat dédié à l'utilisation pour les services IMAP uniquement). Cette dimension importe le plus pour l'émission de certificats.

Nous pouvons donc catégoriser les types d'identifiants d'intérêt comme suit :

CN-ID est Direct et Non Restreint.
DNS-ID est Direct et Non Restreint.
SRV-ID est Direct ou (plus communément) Indirect, et Restreint.
URI-ID est Direct et Restreint.

Cette catégorisation est résumée dans le tableau suivant.

+-----------+-----------+---------------+
|           |  Direct   |  Restreint    |
|           |           |  (Restricted) |
+-----------+-----------+---------------+
|  CN-ID    |  Oui      |  Non          |
+-----------+-----------+---------------+
|  DNS-ID   |  Oui      |  Non          |
+-----------+-----------+---------------+
|  SRV-ID   | Soit l'un |  Oui          |
|           | ou l'autre|               |
+-----------+-----------+---------------+
|  URI-ID   |  Oui      |  Oui          |
+-----------+-----------+---------------+

Il est important de garder ces distinctions à l'esprit lors de l'implémentation de logiciels, du déploiement de services, et de l'émission de certificats pour une authentification sécurisée basée sur PKIX. En particulier, les meilleures pratiques pour les implémentations de serveurs d'application, les implémentations de clients d'application, les fournisseurs de services d'application, et les autorités de certification seront légèrement différentes. Idéalement, une spécification de protocole qui référence ce document stipulera quels identifiants sont obligatoires à implémenter par les serveurs et les clients, quels identifiants devraient être supportés par les émetteurs de certificats, et quels identifiants devraient être demandés par les fournisseurs de services d'application. Ces exigences varieront d'une application à l'autre, donc aucune règle universelle ne peut être établie catégoriquement (par exemple, que toutes les implémentations logicielles, tous les fournisseurs de services, et toutes les autorités de certification pour tous les protocoles d'application doivent utiliser ou supporter DNS-ID comme base de référence à des fins d'interopérabilité).

Cependant, il est souhaitable que chaque protocole d'application définisse au moins une base de référence qui s'applique à l'ensemble de la communauté des développeurs de logiciels, des fournisseurs de services d'application, et des CA qui utilisent ou supportent activement cette technologie (une de ces communautés, le CA/Browser Forum, a déjà codifié une telle base de référence pour les "certificats à validation étendue" dans [EV-CERTS]).

2.2. Noms de domaine DNS (DNS Domain Names)

Aux fins de cette spécification, le nom d'un service d'application est (ou est basé sur) un nom de domaine DNS conforme à l'un des formats suivants :

Un "nom de domaine traditionnel", c'est-à-dire un nom de domaine DNS complet ou "FQDN" ([DNS-CONCEPTS]) qui possède uniquement des étiquettes qui sont des "étiquettes LDH" comme décrit dans [IDNA-DEFS]. De manière informelle, de telles étiquettes sont limitées aux lettres, chiffres et tirets [US-ASCII], où le tiret est interdit en première position de caractère. Des qualifications supplémentaires s'appliquent (voir les spécifications citées ci-dessus pour les détails), mais elles ne sont pas pertinentes pour cette spécification.
Un "nom de domaine internationalisé", c'est-à-dire un nom de domaine DNS qui est conforme au format global d'un nom de domaine (de manière informelle, des étiquettes alphanumériques avec tirets séparées par des points) mais qui contient au moins une étiquette avec des points de code Unicode encodés de manière appropriée en dehors de la plage US-ASCII traditionnelle. C'est-à-dire qu'il contient au moins une U-étiquette ou A-étiquette, mais peut par ailleurs contenir n'importe quelle combinaison d'étiquettes NR-LDH, A-étiquettes, ou U-étiquettes comme décrit dans [IDNA-DEFS] et les documents associés.

2.3. Nommage du sujet dans les certificats PKIX (Subject Naming in PKIX Certificates)

En théorie, l'infrastructure à clé publique Internet utilisant X.509 [PKIX] emploie le modèle de service d'annuaire global défini dans [X.500] et [X.501]. Dans ce modèle, les informations sont conservées dans une Base d'Information d'Annuaire (DIB), et les entrées au sein de celle-ci sont organisées dans une hiérarchie appelée Arborescence d'Information d'Annuaire (DIT). Les entrées d'objet ou d'alias dans cette hiérarchie sont composées d'une collection d'attributs (chacun avec un type défini et une ou plusieurs valeurs) et sont identifiées de manière unique par un Nom Distingué (Distinguished Name - DN) unique. Le DN d'une entrée est construit en combinant le Nom Distingué Relatif de son entrée supérieure dans l'arbre (jusqu'à la racine du DIT) et un ou plusieurs attributs spécialement désignés de l'entrée elle-même (qui constituent collectivement le Nom Distingué Relatif ou RDN de l'entrée - ainsi appelé parce qu'il est relatif au Nom Distingué de son entrée supérieure dans l'arbre). L'entrée la plus proche de la racine est parfois appelée l'entrée "la plus significative", et l'entrée la plus éloignée de la racine est parfois appelée l'entrée "la moins significative". Le RDN est un ensemble (c'est-à-dire une collection non ordonnée) de paires de type d'attribut et de valeur (voir aussi [LDAP-DN]), dont chacune affirme un certain attribut concernant l'entrée.

En pratique, les certificats utilisés dans [X.509] et [PKIX] empruntent des concepts clés de X.500 et X.501 pour identifier les entités (tels que DN et RDN), bien que de tels certificats ne fassent pas nécessairement partie d'une Base d'Information d'Annuaire globale. Spécifiquement, le champ Sujet (Subject) d'un certificat PKIX est un Nom de type X.501 qui "identifie l'entité associée à la clé publique stockée dans le champ de la clé publique du sujet" (voir la Section 4.1.2.6 de [PKIX]). Cependant, il est parfaitement acceptable que le champ Sujet soit vide, tant que le certificat contient une extension de nom alternatif du sujet ("subjectAltName") et que cette extension inclut au moins une entrée subjectAltName, car l'extension subjectAltName permet de lier diverses identités au sujet (voir la Section 4.2.1.6 de [PKIX]). L'extension subjectAltName est elle-même une liste d'entrées typées, chaque type étant une sorte d'identifiant différente.

Pour nos besoins, un service d'application peut être identifié par un nom contenu dans le champ Sujet (c'est-à-dire un CN-ID) et/ou par l'un des types d'identifiants suivants dans une entrée subjectAltName :

DNS-ID
SRV-ID
URI-ID

Les certificats existants utilisent souvent un CN-ID dans le champ Sujet pour représenter un nom de domaine DNS complet. Par exemple, considérez les trois noms de sujet suivants, dans lesquels l'attribut de type Common Name contient une chaîne correspondant au format d'un nom de domaine DNS complet ("im.example.org", "mail.example.net", et "www.example.com", respectivement) :

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

Cependant, parce que le Common Name n'est pas fortement typé, il est possible qu'un Common Name contienne une chaîne conviviale pour l'utilisateur plutôt qu'une chaîne conforme au format d'un nom de domaine DNS complet (souvent, un tel certificat avec un seul Common Name possède également au moins une entrée subjectAltName contenant un nom de domaine DNS complet) :

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

Alternativement, le sujet d'un certificat peut contenir à la fois un CN-ID et un autre attribut Common Name contenant une chaîne conviviale pour l'utilisateur :

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

En général, cette spécification recommande et préfère l'utilisation d'entrées subjectAltName (DNS-ID, SRV-ID, URI-ID, etc.) plutôt que l'utilisation du champ Sujet (CN-ID) lorsque possible, comme expliqué plus complètement dans les sections suivantes. Cependant, une spécification qui réutilise cette spécification PEUT légitimement recommander le support continu du type d'identifiant CN-ID s'il y a de bonnes raisons de le faire, telles que la rétrocompatibilité avec l'infrastructure déployée (voir, par exemple, [EV-CERTS]).

2.3.1. Notes d'implémentation (Implementation Notes)

La confusion peut résulter des différents rendus ou encodages de l'information hiérarchique contenue dans un certificat.

Un certificat est un objet binaire, encodé en utilisant les Règles d'Encodage Distinguées (DER) spécifiées dans [X.690]. Cependant, certaines implémentations génèrent un rendu affichable (c'est-à-dire imprimable) de l'émetteur du certificat, du champ Sujet, et de l'extension subjectAltName, et ces rendus convertissent la séquence encodée en DER en une "représentation sous forme de chaîne" avant affichage. Parce que le champ Sujet du certificat (qui est de type Name [X.509], le même que le Nom Distingué (DN) [X.501]) est une séquence ordonnée, l'ordre est généralement préservé dans la représentation sous forme de chaîne du sujet, bien que les deux représentations sous forme de chaîne les plus courantes des sujets (et des DNs) diffèrent par leur adoption d'un ordre de gauche à droite par rapport à un ordre de droite à gauche. Cependant, les Noms Distingués Relatifs (RDNs) sont des ensembles non ordonnés de paires de type d'attribut et de valeur, donc la représentation sous forme de chaîne d'un RDN peut différer de l'encodage canonique DER (et l'ordre des paires de type d'attribut et de valeur peut différer selon la représentation sous forme de chaîne ou l'ordre d'affichage fourni par diverses implémentations). De plus, diverses spécifications utilisent une terminologie qui se rapporte implicitement à une hiérarchie d'informations (qui peut ou non exister réellement) pour faire référence à l'ordre des RDNs dans un DN ou dans le champ Sujet d'un certificat ; par exemple, "le plus spécifique" (most specific) vs "le moins spécifique" (least specific), "le plus à gauche" (left-most) vs "le plus à droite" (right-most), "premier" (first) vs "dernier" (last), ou "le plus significatif" (most significant) vs "le moins significatif" (least significant) (voir, par exemple, [LDAP-DN]).

Pour réduire la confusion, cette spécification évite l'utilisation de tels termes et emploie à la place la terminologie fournie dans la Section 1.8. En particulier, au lieu d'utiliser le terme de [HTTP-TLS] "le champ Common Name (le plus spécifique) dans le champ Subject", un CN-ID est déclaré être un Nom Distingué Relatif (RDN) à l'intérieur du sujet du certificat contenant une et une seule paire de type d'attribut et de valeur de type Common Name (ce qui exclut la possibilité qu'un RDN contienne plusieurs AVAs (Assertions de Valeur d'Attribut) de type CN, dont l'un pourrait être considéré comme "le plus spécifique").

Enfin, bien que certains soutiennent qu'en théorie l'ordre des RDNs dans le champ Sujet a un sens, en pratique cette règle n'est généralement pas observée. Un AVA de type CN est considéré comme valide quelle que soit sa position dans le champ Sujet.