Résumé

  • SC100 a obtenu les voix favorables des 22 émetteurs et des trois consommateurs de certificats ayant participé, sans opposition ni abstention. Au 31 août 2026, son examen de propriété intellectuelle n’était pas terminé : la clôture annoncée est le 5 septembre à 19 h UTC.
  • Le texte accepté rassemble des obligations déjà présentes. La perspective réseau primaire doit effectuer la validation DNSSEC pour les requêtes de contrôle de domaine et de CAA concernées ; les perspectives distantes peuvent la faire dans le cadre du MPIC.
  • DNSSEC et la corroboration multiperspective ne fournissent pas la même garantie. Le premier qualifie cryptographiquement une réponse DNS ; la seconde compare des observations distinctes avant l’émission.
  • Le projet écarte l’ensemble complet des informations de recherche DNS de deux périmètres de journalisation et d’auto-audit, tout en exigeant une information suffisante. Une preuve minimale doit donc relier un état de contrôle du résolveur à une tentative d’émission qui nomme explicitement la perspective primaire.

Le vote est terminé, l’adoption ne l’est pas

La page officielle de SC100 réunit trois états que l’on confond facilement. Elle donne d’abord le résultat du vote : 22 émetteurs de certificats ont voté oui ; Apple, Cisco Systems et Mozilla ont fait de même parmi les consommateurs. Aucun vote négatif ni aucune abstention n’est enregistré, et le quorum de 15 a été atteint.

Elle ouvre ensuite une période d’examen IPR de trente jours, du 6 août 2026 à 19 h UTC au 5 septembre à la même heure. Enfin, elle joint un projet complet, dans une version acceptant les modifications et dans une version en rouge. Au moment de cette analyse, le délai permettant de notifier l’exclusion d’une revendication essentielle n’avait pas expiré. Les minutes du 13 août disent d’ailleurs simplement que SC100 venait d’entrer dans cette phase.

Une bizarrerie documentaire rend la prudence nécessaire. Le projet propre porte le numéro 2.2.9 et la date du 6 août. Les exigences TLS actuellement publiées portent exactement le même numéro et la même date. Mais leur tableau de révisions se termine avec SC101. SC100 n’y figure pas. L’index des documents confirme le statut de la version courante, tandis que la pièce de SC100 reste marquée DRAFT.

Le numéro ne suffit donc pas à identifier la norme applicable. Une preuve sérieuse doit conserver le statut et l’empreinte du document : exigence finale courante, projet de maintenance en examen ou future publication incorporant le texte.

La motion ajoute une limite d’interprétation. Elle ne fixe pas de date d’effet parce qu’elle entend clarifier et regrouper, non modifier, les obligations existantes. Parler d’une « nouvelle obligation SC100 » serait trompeur. La question utile est de savoir comment prouver l’exécution d’une obligation dont le rôle devient plus visible.

Une obligation attachée à un point d’observation

L’origine de l’exigence est SC085v2, devenue applicable le 15 mars 2026. Lorsqu’une chaîne DNSSEC est présente, les recherches correspondantes de validation du contrôle de domaine et de CAA réalisées depuis la perspective primaire doivent être validées. Le texte 2.2.9 répartit aujourd’hui ces phrases dans plusieurs sections.

Le projet SC100 les place dans un nouveau §4.2.2.2. Le résolveur de la perspective primaire doit suivre l’algorithme de validation de la section 5 du RFC 4035, prendre en charge NSEC3 et SHA-2, et traiter les risques décrits dans la section 4 du RFC 6840.

La règle d’application est ensuite explicite. Pour la validation du contrôle de domaine et les recherches CAA, DNSSEC est un MUST à la perspective primaire. Les méthodes restantes fondées sur le courrier électronique bénéficient d’une exception partielle : les recherches CNAME, CAA et TXT servant à obtenir l’Authorization Domain Name restent obligatoires, tandis que les autres recherches relèvent de SHOULD. Hors de ce périmètre, une politique locale ne peut pas désactiver la validation. Une erreur DNSSEC observée par la perspective primaire, telle que SERVFAIL, ne doit pas devenir une autorisation d’émettre.

Pour les perspectives distantes, le verbe change. Elles MAY effectuer la validation DNSSEC jusqu’à l’ancre racine de l’IANA. Ce choix est permis, pas imposé. Il n’est ni un signe d’échec lorsqu’il n’est pas exercé, ni une garantie de conformité globale lorsqu’il l’est.

Une ligne de journal indiquant seulement dnssec=secure perd ce qui fait la règle. Le résultat peut venir du résolveur primaire, d’un résolveur distant, d’un test hors production ou d’un cache de diagnostic. Le rôle, l’identité du service et l’heure sont constitutifs de la preuve.

Compter des perspectives ne revient pas à compter des validateurs DNSSEC

Le MPIC a été introduit par SC067v3. Il demande, pour les méthodes concernées, que plusieurs perspectives distantes corroborent la conclusion de la perspective primaire avant l’émission. Son objectif annoncé est de rendre plus difficile une attaque BGP à préfixe de même longueur qui tromperait la validation de domaine.

Depuis le 15 juin 2026, le calendrier reproduit dans le projet SC100 exige au moins quatre perspectives distantes, le respect du tableau de quorum et des corroborations dans au moins deux régions de service de RIR. Le 15 décembre, le minimum passera à cinq. Il s’agit du nombre de perspectives participant à la corroboration, non du nombre de résolveurs auxquels DNSSEC est imposé.

Le MPIC répond à la question « d’autres points indépendants voient-ils une conclusion compatible ? ». DNSSEC répond à la question « le résolveur peut-il valider cryptographiquement cette donnée ou cette preuve d’absence ? ». Les états Secure, Insecure, Bogus et Indeterminate du RFC 4035 n’encodent ni la géographie du point d’observation, ni son rôle dans le quorum, ni la décision finale de l’autorité de certification.

Il faut donc éviter deux raccourcis opposés. Un quorum MPIC réussi ne démontre pas que les quatre ou cinq perspectives distantes ont toutes validé DNSSEC. Et l’absence d’une obligation DNSSEC pour ces perspectives ne rend pas leur corroboration fictive. Les deux contrôles peuvent être reliés, mais doivent rester représentés séparément.

« Information suffisante » n’est ni zéro trace ni trace totale

Le problème de preuve avait été préparé par SC096. Ce vote a retiré la vérification DNSSEC du vaste périmètre de journalisation DCV/CAA, au motif notamment que les résolveurs ne sont pas conçus pour une journalisation exhaustive. Son résumé indiquait que la gestion des changements pouvait montrer que les contrôles étaient actifs.

SC100 maintient ce choix, puis le borne. Le §4.2.2.2.7 proposé place l’ensemble complet des informations de recherche DNS liées à DNSSEC hors des auto-audits du §8.7 et des journaux du §5.4.1. Malgré cette exclusion, l’autorité de certification doit conserver assez d’information pour vérifier le respect du reste de la section.

Les minutes du 16 juillet montrent que la formulation est un compromis conscient. Le groupe ne voulait pas dicter un mécanisme de journalisation ; il voulait une preuve suffisante et laissait aux opérateurs la manière de la maintenir. Après la révision et la reprise de la discussion, les minutes du 30 juillet ne signalent pas de nouveau commentaire avant le vote.

Une norme commune a de bonnes raisons de ne pas choisir un produit, une base de données ou un format. En revanche, l’opérateur doit être capable de définir un minimum vérifiable. Une capture de configuration isolée est trop faible ; un enregistrement de chaque paquet est excessif. Le bon objet se situe entre les deux.

Deux reçus, reliés par le rôle et le temps

Le premier est un reçu de contrôle. Il décrit ce que le résolveur affecté à la perspective primaire était configuré et capable de faire pendant une période déterminée. Il devrait relier :

identifiant du contrôle + identifiant de perspective primaire + service/résolveur + version logicielle + empreinte de configuration + version des ancres de confiance + capacités RFC 4035/NSEC3/SHA-2/RFC 6840 + état des exceptions locales + essais + changement approuvé + début et fin de validité

Une empreinte et une référence vers un dépôt protégé peuvent remplacer la publication de paramètres sensibles. Le rôle du reçu est de borner une capacité dans le temps, pas d’affirmer que chaque appel l’a utilisée.

Le second est un reçu d’émission. Pour chaque tentative, il devrait conserver :

identifiant de tentative et de certificat/précertificat + heures de demande et de décision + nom et portée validés + méthode DCV + portée CAA + version normative + perspective primaire + reçu de contrôle/résolveur + familles de requêtes + état DNSSEC + traitement de l’erreur + perspectives distantes + indicateur DNSSEC effectué/non effectué pour chacune + état obtenu le cas échéant + régions RIR + observations et quorum MPIC + lignée des nouvelles tentatives + empreinte immuable

L’expression « non effectué » pour une perspective distante est une valeur utile et licite lorsque le choix facultatif n’est pas exercé. Elle ne doit pas être remplacée par Insecure, qui possède un sens protocolaire. Si une perspective distante valide DNSSEC, son résultat reste attaché à son propre résolveur ; il ne faut pas dupliquer le résultat primaire dans toutes les lignes.

Ces reçus ne figurent pas tels quels dans SC100. Ils constituent une proposition analytique de Daniel Kade. Ils ne sont attribués ni au Forum, ni à DigiCert, ni aux soutiens de la motion, ni aux navigateurs, ni à un auditeur. Leur objectif est de rendre testable le mot « suffisant » sans contredire l’exclusion de la trace DNS complète.

Ce que quatre preuves isolées ne démontrent pas

Une politique CP/CPS peut déclarer que DNSSEC est actif. Un test peut montrer qu’une version de résolveur classe correctement une zone cassée. Une tentative peut enregistrer Secure. Un certificat peut être émis après un quorum MPIC. Ces quatre faits ne démontrent pas encore que, pour cette tentative, la perspective primaire a utilisé cette configuration sur toutes les requêtes requises et a refusé de transformer une erreur en permission.

La preuve naît de la jointure. Le document public dit ce qui devait être pratiqué. Le reçu de contrôle dit quel état technique était approuvé. Le reçu d’émission dit quel rôle l’a appliqué. Le certificat ou précertificat fixe le résultat auquel la décision a conduit.

Sans cette jointure, l’organisation possède des documents mais pas nécessairement une explication reproductible. Le vote unanime de SC100 ne peut pas combler ce manque, pas plus que l’absence d’une annonce publique d’implémentation ne permet d’accuser une autorité de certification.

Limites de l’enquête

Les sources publiques ne décrivent pas l’architecture interne d’un émetteur, ses résolveurs, son modèle de données ou ses pratiques d’échantillonnage. Cette analyse ne conclut à aucune mauvaise émission, aucun empoisonnement DNS, aucune dissimulation et aucun manquement d’une entreprise nommée.

Elle ne prédit pas non plus l’issue du 5 septembre. Une notification d’exclusion, une modification ultérieure ou une autre numérotation restent possibles. Au 31 août, la formulation exacte est simple : vote approuvé, examen ouvert, version courante non modifiée.

Sources