Zusammenfassung

  • CRL Number bleibt in RPKI-CRLs Pflicht, doch ein RP prüft nur nichtkritische Kennzeichnung und eine begrenzte nichtnegative Ganzzahl; zur Reihenfolge darf er den Wert nicht verwenden.
  • Relevant ist genau die CRL, auf die das CRLDP des Zertifikats zeigt und die zugleich mit passendem Hash im aktuellen Manifest des Ausstellers steht.
  • Objektauswahl, Widerrufsstatus, Signed-Object-Prüfung, Herkunftsvalidierung, Router-Policy und Verkehrsergebnis sind getrennte Nachweise.

Der Parser akzeptierte die Zahl, der Selektor durfte sie nicht benutzen

Ein Konformitätstest liefert zwei signierte CRLs. Die nicht im Manifest aufgeführte Liste erhält die größere Nummer. Die andere stimmt mit fileList-Hash und CRLDP überein. Beide lassen sich parsen. Nur eine besitzt aktuelle Publikationsautorität. Wer die größere wählt, verwechselt gültige Syntax mit Zuständigkeit.

Das ist ein konstruiertes Beispiel, kein Produktbefund. RFC 9829 schreibt diese Trennung fest. RFC Editor und Datatracker führen das Dokument als Standards Track RFC vom Juli 2025, das RFC 6487 aktualisiert. Historie, Referenzen, spätere Zitate und Errata-Suche belegen den Dokumentstand. Beim Einfrieren gab es keinen passenden Errata-Eintrag; Implementierungsaussagen folgen daraus nicht.

Die allgemeine Regel in RFC 5280 nutzt CRL Number als monoton steigende Folge. Wo mehrere brauchbare CRLs auftauchen können, hilft die Zahl beim Erkennen der neueren. Im RPKI verkleinern RFC 6481 und das Manifest aus RFC 9286 diese Auswahlmenge: Das signierte fileList bindet Dateinamen und Hash jedes aktuellen Objekts, darunter die jüngste CRL der CA.

Damit ist der Zähler nicht falsch, sondern als Selektor überflüssig.

Pflichtfeld ohne Rangstimme

Eine RPKI-CRL muss weiterhin genau AKI und CRL Number als Erweiterungen enthalten. Der RP verarbeitet AKI. Bei CRL Number kontrolliert er, dass die Erweiterung nicht kritisch und der Wert eine nichtnegative Ganzzahl bis 2^159-1 ist. Danach ignoriert er die Größe.

Ein Betriebsnachweis muss deshalb Vorhandensein, Kodierung und Entscheidungsbefugnis getrennt ausweisen. „Feld gültig“ darf nicht „Feld entscheidet“ bedeuten.

RFC 9829 empfiehlt, CRL Number an die manifestNumber des aufnehmenden Manifests anzugleichen. Das erleichtert Diagnose, ist aber kein alternatives Wahlverfahren. Bei Abweichung soll der Betreiber die Publikationskette untersuchen, nicht die größte Zahl bevorzugen.

Zwei Verweise müssen auf dieselben Bytes zulaufen

RFC 6487 definiert Ressourcenzertifikate und CRL Distribution Points. Die aktualisierte Pfadprüfung bestimmt die relevante aktuelle CRL gemeinsam über das aktuelle Manifest des Ausstellers und das CRLDP des Zertifikats.

CRLDP allein beweist keinen aktuellen Publikationsstand. Das Manifest allein beweist nicht die Zuordnung zu jedem Zertifikat. Ein Dateiname ohne Hash schützt nicht vor ausgetauschtem Inhalt. Ein korrekter Hash in einem ungültigen Manifest besitzt keine validierte Ausstellerautorität. Erst die Schnittmenge legt das Objekt fest.

Die Reihenfolge bleibt auf Manifestebene erhalten. manifestNumber, thisUpdate, nextUpdate, Signatur, EE-Zertifikat und Vergleich mit zuvor validierten Manifesten bilden den Aktualitätsnachweis. Das bestehende RFC-9981-Stück behandelt Zählergrenze und neue Dateinamens-Epoche. Dieser Artikel behandelt stattdessen die CRL-Auswahl innerhalb einer gültigen Epoche.

Der Hash bindet Absicht, nicht jede spätere Wirkung

RFC 9286 soll alte Substitution, Löschung und Veränderung sichtbar machen. RFC 9829 beschreibt den fileList-Hash als kryptografischen Beleg der CA-Absicht, welche CRL die neueste ist, und entfernt damit mögliche Replay-Pfade konkurrierender Auswahlregeln.

Der Beleg ist begrenzt. Ein Hash-Match prüft weder Manifestfrische noch CRL-Signatur, Schlüsselbeziehung, AKI oder Zielseriennummer. Die CRL muss gültig sein; derselbe öffentliche Schlüssel muss CRL und Zertifikat verifizieren; erst eine gelistete Seriennummer begründet Widerruf.

RFC 3779 liefert IP- und AS-Ressourcenerweiterungen. Selbst eine vollständige Zertifikatsentscheidung ist kein Nachweis für eine laufende BGP-Route.

Transport erzeugt eine Ansicht, keine Autorität

RFC 8182 definiert RRDP; rsync ist ein weiterer Abrufweg. Ein erfolgreicher Download zeigt empfangene Bytes. RPs können wegen Cache- und Zeitregeln verschiedene validierte Manifestepochen sehen. Entscheidend sind verwendetes Manifest, Hash und Cacheentscheidung, nicht die auffällige CRL-Nummer.

Der frühere RFC-9589-Artikel behält signing-time, mod-time und den RRDP/rsync-Wechsel als Thema. Seine RFC-9829-Erwähnung begrenzt nur die Aussagekraft einer Dateizeit. Hier geht es um die vollständige Entmachtung von CRL Number und den zweifachen Objektverweis.

Nach der Widerrufsprüfung kombiniert RFC 6811 validierte Ursprungsdaten mit einer BGP-Route. RFC 8210 liefert Cache-Daten an Router. Empfang, lokale Policy, RIB/FIB und Datenebene bleiben eigene Ereignisse.

Die Beweiskette lautet: CA-Publikation, Repository-Transport, Manifestwahl, CRLDP/Name/Hash-Konvergenz, CRL-Prüfung, Seriennummernsuche, Signed Object, Herkunftszustand, Routerbeleg, Policy und beobachteter Verkehr.

Weniger Orakel, klarere Verantwortung

RFC 9829 stärkt das System durch Weglassen einer redundanten Autoritätsquelle. Heng Lus Minimum Initial Specification verlangt einen engen gemeinsamen Kern. Reality Layers trennt Zahl, Publikationsabsicht, Validierung und Ergebnis. Running-Code Primacy fragt, welchen Selektor RP und Router tatsächlich ausgeführt haben.

Ein wirksamer Test gibt dem nicht gelisteten Objekt die höchste Nummer und variiert anschließend Hash, Zeit, Signatur, Schlüssel und Seriennummer einzeln. Für jede Grenze braucht es einen eigenen Grundcode. Eine grüne Sammelanzeige beweist nicht, dass die verbotene Rangstimme verschwunden ist.

Quellen