Zusammenfassung

  • Die RPKI-Manifestnummer ordnet lokal die signierten Dateibestände einer einzelnen CA. Sie ist weder Weltzeit noch Aussage über aktive Routen. Das Feld hat eine Obergrenze; fehlerhafte Ausgabe kann jeden Nachfolger kleiner als den bereits akzeptierten Wert machen.
  • Nach RFC 9981 begründet ein anderer Manifestdateiname eine neue Vergleichsepoche. Die Relying Party muss den Betreiber warnen, und die CA soll den Namenswechsel nicht zum Normalfall machen.
  • Nur der gespeicherte Zahlenbezug beginnt neu. Signaturkette, ein späteres thisUpdate, Datei- und Hashliste sowie die genaue Übereinstimmung von signierter URI und RRDP- beziehungsweise rsync-Ort bleiben verpflichtend.

Neuer in der Zeit, unmöglich größer in der Folge

Eine Zertifizierungsstelle will Manifest 7.914 ausgeben. Ein Rechenfehler schreibt stattdessen 2^159 - 1, den größten darstellbaren Wert. Das richtige Schlüsselpaar signiert, die Zeiten stimmen, Dateinamen und Hashes bilden den Publikationspunkt korrekt ab. Mehrere Relying Parties akzeptieren und speichern die Zahl.

Der Betreiber korrigiert den Zustand und erzeugt ein neues Manifest. Tatsächlich ist es später, kryptografisch gültig und sachlich richtig. Die alte Vergleichsregel lässt es dennoch scheitern: Es gibt keinen zulässigen Wert oberhalb des gespeicherten Maximums.

Zwei Beweise widersprechen sich. Die Signatur ordnet die neue Aussage dem Herausgeber zu. Die Sequenz sagt, sie könne nicht auf den akzeptierten Vorgänger folgen. Wer die Sequenz ignoriert, erleichtert Wiederholungsangriffe. Wer sie ohne Ausnahme durchsetzt, friert den Publikationspunkt dauerhaft ein.

RFC 9981 bestimmt deshalb die kleinste gemeinsam beobachtbare Zäsur: einen anderen Dateinamen. Die CA erhält keine allgemeine Befugnis, unbequeme Historie zu löschen. Der Name wechselt die Vergleichsepoche; alle anderen Nachweise bestehen fort.

Was ein Manifest tatsächlich belegt

Ein RPKI-Manifest ist das signierte Inventar der Dateien, die eine CA an einem Publikationspunkt bereitstellen will. Jeder Dateiname wird an einen Hash gebunden. Damit lassen sich fehlende, ersetzte oder nur unvollständig sichtbare Objekte erkennen.

Das Manifest ist selbst ein signiertes RPKI-Objekt mit einmaligem EE-Zertifikat. Es enthält manifestNumber, thisUpdate, nextUpdate, Hashverfahren und Paare aus Namen und Prüfsumme. Das CA-Zertifikat verweist über die SIA id-ad-rpkiManifest darauf.

Seine Aussage bleibt begrenzt. Ein aufgeführtes ROA beweist keine BGP-Sichtbarkeit. Eine aufgeführte CRL beweist nicht, dass jeder Validator sie geladen hat. Ein erzeugter VRP beweist nicht, dass ein Router ihn verwendet. Das Manifest beschreibt Publikation; Validierung und Weiterleitung liegen in nachfolgenden Ebenen.

Diese Trennung hält die Reaktion verhältnismäßig. Nicht „das gesamte RPKI-Vertrauen“ ist defekt. Die Zahlenhistorie einer CA unter einem Namen lässt sich nicht fortsetzen. Genau dort kann die Reparatur ansetzen.

Ein astronomisch großes, aber endliches Feld

RFC 9286 verlangt, die Nummer für jedes neue Manifest um eins zu erhöhen. Die Relying Party erwartet einen Wert über dem zuvor akzeptierten. Ein Sprung kann ausgelassene Zustände anzeigen; ein Rückgang kann auf ein altes oder wiederholtes Objekt hinweisen.

Zwischen CAs sind die Zahlen nicht vergleichbar, und auch innerhalb einer CA ersetzen sie nicht die Zeit. thisUpdate, nextUpdate, Zertifikatsgültigkeit, Widerruf und die allgemeine Prüfung signierter Objekte bleiben eigenständig.

RFC 9981 nennt die Grenze: ein positiver INTEGER mit höchstens 20 Oktetten, also maximal 2^159 - 1. Bei einem Manifest pro Sekunde würde natürliche Erschöpfung ungefähr 23.171.956.451.847.141.650.870 Quintillionen Jahre dauern. Kapazität ist nicht das Problem.

Software ist es: falsche Addition, Ausgabeschleife ohne Pause, beschädigte Zustandswiederherstellung oder versehentliche Zuweisung des Maximums. Ein einzelner Fehler kann die astronomische Strecke überspringen.

Nach Annahme des Werts können Produkte auseinanderlaufen. Eines verwirft den Zustand vielleicht nach Ablauf; ein anderes lehnt kleinere Werte unbegrenzt ab. Dasselbe Repository wirkt für manche aktuell und für andere eingefroren. Gespeicherter Validatorzustand gehört daher zum Vorfall.

Der Name als ausdrückliche Epochengrenze

Unterscheidet sich der Manifestdateiname von dem zuvor mit der CA verbundenen Namen, darf eine Relying Party das neue Objekt nach RFC 9981 nicht allein wegen der kleineren Nummer ablehnen. Besteht es alle weiteren Prüfungen, wird die Zahl unter dem neuen Namen gespeichert und eine neue Epoche beginnt.

Dieser Name ist kein frei gewähltes Etikett. Er ist das letzte Pfadsegment der id-ad-rpkiManifest-SIA-URI im CA-Zertifikat. Die CA muss den neuen Ort im Zertifikat nennen, dort veröffentlichen und die signed-object URI des EE-Zertifikats mit dem tatsächlichen Bezug in Einklang bringen.

Drei Vorgänge werden damit prüfbar: Das Zertifikat benennt einen Pfad, das Repository liefert dort das Objekt, und der Validator ändert seinen Vergleichsschlüssel. Weder eine zentrale globale Rücksetzung noch die Vermutung „klein heißt wohl neuer“ ist nötig.

Die Relying Party muss warnen. Ein Wechsel kann legitime Wiederherstellung, geplanter CA-Übergang, Fehlkonfiguration oder Hinweis auf Kompromittierung sein. Die Signatur zeigt, wer erklärte, nicht warum die alte Geschichte beendet wurde.

Routinemäßiger Namenswechsel wäre schädlich. Würde jeder Neustart oder jede Aktualisierung eine Epoche öffnen, verlöre die Sequenz ihre Rückschritterkennung und alte gültige Historie ließe sich leichter als Neuanfang präsentieren.

Welche Nachweise die Grenze überschreiten

„Neuer Name, also akzeptieren“ ist falsch. Der Name entscheidet nur, gegen welche gespeicherte manifestNumber verglichen wird.

Das Manifest braucht weiterhin gültige Signatur, gültiges EE-Zertifikat und Kette zur CA. Gültigkeit, Widerruf, RPKI-Profil, Struktur, Hashalgorithmus, Inventar sowie Regeln für fehlende Dateien und falsche Hashes gelten unverändert.

Frische bleibt erhalten. thisUpdate muss später als im zuletzt akzeptierten Manifest sein. Ein altes signiertes Inventar wird durch Kopieren unter einen neuen Pfad nicht frisch. nextUpdate begrenzt weiterhin das erklärte Zeitfenster.

Auch der Ort bleibt Beweis. Die signed-object URI im EE-Zertifikat muss exakt der RRDP-publish-URI oder dem rsync-Pfad entsprechen, über den das Objekt bezogen wurde. Andere Benennung ohne angepasste signierte Referenzen schafft keine RFC-Epoche.

Das Manifest verändert seine Einträge nicht. Es kann ein Inventar wieder validierbar machen, aber keine Zertifikatsressourcen, ROA-Präfixe, Widerrufe oder Routereingaben ändern.

Die Falle mehrerer SIA-Einträge

Ein CA-Zertifikat kann mehrere Manifest-SIA-Beschreibungen tragen. Relying Parties wählen womöglich verschiedene Orte. Entfernt das neue Zertifikat einen alten Namen, behält aber einen zweiten, sehen einige eine neue Epoche und andere eine Fortsetzung der alten.

Beide Gruppen können für die gewählte URI regelkonform handeln und gegenteilige Ergebnisse erzielen. Unter dem neuen Namen wird die kleine Zahl angenommen; unter dem verbliebenen alten wird sie mit dem Maximum verglichen und verworfen. Das sieht leicht wie Cacheverzug, RRDP-Störung oder Produktfehler aus.

Darum darf bei einer Wiederherstellung über Namenswechsel kein früherer Manifestname im neuen Zertifikat verbleiben. Alle SIA, Pfade und Auswahlregeln müssen erfasst werden. Nur den vermeintlichen Hauptort zu ändern reicht nicht.

RRDP und rsync sind Transporte, keine getrennten Wahrheiten. Snapshot, Delta und rsync-Sicht müssen auf Objekte mit übereinstimmenden signierten URIs und Bytes führen. HTTP-Erfolg beweist Zustellung, nicht die kryptografische Autorisierung des Orts.

Warum der Trust Anchor schwerer wiegt

Eine untergeordnete CA kann meist unter ihrem Elternzertifikat einen CA-Schlüsselwechsel ausführen, eine neue Identität und damit neue Manifestgeschichte schaffen. Überlappung und Kontinuität sind weiter nötig, doch eine höhere Autorität verbindet alt und neu.

Ein Trust Anchor hat keine übergeordnete CA. Schlüssel und Zertifikatsorte gelangen gewöhnlich per TAL zur Relying Party. Ein neuer Schlüssel oder eine neue TAL trifft auf unterschiedliche Aktualisierungszeiten, alte Installationen und die Gefahr, dass Validatoren mit altem Material den gesamten Baum verlieren.

RFC 9691 verbessert geplante Übergänge mit TAK-Objekten. Der aktuelle Trust Anchor kann Nachfolgeschlüssel und Orte ankündigen; Validatoren prüfen gegenseitige Beziehungen und warten eine Akzeptanzzeit ab.

TAK ist aber kein magischer Umweg um einen beschädigten Publikationspunkt. Die Relying Party startet mit dem bereits vertrauten Schlüssel, bezieht Zertifikat, Manifest und CRL und verarbeitet TAK anschließend. Kontinuität muss vor dem Notfall vorbereitet und getrennt vom RFC-9981-Namenswechsel geübt werden.

Wiederherstellung zeigt sich in Konvergenz

Eine neue Signatur beendet den Vorfall nicht. Erst wenn unabhängige Implementierungen dasselbe Objekt beziehen, die RFC-9981-Epoche anerkennen, das Inventar prüfen und zu den erwarteten Ausgaben gelangen, ist Wiederherstellung belegt.

Tests verwenden aufgezeichnetes oder synthetisches Material, niemals eine Produktionsnummer nahe dem Maximum. Sie umfassen normale Folge, Sprung, Maximum, kleine Zahl unter gleichem Namen, kleine Zahl unter neuem Namen, älteres thisUpdate, unpassende signierte URI und ein Zertifikat mit verbliebener alter SIA.

Für Produkt und Version werden URI, Namen, gespeicherte Zahl, Zeitvergleich, Warnung, Ergebnis, akzeptierte Objekte und VRP-Differenz festgehalten. Unterschiede sind Belege für Implementierungszustand, die vor einer echten Notlage sichtbar werden sollen.

In Produktion bleiben altes Zertifikat, Manifest, alle URIs, Zahlen, Zeiten und Ausgabefingerprints erhalten. Grund, Freigaben, neue SIA und erwartete Wirkung werden dokumentiert; RRDP-Snapshot, Deltas, rsync, Validatoren und Routerzufuhr werden vor Entfernung alten Materials verglichen.

Scheitert das neue Objekt an Signatur, Zeit, URI oder Inventar, ist ein weiterer Name kein Rollback. Ausgabe stoppen, Nachweise erhalten und, soweit zulässig, zum letzten belegten Zustand zurückkehren. Wiederholte Neustarts verwandeln eine kontrollierte Ausnahme in unerklärliche Geschichte.

Quellen