2. L'enregistrement de ressource TLSA (The TLSA Resource Record)

L'enregistrement de ressource DNS TLSA (RR) est utilisé pour associer un certificat de serveur TLS ou une clé publique au nom de domaine où l'enregistrement est trouvé, formant ainsi une "association de certificat TLSA". La sémantique de l'interprétation du RR TLSA est donnée plus loin dans ce document.

La valeur de type pour le type RR TLSA est définie dans la section 7.1.

Le RR TLSA est indépendant de la classe.

Le RR TLSA n'a pas d'exigences spéciales de durée de vie (TTL).

2.1. Format de transmission RDATA TLSA (TLSA RDATA Wire Format)

Le RDATA pour un RR TLSA se compose d'un champ d'utilisation de certificat d'un octet, d'un champ de sélecteur d'un octet, d'un champ de type de correspondance d'un octet et du champ de données d'association de certificat.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Usage Cert.  |   Sélecteur   | Type Corresp. |               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
/                                                               /
/                 Données d'association certificat              /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1. Le champ d'utilisation du certificat (The Certificate Usage Field)

Une valeur d'un octet, appelée "utilisation du certificat", spécifie l'association fournie qui sera utilisée pour correspondre au certificat présenté dans la poignée de main TLS. Cette valeur est définie dans un nouveau registre IANA (voir section 7.2) afin de faciliter l'ajout d'utilisations de certificat supplémentaires à l'avenir. Les utilisations de certificat définies dans ce document sont :

0 -- Contrainte CA: L'utilisation de certificat 0 est utilisée pour spécifier un certificat CA, ou la clé publique d'un tel certificat, qui DOIT être trouvé dans l'un des chemins de certification PKIX pour le certificat d'entité finale donné par le serveur dans TLS. Cette utilisation de certificat est parfois appelée "contrainte CA" car elle limite quelle CA peut être utilisée pour émettre des certificats pour un service donné sur un hôte. Le certificat présenté DOIT passer la validation du chemin de certification PKIX, et un certificat CA qui correspond à l'enregistrement TLSA DOIT être inclus dans le cadre d'un chemin de certification valide. Parce que cette utilisation de certificat autorise à la fois les ancres de confiance et les certificats CA, le certificat peut avoir ou non l'extension basicConstraints présente.

1 -- Contrainte de certificat de service: L'utilisation de certificat 1 est utilisée pour spécifier un certificat d'entité finale, ou la clé publique d'un tel certificat, qui DOIT correspondre au certificat d'entité finale donné par le serveur dans TLS. Cette utilisation de certificat est parfois appelée "contrainte de certificat de service" car elle limite quel certificat d'entité finale peut être utilisé par un service donné sur un hôte. Le certificat cible DOIT passer la validation du chemin de certification PKIX et DOIT correspondre à l'enregistrement TLSA.

2 -- Assertion d'ancre de confiance: L'utilisation de certificat 2 est utilisée pour spécifier un certificat, ou la clé publique d'un tel certificat, qui DOIT être utilisé comme ancre de confiance lors de la validation du certificat d'entité finale donné par le serveur dans TLS. Cette utilisation de certificat est parfois appelée "assertion d'ancre de confiance" et permet à un administrateur de nom de domaine de spécifier une nouvelle ancre de confiance -- par exemple, si le domaine émet ses propres certificats sous sa propre CA qui n'est pas censée être dans la collection d'ancres de confiance des utilisateurs finaux. Le certificat cible DOIT passer la validation du chemin de certification PKIX, tout certificat correspondant à l'enregistrement TLSA étant considéré comme une ancre de confiance pour cette validation de chemin de certification.

3 -- Certificat émis par le domaine: L'utilisation de certificat 3 est utilisée pour spécifier un certificat, ou la clé publique d'un tel certificat, qui DOIT correspondre au certificat d'entité finale donné par le serveur dans TLS. Cette utilisation de certificat est parfois appelée "certificat émis par le domaine" car elle permet à un administrateur de nom de domaine d'émettre des certificats pour un domaine sans impliquer une CA tierce. Le certificat cible DOIT correspondre à l'enregistrement TLSA. La différence entre l'utilisation de certificat 1 et l'utilisation de certificat 3 est que l'utilisation de certificat 1 exige que le certificat passe la validation PKIX, mais la validation PKIX n'est pas testée pour l'utilisation de certificat 3.

Les utilisations de certificat définies dans ce document s'appliquent explicitement uniquement aux certificats au format PKIX en encodage DER [X.690]. Si TLS autorise d'autres formats ultérieurement, ou si des extensions à ce RRtype sont effectuées qui acceptent d'autres formats pour les certificats, ces certificats auront besoin de leurs propres valeurs d'utilisation de certificat.

2.1.2. Le champ sélecteur (The Selector Field)

Une valeur d'un octet, appelée "sélecteur", spécifie quelle partie du certificat TLS présenté par le serveur sera comparée aux données d'association. Cette valeur est définie dans un nouveau registre IANA (voir section 7.3). Les sélecteurs définis dans ce document sont :

0 -- Certificat complet: la structure binaire du certificat telle que définie dans [RFC5280]

1 -- SubjectPublicKeyInfo: structure binaire encodée DER telle que définie dans [RFC5280]

(Notez que l'utilisation de "sélecteur" dans ce document est complètement sans rapport avec l'utilisation de "sélecteur" dans DomainKeys Identified Mail (DKIM) [RFC6376].)

2.1.3. Le champ de type de correspondance (The Matching Type Field)

Une valeur d'un octet, appelée "type de correspondance", spécifie comment l'association de certificat est présentée. Cette valeur est définie dans un nouveau registre IANA (voir section 7.4). Les types définis dans ce document sont :

0 -- Correspondance exacte sur le contenu sélectionné

1 -- Hachage SHA-256 du contenu sélectionné [RFC6234]

2 -- Hachage SHA-512 du contenu sélectionné [RFC6234]

Si le type de correspondance de l'enregistrement TLSA est un hachage, le fait que l'enregistrement utilise le même algorithme de hachage que celui utilisé dans la signature du certificat (si possible) aidera les clients qui prennent en charge un petit nombre d'algorithmes de hachage.

2.1.4. Le champ de données d'association de certificat (The Certificate Association Data Field)

Ce champ spécifie les "données d'association de certificat" à faire correspondre. Ces octets sont soit des données brutes (c'est-à-dire le certificat complet ou son SubjectPublicKeyInfo, selon le sélecteur) pour le type de correspondance 0, soit le hachage des données brutes pour les types de correspondance 1 et 2. Les données font référence au certificat dans l'association, et non à l'objet certificat ASN.1 TLS.

2.2. Format de présentation RR TLSA (TLSA RR Presentation Format)

Le format de présentation de la partie RDATA (tel que défini dans [RFC1035]) est le suivant :

• Le champ d'utilisation du certificat DOIT être représenté comme un entier non signé de 8 bits.
• Le champ sélecteur DOIT être représenté comme un entier non signé de 8 bits.
• Le champ de type de correspondance DOIT être représenté comme un entier non signé de 8 bits.
• Le champ de données d'association de certificat DOIT être représenté comme une chaîne de caractères hexadécimaux. Les espaces sont autorisés dans la chaîne de caractères hexadécimaux, comme décrit dans [RFC1035].

2.3. Exemples de RR TLSA (TLSA RR Examples)

Dans les exemples suivants, le nom de domaine est formé en utilisant les règles de la section 3.

Un exemple d'association hachée (SHA-256) d'un certificat CA PKIX :

_443._tcp.www.example.com. IN TLSA (
   0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
         7983a1d16e8a410e4561cb106618e971 )

Un exemple d'association de clé publique de sujet hachée (SHA-512) d'un certificat d'entité finale PKIX :

_443._tcp.www.example.com. IN TLSA (
   1 1 2 92003ba34942dc74152e2f2c408d29ec
         a5a520e7f2e06bb944f4dca346baf63c
         1b177615d466f6c4b71c216a50292bd5
         8c9ebdd2f74e38fe51ffd48c43326cbc )

Un exemple d'association de certificat complet d'un certificat d'entité finale PKIX :

_443._tcp.www.example.com. IN TLSA (
   3 0 0 30820307308201efa003020102020... )