6. Vérifier l'identité du service (Verifying Service Identity)

Cette section fournit des règles et des conseils pour les implémenteurs de logiciels clients d'application concernant les algorithmes de vérification de l'identité du service d'application.

6.1. Aperçu (Overview)

À un haut niveau, le client vérifie l'identité du service d'application en effectuant les opérations suivantes (ces opérations sont définies dans les sous-sections suivantes de ce document) :

Le client construit une liste d'identifiants de référence acceptables basés sur le domaine source (source domain) et, optionnellement, le type de service auquel le client se connecte.
Le serveur présente ses identifiants sous la forme d'un certificat PKIX.
Le client vérifie chacun de ses identifiants de référence par rapport aux identifiants présentés dans le but de trouver une correspondance.
Lors de la vérification d'un identifiant de référence par rapport à un identifiant présenté, le client met en correspondance le domaine source des identifiants et, optionnellement, leur type de service d'application.

Naturellement, en plus de vérifier les identifiants, le client peut avoir besoin d'effectuer d'autres vérifications pour s'assurer que le serveur est autorisé à fournir le service demandé ; cependant, de telles vérifications ne sont pas une question de vérification de l'identité du service d'application présentée dans un certificat et les méthodes pour le faire (par exemple, consulter des informations de politique locale) sont donc hors de portée pour ce document.

6.2. Construction d'une liste d'identifiants de référence (Constructing a List of Reference Identifiers)

6.2.1. Règles (Rules)

Le client DOIT (MUST) construire une liste d'identifiants de référence acceptables, et il DOIT (MUST) le faire indépendamment des identifiants présentés par le service.

Les entrées que le client utilise pour construire sa liste d'identifiants de référence peuvent être un URI tapé par un utilisateur dans une interface (par exemple, une URL HTTPS pour un site web), des informations de compte configurées (par exemple, le nom de domaine d'un hôte ou URI spécifique utilisé pour récupérer des informations ou se connecter à un réseau, qui peut être différent de la partie nom de domaine DNS d'un nom d'utilisateur), un lien hypertexte dans une page web qui déclenche un navigateur pour récupérer un objet média ou un script, ou d'autres combinaisons d'informations qui peuvent donner un domaine source et un type de service d'application.

Le client peut avoir besoin d'extraire le domaine source et le type de service d'application de l'entrée qu'il a reçue. Les données extraites DOIVENT (MUST) inclure uniquement des informations qui peuvent être analysées en toute sécurité à partir de l'entrée (par exemple, un nom de domaine DNS complet analysé à partir du composant "host" (ou son équivalent) d'un URI, ou un type de service d'application dérivé du schéma d'un URI) ou des informations dérivées d'une manière qui n'est pas susceptible de corruption par des attaquants réseau (par exemple, des données extraites d'un domaine de délégation établi explicitement via la configuration client ou système, des données résolues via [DNSSEC], ou des données obtenues d'un service de mappage de domaine tiers en lequel un utilisateur humain a explicitement placé sa confiance et avec lequel le client communique via une connexion ou association qui fournit une authentification mutuelle et une vérification d'intégrité). Ces considérations s'appliquent uniquement à l'extraction du domaine source à partir de l'entrée ; naturellement, si l'entrée elle-même est invalide ou corrompue (par exemple, si un utilisateur clique sur un lien fourni par une entité malveillante dans une attaque de phishing), le client peut finir par communiquer avec un service d'application involontaire.

Exemple : Étant donné l'URI d'entrée <sips:[email protected]>, un client dériverait le type de service d'application "sip" du "schéma" et analyserait le nom de domaine "example.net" à partir du composant "host" (ou son équivalent).

Chaque identifiant de référence dans la liste DEVRAIT (SHOULD) être basé sur le domaine source et NE DEVRAIT PAS (SHOULD NOT) être basé sur un domaine dérivé (par exemple, un nom d'hôte ou un nom de domaine découvert à la suite d'une résolution DNS du domaine source). Cette règle est importante car seule une correspondance entre l'entrée utilisateur et l'identifiant présenté peut donner au client une certaine assurance que le certificat peut être légitimement utilisé pour sécuriser la communication entre le client et le serveur. Il n'y a qu'un seul cas où un client interactif peut outrepasser la recommandation de cette règle et communiquer avec un nom de domaine autre que le domaine source : si un utilisateur humain a "épinglé" (pinned) le certificat du service d'application à un nom de domaine alternatif, comme discuté plus loin dans les Sections 6.6.4 et 7.1. Dans ce cas, l'entrée que le client utilise pour construire sa liste d'identifiants de référence peut contenir plusieurs noms de domaine DNS complets : (a) le domaine source et (b) le domaine alternatif contenu dans le certificat épinglé.

En utilisant la combinaison d'un ou plusieurs noms de domaine DNS complets et d'un type de service d'application, le client construit une liste d'identifiants de référence conformément aux règles suivantes :

La liste DEVRAIT (SHOULD) inclure un DNS-ID construit directement à partir de (a) le nom de domaine DNS complet contenu dans ou dérivé de manière sécurisée de l'entrée (c'est-à-dire, le domaine source) ou (b) le nom de domaine DNS complet explicitement associé au domaine source via la configuration utilisateur (c'est-à-dire, un domaine dérivé).
Si un serveur pour le type de service d'application est généralement localisé via des enregistrements DNS SRV, la liste DEVRAIT (SHOULD) inclure un SRV-ID.
Si un serveur pour le type de service d'application est généralement associé à un URI à des fins de sécurité (c'est-à-dire, si un document de protocole formel spécifie l'utilisation d'URIs dans les certificats serveur), la liste DEVRAIT (SHOULD) inclure un URI-ID.
La liste PEUT (MAY) inclure un CN-ID, principalement pour la rétrocompatibilité avec l'infrastructure déployée.

Les types d'identifiants qu'un client inclut dans sa liste d'identifiants de référence est une question de politique locale. Par exemple, il peut y avoir un environnement de déploiement où des clients construits pour se connecter à un certain type de service (disons, uniquement un service IM) sont configurés pour accepter comme valides uniquement les certificats contenant un SRV-ID pour ce type de service d'application ; dans ce cas, le client inclurait uniquement un SRV-ID pour le type de service d'application correspondant dans sa liste d'identifiants de référence (et non, par exemple, un DNS-ID). En revanche, un client plus indulgent (même un construit pour se connecter uniquement à un certain type de service) pourrait inclure à la fois un SRV-ID et un DNS-ID dans sa liste d'identifiants de référence.

Note d'implémentation : En raison de la prévalence des certificats contenant des CN-IDs, il est très probable que les implémenteurs de logiciels clients auront besoin de supporter les CN-IDs dans un avenir prévisible. Les implémenteurs sont invités à surveiller l'état de l'art des politiques d'émission de certificats et à abandonner le support des CN-IDs à l'avenir si possible.

Note d'implémentation : Un client n'a pas besoin de construire les identifiants mentionnés ci-dessus dans la forme réelle trouvée dans un certificat (par exemple, en tant que types ASN.1) ; il suffit de construire des équivalents fonctionnels de tels identifiants à des fins de correspondance.

Avertissement de sécurité : Un client NE DOIT PAS (MUST NOT) construire un identifiant de référence correspondant à un Nom Distingué Relatif (RDN) autre que ceux de type Common Name, et un client NE DOIT PAS (MUST NOT) vérifier un RDN autre que ceux de type Common Name dans un identifiant présenté.

6.2.2. Exemples (Examples)

Un navigateur web se connectant à un site web "www.example.com" via HTTPS pourrait avoir deux identifiants de référence : un DNS-ID de "www.example.com" et, comme solution de repli, un CN-ID de "www.example.com".

Un agent utilisateur de messagerie se connectant à un service de messagerie "example.net" (qui se résout en "mail.example.net") via IMAPS pourrait avoir cinq identifiants de référence : un SRV-ID de "_imaps.example.net" (voir [EMAIL-SRV]), des DNS-IDs de "example.net" et "mail.example.net", et, comme solutions de repli, des CN-IDs de "example.net" et "mail.example.net". (Un agent utilisateur plus ancien qui ne supporte pas [EMAIL-SRV] pourrait être explicitement configuré pour se connecter à "mail.example.net", tandis qu'un agent utilisateur compatible SRV dériverait "example.net" d'une adresse e-mail de la forme "[email protected]" mais pourrait aussi accepter "mail.example.net" comme partie nom de domaine DNS d'un identifiant de référence pour le service.)

Un agent utilisateur Voix sur IP (VoIP) se connectant à un service vocal "voice.example.edu" via SIP pourrait n'avoir qu'un seul identifiant de référence : un URI-ID de "sip:voice.example.edu" (voir [SIP-CERTS]).

Un client de messagerie instantanée (IM) se connectant à un service IM "im.example.org" via XMPP pourrait avoir trois identifiants de référence : un SRV-ID de "_xmpp-client.im.example.org" (voir [XMPP]), un DNS-ID de "im.example.org", et une "XmppAddr" spécifique à XMPP (voir [XMPP]) de "im.example.org".

6.3. Préparation à la recherche d'une correspondance (Preparing to Seek a Match)

Une fois que le client a construit sa liste d'identifiants de référence et a reçu les identifiants du serveur sous la forme d'un certificat PKIX, le client vérifie ses identifiants de référence par rapport aux identifiants présentés dans le but de trouver une correspondance. La recherche échoue si le client épuise sa liste d'identifiants de référence sans trouver de correspondance. La recherche réussit si l'un des identifiants présentés correspond à l'un des identifiants de référence, moment auquel le client DEVRAIT (SHOULD) arrêter la recherche.

Note d'implémentation : Un client pourrait être configuré pour effectuer plusieurs recherches, c'est-à-dire pour correspondre à plus d'un identifiant de référence. Bien que cette spécification n'interdise pas un tel comportement, les règles pour correspondre à plusieurs identifiants de référence sont une question pour les implémentations ou les spécifications futures.

Avertissement de sécurité : Si un identifiant présenté contient un DNS-ID, SRV-ID, URI-ID, ou tout type d'identifiant spécifique à l'application supporté par le client, le client NE DOIT PAS (MUST NOT) chercher une correspondance avec un identifiant de référence CN-ID.

Avant d'appliquer les règles de comparaison fournies dans les sections suivantes, le client peut avoir besoin de diviser un identifiant de référence en une partie nom de domaine DNS et une partie type de service d'application, comme suit :

Un identifiant de référence de type DNS-ID ne contient pas de partie type de service d'application et peut être utilisé directement comme nom de domaine DNS pour la comparaison. Par exemple, un DNS-ID de "www.example.com" résulte en une partie nom de domaine DNS de "www.example.com".
Un identifiant de référence de type CN-ID ne contient pas non plus de partie type de service d'application et peut être utilisé directement comme nom de domaine DNS pour la comparaison. Comme noté, ce document stipule qu'un CN-ID contient toujours une chaîne conforme au format d'un nom de domaine DNS (distinguant ainsi un CN-ID d'un Common Name contenant un nom convivial).
Pour un identifiant de référence de type SRV-ID, la partie nom de domaine DNS est le Nom et la partie type de service d'application est le Service. Par exemple, un SRV-ID de "_imaps.example.net" se divise en une partie nom de domaine DNS de "example.net" et une partie type de service d'application de "imaps" (qui correspond au protocole d'application IMAP comme expliqué dans [EMAIL-SRV]).
Pour un identifiant de référence de type URI-ID, la partie nom de domaine DNS est la partie "reg-name" du composant "host" (ou son équivalent) et la partie type de service d'application est le type de service d'application associé au nom de schéma correspondant à la règle [ABNF] "scheme" de [URI] (moins le caractère séparateur ':'). Comme noté, ce document stipule qu'un URI-ID contient toujours un URI contenant un composant "host" (ou son équivalent) qui contient un "reg-name". (La correspondance uniquement avec la règle "reg-name" de [URI] limite la vérification aux noms de domaine DNS, permettant la distinction entre un URI-ID et une entrée uniformResourceIdentifier contenant une adresse IP ou un simple nom d'hôte, ou pas de composant "host" du tout). De plus, notez que l'extraction du "reg-name" peut nécessiter une normalisation de l'URI (comme expliqué dans [URI]). Par exemple, un URI-ID de "sip:voice.example.edu" se divise en une partie nom de domaine DNS de "voice.example.edu" et un type de service d'application de "sip" (qui est associé au protocole d'application SIP comme expliqué dans [SIP-CERTS]).

Les sections suivantes fournissent des règles de comparaison détaillées pour faire correspondre la partie nom de domaine DNS et la partie type de service d'application des identifiants de référence.

6.4. Correspondance de la partie nom de domaine DNS (Matching the DNS Domain Name Portion)

Le client DOIT (MUST) faire correspondre la partie nom de domaine DNS d'un identifiant de référence selon les règles suivantes, et DEVRAIT (SHOULD) vérifier simultanément le type de service d'application, comme décrit dans la Section 6.5. Les règles diffèrent selon que le domaine à vérifier est un "nom de domaine traditionnel" ou un "nom de domaine internationalisé" (tels que définis dans la Section 2.2). De plus, nous définissons des règles supplémentaires pour les soi-disant "certificats wildcard" afin de répondre aux besoins des clients supportant les identifiants présentés contenant le caractère générique '*', et nous stipulons les circonstances dans lesquelles il est acceptable de vérifier le type d'identifiant "CN-ID" en dernier ressort.

6.4.1. Vérification des noms de domaine traditionnels (Checking of Traditional Domain Names)

Si la partie nom de domaine DNS d'un identifiant de référence est un "nom de domaine traditionnel", alors la correspondance de l'identifiant de référence par rapport à l'identifiant présenté est effectuée en comparant l'ensemble des étiquettes de nom de domaine en utilisant une comparaison ASCII insensible à la casse, comme clarifié par [DNS-CASE] (par exemple, "WWW.Example.Com" serait en minuscules "www.example.com" pour la comparaison). Chaque étiquette DOIT (MUST) correspondre pour qu'elle soit considérée comme une correspondance, à moins d'être complétée par les règles de vérification des étiquettes wildcard (Section 6.4.3).

6.4.2. Vérification des noms de domaine internationalisés (Checking of Internationalized Domain Names)

Si la partie nom de domaine DNS d'un identifiant de référence est un nom de domaine internationalisé, l'implémentation DOIT (MUST) convertir toute U-étiquette [IDNA-DEFS] dans le nom de domaine en une A-étiquette avant de vérifier le nom de domaine. Conformément à [IDNA-PROTO], les A-étiquettes DOIVENT (MUST) être comparées comme ASCII insensible à la casse. Chaque étiquette DOIT (MUST) correspondre pour qu'elle soit considérée comme une correspondance, à moins d'être complétée par les règles de vérification des étiquettes wildcard (Section 6.4.3 ; cependant, voir aussi la Section 7.2 concernant les wildcards dans les noms de domaine internationalisés).

6.4.3. Vérification des certificats wildcard (Checking of Wildcard Certificates)

Un client employant les règles de cette spécification PEUT (MAY) faire correspondre un identifiant de référence à un identifiant présenté dont la partie nom de domaine DNS contient le caractère générique '*' comme partie ou totalité d'une étiquette (selon la description des étiquettes et des noms de domaine dans [DNS-CONCEPTS]).

Pour des informations sur les caractéristiques de sécurité des certificats wildcard, voir la Section 7.2.

Si un client fait correspondre un identifiant de référence à un identifiant présenté dont la partie nom de domaine DNS contient le caractère générique '*', les règles suivantes s'appliquent :

Le client NE DEVRAIT PAS (SHOULD NOT) tenter de faire correspondre un identifiant présenté dans lequel le caractère générique constitue une étiquette autre que l'étiquette la plus à gauche (par exemple, ne pas correspondre bar.*.example.net).
Si le caractère générique est le seul caractère de l'étiquette la plus à gauche de l'identifiant présenté, le client NE DEVRAIT PAS (SHOULD NOT) correspondre à autre chose que l'étiquette la plus à gauche de l'identifiant de référence (par exemple, *.example.com correspondrait à foo.example.com mais pas à bar.foo.example.com ou example.com).
Le client PEUT (MAY) correspondre à un identifiant présenté dans lequel le caractère générique n'est pas le seul caractère de l'étiquette (par exemple, baz*.example.net et baz.example.net et bz.example.net seraient considérés comme correspondant à baz1.example.net, foobaz.example.net, et buzz.example.net, respectivement). Cependant, le client NE DEVRAIT PAS (SHOULD NOT) tenter de faire correspondre un identifiant présenté où le caractère générique est intégré dans une A-étiquette ou U-étiquette [IDNA-DEFS] d'un nom de domaine internationalisé [IDNA-PROTO].

6.4.4. Vérification des Common Names (Checking of Common Names)

Comme noté, un client NE DOIT PAS (MUST NOT) chercher une correspondance avec un identifiant de référence CN-ID si un identifiant présenté contient un DNS-ID, SRV-ID, URI-ID, ou un type d'identifiant spécifique à l'application supporté par le client.

Par conséquent, si et seulement si l'identifiant présenté ne contient pas de DNS-ID, SRV-ID, URI-ID, ou de type d'identifiant spécifique à l'application supporté par le client, le client PEUT (MAY) en dernier ressort vérifier la chaîne trouvée dans le champ Common Name du champ Subject (c'est-à-dire, le CN-ID) si elle correspond au format d'un nom de domaine DNS complet. Si le client choisit de comparer un identifiant de référence de type CN-ID avec cette chaîne, il DOIT (MUST) suivre les règles de comparaison pour la partie nom de domaine DNS d'un identifiant de type DNS-ID, SRV-ID, ou URI-ID, comme décrit dans les Sections 6.4.1, 6.4.2, et 6.4.3.

6.5. Correspondance de la partie type de service d'application (Matching the Application Service Type Portion)

Si le client vérifie un identifiant de type SRV-ID et URI-ID, il DOIT (MUST) vérifier la partie type de service d'application de l'identifiant ainsi que la partie nom de domaine DNS. Le client fait cela en divisant l'identifiant en une partie nom de domaine DNS et une partie type de service d'application (comme recommandé à la Section 6.3), puis en vérifiant la partie nom de domaine DNS (comme décrit à la Section 6.4) et la partie type de service d'application (comme décrit dans les sous-sections suivantes).

Note d'implémentation : Un identifiant de type SRV-ID ou URI-ID fournit une partie type de service d'application à vérifier, mais cette partie est combinée uniquement avec la partie nom de domaine DNS du SRV-ID ou URI-ID lui-même. Par exemple, si la liste d'identifiants de référence d'un client contient un SRV-ID de "_xmpp-client.im.example.org" et un DNS-ID de "apps.example.net", le client vérifierait (a) la combinaison d'un type de service d'application de "xmpp-client" et d'un nom de domaine DNS de "im.example.org" et (b) la combinaison d'un nom de domaine DNS de "apps.example.net" ; cependant, le client ne vérifierait pas (c) la combinaison d'un type de service d'application de "xmpp-client" et d'un nom de domaine DNS de "apps.example.net" car il n'a pas de SRV-ID de "_xmpp-client.apps.example.net" dans sa liste d'identifiants de référence.

6.5.1. SRV-ID

La partie nom de service d'un SRV-ID (par exemple, "imaps") DOIT (MUST) être mise en correspondance de manière insensible à la casse, conformément à [DNS-SRV]. Notez que le caractère "_" est ajouté au début des identifiants de service dans les enregistrements DNS SRV et les SRV-IDs (conformément à [SRVNAME]) et n'a pas besoin d'être inclus dans la comparaison.

6.5.2. URI-ID

La partie nom de schéma d'un URI-ID (par exemple, "sip") DOIT (MUST) être mise en correspondance de manière insensible à la casse, conformément à [URI]. Notez que le caractère ":" est un séparateur entre le nom de schéma et le reste de l'URI et n'a pas besoin d'être inclus dans la comparaison.

6.6. Résultat (Outcome)

Le résultat du processus de correspondance sera l'un des cas suivants.

6.6.1. Cas #1 : Correspondance trouvée (Case #1: Match Found)

Si le client a trouvé un identifiant présenté qui correspond à un identifiant de référence, alors la vérification de l'identité du service a réussi. Dans ce cas, le client DOIT (MUST) utiliser l'identifiant de référence correspondant comme l'identité authentifiée du service d'application.

6.6.2. Cas #2 : Aucune correspondance trouvée, certificat épinglé (Case #2: No Match Found, Pinned Certificate)

Si le client n'a pas trouvé d'identifiant présenté correspondant à l'un des identifiants de référence mais que le client a précédemment épinglé le certificat du service d'application à l'un des identifiants de référence dans la liste construite pour cette tentative de communication ("épinglage" est décrit à la Section 1.8) et que le certificat présenté correspond au certificat épinglé (y compris le contexte décrit à la Section 7.1), alors la vérification de l'identité du service a réussi.

6.6.3. Cas #3 : Aucune correspondance trouvée, pas de certificat épinglé (Case #3: No Match Found, No Pinned Certificate)

Si le client n'a pas trouvé d'identifiant présenté correspondant à l'un des identifiants de référence et que le client n'a pas précédemment épinglé le certificat à l'un des identifiants de référence dans la liste construite pour cette tentative de communication, alors le client DOIT (MUST) procéder comme décrit à la Section 6.6.4.

6.6.4. Repli (Fallback)

Si le client est un client interactif directement contrôlé par un utilisateur humain, il DEVRAIT (SHOULD) informer l'utilisateur de la non-correspondance d'identité et peut terminer automatiquement la tentative de communication avec une erreur de mauvais certificat. Ce comportement est préférable car il peut empêcher un utilisateur de contourner par inadvertance les protections de sécurité dans des situations hostiles.

Avertissement de sécurité : Certains clients interactifs donnent aux utilisateurs avancés la possibilité de procéder à l'acceptation malgré la non-correspondance de l'identité, "épinglant" ainsi effectivement le certificat à l'un des identifiants de référence dans la liste que le client a construite pour cette tentative de communication. Bien qu'un tel comportement puisse être approprié dans certaines circonstances spécialisées, il devrait généralement être exposé uniquement aux utilisateurs avancés ; même alors, il doit être traité avec une extrême prudence, par exemple en encourageant d'abord même un utilisateur avancé à terminer la tentative de communication, en forçant l'utilisateur à voir le chemin de certification complet si l'utilisateur choisit de continuer quand même, et seulement alors en permettant à l'utilisateur d'épingler le certificat (temporairement ou de manière permanente, au choix de l'utilisateur).

Sinon, si le client est une application automatisée non directement contrôlée par un utilisateur humain, il DEVRAIT (SHOULD) terminer la tentative de communication avec une erreur de mauvais certificat et enregistrer l'erreur de manière appropriée. L'application automatisée PEUT (MAY) fournir un paramètre de configuration pour désactiver ce comportement, mais DOIT (MUST) activer ce comportement par défaut.