Résumé

  • La première clé de signature de la racine n’a pas été créée au moment même où la zone signée est devenue opérationnelle. La cérémonie du 16 juin à Culpeper a généré KSK-2010 ; celle du 12 juillet à El Segundo a intégré la clé à l’installation occidentale et préparé une nouvelle étape d’exploitation.
  • IANA date du 15 juillet 2010 la première racine signée en production. Les scripts, la séparation des rôles, les représentants externes, les caméras, les empreintes cryptographiques et les journaux rendent une partie de la garde vérifiable. Ils ne prouvent pas que tous les résolveurs validaient DNSSEC.

Trois dates, trois opérations

Le 15 juillet 2010, IANA a annoncé que la zone racine était signée. L’annonce portait sur les données publiées par la racine. Elle ne prétendait pas que chaque résolveur récursif du monde avait activé la validation. Une cérémonie ne pouvait pas davantage imposer ce choix à des opérateurs indépendants.

Les archives d’IANA distinguent ce jalon de deux cérémonies. La première s’est tenue le 16 juin à Culpeper, en Virginie, dans l’installation Est. La seconde a eu lieu le 12 juillet à El Segundo, en Californie. La chronologie du lancement place la première racine signée en production le 15 juillet. Créer et utiliser la clé sous contrôle, préparer une seconde installation, puis faire fonctionner la chaîne de signature en production sont des travaux différents.

La première cérémonie a commencé à 17 h UTC le 16 juin et s’est poursuivie après minuit. Une présentation contemporaine d’ICANN situe sa fin à 00 h 25 UTC le 17 juin. Les documents ultérieurs qui retiennent le 17 juin comme date de génération décrivent l’heure de clôture de la même session, et non nécessairement un événement distinct.

Culpeper : donner une provenance à la clé

Les objectifs publiés étaient précis : mettre en service l’installation Est de gestion des clés, générer KSK-2010 et signer les clés de signature de zone (ZSK) prévues pour le troisième trimestre. La KSK signe l’ensemble DNSKEY de la racine. Une ZSK distincte signe les enregistrements de la zone. DNSSEC relie les signatures d’un niveau à l’autre ; cela ne signifie pas que la KSK signe directement chaque enregistrement DNS.

IANA conserve les scripts, les manifestes SHA-256, une image ISO, trois vidéos et le journal kskgen-20100616-211906.log. Ces éléments permettent de confronter le déroulement annoncé aux traces publiées. Ils ne font pas de toute personne consultant les archives un témoin physique de chaque action, et ne démontrent pas qu’aucun geste n’a eu lieu hors champ. Leur utilité est plus limitée et plus concrète : ils laissent une trace documentaire que d’autres peuvent examiner.

La répartition des rôles faisait partie du mécanisme. Le communiqué d’ICANN du 7 juin évoquait 14 Trusted Community Representatives, sans lien d’emploi avec ICANN, VeriSign ou le ministère américain du Commerce, chacun doté d’une fonction distincte. Une présentation ICANN38 a ensuite compté 16 représentants présents dans des catégories comprenant Crypto Officers, Recovery Key Share Holders et suppléants. Ces chiffres portent sur des périmètres différents — bénévoles annoncés et personnes affectées aux rôles pendant la session — et ne doivent pas être ramenés à un compte unique.

Des employés, un auditeur, un représentant de VeriSign et un opérateur caméra étaient également présents.

El Segundo : rendre une seconde installation opérante

La deuxième cérémonie a eu lieu le 12 juillet dans l’installation Ouest, à El Segundo. IANA indique un début à 20 h UTC. Les objectifs incluaient la mise en service du site, l’importation de KSK-2010 et la signature des ZSK du quatrième trimestre. Les archives comprennent des scripts, des sommes de contrôle, des vidéos et le journal ksrsigner-20100712-224426.log.

Selon la mise à jour de lancement d’IANA, des éléments de la clé ont été transportés vers l’ouest, la clé y a été importée ou répliquée et la signature trimestrielle a progressé. VeriSign a accepté la réponse signée. Le dossier public montre donc une seconde installation intégrée à l’exploitation, pas une simple mise en scène. Il ne permet pas d’affirmer qu’un seul exemplaire de la clé a existé durant tout son cycle de vie : les sources décrivent un dispositif contrôlé réparti entre plusieurs installations.

La redondance répondait au besoin de continuité, tout en créant un autre problème de contrôle. Davantage de copies, de personnes et d’artefacts demandent de vérifier ce qui est reproduit, qui peut autoriser l’usage et comment récupérer après une panne. La séparation des rôles, les répétitions, le matériel sécurisé, les journaux et l’audit devaient compliquer une action unilatérale tout en rendant le travail courant reproductible.

Une racine signée n’est pas une adoption universelle

Après l’annonce du 15 juillet, une brève suspension des changements de la racine a couru jusqu’au 20 juillet afin d’observer les effets et de corriger les difficultés. Ce délai rappelle que produire des signatures et les exploiter de manière sûre sont deux opérations distinctes. Les données devaient être distribuées ; chaque administrateur de résolveur devait encore décider s’il validerait les réponses.

Le rapport du NTIA du 28 mai décrivait un contrôle partagé : IANA/ICANN était responsable de la KSK, VeriSign signait et distribuait la zone complète avec les ZSK, et le NTIA autorisait alors les modifications de la racine. Ce document antérieur au lancement précisait que certains tests d’autorisation restaient incomplets en mai. Il renseigne sur le dispositif prévu et les travaux encore en cours à cette date ; les mises à jour de juillet consignent la réalisation du lancement.

Les caméras, les empreintes et la présence de représentants donnaient une forme publique à une opération qui devait rester privée. On pouvait comparer les étapes annoncées aux artefacts conservés. Cela ne résolvait pas toutes les questions politiques sur l’administration de la racine et ne démontrait pas une adoption mondiale. Un résolveur sans validation ne reçoit pas la protection de DNSSEC parce qu’une cérémonie a été menée correctement.

La conclusion doit donc rester à cette échelle. La cérémonie n’a pas décrété que l’Internet faisait confiance à une organisation. Elle a produit une clé dans un cadre documenté ; la seconde installation a élargi la chaîne de garde et de signature ; la production a ensuite publié la zone signée. Dans la perspective de Heng Lu, une procédure de coordination se juge par l’étape opérationnelle qu’elle rend possible : le mainteneur a accepté une réponse signée, puis la racine a pu être distribuée. Les archives étayent cette conclusion mieux qu’une affirmation d’adoption universelle.

Les rotations de 2016–2018 et le prochain remplacement de KSK portent sur une autre question : remplacer une clé déjà déployée et vérifier que les résolveurs suivent le changement. En 2010, la question venait avant : comment créer, conserver, transférer et utiliser la première autorité cryptographique de la racine avec assez de preuves pour que d’autres puissent examiner le processus ?

Sources

Contexte ultérieur complémentaire, non utilisé comme preuve des faits de 2010