Premier champ d’un enregistrement TLSA.
Source : DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), récupérée le 2026-10-20. Licence des données : CC0-1.0. TLSA Certificate Usages
Remarques sur les entrées notables
PKIX-TA (0) exige une chaîne menant à une AC publique et la correspondance de cette AC avec l’enregistrement TLSA ; la RFC 7672 le déconseille pour SMTP.
Les usages 0 et 1 ajoutent une contrainte DNS à la validation ordinaire de la PKI du Web. Pour SMTP entre serveurs de messagerie, la RFC 7672 §3.1.3 indique que les enregistrements TLSA NE DEVRAIENT PAS les utiliser : un attaquant capable de falsifier le DNS peut de toute façon les remplacer, et les serveurs de messagerie ne partagent aucune liste commune d’AC de confiance.
DANE-TA (2) épingle dans le DNS une ancre de confiance, généralement l’AC émettrice.
Avec l’usage 2, la chaîne du serveur doit mener au certificat ou à la clé indiqués dans l’enregistrement TLSA, sans qu’il s’agisse forcément d’une AC publique. La RFC 7672 §3.1.2 exige que le serveur envoie l’ancre de confiance dans sa chaîne lorsque l’enregistrement correspond à une clé plutôt qu’à un certificat complet.
DANE-EE (3) épingle dans le DNS le certificat ou la clé du serveur lui-même ; les noms et l’expiration du certificat ne sont pas vérifiés.
Avec l’usage 3, l’enregistrement TLSA suffit à lier la clé au nom : selon la RFC 7672 §3.1.1, le serveur est authentifié même si aucun nom du certificat ne correspond, et la date d’expiration du certificat DOIT être ignorée. L’enregistrement courant « 3 1 1 » (DANE-EE, SPKI, SHA-256) survit aux renouvellements de certificat tant que la clé reste la même.