Zusammenfassung

  • Der 30-Tage-Timer aus RFC 9691 beginnt pro Relying Party nach deren erster erfolgreichen Prüfung derselben Nachfolgerbeziehung; es gibt keinen globalen Startpunkt.
  • Ein belastbarer Wechsel trennt wechselseitige TAKs, Beobachtungshistorie, Repository-Gleichwertigkeit, tatsächlich gewählte Wurzel, alte TALs und die Vernichtung des Vorgängerschlüssels.

Ein TAL nach RFC 8630 gibt einer Relying Party den öffentlichen Trust-Anchor-Schlüssel und Zertifikatsadressen. Solange der Schlüssel bleibt, lässt sich das Zertifikat neu ausstellen. Der Wechsel von A zu B verändert dagegen den lokalen Vertrauensbeginn.

RFC 9691 definiert dafür das signierte TAK-Objekt. A nennt B als successor; B nennt A als predecessor. Ein Validator prüft B bis zu dessen TAK und verlangt, dass B.current mit A.successor sowie B.predecessor mit A.current übereinstimmt.

Die wechselseitige Bindung belegt einen geplanten Übergang zwischen gültigen Objekten. Sie zählt keine Validatoren und sagt nicht, welcher davon B in der Produktion benutzt.

Jeder Validator besitzt seinen ersten Tag

Sieht ein Validator B erstmals erfolgreich, nachdem B im vorherigen erfolgreichen Lauf fehlte, startet er seinen Timer. Bis zum Ablauf validiert er regulär mit A; B dient nur dem Test. Bleibt die Beziehung gültig, kann diese Instanz nach 30 Tagen B übernehmen und von dort neu validieren.

Scheitert B oder verschwindet aus dem TAK, wird der Timer abgebrochen. Ändern sich Schlüssel oder URI-Menge, beginnt ein neuer Vorgang. Dauerläufer, Wartungsinstanzen und Kaltstarts haben deshalb verschiedene Starttage. Software ohne automatische TAK-Übernahme meldet nur an Menschen oder bleibt beim TAL.

Der Nachweis nennt Validator, Version, lokalen TAL-Fingerabdruck, A/B-Fingerabdrücke und URI, vorherigen Lauf, Erstsicht, Abbrüche, Neustarts, Ablauf und produktiv gewählte Wurzel. „Seit 30 Tagen veröffentlicht“ hat kein akzeptierendes Subjekt.

RFC 9691 warnt auch vor dem unveränderten Wiedereinsetzen eines zurückgezogenen B. Ein Validator kann den Rückzug verpasst und seinen alten Timer behalten haben. Eine geänderte URI-Menge erzwingt einen neuen Timer, auch wenn SubjectPublicKeyInfo bleibt. Der neueste Snapshot ersetzt keine Historie.

Zwei gültige TAKs sind noch keine gleichen Repositories

Während der Überlappung liegen A und B in getrennten Verzeichnissen. Abgesehen vom TAK müssen CA-Zertifikate, IP- und AS-Ressourcen und Delegationen unter beiden Wurzeln denselben Validierungsausgang liefern.

Bei einem Publikationsserver gehören die RFC-8181-Operationen für beide Seiten in eine Anfrage. Bei mehreren Servern bleibt eine kurze Abweichung möglich. Widerruf oder Ressourcenverkleinerung sind erst nach Aktualisierung aller Punkte vollständig; eine Erweiterung darf dem Kind erst nach vollständiger Vorbereitung mitgeteilt werden.

Darum werden die validierten Projektionen unter A und B verglichen: Ressourcen, Delegationen, Zertifikate, Manifeste, CRLs und Generationen. Gefordert ist semantische Gleichwertigkeit, nicht Bytegleichheit. Eine TAK-Signatur übernimmt diese Betriebsarbeit nicht.

A zu entfernen ist eine eigene Machtentscheidung

Der Standard beschreibt vier Phasen: TAK nur für A; Erzeugung von B und gegenseitige Verweise; Verteilung eines B-TAL bei weiterlaufendem A; schließlich Löschen des A-Repositories und Vernichten des privaten Schlüssels.

Unterschiedliche URI in B-TAL und B-TAK können Hinweise auf den benutzten Kanal liefern. Schweigen ist jedoch mehrdeutig: Migration, Stillstand, Cache, Paketupdate oder fehlende Unterstützung. Der APNIC-Beitrag von 2025 beschrieb Untersuchungen der RIRs im NRO-RPKI-Programm; das ist Planungskontext, kein Beleg universeller Einführung.

Nach dem Entfernen von A kann eine nur mit A gestartete Instanz B nicht über den In-Band-Pfad lernen und braucht lokale Reparatur. Hat sie mehrere Generationen verpasst, kann pro Sprung ein weiterer Timer folgen. A unbegrenzt zu erhalten vermeidet den Absturz, erhält aber alte kryptographische Macht.

TAK heilt keinen kompromittierten aktuellen Schlüssel. Wer A kontrolliert, kontrolliert bereits die von A signierten Aussagen. Bei einer Out-of-Band-Konvertierung eines nicht bereits vertrauensverankerten TAK zum TAL wandert die Autorität zum Verteiler.

RFC 6487, RFC 6488, RFC 9286 und RFC 6481 regeln Zertifikate, signierte Objekte, Manifeste und Repositories. RFC 9319 liegt weiter unten: Ein Wurzelwechsel beweist weder Router-Übernahme noch Paketpfad.

Lu Hengs minimale Anfangsspezifikation standardisiert den kleinen gemeinsamen Mechanismus und lässt lokale Entscheidungen sichtbar. Die Realitätsebenen trennen signierte Aussage, ausgeführten Zustand und Netzwirkung. Running-Code Primacy gibt der beobachteten Validator-Wirklichkeit Vorrang vor dem Kalender.

Quellen