5. Cas d'usage et exigences TLSA et DANE (TLSA and DANE Use Cases and Requirements)

Les différents types d'associations de certificats définis dans TLSA correspondent à diverses sections de [RFC6394]. Les cas d'usage de la section 3 de [RFC6394] sont couverts dans ce document comme suit :

• 3.1 Contraintes CA -- Implémenté en utilisant l'utilisation de certificat 0.

• 3.2 Contraintes de certificat -- Implémenté en utilisant l'utilisation de certificat 1.

• 3.3 Assertion d'ancre de confiance et certificats émis par le domaine -- Implémentés en utilisant respectivement les utilisations de certificat 2 et 3.

Les exigences de la section 4 de [RFC6394] sont couvertes dans ce document comme suit :

Ports multiples (Multiple Ports) -- Les enregistrements TLSA pour différents services d'application s'exécutant sur un seul hôte peuvent être distingués par le nom de service et le numéro de port préfixés au nom d'hôte (voir section 3).

Pas de rétrogradation (No Downgrade) -- La section 4 spécifie les conditions dans lesquelles un client peut traiter et agir sur les enregistrements TLSA. Plus précisément, si le statut DNSSEC pour l'ensemble d'enregistrements de ressources TLSA est déterminé comme étant faux, la connexion TLS (si démarrée) échouera.

Encapsulation -- L'encapsulation est couverte dans la sémantique de réponse TLSA.

Prévisibilité (Predictability) -- Les annexes de cette spécification fournissent des considérations opérationnelles et des conseils de mise en œuvre afin de permettre aux développeurs d'applications de former une interprétation cohérente du comportement client recommandé.

Sécurité opportuniste (Opportunistic Security) -- Si un client conforme à cette spécification peut déterminer de manière fiable la présence d'un enregistrement TLSA, il tentera d'utiliser cette information. Inversement, si un client peut déterminer de manière fiable l'absence de tout enregistrement TLSA, il reviendra au traitement de TLS de manière normale. Ceci est discuté dans la section 4.

Combinaison -- Plusieurs enregistrements TLSA peuvent être publiés pour un nom d'hôte donné, permettant ainsi au client de construire plusieurs associations de certificats TLSA qui reflètent différentes assertions. Aucun support n'est fourni pour combiner deux associations de certificats TLSA en une seule opération.

Rotation (Roll-over) -- Les enregistrements TLSA sont traités de manière normale dans le cadre du protocole DNS, y compris l'expiration du TTL des enregistrements. Cela garantit que les clients ne s'accrocheront pas aux assertions faites par des enregistrements TLSA expirés et pourront passer de l'utilisation d'une clé publique ou d'une utilisation de certificat à une autre.

Gestion simple des clés (Simple Key Management) -- Le sélecteur SubjectPublicKeyInfo dans l'enregistrement TLSA fournit un mode qui permet à un détenteur de domaine de ne maintenir qu'une seule paire de clés publique/privée de longue durée sans avoir besoin de gérer des certificats. L'annexe A décrit l'utilité et les inconvénients potentiels de l'utilisation de ce mode.

Dépendances minimales (Minimal Dependencies) -- Cette spécification s'appuie sur DNSSEC pour protéger l'authenticité de l'origine et l'intégrité de l'ensemble d'enregistrements de ressources TLSA. De plus, si la validation DNSSEC n'est pas effectuée sur le système qui souhaite utiliser les liaisons de certificat TLSA, cette spécification exige que le "dernier kilomètre" soit sur un transport sécurisé. Il n'y a pas d'autres dépendances de déploiement pour cette approche.

Options minimales (Minimal Options) -- Les modes de fonctionnement correspondent précisément aux cas d'usage et aux exigences DANE. L'utilisation de DNSSEC est obligatoire en ce sens que cette spécification encourage les applications à utiliser uniquement les enregistrements TLSA qui sont validés.

Caractères génériques (Wildcards) -- Les caractères génériques sont couverts de manière limitée dans la syntaxe de requête TLSA ; voir l'annexe A.

Redirection -- La redirection est couverte dans la syntaxe de requête TLSA ; voir l'annexe A.