1. Introduction

1. Introduction

1.1. Motivation

Une grande partie du visage visible d'Internet se compose de services qui utilisent une architecture client-serveur dans laquelle un client interactif ou automatisé communique avec un service d'application (application service) afin de récupérer ou télécharger des informations, de communiquer avec d'autres entités, ou d'accéder à un réseau de services plus large. Lorsque le client communique avec un service d'application en utilisant le protocole TLS (Transport Layer Security) [TLS] ou DTLS (Datagram Transport Layer Security) [DTLS], il fait référence à une certaine notion de l'identité du serveur (par exemple, "le site web example.com") tout en tentant d'établir une communication sécurisée. De même, lors de la négociation TLS, le serveur présente une notion de son identité de service, sous la forme d'un certificat à clé publique émis par une autorité de certification (CA) dans le contexte d'une infrastructure à clé publique Internet utilisant X.509 [PKIX]. De manière informelle, nous pouvons penser à ces identités comme à l'"identité de référence" (reference identity) du client et à l'"identité présentée" (presented identity) du serveur (ces idées approximatives sont définies plus précisément plus loin dans ce document via le concept d'identifiants particuliers). En général, un client doit vérifier que l'identité présentée par le serveur correspond à son identité de référence, afin de pouvoir authentifier la communication.

De nombreuses technologies applicatives suivent le modèle décrit. De tels protocoles ont traditionnellement spécifié leurs propres règles pour représenter et vérifier l'identité du service d'application. Malheureusement, cette divergence d'approches a causé une certaine confusion parmi les autorités de certification, les développeurs d'applications et les concepteurs de protocoles.

Par exemple, divers protocoles d'application représentent l'identité de service de différentes manières (par exemple, certains utilisent des noms de domaine DNS comme identifiants génériques d'infrastructure à clé publique (PKI), tandis que d'autres définissent des identifiants spécifiques à l'application), et de nombreux protocoles ne fournissent pas de règles claires pour gérer les noms de domaine internationalisés, les noms de domaine wildcard (avec caractères génériques), ou les identités multiples par certificat. Cela rend difficile pour les autorités de certification d'émettre des certificats qui fonctionnent de manière cohérente dans une large gamme d'applications, pour les développeurs de logiciels de créer un code de vérification d'adresse cohérent, et pour les concepteurs de protocoles de décider comment gérer la vérification d'identité dans leurs définitions de protocole.

Si un ensemble unique et unifié de règles pour représenter et vérifier l'identité de service d'application existait, cela pourrait réduire la confusion parmi les divers participants et également améliorer la qualité des logiciels en permettant aux implémentations de partager un code commun pour l'authentification plutôt que d'exiger que chaque application réimplémente la logique de vérification de manière ad hoc.

1.2. Public (Audience)

Le public visé par ce document comprend :

• Les concepteurs de protocoles d'application spécifiant des protocoles qui fonctionnent sur TLS.

• Les développeurs de logiciels d'application implémentant de tels protocoles.

• Les fournisseurs de services déployant de tels services.

• Les autorités de certification émettant des certificats pour une utilisation dans de tels services.

1.3. Comment lire ce document (How to Read This Document)

Ce document est écrit principalement pour être réutilisé par les concepteurs de protocoles d'application ; ainsi, la plupart du langage des "Exigences" peut être interprété comme "une spécification de protocole d'application qui réutilise ce document doit inclure ou référencer les exigences suivantes".

Pour les développeurs de logiciels d'application, nous fournissons des sections distinctes couvrant la vérification de l'identité du serveur (Section 6) et les considérations de sécurité associées (Section 7).

Pour les fournisseurs de services et les autorités de certification, nous fournissons des sections distinctes couvrant la représentation de l'identité du serveur (Section 4) et la demande de certificats serveur (Section 5).

1.4. Applicabilité (Applicability)

Ce document ne vise pas à définir une politique d'utilisation générale pour tous les certificats PKIX. Au lieu de cela, sa portée est limitée aux clients TLS utilisant des certificats X.509 (PKIX) pour authentifier les serveurs. Il ne régit pas l'authentification dans le cadre de S/MIME, IPsec, ou d'autres protocoles (sauf indication explicite dans la spécification d'un tel protocole qui réutilise ce document). Bien que les concepts définis dans ce document puissent être utiles dans d'autres contextes, de telles extensions sont hors de portée pour ce document.

Ce document est principalement destiné à être adopté par de nouveaux protocoles d'application, bien qu'il soit prévu que les protocoles d'application existants (tels que ceux listés à l'Annexe B) puissent migrer progressivement vers l'utilisation de ce document.

1.5. Aperçu des recommandations (Overview of Recommendations)

Nous résumons les recommandations de ce document dans le tableau suivant ; les détails sont fournis dans les sections ci-dessous.

Entité	Rôle	Recommandation
Concepteur de protocole	Spécifier	Référencer ce document si possible ; définir des types d'identifiants spécifiques.
Dév. logiciel d'app	Implémenter la vérification	Suivre les alros de la Section 6 ; traiter les wildcards avec soin ; supporter le "pinning" (remplacement utilisateur).
Fournisseur de service	Déployer le service	Obtenir des certs avec DNS-ID ; inclure SRV-ID ou URI-ID si nécessaire.
Autorité de cert.	Émettre le certificat	Inclure DNS-ID dans subjectAltName ; inclure Common Name dans le Sujet uniquement pour la rétrocompatibilité.

1.6. Généralisation à partir des technologies actuelles (Generalization from Current Technologies)

Les recommandations spécifiées dans ce document ont été généralisées à partir des règles de vérification d'identité contenues dans diverses spécifications de protocoles d'application (y compris celles listées à l'Annexe B). Notre approche générale a été que nous devrions suivre les pratiques existantes à moins qu'il n'y ait des raisons impérieuses de ne pas le faire (par exemple, pour combler des failles de sécurité identifiées dans les spécifications précédentes). Après une analyse détaillée des pratiques actuelles et une consultation approfondie avec la communauté de développement de protocoles d'application, les auteurs estiment que les règles spécifiées dans ce document sont substantiellement cohérentes avec la majorité de l'utilisation actuelle déployée. Lorsque nous nous sommes efforcés de maximiser la compatibilité avec l'utilisation actuelle, comme l'utilisation du "Common Name" X.509 pour représenter les identités de serveur, nous avons parfois recommandé de resserrer les restrictions existantes pour des raisons de sécurité (par exemple, pour protéger contre les attaques associées aux certificats wildcard).

1.7. Portée (Scope)

1.7.1. Dans le périmètre (In Scope)

Cette spécification s'applique aux implémentations logicielles et aux déploiements où toutes les conditions suivantes s'appliquent :

1. Un client cherche à communiquer avec un service identifié par un nom de domaine DNS.

2. Le client utilise le DNS pour résoudre le nom de domaine en une adresse réseau (par exemple, une adresse IPv4 ou IPv6).

3. Le client communique avec le serveur en utilisant le protocole TLS (Transport Layer Security) [TLS] ou DTLS (Datagram Transport Layer Security) [DTLS] et leurs extensions (par exemple, l'extension Server Name Indication de [TLS-EXT]).

4. Le serveur présente son identité au client sous la forme d'un certificat à clé publique basé sur X.509 [PKIX].

5. Le client utilise le certificat présenté par le serveur au cours de la vérification de l'identité du serveur.

1.7.2. Hors périmètre (Out of Scope)

Les sujets suivants sont hors de portée pour ce document :

• Authentification client ou serveur autre que l'authentification de service d'application (par exemple, authentification de client, ou authentification dans des protocoles basés sur XML où les pairs peuvent agir à la fois comme client et serveur).

• Certificats dans le contexte de profils PKI autres que PKIX (par exemple, OpenPGP [OPENPGP]).

• Authentification de services non identifiés par des noms de domaine DNS (par exemple, services identifiés par des adresses IP telles que des adresses [IP] ou [IPv6], ou par d'autres types d'identifiants tels que ceux utilisés dans [NAPTR]).

• Résolution de noms de domaine DNS en adresses IP (bien que ce soit une condition préalable nécessaire à l'opération de ce document).

• Mécanismes de vérification de la validité d'un certificat (par exemple, contre une liste de révocation de certificats [PKIX] ou via le protocole OCSP [OCSP]).

• Décisions d'autorisation (par exemple, si un client doit faire confiance à une autorité de certification particulière ou se connecter à un serveur particulier).

• Comment vérifier une identité si le certificat ne contient aucun type d'identifiant connu (par exemple, uniquement des types d'identifiants propriétaires que le client ne comprend pas).

• Détails de l'interface utilisateur (par exemple, [WSC-UI]).

1.8. Terminologie (Terminology)

Parce que de nombreux concepts liés à l'"identité" sont souvent trop vagues pour être actionnables dans les protocoles d'application, nous définissons un ensemble de termes plus concrets à utiliser dans cette spécification.

Service d'application (application service) : Un service sur Internet avec lequel un client interactif ou automatisé se connecte afin de récupérer ou télécharger des informations, de communiquer avec d'autres entités, ou de se connecter à un réseau de services plus large.

Fournisseur de service d'application (application service provider) : Une entité qui héberge et gère un service d'application particulier.

Type de service d'application (application service type) : Un identifiant qui distingue le protocole d'application spécifique ou la configuration de protocole qui distingue un service d'application d'un autre. Les valeurs possibles incluent un nom de service DNS SRV (par exemple, "ldap", "imap", "xmpp-client") ou un nom de schéma URI (par exemple, "http", "sip", "acap").

Type d'attribut (attribute type) : L'identifiant d'objet pour le type d'information détenu dans un attribut X.500 [X.500]. Dans le contexte de ce document, cela fait référence à des identifiants d'objet particuliers (par exemple, CN) utilisés dans des Assertions de Valeur d'Attribut [X.501].

Assertion de Valeur d'Attribut (Attribute Value Assertion - AVA) : Une assertion d'un type d'attribut et d'une valeur correspondante [X.501].

Autorité de certification (certification authority - CA) : Une entité qui émet des certificats (par exemple, "Example CA").

CN-ID : Un attribut Common Name (c'est-à-dire un attribut de type 2.5.4.3 [X.520]) dans le champ Subject d'un certificat [PKIX] qui contient une chaîne correspondant à la syntaxe d'un nom de domaine DNS.

Common Name : Un attribut (c'est-à-dire un attribut de type 2.5.4.3 [X.520]) dans le champ Subject d'un certificat [PKIX]. Pour des raisons historiques, il est souvent nécessaire de vérifier le Common Name en tant qu'identifiant, mais il est courant pour les autorités de certification d'y placer non seulement des noms de domaine DNS mais aussi d'autres chaînes (par exemple, "John Doe" ou "Simple Authority"). Nous devons donc distinguer le Common Name en tant qu'identifiant (voir CN-ID) des autres formes de Common Name.

DNS-ID : Un identifiant de type dNSName dans l'extension subjectAltName (tel que défini dans [PKIX]).

Identifiant (identifier) : Une chaîne utilisée par un client ou un serveur pour identifier une entité d'application spécifique.

Type d'identifiant (identifier type) : Une classe spécifique d'identifiants (par exemple, DNS-ID, CN-ID, SRV-ID, ou URI-ID).

PKIX : Infrastructure à clé publique utilisant X.509 (Public Key Infrastructure using X.509), telle que définie dans [PKIX].

Identité présentée (presented identity) : Un identifiant présenté par un serveur à un client dans un certificat PKIX.

Identité de référence (reference identity) : Un identifiant qu'un client s'attend à ce qu'un serveur présente dans un certificat.

Domaine source (source domain) : Le nom de domaine DNS complet [DNS-CONCEPTS] qu'un client extrait de son entrée reçue (entrée utilisateur, configuration, etc.). Le domaine source est l'identifiant principal avec lequel une connexion sécurisée est établie.

SRV-ID : Un identifiant de type otherName dans l'extension subjectAltName, sous la forme de SRVName (tel que défini dans [SRVNAME]).

URI-ID : Un identifiant de type uniformResourceIdentifier dans l'extension subjectAltName (tel que défini dans [PKIX]).

Certificat wildcard (wildcard certificate) : Un certificat contenant au moins un identifiant avec un caractère générique ('*').

Épinglage (pinning) : L'action d'un utilisateur d'associer ou d'"épingler" un certificat spécifique à un service particulier, généralement lors de la première connexion ou après un examen manuel par l'utilisateur suite à un échec de validation de certificat.

Les mots-clés "DOIT" (MUST), "NE DOIT PAS" (MUST NOT), "REQUIS" (REQUIRED), "DEVRA" (SHALL), "NE DEVRA PAS" (SHALL NOT), "DEVRAIT" (SHOULD), "NE DEVRAIT PAS" (SHOULD NOT), "RECOMMANDÉ" (RECOMMENDED), "PEUT" (MAY), et "OPTIONNEL" (OPTIONAL) dans ce document doivent être interprétés comme décrit dans [KEYWORDS].