GOpenCDR-DNSSEC-Praxiserklärung

Über diese Erklärung

Dies ist die DNSSEC-Praxiserklärung (DNSSEC Practice Statement) für die GOpenCDR-Root-Zone und für die TLD-Zonen, die Gelhaus Solutions signiert, nach dem Aufbau von RFC 6841. Sie legt dar, wie die Schlüssel verwahrt, wie Zonen signiert und veröffentlicht werden und was eine vertrauende Partei prüfen kann.

Die Root von GOpenCDR ist eine Überlagerung. Sie enthält nur die TLDs von GOpenCDR und ersetzt nie die IANA-Root oder deren Vertrauensanker: Ein validierender Resolver behält den IANA-Anker unverändert und fügt den von GOpenCDR daneben hinzu.

Veröffentlichung

Der Vertrauensanker wird im Format von RFC 9718 über drei unabhängige Wege veröffentlicht: über HTTPS unter cdr.gplatform.org, im öffentlichen Transparenzlog und in signierten Release-Paketen. Ein Wechsel des Ankers wird auf allen drei Wegen mindestens 30 Tage im Voraus angekündigt.

Der Vertrauensanker der Root wird als Testanker veröffentlicht. Er kann kurzfristiger als mit 30 Tagen Vorlauf ersetzt werden, und auch dann wird jeder Ersatz auf allen drei Wegen angekündigt und im Transparenzlog festgehalten.

Diese Erklärung wird mit allen früheren Fassungen im Dokumentenarchiv aufbewahrt.

Schlüssel

• Algorithmus. Jeder Schlüssel nutzt Algorithmus 13 (ECDSA P-256 mit SHA-256), und jeder DS-Eintrag, den wir veröffentlichen, nutzt Digest-Typ 2 (SHA-256). SHA-1 wird nirgends verwendet.
• Eine Rolle, ein Schlüssel. Der Key-Signing-Key (KSK) der Root, der Zone-Signing-Key (ZSK) der Root sowie KSK und ZSK jeder TLD sind getrennte Schlüssel, jeder als eigener Schlüssel in HashiCorp Vault.
• Schlüssel verlassen den Schlüsselspeicher nie. Jeder Schlüssel ist nicht exportierbar, eine Klartextsicherung ist abgeschaltet, und jede Signatur entsteht im Schlüsselspeicher. Einen Rückgriff auf einen lokalen Schlüssel gibt es nicht.
• Der Schlüsselspeicher läuft auf eigener Hardware in Deutschland und ist nur über WireGuard von benannten Hosts erreichbar. Er führt zwei Audit-Geräte, Zugangsdaten sind an Netzadressen gebunden, und ein dauerhaftes Root-Token existiert nicht.
• Der KSK der Root ist offline. Er liegt in einem getrennten Zeremonie-Schlüsselspeicher, der außerhalb von Schlüsselzeremonien versiegelt bleibt und sich nur mit drei von fünf Schlüsselanteilen öffnen lässt, die jeweils eine andere Person hält und die in manipulationssicheren Beuteln an getrennten Orten liegen. Er wird nur bei Zeremonien verwendet, um die DNSKEY-Sätze der Root im Voraus zu signieren, und der Online-Signierer hält ihn nie.
• Uhren. Ein Signierer verweigert das Signieren, wenn seine Zeit nicht über NTS synchronisiert ist oder um mehr als eine Sekunde abweicht.

Zeremonien

Offline-Schlüssel werden nur in Zeremonien nach Skript mit mindestens zwei Zeugen erzeugt und verwendet. Die Skripte werden veröffentlicht, jede Zeremonie wird aufgezeichnet oder in signierten Notizen dokumentiert, und ihr Protokoll wird im Transparenzlog eingetragen. Änderungen an der Root, die keine Notfälle sind, ruhen 72 Stunden rund um eine Zeremonie.

Signieren

• Gültigkeit. Signaturen gelten 30 Tage, mit zufälliger Streuung. Eine Zone wird neu signiert, wenn weniger als 21 Tage verbleiben, und die Veröffentlichungsschranke lehnt alles mit weniger als 20 Tagen ab. Alarme lösen bei 17 und bei 14 Tagen aus, sodass ein Ausfall von etwa zwei Wochen zwischen Signierer und Schlüsselspeicher im Feld folgenlos bleibt.
• Nachweis der Nichtexistenz. Die Root nutzt NSEC. TLDs nutzen standardmäßig NSEC, und eine TLD kann NSEC3 mit den Parametern wählen, die RFC 9276 empfiehlt.
• Unversehrtheit der Zone. Jede Zone, die wir veröffentlichen, trägt einen ZONEMD-Eintrag mit SHA-384, und Mirrors weisen jede Kopie zurück, deren ZONEMD oder DNSSEC-Kette nicht besteht.
• Zwei Validatoren. Zwei unabhängige Validatoren prüfen jede Zone vor der Veröffentlichung. Eine Zone, die an einem von beiden scheitert, wird nicht veröffentlicht, und die bereits ausgelieferte Fassung bleibt in Betrieb.

Schlüsselwechsel

• ZSKs wechseln alle 180 Tage im Pre-Publication-Verfahren.
• KSKs von TLDs wechseln jährlich im Double-DS-Verfahren.
• Der KSK der Root wechselt alle zwei Jahre nach den Zeitvorgaben von RFC 5011.
• Ein Notfallwechsel wird jedes Jahr für jede Schlüsselrolle geprobt.

Ein Schlüsselwechsel läuft unter einer Validierungsüberwachung, kann angehalten werden und blockiert Änderungen an der Root, die keine Notfälle sind, solange er läuft.

Untergeordnete Zonen und DS-Einträge

Ein Registrant veröffentlicht DS-Einträge für eine signierte untergeordnete Zone über das Portal oder die API. DS-Einträge werden für die Algorithmen 8, 13, 14, 15 und 16 und die Digest-Typen 2 und 4 angenommen. Ein DS-Eintrag wird nur veröffentlicht, wo die Schlüssel der untergeordneten Zone zu ihm passen, denn ein DS-Eintrag, zu dem kein Schlüssel passt, lässt die Validierung des Namens für alle scheitern. Ein DS-Eintrag wird auf dieselbe Weise entfernt, wirksam mit der nächsten Zonenfassung.

Kontrollen rund um die Root

• Vier Augen. Jede Änderung an der Root-Zone und jedes Schlüsselereignis braucht eine zweite berechtigte Person, die zum Zeitpunkt der Freigabe mit einem hardwaregebundenen Passkey bestätigt. Niemand gibt eine eigene Änderung frei. Solange nur eine Person eine Root-Rolle innehat, darf sie nach einer Wartezeit von 24 Stunden allein freigeben, und jede solche Freigabe wird dauerhaft im Audit-Eintrag und im Transparenzlog gekennzeichnet. Diese Ausnahme endet endgültig, sobald eine zweite Root-Person existiert.
• Reihenfolge der Delegierung. Eine TLD gelangt erst in die Root, wenn ihre Schlüssel existieren, ihre Zone erzeugt ist und jeder Server, der sie ausliefern soll, korrekt antwortet.
• Aufzeichnungen. Jede Änderung an der Root und jedes Schlüsselereignis hat einen Audit-Eintrag und einen Eintrag im öffentlichen Transparenzlog, dessen Prüfpunkte im Schlüsselspeicher mit Ed25519 signiert und von einem unabhängigen Zeugen gegengezeichnet werden.

Kompromittierung und Wiederherstellung

Könnte ein Schlüssel kompromittiert sein, handelt Tier 0 sofort nach seinem Notfallverfahren, das nur aussetzen oder verschärfen darf, und wechselt den Schlüssel im Notfallverfahren. Das Ereignis und was dagegen getan wurde, wird im Transparenzlog veröffentlicht. Wie Sie einen Verdacht melden, steht in der Sicherheits- und Offenlegungsrichtlinie.

Überprüfung und Änderung

Tier 0 überprüft diese Praxis jedes Jahr. Diese Erklärung ändert sich nur nach öffentlicher Kommentierung, und in Kraft ist die Fassung im Archiv mit dem jüngsten Datum.

Sie gibt keine Gewährleistung und begründet kein Service Level. Die Haftung richtet sich nach den allgemeinen Nutzungsbedingungen.