Zusammenfassung

  • RFC 6487 verbietet authorityCertIssuer und authorityCertSerialNumber im Authority Key Identifier eines RPKI-Ressourcenzertifikats. Im allgemeineren X.509-Profil RFC 5280 sind beide dagegen als optionale Felder definiert.
  • Barry-Commit 994a598 bindet authorityCertIssuer an einen GeneralNames-Parser, der ein Array verlangt. Einen Tag später ersetzt Rapport-Commit b1a59a den bisherigen Einzelstring durch ein Array mit einem rfc822Name und korrigiert die erwartete FORT-Meldung.
  • Das Skript startet Barry, dann die ausgewählte Relying Party, prüft anschließend das Log und zuletzt die VRPs. Der Quelltext belegt diese beabsichtigte Reihenfolge, nicht aber ihre öffentliche Ausführung oder ein dekodiertes Testzertifikat.
  • Rapport nennt vier auswählbare Validatoren. Die feldgenaue Diagnose wird in diesem Test jedoch nur für fort2 geprüft; eine leere Ausgabe bei den anderen zeigt eine Folge, aber nicht zwingend deren Ursache.

Der Fehler muss hergestellt werden, bevor er abgelehnt werden kann

Die Profilregel ist eindeutig. Der Authority Key Identifier verbindet ein Zertifikat mit dem öffentlichen Schlüssel seines Ausstellers. RFC 6487 schreibt die Erweiterung für Ressourcenzertifikate mit Ausnahme des selbstsignierten Falls vor, verlangt eine nichtkritische Kennzeichnung und untersagt die beiden Felder authorityCertIssuer und authorityCertSerialNumber. RFC 5280 lässt diese Komponenten in der allgemeinen PKIX-Syntax zu, sofern sie gemeinsam auftreten. RPKI schränkt die Wahlmöglichkeit der Basissyntax bewusst ein.

Ein Negativtest klingt daher einfach: Man erzeugt ein CA-Zertifikat mit dem untersagten Mitglied, hängt ein ROA darunter und zeigt, dass der Validator keine Route-Origin-Nutzlast exportiert. Doch das Erzeugen ist keine Vorbemerkung. Versteht der Generator das Fixture nicht, lässt er das Feld weg oder bricht er vor dem Schreiben des Zertifikats ab, erreicht der beabsichtigte Fehler den Validator nie. Null VRPs können dann wie ein korrekter Schutzmechanismus aussehen, obwohl die zu prüfende Grenze gar nicht überschritten wurde.

Barry übernimmt genau diese Herstellungsaufgabe. LACNIC beschrieb das Projekt 2025 als Generator gültiger und absichtlich ungültiger RPKI-Repositories aus Schlüssel-Wert-Dateien. Rapport führt diese Repositories anschließend einer Relying Party zu und untersucht ihre Ausgaben. Die Arbeitsteilung macht Grenzfälle wiederholbar, verpflichtet aber dazu, auch den Generator als Bestandteil des Nachweises zu behandeln.

Ein String erfüllt keinen GeneralNames-Vertrag

Am 1. September 2026 implementierte Barry-Commit 994a598321336baf1767f0fbfb460ed96c29fe4f die Angabe authorityCertIssuer. In ext.c wird das Feld dem internen Typ ft_gnames zugeordnet. Die Funktion parse_gnames in field.c akzeptiert nur eine Menge beziehungsweise ein Array, zählt dessen Elemente, legt für jedes ein ASN.1-GeneralName-Objekt an und parst die Einträge als Objekte. Bei einem anderen Werttyp führt der Code in den Fehlerpfad „Menge/Array erwartet“.

Das mit demselben Commit hinzugefügte Barry-Fixture macht die Grammatik sichtbar. Sein Array enthält ein rfc822Name, eine IP-Adresse und eine registrierte Kennung. Es beschreibt kein zulässiges RPKI-Zertifikat, sondern prüft, welche Varianten von GeneralName der Generator kodieren kann.

Die vorherige Rapport-Fassung verwendete authorityCertIssuer = "CN=Fake Issuer": einen skalaren String, kein Array. Aus dem Vergleich mit dem heutigen Parser folgt in engem Rahmen, dass diese Form dessen aktuellen Eingabevertrag nicht erfüllt. Daraus folgt nicht, wie eine ältere Barry-Version in einem konkreten Lauf reagierte oder ob der Test mit genau dieser Kombination jemals ausgeführt wurde. Öffentliche Laufzeitbelege fehlen.

Rapport-Commit b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c änderte das Fixture am 2. September. Nun steht dort ein Array mit einem Element: Typ rfc822Name, als Wert eine Beispieladresse. Ob diese Adresse einen plausiblen Aussteller bezeichnet, ist unerheblich; im RPKI-Profil ist bereits das Mitglied unzulässig. Entscheidend ist, dass Barry die verbotene Struktur nun in seiner eigenen Typgrammatik ausdrücken kann.

Auch die erwartete Fehlermeldung war verschoben

Vor der Korrektur suchte run.sh im FORT-Log nach einer Meldung über authorityCertSerialNumber. Das Fixture wollte jedoch authorityCertIssuer setzen. Nach b1a59a nennt die Assertion das Issuer-Feld. Damit schließt sich eine zweite Lücke: Selbst ein richtig konstruiertes Fehlobjekt liefert wenig Evidenz, wenn der Test die Ablehnung einem anderen Defekt zuschreibt.

Die Reihenfolge des korrigierten Skripts ist sinnvoll: run_barry, run_rp, check_logfile, check_vrps. Eine prüfbare Ausführung sollte an jeder Grenze einen eigenen Beleg hinterlassen. Dazu gehören Barry-Commit und Binärfingerabdruck, Fixture-Hash und Exit-Status, das erzeugte Zertifikat samt dekodierter AKI, Validatorname, Version, Konfiguration und Trust Anchor, ein stabiler Ablehnungshinweis sowie Hashes der erwarteten und tatsächlichen VRP-Mengen.

Auf der eingefrorenen öffentlichen Oberfläche liegen diese Belege nicht vor. GitHub weist für b1a59a keine Check Runs aus; im Rapport-Repository sind weder Tags noch Releases sichtbar. Das beweist nicht, dass die Maintainer nie lokal oder in einer privaten Umgebung getestet haben. Es begrenzt lediglich die öffentliche Aussage: Eine Quelltextkorrektur ist noch kein reproduzierbares, einer Version zugeordnetes Testergebnis.

Leer ist ein Effekt, keine Diagnose

Die Funktion check_vrps baut ihre Erwartungsdatei aus den übergebenen Argumenten. Dieser Test ruft sie ohne Argumente auf, also bleibt die Erwartung leer. Anschließend wird die CSV-Ausgabe der Relying Party normalisiert, sortiert und mit der leeren Datei verglichen. Ein erfolgreicher Diff belegt, dass in diesem Dateiausgabepfad kein VRP erschien.

Diese Folge ist wichtig, weil unter dem fehlerhaften CA-Zertifikat ein ROA liegt. Dennoch können verschiedene Ursachen dieselbe Leere erzeugen: eine korrekte Zurückweisung der AKI, ein Abrufproblem, ein anderer Kettenfehler, ein falscher TAL oder ein Abbruch Barrys vor Bereitstellung des Objekts. Ohne Konstruktions- und Ausführungsbeleg benennt die Ausgabe keine Ursache.

Für FORT enthält der Test ein weiteres Signal. Der Aufruf lautet check_logfile fort2; der Helper prüft das Log nur, wenn der aktive RP-Selektor dem ersten Argument entspricht. Bei allen anderen kehrt er ohne Textprüfung zurück. Die genaue Meldung zu authorityCertIssuer ist somit eine FORT-2-spezifische Assertion.

Das README des festgehaltenen Commits nennt vier Selektoren: fort2, routinator, rpki-client und rpki-prover; jeder Lauf zielt auf einen davon. Vier Adapter ergeben nicht automatisch vier gleich starke Diagnosen. Für die übrigen drei bleibt in diesem Fall der sichtbare gemeinsame Test auf leere VRP-Ausgabe. Er kann die begrenzte Aussage tragen, dass keine Nutzlast exportiert wurde, nicht aber mit gleicher Genauigkeit den Ablehnungsgrund.

Eine belastbare Matrix braucht drei Spalten

Eine für Betreiber brauchbare Konformitätsmatrix sollte Konstruktion, Entscheidung und Ausgabe trennen. In die erste Spalte gehören Barry-Version, Binary-Hash, Fixture, Exit-Code, Zertifikat und AKI-Dekodierung. In die zweite gehören Validatorversion, Konfiguration, TAL und Ablehnungssignal. Die dritte enthält erwartete und beobachtete VRP-Menge. Erst danach ist eine farbliche Zusammenfassung vertretbar.

Nicht jedes Projekt garantiert stabile menschlich lesbare Logtexte. Eine portable Suite sollte daher keinen einheitlichen Satz erzwingen. Strukturierte Fehlerklassen, produktspezifische Codes oder eine eng formulierte Feststellung wie „keine Nutzlast akzeptiert“ sind legitime Alternativen. Vergleichbarkeit entsteht durch präzise Beschriftung, nicht durch künstlich identische Schnittstellen.

Daneben sollten drei Reifestufen getrennt bleiben: Der Test ist im Quelltext vorhanden; der Test wurde gegen einen bestimmten Build ausgeführt; das Ergebnis ist Teil einer versionierten Suite. Die erste Stufe ermöglicht Review, die zweite Reproduktion, die dritte eine Zuordnung zur installierbaren Software. Wer sie zu „bestanden“ verdichtet, macht aus einem beweglichen Hauptzweig eine rückwirkende Garantie.

Das dekodierte Zertifikat ist das fehlende Bindeglied

Der kleinste zusätzliche Beleg mit der größten Wirkung wäre das von Barry erzeugte Zertifikat samt unabhängiger AKI-Dekodierung. Das Fixture beschreibt, was die Autorin oder der Autor erzeugen wollte; der Parser beschreibt, welche Eingabeform der Code akzeptiert. Erst das DER-Artefakt zeigt, welche Bytes der Validator tatsächlich erhalten konnte. Zertifikats-Hash, Version des Dekodierwerkzeugs und sichtbare AKI-Felder würden Absicht und Testeingabe eindeutig verbinden.

Dieser Schritt trennt außerdem eine neue Fähigkeit Barrys von ihrer Nutzung in einem konkreten Rapport-Lauf. Der Commit fügt Feldbindung, GeneralNames-Parser und einen Funktionstest hinzu. Das neue Rapport-Array passt zu diesem Vertrag. Ohne Laufartefakt bleibt dennoch offen, welches Binary ausgewählt wurde, ob eine Konfiguration den Pfad änderte und ob genau dieses Zertifikat im bereitgestellten Repository lag. Kohärenter Quelltext ist eine notwendige, aber keine hinreichende Laufzeitidentität.

Ein solcher Nachweis muss nicht schwergewichtig sein. Ein kleines maschinenlesbares Manifest kann Fixture-Hash, Barry-Commit und Binary-Hash, erzeugte Objektliste, Validatorversion, Start- und Endzeit, Exit-Codes, Diagnoseklasse sowie Hashes der erwarteten und tatsächlichen VRPs enthalten. An einen CI-Job oder ein Release gebunden, bleibt es überprüfbar, auch wenn eine Weboberfläche oder die Formulierung eines Logs später wechselt.

Auch der Transport gehört hinein. Rapport kann das Repository über die konfigurierte Abrufstrecke anbieten; ein fehlgeschlagener Abruf und eine kryptografische Zurückweisung dürfen nicht in derselben Ergebniszelle enden. Protokoll, Abrufstatus und Abschluss des Validierungszyklus machen aus einer leeren Ausgabe eine einordenbare Beobachtung.

Für die betriebliche Freigabe ergeben sich daraus klare Zuständigkeiten. Der Quelltest beantwortet die Frage nach beabsichtigter Abdeckung. Der Lauf gegen einen Kandidaten-Build beantwortet die Frage nach dessen Verhalten. Das versionierte Ergebnis beantwortet die Frage, welche Zusage über längere Zeit referenziert werden kann. Keine dieser Ebenen sollte stillschweigend für die beiden anderen sprechen.

LACNIC bezeichnete Barry und Rapport im Dezember 2025 noch als frühe Projekte und stellte damals FORT in den Mittelpunkt. Das spätere README führt vier Selektoren. Beide Quellen beschreiben unterschiedliche Zeitpunkte. Der ältere Beitrag darf heutige Fähigkeiten nicht wegdefinieren; die heutige Liste darf keine historischen, symmetrischen Ergebnisse erfinden.

Die stärkste derzeit mögliche Aussage bleibt deshalb bescheiden. Barry erhielt die Mechanik zur Kodierung von authorityCertIssuer. Rapport passte das Fixture an diesen Typ an und brachte die FORT-Diagnose mit dem geprüften Feld in Einklang. Die Testdefinition ist schlüssiger geworden. Die öffentliche Evidenz bescheinigt aber keinen erfolgreichen Lauf für FORT oder die drei anderen Relying Parties.

Quellen

  1. LACNIC Blog, „Open-Source Projects at LACNIC“: https://blog.lacnic.net/en/open-source-projects-lacnic/
  2. Barry-Commit 994a598: https://github.com/LACNIC/barry/commit/994a598321336baf1767f0fbfb460ed96c29fe4f
  3. Barry-Parser und Feldbindung: https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/src/field.c und https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/src/ext.c
  4. GeneralNames-Fixture von Barry: https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/test/functional/tests/gnames.rd
  5. Rapport-Korrektur b1a59a: https://github.com/LACNIC/rapport/commit/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c
  6. Korrigiertes Fixture und Runner: https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd und https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/run.sh
  7. Rapport-Helper und README: https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tools/checks.sh und https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/README.md
  8. RFC 6487: https://www.rfc-editor.org/rfc/rfc6487.html
  9. RFC 5280: https://www.rfc-editor.org/rfc/rfc5280.html
  10. Fixture und Runner vor der Korrektur in Commit 69da5fe: https://github.com/LACNIC/rapport/blob/69da5fe98cf09594fc009f4151a84368c08489ba/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd und https://github.com/LACNIC/rapport/blob/69da5fe98cf09594fc009f4151a84368c08489ba/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/run.sh
  11. Vom Korrektur-Commit b1a59a geänderte Dateien: https://github.com/LACNIC/rapport/commit/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/checks
  12. Verlauf des Fixture-Pfads auf main: https://github.com/LACNIC/rapport/commits/main/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd
  13. Tags und Releases von Rapport: https://github.com/LACNIC/rapport/tags und https://github.com/LACNIC/rapport/releases