Zusammenfassung

  • RFC 9691 erlaubt die Ankündigung eines Nachfolgeschlüssels in einem TAK-Objekt; während der 30-tägigen Annahmefrist validiert die RP weiter mit dem aktuellen Schlüssel.
  • Der Nachfolger muss wechselseitig mit seinem Vorgänger verknüpft sein, und Schlüssel sowie Zertifikatsadressen müssen während der Frist stabil bleiben.
  • Der Wechsel eines Validators ist kein Nachweis für die Übernahme durch alle RPs.

Der Trust Anchor Locator nach RFC 8630 nennt die Fundstellen des CA-Zertifikats und enthält den öffentlichen Schlüssel, mit dem eine RP das abgerufene selbstsignierte Zertifikat als vorgesehenen Trust Anchor erkennt. Dieses außerhalb der Hierarchie verteilte Vertrauensmaterial macht einen Schlüsselwechsel zu mehr als einer gewöhnlichen Repository-Aktualisierung.

RFC 9691 definiert das signierte Trust Anchor Key Object. Ein TAK kann den aktuellen Schlüssel und seine Zertifikatsadressen sowie einen Nachfolgeschlüssel mit dessen Adressen enthalten. Die bloße Veröffentlichung führt nicht zur Annahme. Die RP validiert unter dem Nachfolgeschlüssel und prüft die Verbindung in beide Richtungen: Das aktuelle TAK nennt den Nachfolger, und das TAK des Nachfolgers nennt den aktuellen Schlüssel als Vorgänger.

Nach der ersten erfolgreichen Prüfung beginnt eine Annahmefrist von 30 Tagen. Für die produktive Validierung bleibt der aktuelle Schlüssel in Gebrauch. Bei späteren erfolgreichen Läufen müssen Schlüssel und Zertifikatsadressen unverändert sein. Verschwindet der Nachfolger oder schlägt seine Prüfung fehl, wird die Frist aufgehoben. Erst nach ihrem regelgerechten Ablauf wird der Nachfolger zum aktuellen Schlüssel.

Damit sind Veröffentlichung, Prüfung durch eine bestimmte RP, stabile Beobachtung und tatsächlicher Wechsel verschiedene Tatsachen. Keine davon belegt allein, dass die gesamte Validatorpopulation umgestellt ist.

RPs ohne TAK-Unterstützung verwenden weiterhin den Schlüssel aus ihrem TAL oder aus einer manuellen Konfiguration. Nach RFC 9691 kann es deshalb nötig sein, frühere und neue Schlüsselpaare mit getrennten Repository-Verzeichnissen parallel zu betreiben. Ein alter TAL-Client und eine moderne RP mitten in der Annahmefrist haben unterschiedliche Zustände.

RFC 6489 beschreibt eine verwandte, vorsichtige CA-Schlüsselablösung: neue CA-Instanz, Veröffentlichung von Zertifikat, CRL und Manifest, Vorbereitungszeit, Neuausstellung der untergeordneten Produkte und erst danach Stilllegung der alten Instanz. RFC 6916 trennt bei einem Algorithmuswechsel ebenfalls die Einsatzbereitschaft der CAs, die Neuausstellung, die Bereitschaft der RPs, die Übergangszeit und das Ende der alten Suite.

Ein Annahmeprotokoll sollte Fingerabdrücke beider Schlüssel, Zertifikatsadressen, Hashes beider TAKs, erste erfolgreiche Prüfung, Beginn und Fortbestand der Frist, Wechselzeit sowie Kennung und Version des Validators verbinden. TAL-abhängige Gruppen, ihre Unterstützungsfrist und die Entscheidung zur Abschaltung gehören in einen eigenen Nachweisstrang.

Das ist eine redaktionelle Governance-Folgerung, kein von den RFCs vorgeschriebenes Prüfschema. Sie bewahrt die Reichweite jedes Belegs und verhindert, dass eine lokale Beobachtung als universelle Übernahme ausgegeben wird.

Quellen