Résumé

  • SC101 précise comment une autorité de certification dérive l’Authorization Domain Name, le nom sur lequel elle vérifie le contrôle, à partir du FQDN demandé dans un certificat TLS publiquement reconnu.
  • L’ancienne définition pouvait être lue comme autorisant d’abord la suppression de labels à gauche, puis le suivi d’un CNAME. Cette séquence pouvait déplacer la preuve vers un prestataire sans lui donner le contrôle des sous-domaines du client.
  • La nouvelle section choisit d’abord la méthode de validation, limite les opérations auxquelles cette méthode donne droit et impose de suivre les CNAME avant d’élaguer les labels lorsque les deux opérations sont admises.
  • Jusqu’au 15 novembre 2026, le texte courant permet néanmoins de suivre soit sa nouvelle section 3.2.2.4, soit celle de la v2.2.7. Un dossier probant doit donc conserver le référentiel choisi et tout le trajet jusqu’à l’ADN.

Une date d’effet ne suffit pas à décrire la transition

La version 2.2.9 des TLS Baseline Requirements porte la date du 6 août 2026. Son historique rattache la révision à SC101, « Clarify Authorization Domain Names ». Cela pourrait laisser croire que toute émission postérieure au 6 août utilise nécessairement le nouvel algorithme.

La section concernée dit autre chose. Avant le 15 novembre, une CA peut se conformer à la section 3.2.2.4 du texte courant ou à celle de la v2.2.7. À partir de cette date, la section courante devient obligatoire. Il ne s’agit donc pas d’une tolérance informelle laissée à l’appréciation d’un contrôleur. La solution antérieure est intégrée comme chemin normatif temporaire dans le nouveau document.

Cette architecture produit une phrase trompeusement exacte : « l’émission est conforme à la version courante ». La v2.2.9 est bien courante, mais elle renvoie elle-même à deux façons licites de dériver l’ADN. Sans champ supplémentaire, le lecteur ne sait pas si le moteur a déjà exécuté la nouvelle séquence ou si l’autorité a exercé l’option antérieure.

Le vote ne résout pas cette question d’exécution. La page du scrutin SC0101v2 rapporte 27 voix favorables parmi les émetteurs et quatre parmi les consommateurs de certificats — Apple, Google, Microsoft et Mozilla — sans opposition ni abstention. Les seuils ont été déclarés atteints et le quorum était de 17. Après la discussion du 12 au 19 juin et le vote du 23 au 30 juin, la revue de propriété intellectuelle s’est achevée le 6 août.

Le consensus établit la règle commune. Il ne prouve pas que chaque système de validation, documentation CP/CPS, batterie de tests, nœud de production et méthode d’audit ait basculé le même jour.

L’ADN est la frontière réelle de l’autorisation

Un demandeur présente un nom de domaine pleinement qualifié pour l’inscrire dans un certificat. L’autorité choisit une méthode admise pour vérifier le contrôle. La vérification ne se fait pas nécessairement sur la chaîne exacte demandée : l’Authorization Domain Name peut être obtenu par certaines transformations autorisées.

Cette souplesse évite de répéter une preuve pour chaque hôte quand la politique reconnaît une autorisation plus large. Elle crée aussi un point critique. Un alias DNS décrit une destination technique ; il ne transfère pas automatiquement la maîtrise de toute la hiérarchie de noms située chez le client.

Le texte explicatif de SC101 décrit l’interprétation problématique. À partir d’un FQDN, une CA pouvait être comprise comme autorisée à retirer un ou plusieurs labels à gauche, puis à suivre un ou plusieurs CNAME. Or un CNAME de example.com vers example.org ne donne pas à l’opérateur de example.org le contrôle de blog.example.com. Si blog disparaît avant le suivi de l’alias, un prestataire capable de prouver la maîtrise de la cible peut sembler autorisé pour un sous-domaine qui reste sous le contrôle du client.

Le Forum évoque notamment le cas d’un opérateur de CDN pour expliquer la structure du risque. Il ne dit pas qu’un CDN déterminé, ni qu’une CA nommée, a exploité cette lecture. Transformer l’hypothèse en incident serait dépasser la source.

La méthode vient désormais avant les transformations

SC101 remplace l’élasticité de l’ancienne définition par une procédure ordonnée.

La CA part du FQDN demandé et choisit une méthode de validation. Ce choix détermine si le suivi d’un CNAME est disponible, si l’élagage de labels est disponible, si les deux le sont ou si aucun ne l’est. Toutes les méthodes ne valident pas au même endroit : celles qui utilisent un nom technique préfixé par un tiret bas ne reçoivent pas automatiquement les mêmes possibilités que celles qui opèrent sur le nom lui-même.

Si les deux transformations sont autorisées et effectivement utilisées, les CNAME sont suivis avant toute suppression de labels à gauche. L’ordre empêche l’élagage préalable d’élargir artificiellement l’autorité apparente de la cible. Le nom obtenu devient l’ADN ; la méthode sélectionnée prouve le contrôle de cet ADN, qui peut être égal ou différent du FQDN de départ.

Le texte normatif complet et son tableau de méthodes doivent guider l’implémentation. Cette description n’est pas un substitut pour ingénieur. Elle montre toutefois les états que le système devrait pouvoir rendre observables : méthode choisie, opérations autorisées, chaîne CNAME observée, labels retirés, ADN final et preuve appliquée.

Le scrutin lie aussi une comparaison GitHub immuable. La bibliothèque des versions conserve les documents courant et antérieurs. Ces éléments permettent de vérifier la fabrication de la règle. Ils ne révèlent pas le branchement exécuté par un service de validation lors d’une émission précise.

Un reçu de transition doit raconter le chemin

Un indicateur binaire — validation réussie ou échouée — est trop pauvre. Pour toute émission sensible réalisée pendant la fenêtre, le dossier devrait associer :

horodatage d’émission + FQDN demandé + méthode choisie + version et section BR + observations et chaîne CNAME + élagages ordonnés + ADN retenu + identité et date de la preuve + version CP/CPS + version de code/configuration + référence de test ou d’audit + exceptions

L’heure fixe les choix normatifs disponibles. Le couple FQDN/ADN montre le déplacement éventuel de l’autorisation. La méthode explique quelles transformations étaient permises. La version distingue la branche v2.2.7 de la v2.2.9. Les observations DNS empêchent une résolution ultérieure, différente, d’être prise pour l’état historique. La version CP/CPS décrit la pratique annoncée ; la version logicielle et la configuration décrivent ce qui pouvait réellement s’exécuter.

Le reçu doit être relié à un identifiant durable d’émission ou de certificat. Des empreintes peuvent rendre les substitutions ultérieures détectables. Les secrets de challenge n’ont pas à devenir publics : conservation et accès peuvent rester contrôlés. L’objectif est de permettre à un examinateur autorisé de reproduire la décision, non de publier les données opérationnelles.

Cette structure est une proposition analytique de Daniel Kade. Elle n’est pas présentée comme une obligation cachée du CA/Browser Forum. Les Baseline Requirements contiennent déjà des obligations de journalisation, de politique et d’audit ; l’argument est que le choix exceptionnel entre deux sections exige une identité de version explicite pour devenir intelligible.

La politique déclarée, le code déployé et l’émission ne se confondent pas

Les CA donnent effet aux règles dans leur Certificate Policy et leur Certification Practice Statement. Le cadre RFC 3647 aide à structurer ces déclarations. Une mise à jour CP/CPS peut annoncer la date de bascule, les méthodes affectées et le traitement d’un retour arrière.

Mais ce document n’est pas une trace d’exécution. Il peut précéder le déploiement du dernier nœud, ou le suivre. Une flotte peut être migrée par étapes. Un mécanisme de secours peut conserver une autre configuration. Une opération commencée avant la limite peut finir après. L’audit doit relier la politique annoncée, l’état du système et le dossier individuel ; aucun des trois ne remplace les deux autres.

Le Forum fixe le socle, les programmes racine gardent leur autorité

Les Baseline Requirements se présentent comme nécessaires mais insuffisantes et indiquent qu’elles deviennent contraignantes par l’adoption et l’exécution des fournisseurs de logiciels utilisés par les parties qui se fient aux certificats. Le Forum produit donc un socle commun ; les programmes racine décident de la confiance dans leurs produits.

La politique du programme racine de Mozilla incorpore des exigences communes tout en maintenant des dispositions Mozilla qui peuvent prévaloir ou être plus strictes. La politique d’Apple illustre elle aussi une couche de programme propre. Ces références définissent la limite institutionnelle, sans évaluer l’action de Mozilla ou d’Apple dans SC101.

Le vote, la déclaration CP/CPS, le comportement d’une émission et une décision de programme racine sont quatre archives différentes. Le projet existant sur le pouvoir d’un navigateur face à Entrust traite la dernière. Ici, la question reste volontairement en amont : laquelle des deux dérivations autorisées a produit ce certificat ?

Ce que les sources publiques ne permettent pas d’affirmer

La règle et son calendrier sont publics. L’état détaillé de chaque CA ne l’est pas nécessairement. L’absence d’un communiqué d’implémentation ne prouve pas un retard. Une mention générale de conformité à la v2.2.9 ne prouve pas non plus l’usage du nouvel algorithme avant la date obligatoire.

Sans trace d’émission, le bon constat est « référentiel non démontré ». Ce n’est ni un verdict de non-conformité ni une certification de migration. La précision sur l’incertitude protège autant les opérateurs légitimes que les utilisateurs du certificat.

Sources