Zusammenfassung

  • Eine Rapport-Änderung vom 4. September 2026 trennte zwei RFC-9286-Fälle. Im Fall derselben CA-Instanz legt der Test zunächst einen gültigen Cache an, entfernt dann ca2.mft und erwartet weiterhin sechs VRPs, einschließlich zweier gecachter VRPs der betroffenen CA.
  • Der Skriptkommentar verlangt eine Warnung wegen des fehlenden Manifests. Die einzige folgende check_logfile-Zeile beginnt aber mit # und wird am festgehaltenen Commit von der Shell nicht ausgeführt.
  • RFC 9286 formuliert Warnung und Cache-Fortführung getrennt: Der fehlgeschlagene Abruf muss eine begründete Warnung erzeugen, ein menschlicher Operator sollte benachrichtigt werden, und die gecachten Objekte derselben CA sollten bis zur Alterung oder erfolgreichen Ersetzung weiterverwendet werden.
  • Eine vollständige Abnahme braucht zwei Belegspalten: die getroffene Cache-Entscheidung und das semantische Betriebssignal. Erhaltene VRPs belegen keine Warnung; eine Warnung belegt nicht den richtigen VRP-Satz.

Ein Ausfall, der sechs Ergebnisse stehen lässt

Der Test beginnt absichtlich nicht mit einem Fehler, sondern mit einem verifizierbaren Normalzustand. Zwei CA-Instanzen liefern jeweils zwei VRPs. Der erste Durchlauf erzeugt damit vier bekannte Ergebnisse und einen gültigen Cache. Für den zweiten Durchlauf kommt eine dritte CA hinzu. Gleichzeitig entfernt das Skript das Manifest ca2.mft der zweiten CA. Der ausgewählte Relying Party wird erneut gestartet, während HTTP-Abrufe abgeschaltet sind. Ein alternativer Abruf kann die vorbereitete Lücke also nicht verdecken.

Die zweite Erwartung umfasst sechs VRPs. Zwei stammen weiterhin aus der ersten CA, zwei neu aus der dritten und zwei aus dem letzten erfolgreichen Zustand der zweiten CA. Der Test macht damit eine wichtige Kontinuitätseigenschaft messbar: Ein vorübergehend nicht abrufbares Manifest derselben CA-Instanz darf den zuletzt erfolgreich validierten Objektbestand nicht reflexartig aus der Berechnung löschen.

Das ist keine Nachsicht gegenüber einem ungültigen Zustand. Es ist eine Begrenzung der Folgen eines Transport- oder Veröffentlichungsproblems. Würden die Objekte nach einem einzelnen Fehlschlag sofort verworfen, könnte der Relying Party gültige Routen als ungültig behandeln oder unter anderen Ausgangsbedingungen die umgekehrte Fehlinterpretation erzeugen. Ein begrenztes Weiterverwenden des letzten erfolgreichen Zustands verhindert, dass die Erreichbarkeit des Repositories mit einer Änderung der Routenermächtigung verwechselt wird.

Gerade weil das Resultat äußerlich ruhig bleibt, ist die Warnung kein Zusatzkomfort. Direkt vor der Prüfung der sechs VRPs steht im Skript, der Validator müsse wegen des fehlenden Manifests warnen. Die nächste Zeile enthält eine auf FORT zugeschnittene Logprüfung. Da sie mit # beginnt, behandelt eine POSIX-Shell sie als Kommentar. Die festgehaltene Version prüft über diesen Pfad den erhaltenen Ergebnissatz, nicht aber das Auftreten des angekündigten Hinweises.

Die Aussagekraft dieses Quelltextbefunds ist bewusst eng. Er beweist nicht, dass FORT, Routinator, rpki-client, rpki-prover oder ein anderer Relying Party tatsächlich geschwiegen hat. Er beweist weder einen fehlgeschlagenen Test noch falsche Erwartungswerte und sagt nichts über ein Produktionsrepository. Auch der Grund für die Auskommentierung, eine mögliche Abdeckung an anderer Stelle oder ein künftiger Aktivierungstermin sind daraus nicht abzulesen. Belegt ist nur, dass die sichtbare Warnungsassertion dieses konkreten Fallback-Szenarios am festgehaltenen Stand nicht ausgeführt wird.

Derselbe Veröffentlichungsort ist nicht dieselbe CA

RFC 9286 beschreibt ein Manifest als signiertes Inventar der Zertifikate, der CRL und der signierten Objekte, die zu einem CA-Veröffentlichungspunkt gehören. Mehrere CA-Instanzen dürfen einen Veröffentlichungsort gemeinsam nutzen. Jedes Manifest beschreibt dennoch nur die zugehörige CA-Instanz. Die Identitätsgrenze verläuft daher nicht schlicht um ein Verzeichnis.

Die Manifestverarbeitung erfolgt für jede CA-Instanz getrennt, geführt von der Manifest-URI im SIA des CA-Zertifikats. Scheitert der Abruf, endet dieser Verarbeitungsschritt und geht in den Fehlerpfad für genau diese Instanz über. Andere Dateien am selben Ort ersetzen das fehlende Manifest nicht. Ebenso wenig reicht ein gemeinsamer Repository-Pfad aus, um einen Cache eindeutig einer CA-Identität zuzuordnen.

Im Fehlerpfad setzt die RFC zwei verschiedene normative Anweisungen. Der fehlgeschlagene Abruf muss eine Warnung hervorbringen, die den Abbruchgrund für die betreffende CA-Instanz nennt; zusätzlich wird empfohlen, einen menschlichen Operator zu benachrichtigen. Davon getrennt sollte der Relying Party die mit derselben Instanz verbundenen Cache-Objekte weiterverwenden, bis sie veralten oder nach einem erfolgreichen Abruf ersetzt werden.

Beide Regeln bilden gemeinsam eine sichere Haltung, aber keine Regel kann die andere beweisen. Der Cache beantwortet, welche Objekte die Validierungsentscheidung weiterhin tragen. Die Warnung beantwortet, warum ein Teil dieser Objekte nicht aus einem aktuellen Abruf stammt, welche CA betroffen ist und wer reagieren sollte. Sechs VRPs können sowohl aus einem vollständig frischen Lauf als auch aus einem Lauf mit zwei fortgeschriebenen Ergebnissen stammen. In der Zahl selbst steckt keine Herkunft.

Damit wird Beobachtbarkeit zur Sicherheitsgrenze. Die Cache-Entscheidung verhindert einen unnötigen Sprung im Kontrollzustand. Das Warnsignal verhindert, dass dieser ruhige Kontrollzustand als störungsfreie Erneuerung missverstanden wird. Wenn eine Testsuite nur die Endmenge prüft, kann ein Operator nicht zwischen „sechs frisch geladene VRPs“ und „sechs VRPs, davon zwei wegen eines Abruffehlers aus dem Cache“ unterscheiden.

Die RFC begründet diese Schonfrist mit der Möglichkeit, dass ein späterer Abruf das Problem auflöst. Der letzte erfolgreiche Zustand schützt in der Zwischenzeit vor einer falschen Interpretation des Repositories. Die Schonfrist ist aber weder zeitlos noch still. Cache-Objekte haben Frischegrenzen, ein neuer Versuch muss folgen, und der Grund der Fortführung muss sichtbar sein. Erst diese Kombination macht aus einem Fehler einen kontrollierten Degradationszustand.

Der Nachbartest zeigt die fehlende Hälfte

Die gleiche Änderung führte einen hilfreichen Vergleichsfall ein. Dort ändern sich CA-Zertifikat und Manifest-URI im SIA. Behandelt wird also ein defekter SIA-Verweis mit veränderter CA-Identität, nicht das vorübergehend fehlende Manifest derselben Instanz. Der erwartete VRP-Satz lässt die betroffene CA weg und behält die Ergebnisse einer Schwester-CA sowie der neuen CA. Außerdem wird eine check_logfile-Prüfung auf eine Warnung tatsächlich ausgeführt.

Aus diesem Unterschied folgt kein Produkturteil. Er zeigt etwas Präziseres: Rapport kann die Identität einer CA-Instanz von der Kontinuität ihres Veröffentlichungsorts unterscheiden, und die Testsuite kann in einem benachbarten Szenario eine operatorseitig sichtbare Diagnose prüfen. Die erkennbare Lücke liegt darin, beide Fähigkeiten auch beim Cache-Fallback derselben Instanz in einem Abnahmeergebnis zusammenzuführen.

Ein beliebiges Vorkommen des Wortes „Warnung“ wäre dabei zu schwach. Im Fall des defekten SIA werden die betroffenen VRPs entfernt; im Fall des fehlenden Manifests bleiben sie erhalten. Beide Fälle können warnen, müssen aber unterschiedliche Gründe und Maßnahmen ausdrücken. Eine brauchbare Assertion bindet deshalb Fehlerklasse, CA-Instanz und Fallback-Entscheidung zusammen. Sonst könnte ein Test mit der Warnung eines anderen Ereignisses oder mit einer falschen Cache-Entscheidung bestehen.

Nicht der FORT-Satz ist die Schnittstelle

Die vorhandene Zeile einfach zu aktivieren wäre technisch naheliegend, würde aber den genauen Wortlaut eines FORT-Logs zur gemeinsamen Schnittstelle machen. Produktmeldungen ändern Großschreibung, Wortfolge und Detailgrad aus guten Gründen. Bricht die Suite bei jeder redaktionellen Verbesserung, konkurriert die Warnungsprüfung mit der Wartbarkeit und wird leicht wieder deaktiviert oder bis zur Bedeutungslosigkeit aufgeweicht.

Eine Testsuite für mehrere Relying Parties sollte ein semantisches Ereignis definieren. Es muss mindestens die Fehlerklasse „Manifest nicht abrufbar“, eine stabile Referenz auf die betroffene CA-Instanz, die Entscheidung zur Cache-Nutzung, Cache-Alter oder Frischegrenze, Schweregrad, Emissionszeit und den Status von Benachrichtigung oder Eskalation enthalten. Ein Adapter je Implementierung kann diese Felder aus einem strukturierten Ereignis, einer Metrik, einem Systemlog oder einer dokumentierten Diagnose gewinnen.

Portabilität bedeutet dabei nicht Beliebigkeit. Zeitformat, Reihenfolge und natürliche Sprache dürfen variieren. Der Grund darf aber nicht zu einer kontextlosen Allgemeinmeldung schrumpfen. Die CA muss identifizierbar bleiben, und die Cache-Entscheidung darf nicht erst aus der VRP-Anzahl erraten werden. Eine gemeinsame Semantik trennt unverzichtbare Information von erlaubter Produktdarstellung.

Die Abnahmequittung mit zwei Spalten

Jeder Lauf sollte zusätzlich zum Gesamtstatus eine Quittung erzeugen. Die erste Spalte beschreibt die Cache-Entscheidung: Kennung der CA-Instanz, Fingerabdruck des aktuellen Zertifikats und SIA, letzter erfolgreicher Abruf, Cache-Satz oder dessen Digest, Frischegrenze, Grund des aktuellen Fehlschlags, Delta der behaltenen und entfernten VRPs, Isolation der Schwester-CAs und nächster Wiederholungsversuch.

Die zweite Spalte beschreibt das Betriebssignal: erkannte semantische Fehlerklasse, CA-Referenz, ausdrückliche Fallback-Entscheidung, Cache-Alter, Schweregrad, Ausgabezeit und Zustellung an den vorgesehenen Log-, Metrik-, Bereitschafts- oder Eskalationsweg. Beide Spalten müssen auf die jeweilige Ursprungsinformation verweisen, damit eine Prüfung nicht nur das Endurteil, sondern dessen Grundlage nachvollziehen kann.

Diese Form verhindert zwei bequeme Abkürzungen. „Die VRPs sind erhalten“ bedeutet nicht „der Operator wurde gewarnt“. „Eine Warnung erschien“ bedeutet nicht „der richtige Cache wurde erhalten“. Erst wenn beide Spalten unabhängig bestehen, ist die von RFC 9286 beschriebene Haltung vollständig belegt: Der Dienst arbeitet kontrolliert mit einem letzten validierten Zustand weiter, und dessen sinkende Aktualität bleibt nicht unsichtbar.

Die Bindung an die CA-Instanz ist besonders wichtig. Da mehrere Instanzen denselben Veröffentlichungsort teilen können, beweist der Ort allein nicht die Zugehörigkeit gecachter Objekte. Zertifikats- und SIA-Fingerabdruck, letzter erfolgreicher Zustand und Isolation der Schwester-CAs verhindern, dass alte Objekte der falschen Identität zugeschlagen werden. Dieselbe Referenz im Warnereignis macht aus einem allgemeinen Repository-Alarm eine handlungsfähige Diagnose.

Was der öffentliche Befund trägt

LACNIC stellte Rapport als Tester für RPKI-Relying-Parties vor; das Repository bezeichnet die Arbeit als frühe Entwicklungsphase. Gerade in dieser Phase sind offene Testskripte wertvoll. Sie zeigen, wie normative Sätze in ausführbare Szenarien übersetzt werden, und machen eine noch nicht ausgeführte Kontrollkante sichtbar.

Der festgehaltene Stand trägt vier begrenzte Aussagen. Die Änderung vom 4. September 2026 trennte Identitätswechsel und Fallback derselben CA-Instanz. Das zweite Szenario erwartet sechs VRPs, darunter zwei aus dem betroffenen Cache. Sein Kommentar verlangt eine Warnung, aber die Prüfzeile ist auskommentiert. RFC 9286 formuliert Warnung und Cache-Fortführung getrennt, während der Nachbartest zeigt, dass das Framework eine Logprüfung ausführen kann.

Er trägt keine Behauptung über das reale Schweigen eines Validators, den Produktionseinsatz von Rapport oder die Absicht der Maintainer. Der überprüfbare nächste Schritt ist nicht, diese Lücken mit Vermutungen zu füllen. Er besteht darin, zwei Testergebnisse auszuweisen und für jedes eine eigene Beweisspur aufzubewahren.

Quellen