7. Considérations de sécurité (Security Considerations)

7.1. Certificats épinglés (Pinned Certificates)

Comme défini à la Section 1.8, un certificat est dit "épinglé" à un nom de domaine DNS si l'utilisateur a explicitement choisi d'associer le certificat du service à ce nom de domaine DNS malgré le fait que le certificat contient d'autres noms de domaine DNS (par exemple, un utilisateur a explicitement approuvé "apps.example.net" comme un domaine associé au domaine source de "example.com"). L'association de nom mise en cache DOIT (MUST) tenir compte à la fois du certificat présenté et du contexte dans lequel il a été accepté ou configuré (où "contexte" comprend la chaîne de certificats du certificat présenté à l'ancre de confiance, le domaine source, le type de service d'application, et le domaine dérivé et le numéro de port du service, ainsi que toute autre information pertinente fournie par l'utilisateur ou associée par le client).

7.2. Certificats wildcard (Wildcard Certificates)

Ce document stipule que le caractère générique '*' NE DEVRAIT PAS (SHOULD NOT) être inclus dans les identifiants présentés mais PEUT (MAY) être vérifié par les clients d'application (principalement pour la rétrocompatibilité avec l'infrastructure déployée). En conséquence, les règles fournies dans ce document sont plus restrictives que les règles de nombreuses technologies d'application existantes (telles que celles extraites à l'Annexe B). Plusieurs considérations de sécurité justifient le resserrement des règles :

Les certificats wildcard portent garant pour n'importe quel nom d'hôte et tous les noms d'hôtes dans leur domaine. Cela peut être pratique pour les administrateurs mais introduit également le risque de se porter garant pour des hôtes malveillants ou défectueux. Voir par exemple [Defeating-SSL] (commençant à la diapositive 91) et [HTTPSbytes] (diapositives 38-40).
Les spécifications pour les technologies d'application existantes ne sont pas claires ou cohérentes concernant les emplacements autorisés pour le caractère générique, par exemple s'il peut être :
- Uniquement l'étiquette complète la plus à gauche (par exemple, *.example.com)
- Un fragment de l'étiquette la plus à gauche (par exemple, fo*.example.com, f*o.example.com, ou *oo.example.com)
- Tout ou partie d'une étiquette autre que celle la plus à gauche (par exemple, www.*.example.com ou www.foo*.example.com)
- Tout ou partie d'une étiquette identifiant ce qu'on appelle un "suffixe public" (par exemple, *.co.uk ou *.com)
- Inclus plus d'une fois dans une étiquette donnée (par exemple, fbr.example.com)
- Inclus comme tout ou partie de plus d'une étiquette (par exemple, ..example.com)
Ces ambiguïtés sont susceptibles d'introduire des variances exploitables dans le comportement de vérification d'identité parmi les implémentations clientes et de conduire à des algorithmes de vérification d'identité trop complexes et inefficaces.
Il n'existe aucune spécification définissant comment le caractère générique peut être incorporé dans une A-étiquette ou U-étiquette [IDNA-DEFS] d'un nom de domaine internationalisé [IDNA-PROTO] ; par conséquent, il est fortement déconseillé aux implémentations d'inclure ou de tenter de vérifier des caractères génériques intégrés dans une A-étiquette ou U-étiquette d'un nom de domaine internationalisé (par exemple, "xn--kcry6tjko*.example.org"). Notez, cependant, qu'un identifiant de nom de domaine présenté PEUT (MAY) contenir le caractère générique tant que ce caractère occupe l'intégralité de la position de l'étiquette la plus à gauche où toutes les étiquettes restantes sont des étiquettes NR-LDH, des A-étiquettes, ou des U-étiquettes valides (par exemple, "*.xn--kcry6tjko.example.org").

Malgré les considérations de sécurité précédentes, une spécification qui réutilise cette spécification peut légitimement encourager le support continu du caractère générique 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]).

7.3. Noms de domaine internationalisés (Internationalized Domain Names)

Permettre les noms de domaine internationalisés peut conduire à l'inclusion de caractères visuellement similaires (ce qu'on appelle "confusables") dans les certificats ; pour une discussion, voir par exemple [IDNA-DEFS].

7.4. Identifiants multiples (Multiple Identifiers)

Un service d'application donné peut être adressé par plusieurs noms de domaine DNS pour diverses raisons, et un déploiement donné peut servir plusieurs domaines (par exemple, dans des environnements dits d'"hébergement virtuel"). L'utilisation de plusieurs identifiants est gérée comme suit :

Dans l'échange de poignée de main TLS par défaut, le client est incapable d'indiquer le nom de domaine DNS avec lequel il souhaite communiquer, et le serveur TLS ne retourne qu'un seul certificat qui est le sien. Sans extensions à TLS, la solution de contournement typique utilisée pour faciliter le mappage des services d'application à plusieurs noms de domaine DNS est d'intégrer tous les noms de domaine dans un seul certificat.

Une approche plus récente (formalisée dans [TLS-EXT]) consiste pour le client à spécifier le nom de domaine DNS qu'il attend ou désire pour le service en utilisant l'extension TLS "Server Name Indication" (SNI) lors de l'envoi du message client_hello. Le service peut alors retourner le certificat approprié dans son message Certificate, et ce certificat peut représenter un seul nom de domaine DNS.

Afin de s'adapter à la solution de contournement nécessaire avant le développement de l'extension SNI, cette spécification autorise la présence de plusieurs DNS-IDs, SRV-IDs ou URI-IDs dans un certificat ; cependant, elle décourage explicitement les CN-IDs multiples. Bien qu'il serait souhaitable d'interdire complètement les CN-IDs multiples, il y a plusieurs raisons pour lesquelles cette spécification stipule actuellement qu'ils NE DEVRAIENT PAS (SHOULD NOT) (au lieu de NE DOIVENT PAS (MUST NOT)) être inclus :

Au moins une communauté d'intérêt technique importante autorise explicitement les CN-IDs multiples [EV-CERTS].
Au moins une autorité de certification importante est connue pour émettre des certificats contenant plusieurs CN-IDs.
De nombreux fournisseurs de services considèrent souvent nécessaire d'inclure plusieurs CN-IDs dans des environnements d'hébergement virtuel parce qu'au moins un système d'exploitation largement déployé ne supporte pas encore l'extension SNI.

Il est espéré que la recommandation concernant les CN-IDs multiples sera encore resserrée à l'avenir.