Zusammenfassung

  • RFC 6916 koordiniert den Algorithmuswechsel zwischen Zertifizierungsstellen, Veröffentlichungsrepositorien und Relying Parties, statt ihn als lokale Softwareaktualisierung zu behandeln.
  • Der hierarchische Ablauf hält während einer Übergangszeit signierte Produkte unter dem alten und dem neuen Algorithmussatz parallel verfügbar und setzt danach Fristen für die Validierer.
  • Das Dokument rechnet mit mehreren Jahren Umstellungszeit und beschreibt keinen Notfallwechsel. Es ordnet eine geplante Ablösung, bietet aber keine fertige Reaktion auf einen plötzlichen kryptografischen Ausfall.

Ein Kryptowechsel bewegt eine ganze Kette

In der Resource Public Key Infrastructure (RPKI) sind signierte Aussagen in eine Hierarchie eingebettet. Eine Zertifizierungsstelle (CA) zertifiziert die darunterliegende Stelle; diese kann Zertifikate und signierte Objekte für weiter unten im Baum liegende Ressourcen ausstellen. Eine Relying Party (RP) ruft die veröffentlichten Daten ab und prüft die Kette. Netzbetreiber können die Validierungsergebnisse anschließend in ihre eigene Routing-Policy einbeziehen.

Diese Schritte sind nicht gleichbedeutend. Ein ausgestelltes Zertifikat beweist nicht, dass jedes Repository die passenden Objekte veröffentlicht hat. Eine Veröffentlichung beweist nicht, dass alle RPs die Daten validieren können. Und ein Validierungsergebnis bestimmt für sich genommen nicht, welche Route ein Router annimmt: Das entscheidet später der Betreiber. RFC 6916 fragt deshalb mehr als nur, wie eine kryptografische Suite ersetzt wird. Es geht darum, während des Wechsels einen nutzbaren Vertrauenspfad zwischen allen Stufen zu erhalten.

RFC 6916, „Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)“, erschien im April 2013 als Best Current Practice 182 (BCP 182). Als Autoren sind Roque Gagliano, Stephen Kent und Sean Turner aufgeführt. Das Dokument beruht auf einem IETF-Konsens und ist keine persönliche Anweisung eines einzelnen Autors. RFC 6916

Der Zeitplan kommt vor dem Ersatzalgorithmus

RFC 6916 wählt keinen neuen Algorithmus aus. Der Text verlangte 2013 zunächst eine Aktualisierung des damals in RFC 6485 festgelegten RPKI-Algorithmusprofils und danach einen eigenen Übergangszeitplan. RFC 7935 löste RFC 6485 später ab und legt das in den aktuellen Quellen geprüfte Profil fest. Für einen künftigen Wechsel müsste also das jeweils geltende Profil aktualisiert werden; ein neues Kennzeichen im Zertifikat reicht nicht aus. RFC 7935

Der Zeitplan soll fünf Termine enthalten: die Bereitschaft der CAs zur Ausstellung mit der neuen Suite, die erneute Ausstellung ihrer Produkte, die Bereitschaft der RPs, den Zeitpunkt, ab dem die alte Suite optional ist, und ihr Lebensende. RFC 6916 setzt jeden Meilenstein auf eine Minute nach Mitternacht UTC und fordert Bereitschaftskennzahlen für CAs und RPs. Zeit wird damit zu einer Betriebsbedingung des Vertrauenssystems: Repositorien, Validierungssoftware und Zertifikate müssen zum jeweiligen Termin die richtige Version verwenden können.

Ein Algorithmuswechsel ist außerdem etwas anderes als ein gewöhnlicher Schlüsseltausch. RFC 6489 beschreibt den CA-Schlüsselwechsel, wenn die Algorithmussuite gleich bleibt. RFC 6916 betrifft den Wechsel der Suite selbst und damit Zertifikate, Sperrlisten, Manifeste und signierte Objekte. Ein Verfahren, das einen einzelnen Schlüssel austauschen kann, löst nicht automatisch die Migration der gesamten Kryptografie. RFC 6489

Warum der übergeordnete CA zuerst umstellt

Die Migration verläuft von oben nach unten. Eine untergeordnete CA kann kein Zertifikat mit der neuen Suite anfordern, bevor die übergeordnete CA es ausstellen kann. Das Dokument vermeidet auch CA-Zertifikate, bei denen Signaturalgorithmus und öffentlicher Schlüssel des Subjekts verschiedenen Suites angehören. Ohne diese Reihenfolge wären gemischte Zertifikate und komplexere Repository-Strukturen zu behandeln; RFC 6916 warnt, dass ein nicht hierarchisches Vorgehen die veröffentlichten Daten exponentiell anwachsen lassen könnte.

Die Hierarchie ist hier Teil der Steuerungsfläche. Die Bereitschaft der übergeordneten CA ist eine tatsächliche Abhängigkeit ihrer Kinder, die diese nicht überspringen können. Der Standard legt die Reihenfolge offen: Bereitschaft, Ausstellung, Unterstützung durch die Validierer und schließlich Rückzug der alten Suite. Er behauptet nicht, eine zentrale Stelle könne alle Systeme gleichzeitig zum Wechsel verpflichten.

Parallele Veröffentlichung schafft Prüfzeit

Das gestufte Verfahren lässt die alte Suite im Produktivbetrieb weiterlaufen, während die neue eingeführt und getestet wird. In Phase 0 wird nur die bestehende Suite unterstützt. Phase 1 beginnt am CA-Ready-Termin: Nicht-Blatt-CAs müssen Anfragen mit der neuen Suite verarbeiten können; RPs verwenden im Produktivbetrieb jedoch weiter die alte. Neue Produkte dürfen zu Testzwecken veröffentlicht werden, möglichst an getrennten Veröffentlichungspunkten.

Phase 2 beginnt am CA-Go-Termin. Jeder Satz signierter Produkte muss nun unter beiden Algorithmen verfügbar sein. RPs können die neue Fassung prüfen und gleichzeitig die alte weiterverwenden. Entsprechende Ergebnisse, etwa die in ROAs enthaltenen Autorisierungen für Routenursprünge, sollen laut RFC bis auf zeitliche Unterschiede übereinstimmen. Sind viele CAs nicht bereit, muss der Zeitplan neu veröffentlicht werden. Die volle RP-Unterstützung ist noch nicht verpflichtend, aber Validierungsprobleme können den nächsten Schritt verzögern.

Ab Phase 3, dem RP-Ready-Termin, müssen alle RPs die neue Suite validieren können. Sie sollen deren Produkte bevorzugen, während beide Fassungen noch verfügbar sind. Phase 4 beginnt am Termin „Twilight“: Die neue Suite ist nun für RPs und CAs erforderlich. Alte Produkte können noch vorhanden sein, sind aber möglicherweise nicht mehr vollständig. Zum Lebensende wird die alte Suite außer Dienst gestellt; ihre Trust-Anchor-Locator werden von den Veröffentlichungspunkten entfernt. RFC 6916, Abschnitte 4 und 10

Der Rückweg ist zeitlich begrenzt. Ein RP, das die neuen Produkte noch nicht validieren kann, darf die alten weiterverwenden, solange diese erforderlich und verfügbar sind. Die Koexistenz ist jedoch nicht dauerhaft zugesichert. Sie ist ein begrenztes Fenster, in dem sich Implementierungen vergleichen und Verzögerungen erkennen lassen, bevor der alte Pfad wegfällt. RFC 6481

Das Ausfallrisiko betrifft beide Seiten

RFC 6916 benennt Fehler auf beiden Seiten. Hat eine CA die Umstellung bis zum Lebensende der alten Suite nicht abgeschlossen, sind ihre signierten Produkte nicht mehr gültig. Ein RP, das nicht migriert ist, kann Produkte der neuen Suite nicht mehr validieren. Dadurch kann seine Sicht auf die Routinginformationen in der RPKI unvollständig werden.

Das bedeutet nicht, dass alle Routen verschwinden. RPs liefern Validierungsergebnisse; Router und Betreiber legen fest, wie sie damit umgehen. Ein fehlendes oder ungültiges Objekt kann die Validierung des Routenursprungs beeinflussen, doch die tatsächliche Routingfolge hängt von lokaler Policy, Software und den betroffenen Ressourcen ab. Der Standard beschreibt das Risiko unvollständiger Validierung, beziffert aber keinen Ausfall und schreibt keine allgemeine Ablehnung von Routen vor.

Der vorsichtige Zeitplan zeigt zugleich eine Grenze. Die Zusammenfassung erwartet eine mehrjährige Migration und legt keinen Notfallwechsel fest. Für einen geplanten Ersatz, der breite Implementierung und kompatible Veröffentlichung erfordert, ist das nachvollziehbar. Offen bleibt aber, was geschieht, wenn ein Algorithmus oder Schlüssel bereits vor Abschluss des Zyklus unsicher wird. RFC 6916 liefert dafür keinen Krisenplan.

Gaglianos Platz in der öffentlichen Dokumentation

Ciscos öffentliches Profil bezeichnet Gagliano als Principal Solutions Engineer und nennt frühere Tätigkeiten in Technik und Architektur bei LACNIC, ANTEL und Sprint. Das verortet seine Laufbahn zwischen Netzbetreibern, Regionalregister und Anbieter, belegt aber nicht, warum er eine konkrete RFC-Regel befürwortete. Die belastbare Aussage steht im RFC selbst: Gagliano war Mitautor eines Konsensverfahrens, das die Bereitschaft als Eigenschaft der gesamten RPKI-Kette behandelt. Cisco-Autorenprofil

Das in RFC 7935 geprüfte Algorithmusprofil legt RSA mit 2048-Bit-Schlüssel und SHA-256 fest. 2026 untersucht ein informativer Internet-Draft Post-Quanten-Kandidaten und Migrationsarchitekturen, darunter parallele Veröffentlichung und einen gemischten Baum. Die Autoren stellen klar, dass der Entwurf weder RFC 7935 noch RFC 6916 aktualisiert, ein Produktionsprofil auswählt oder die geprüften Varianten für den produktiven RPKI-Betrieb freigibt. Forschung ist kein Beleg für eine genehmigte oder terminierte Produktionsmigration. RFC 7935; draft-yoshikawa-sidrops-pqc-rpki-02

Der dauerhafte Beitrag von RFC 6916 ist das Verfahren. Es zerlegt das Ziel „einen stärkeren Algorithmus einsetzen“ in beobachtbare Abhängigkeiten: CAs stellen mit der neuen Suite aus, Veröffentlichungspunkte führen entsprechende Produkte, RPs validieren sie, und der alte Pfad bleibt bestehen, bis die Bereitschaft überprüft ist. Zugleich macht das Dokument offene Fragen sichtbar: Wie wird Bereitschaft gemessen? Wie werden verspätete Teilnehmer unterstützt? Wie unterscheidet sich ein Notfall von einer planmäßigen Migration? Darüber müssen Betreiber und Normungsgremien entscheiden.