6.1. Validation du nom d'hôte

Les auteurs d'applications doivent noter que certaines implémentations TLS ne valident pas les noms d'hôte. Si l'implémentation TLS qu'ils utilisent ne valide pas les noms d'hôte, les auteurs pourraient avoir besoin d'écrire leur propre code de validation ou d'envisager d'utiliser une implémentation TLS différente.

Il est noté que les exigences concernant la validation du nom d'hôte (et, en général, la liaison entre la couche TLS et le protocole qui s'exécute au-dessus) varient entre différents protocoles. Pour HTTPS, ces exigences sont définies par la Section 3 de [RFC2818].

Les lecteurs sont référés à [RFC6125] pour plus de détails concernant la validation générique du nom d'hôte dans le contexte TLS. De plus, cette RFC contient une longue liste de protocoles exemples, dont certains implémentent une politique très différente de HTTPS.

Si le nom d'hôte est découvert indirectement et de manière non sécurisée (par exemple, par une requête DNS non sécurisée pour un enregistrement MX ou SRV), il NE DEVRAIT PAS être utilisé comme identifiant de référence [RFC6125] même lorsqu'il correspond au certificat présenté. Cette réserve ne s'applique pas si le nom d'hôte est découvert de manière sécurisée (pour plus de discussion, voir [DANE-SRV] et [DANE-SMTP]).

La validation du nom d'hôte s'applique généralement uniquement au certificat "entité finale" feuille. Naturellement, afin d'assurer une authentification appropriée dans le contexte de la PKI, les clients applicatifs doivent vérifier le chemin de certification entier conformément à [RFC5280] (voir aussi [RFC6125]).