Zusammenfassung

  • RFC 9589 verlangt CMS signing-time in RPKI Signed Objects und schließt binary-signing-time aus.
  • Derselbe Wert kann als mod-time der rsync-Datei und der aus RRDP materialisierten Datei dienen, damit der Fallback unnötige Transfers vermeidet.
  • Die Signatur macht den Wert nicht zu einem verlässlichen Zeitpunkt, einer aktuellen Manifest-Aussage, einer Zertifikatsvalidierung oder einer Beobachtung von BGP.

Ein kleiner gemeinsamer Nenner

RRDP transportiert Snapshot und Delta, rsync eine Dateihierarchie. Keiner der beiden Wege entscheidet allein, ob ein Objekt nutzbar ist. Fehlerhaftes XML, abgelaufenes TLS oder Timeout können den Wechsel auslösen, obwohl die Party die DER-Objekte schon über RRDP erhalten hat.

rsync kann bei gleicher Dateigröße und gleicher Änderungszeit einen Transfer überspringen. Werden RRDP-Kopien mit der lokalen Abrufzeit geschrieben und rsync-Dateien anders gestempelt, wird beim ersten Fallback bereits vorhandenes Material erneut bewegt. RFC 9589 setzt deshalb eine enge Konvention: Der Herausgeber führt signing-time im CMS-Objekt; der Repository Operator soll damit die rsync-mod-time setzen; die Relying Party soll sie bei RRDP-Materialisierung ebenfalls verwenden.

Das spart Last, ersetzt aber keinen Validierungsschritt. Es ist ein Vergleichssignal für die Übertragung, kein Befehl zur Annahme.

Eine Signatur beglaubigt nicht die Uhr

Die Signatur schützt den enthaltenen Wert vor unbemerkter Veränderung. Sie beweist weder eine richtige Uhr noch den Zeitpunkt der Schlüsselnutzung oder Veröffentlichung. RFC 9589 stellt klar, dass keine Korrektheitsanforderung an signing-time besteht und der Wert keine zuverlässige Information über die Signaturerzeugungszeit liefert.

Für die Umschaltung genügt Konsistenz: derselbe Gegenstand erhält in beiden Serialisierungen denselben Vergleichswert. Für eine Incident-Zeitleiste braucht es kontrollierte Logs und Beobachtungen. Gleiche Größe und mod-time sind zudem kein kryptographischer Gleichheitsbeweis; sie sind der schnelle rsync-Test. CMS, Resource Certificates und objektspezifische Regeln bleiben zuständig.

Was weiter geprüft werden muss

Das Objekt durchläuft RFC 6488 und seine Typregeln; das EE-Zertifikat muss gültig und nicht widerrufen sein. RFC 9286 liefert das signierte aktuelle Manifest. Nach RFC 9829 ist die relevante CRL sowohl die vom Zertifikat benannte als auch die mit passendem Hash im aktuellen CA-Manifest aufgeführte.

Auch eine gültige ROA bleibt eng: Sie autorisiert einen AS für bestimmte Präfixe. Sie beweist keine aktuelle Ankündigung, Auswahl, FIB-Installation oder Paketankunft. RRDP-Erfolg und rsync-Fallback verändern diese Reichweite nicht.

Zu erfassen sind URI, Byte-Hash, Transferentscheidung, Zertifikat, CRL, Manifest, Objektvalidierung, validierter Output-Fingerprint und erst danach der Policy-Input. Gelungener Transport ist nur gelungener Transport.

Den tatsächlich genutzten Fallback testen

Ein Testkorpus enthält normale Umschaltung, kaputtes RRDP-XML, abgelaufenes TLS, Timeout, fehlende Dateien, andere Größe oder mod-time, widerrufenes EE-Zertifikat und Objekt außerhalb des aktuellen Manifests. Pro Produktversion werden Pfad, Hash, signing-time, beide Zeiten, Größe, Transferentscheidung und Validierungsausgabe aufbewahrt.

Unterschiedliche Validator-Ausgaben sind Belege. Weniger Bytes bei verändertem akzeptierten Satz sind kein automatischer Erfolg; mehr Bytes bei gleicher Ausgabe können lediglich Kosten sein. Eine Kompatibilitätsbehauptung ersetzt nicht den Test des laufenden Pfads.

Quellen