Zusammenfassung

  • Der erste DNSSEC-Schlüssel für die Root-Zone entstand nicht in dem Moment, in dem die signierte Zone live ging. Die Zeremonie am 16. Juni in Culpeper erzeugte KSK-2010; am 12. Juli band eine zweite Zeremonie in El Segundo den Schlüssel in den westlichen Standort ein und setzte den Betriebsablauf fort.
  • IANA datiert die erste signierte Root-Zone im Produktivbetrieb auf den 15. Juli 2010. Skripte, getrennte Rollen, externe Vertreter, Kameras, Hashwerte und Protokolle machten Teile der Schlüsselverwahrung überprüfbar. Sie beweisen nicht, dass alle Resolver DNSSEC validierten.

Drei Daten, drei Arbeitsschritte

Am 15. Juli 2010 meldete IANA, dass die Root-Zone signiert sei. Die Meldung bezog sich auf die veröffentlichten Root-Daten. Sie behauptete nicht, jeder rekursive Resolver weltweit habe die Validierung aktiviert. Eine Zeremonie konnte diese Entscheidung unabhängigen Betreibern auch nicht abnehmen.

Das IANA-Archiv trennt diesen Meilenstein von zwei Zeremonien. Die erste fand am 16. Juni in Culpeper, Virginia, im östlichen Schlüsselverwaltungszentrum statt. Die zweite folgte am 12. Juli in El Segundo, Kalifornien. Laut Startchronologie ging die erste signierte Root-Zone am 15. Juli in Produktion. Einen Schlüssel kontrolliert zu erzeugen und zu verwenden, einen zweiten Standort vorzubereiten und den Produktions-Signaturpfad zu starten waren verschiedene Aufgaben.

Die erste Zeremonie begann am 16. Juni um 17:00 UTC und dauerte über Mitternacht hinaus. Eine zeitgenössische ICANN-Präsentation nennt 00:25 UTC am 17. Juni als Ende. Spätere Dokumente, die den 17. Juni als Erzeugungsdatum angeben, beziehen sich möglicherweise auf den Abschluss derselben Sitzung.

Culpeper: einen Schlüssel mit nachvollziehbarer Herkunft erzeugen

Die veröffentlichten Ziele waren konkret: das östliche Schlüsselverwaltungszentrum in Betrieb nehmen, KSK-2010 erzeugen und die für das dritte Quartal 2010 vorgesehenen Zonen-Signaturschlüssel (ZSK) signieren. Die KSK signiert den DNSKEY-Schlüsselsatz der Root-Zone; eine separate ZSK signiert deren Ressourceneinträge. DNSSEC verbindet Signaturen über Ebenen hinweg. Das bedeutet nicht, dass die KSK jeden DNS-Eintrag direkt signiert.

Im Archiv liegen Skripte, SHA-256-Manifeste, ein ISO-Abbild, drei Kameraaufzeichnungen und das Erzeugungsprotokoll kskgen-20100616-211906.log. Damit lassen sich geplante Schritte und veröffentlichte Artefakte abgleichen. Wer die Dateien aus der Ferne prüft, wird dadurch nicht zum physischen Zeugen jeder Handlung. Die Unterlagen beweisen auch nicht allein, dass außerhalb des Kamerabilds nichts geschah. Ihr engerer Wert besteht darin, eine prüfbare Dokumentenspur zu hinterlassen.

Auch die Aufgabenteilung war eine Schutzmaßnahme. ICANN nannte am 7. Juni 14 Trusted Community Representatives, die nicht bei ICANN, VeriSign oder dem US-Handelsministerium angestellt waren und unterschiedliche Aufgaben bei der Schlüsselverwaltung erhielten. Eine zeitgenössische Präsentation auf der ICANN38 zählte später 16 anwesende Vertreter in Rollen wie Crypto Officers, Recovery Key Share Holders und Stellvertretern. Die Zahlen beschreiben verschiedene Gruppen: angekündigte Freiwillige und den Rollenplan vor Ort. Sie lassen sich nicht zu einer einzigen eindeutigen Kopfzahl verschmelzen.

Hinzu kamen Beschäftigte, ein Auditor, ein VeriSign-Vertreter und ein Kameramann.

El Segundo: einen zweiten Standort einbinden

Die zweite Zeremonie fand am 12. Juli im westlichen Schlüsselverwaltungszentrum in El Segundo statt. IANA verzeichnet den Beginn um 20:00 UTC. Zu den Zielen gehörten, den Standort in Betrieb zu nehmen, KSK-2010 zu importieren und die ZSK des vierten Quartals 2010 zu signieren. Das Archiv enthält Skripte, Prüfsummen, Videoaufnahmen und das Protokoll ksrsigner-20100712-224426.log.

Laut IANAs Statusbericht wurden Schlüsselmaterialien nach Westen gebracht, der Schlüssel dort importiert oder repliziert und der nächste vierteljährliche Signaturschritt ausgeführt. VeriSign akzeptierte die signierte Antwort. Der zweite Standort war damit Teil des Betriebs und keine bloße Kulisse. Die Quellen stützen jedoch nicht die Behauptung, während des gesamten Lebenszyklus habe nur eine einzige Kopie existiert. Sie beschreiben eine kontrollierte Struktur mit mehreren Einrichtungen.

Zwei Standorte verbessern die Kontinuität, machen die Verwahrung aber komplexer. Es muss klar sein, was repliziert wird, wer die Nutzung genehmigen darf und wie sich ein Ausfall auffangen lässt. Getrennte Rollen, Probeläufe, gesicherte Geräte, Protokolle und Audits sollten einseitige Zugriffe erschweren und routinemäßige Arbeit wiederholbar machen.

Signieren ist keine weltweite Einführung

Nach der Meldung vom 15. Juli wurden Änderungen an der Root-Zone bis zum 20. Juli kurzzeitig ausgesetzt, damit Folgen beobachtet und Probleme behoben werden konnten. Die Pause zeigt, dass Signaturen zu erzeugen und sie sicher zu betreiben zwei Aufgaben sind. Die signierten Daten mussten verteilt werden; jeder Resolver-Betreiber musste weiterhin selbst entscheiden, ob er Antworten validierte.

Der NTIA-Bericht vom 28. Mai beschrieb die damalige Aufgabenverteilung: IANA/ICANN verantwortete die KSK, VeriSign signierte und verteilte die vollständige Root-Zone mit ZSK, und NTIA genehmigte unter der damaligen Vereinbarung Änderungen an der Root-Zone. Der Bericht vor dem Start hielt außerdem fest, dass im Mai einige Autorisierungstests noch offen waren. Er belegt den geplanten Zuständigkeitsbereich und den damaligen Arbeitsstand, nicht den Abschluss aller Prüfungen zu diesem Zeitpunkt. Die späteren IANA-Meldungen dokumentieren den Start im Juli.

Kameras, Hashwerte, unabhängige Vertreter und Audit-Unterlagen schufen eine öffentliche Belegspur für einen Vorgang, bei dem der private Schlüssel geheim bleiben musste. Die Unterlagen erlauben einen Abgleich zwischen angekündigtem Verfahren und erhaltenen Nachweisen. Sie beantworten nicht jede politische Frage zur Verwaltung der Root-Zone und belegen keine weltweite Einführung. Ein Resolver ohne Validierung erhält keinen DNSSEC-Schutz, nur weil die Zeremonie sorgfältig durchgeführt wurde.

Die belastbare Schlussfolgerung bleibt daher begrenzt. Die Zeremonie verordnete kein Vertrauen in eine Organisation. Sie erzeugte einen Schlüssel in einem dokumentierten Verfahren; der zweite Standort wurde Teil der Verwahrungs- und Signaturkette; anschließend veröffentlichte das Produktionssystem die signierte Root-Zone. Mit Heng Lus Blick auf Koordinationsverfahren zählt das operative Ergebnis: Der Root-Zonen-Betreiber nahm eine signierte Antwort an und die Daten konnten verteilt werden. Das ist besser belegt als eine Behauptung weltweiter Übernahme.

Die Rollovers von 2016 bis 2018 und ein kommender KSK-Wechsel behandeln eine andere Frage: Wie ersetzt man einen bereits eingesetzten Schlüssel und prüft, ob Resolver der Änderung folgen? 2010 lag die vorgelagerte Frage auf dem Tisch: Wie erzeugt, verwahrt, transportiert und betreibt man den ersten kryptografischen Schlüssel der Root-Zone und lässt genügend Nachweise für eine spätere Prüfung zurück?

Quellen

Zusätzlicher späterer Kontext, kein Beleg für die Ereignisse von 2010