Zusammenfassung

  • Die NRO-Roadmap vom Dezember 2025 führte kurzlebige Trust-Anchor-Zertifikate als RPKI-Kernfunktion auf. Angeboten wurde sie demnach damals von APNIC, ARIN und LACNIC; für alle fünf RIRs galt Ende 2025 als Ziel.
  • Am 29. August 2026 lieferte AFRINICs veröffentlichter TAL weiterhin ein selbstsigniertes Root-Zertifikat mit einer Laufzeit vom 30. März 2020 bis zum 28. März 2030.
  • Daraus folgt eine Lücke im öffentlichen Nachweis, nicht der Beleg eines Ausfalls: Die Roadmap definiert „short-lived“ nicht und dokumentiert weder Ausnahme noch Aufschub oder eine spätere AFRINIC-Umsetzung.
  • Ein belastbarer Umsetzungsbeleg müsste Definition, ausgestelltes Zertifikat, TAL-Schlüsselkontinuität, Repository-Verfügbarkeit, beobachtete Aktualisierung bei Relying Parties, Ausnahmen, Rückfallweg und Korrekturhistorie verbinden.

Der Termin ist vorbei, der Folgezustand bleibt offen

Die entscheidende Zeile der NRO-Roadmap ist knapp. Sie nennt „Short-lived TA certificates“, führt APNIC, ARIN und LACNIC als damalige Anbieter und setzt „End of 2025“ als Termin für sämtliche Regional Internet Registries. Zuletzt geändert wurde die Seite am 2. Dezember 2025. Sie war also ein Arbeitsversprechen, kein nachträglicher Abschlussbericht.

Das ist für eine Roadmap normal. Problematisch wird die Form erst nach Ablauf des Datums. Dann braucht das Versprechen einen Anschluss: geliefert, mit Ausnahme geliefert, verschoben, durch eine andere Kontrolle ersetzt oder noch nicht abgeschlossen. Bleibt dieser Anschluss aus, müssen Außenstehende aus technischen Einzelteilen einen institutionellen Zustand erraten.

AFRINICs öffentlich erreichbarer Vertrauensanker macht diese Grenze sichtbar. Am 29. August 2026 ließ sich der veröffentlichte Trust Anchor Locator abrufen. Er verwies auf AfriNIC.cer im RPKI-Repository. Das dort gelieferte selbstsignierte Zertifikat nannte als Subject und Issuer AfriNIC-Root-Certificate, trug die Seriennummer E5CF72BA6C7E9E28 und war vom 30. März 2020 bis zum 28. März 2030 gültig. Sein SHA-256-Fingerabdruck war reproduzierbar.

Diese Beobachtung ist konkret, aber begrenzt. Das Zertifikat war erreichbar, die Adresse funktionierte, seine Felder ließen sich prüfen. Nichts davon belegt einen Routenausfall, ein ungültiges Zertifikat oder ein Sicherheitsereignis. Es zeigt lediglich, dass acht Monate nach dem gemeinsamen Zieltermin noch ein Artefakt mit ungefähr zehnjährigem Gültigkeitsfenster sichtbar war, während die öffentliche Roadmap keinen erklärenden AFRINIC-Folgezustand auswies.

Dafür kann es harmlose Gründe geben. Die Roadmap kann veraltet sein. Eine technische Umstellung kann geplant oder erprobt worden sein. AFRINIC kann eine Ausnahme oder einen späteren Austausch vorgesehen haben. Auch kann die NRO unter „short-lived“ eine genauer gefasste Eigenschaft verstehen, die auf den geprüften Seiten nicht verlinkt ist. Die Quellen entscheiden zwischen diesen Möglichkeiten nicht. Gerade deshalb darf ein Termin nicht als Nachweis behandelt werden.

Ohne Definition ist „kurzlebig“ kein Prüfkriterium

Zehn Jahre wirken lang. Trotzdem wäre es unredlich, allein aus dem Adjektiv und dem sichtbaren Intervall einen erwiesenen Zielverstoß abzuleiten. Die geprüfte Roadmap nennt keine maximale Laufzeit, keinen Erneuerungsvorlauf, keine zulässige Überlappung und keine Ausnahmeregel. Sie sagt auch nicht, ob „kurzlebig“ absolut oder im Verhältnis zur vorherigen Praxis gemeint ist.

Das Zertifikat bleibt wichtig, weil es ein beobachtbares Produktionsartefakt ist und keine Selbstdarstellung. Es liefert die untere Ebene der Prüfung. Die obere Ebene – das institutionelle Akzeptanzkriterium – fehlt. Gute Rechenschaft trennt daher drei Dinge: die Zusage, das ausgelieferte Objekt und die Entscheidung, nach welchen Belegen dieses Objekt die Zusage erfüllt.

Wer diese Ebenen zusammenzieht, belohnt Ankündigungen. Ein vorhandenes Feature in Software ist nicht automatisch produktiv eingeführt. Ein ausgestelltes Zertifikat beweist nicht, dass es am stabilen Ort verfügbar war oder von einer begrenzten, benannten Stichprobe abgerufen wurde. Und ein vergangenes Kalenderdatum beweist nichts über irgendeinen dieser Schritte.

Eine nüchterne Statusliste müsste fünf Antworten zulassen: nach veröffentlichter Definition umgesetzt; mit dokumentierter Ausnahme umgesetzt; begründet auf einen neuen Termin verschoben; durch eine andere Schutzmaßnahme ersetzt; oder noch offen. Schweigen ist kein sechster technischer Zustand. Es ist eine fehlende öffentliche Zustandsangabe.

Der TAL bindet den Schlüssel, nicht ein ewiges Zertifikat

RFC 7730 erklärt, warum eine kürzere Zertifikatslaufzeit nicht bedeutet, dass Betreiber bei jeder Erneuerung eine völlig neue Vertrauensentscheidung verteilen müssen. Ein TAL enthält Abruforte und das öffentliche Schlüsselmaterial, mit dem das Trust-Anchor-Zertifikat geprüft wird. Das referenzierte Objekt muss ein aktuelles, selbstsigniertes RPKI-CA-Zertifikat sein; sein öffentlicher Schlüssel muss zum TAL passen.

Der Vertrauensankerschlüssel soll bei gewöhnlicher Erneuerung oder einer Änderung der Ressourcen stabil bleiben. Das neu ausgestellte Zertifikat kann unter derselben URI erscheinen. Schlüsselkontinuität und Zertifikatslaufzeit sind damit getrennte Größen. Erst ein Schlüsselwechsel ist die wesentlich tiefere Vertrauensoperation.

Aus dieser Trennung folgt eine Kette von Zuständen. AFRINIC muss ein korrektes Folgezertifikat ausstellen. Das Repository muss es an der erwarteten Stelle bereitstellen. Relying-Party-Software muss es abrufen, Aktualität und Selbstsignatur prüfen, den Schlüssel mit dem TAL vergleichen und lokal akzeptieren. RFC 7730 sieht diese Prüfung bei der Repository-Synchronisierung und vor Ablauf der zwischengespeicherten Kopie vor.

Darum reicht auch die Meldung „ein kürzeres Zertifikat wurde ausgestellt“ nicht als vollständiger Betriebsnachweis. Nützlich wäre eine Kette aus definierter Laufzeit, korrekter Ausstellung, Schlüsselübereinstimmung, Veröffentlichung, begrenzter Abrufbeobachtung, bekannten Ausnahmen und erprobtem Korrekturweg.

Diese Kette sagt weiterhin nichts automatisch über Routing aus. Das Trust-Anchor-Zertifikat steht oberhalb eines Zertifizierungsbaums, aus dem Validatoren geprüfte RPKI-Nutzdaten ableiten. Die eingefrorenen Quellen belegen weder einen RPKI Invalid gewordenen Pfad noch die Ablehnung eines Präfixes, einen gescheiterten Repository-Abruf oder einen falschen Cachezustand. Dafür wären jeweils eigene Messungen nötig.

Eine kürzere Uhr verlagert das Risiko

Der Nutzen kürzerer Laufzeiten liegt nicht in der Gleichung kurz gleich sicher. Ein engeres Zeitfenster kann begrenzen, wie lange ein überholtes Zertifikat noch als aktueller Zustand gelten kann. Zugleich zwingt es Ausstellung, Veröffentlichung und Abruf dazu, von seltenen Sonderfällen zu eingeübter Routine zu werden.

Diese Routine ist selbst eine Abhängigkeit. Häufigere Erneuerungen schaffen mehr Gelegenheiten, Automation und Repository-Verhalten zu beobachten. Sie bringen aber auch den nächsten Stichtag näher. Scheitert die Ausstellung oder Veröffentlichung kurz vor Ablauf, bleibt weniger Zeit für Diagnose und Reparatur. Lange Laufzeiten reduzieren die Häufigkeit dieses Übergangs, lassen dafür einen alten Ausdruck von Ressourcen und Daten länger bestehen.

Es geht daher nicht um Sicherheit gegen Bequemlichkeit. Eine Fehlerverteilung wird gegen eine andere getauscht. Der Vorteil entsteht nur, wenn Ersatz und Abruf zuverlässig sind. Genau das sollte ein öffentlicher Nachweis sichtbar machen, ohne sensible Einzelheiten preiszugeben.

HSM-Aufbau, private Schlüssel, operative Zugangsdaten oder angreifbare Ablaufdetails gehören nicht in die Öffentlichkeit. Termine, Seriennummern, Fingerabdrücke, Ergebnisklassen, aggregierte Abrufbeobachtungen und begründete Ausnahmezustände sind dagegen öffentliche Rechenschaftsdaten.

Wie ein knapper Umsetzungsnachweis aussehen könnte

Am Anfang steht die Definition: normale Zertifikatslaufzeit, Vorlauf der Erneuerung, Überlappungsregel und zuständige Ausnahmeinstanz. Ist „kurzlebig“ relativ gemeint, müssen Vergleichsmaßstab und Ausgangswert genannt werden.

Danach folgt das Produktionsartefakt: zuständiger RIR, Seriennummer, SHA-256-Fingerabdruck, notBefore, notAfter, Repository-URI und Bestätigung der Übereinstimmung mit dem TAL-Schlüssel. Das sind öffentlich lesbare Zertifikatsdaten, keine Betriebsgeheimnisse.

Der nächste Abschnitt muss Populationen auseinanderhalten. Erstens: War das erwartete Objekt am autoritativen Veröffentlichungspunkt verfügbar? Zweitens: Hat eine erklärte Stichprobe von Validatoren es im vorgesehenen Fenster abgerufen und akzeptiert? Drittens: Welche Relying Parties lagen außerhalb der Messgrenze? Aus einer Stichprobe darf nie eine Behauptung über jeden Validator im Internet werden.

Ausnahmen gehören in denselben Datensatz. Ein altes Zertifikat kann wegen einer nicht abgeschlossenen Abhängigkeit, einer Sicherheitsprüfung oder einer geänderten Definition länger bestehen. Erforderlich sind kein vertrauliches Sitzungsprotokoll, sondern eine Kennung, ein Verantwortlicher, eine begrenzte Begründungsklasse, ein Prüftermin und eine Abschlussbedingung.

Schließlich braucht der Nachweis additive Korrekturen. Wird ein Fingerabdruck berichtigt, ein Zertifikat ersetzt oder ein Termin neu bewertet, muss der frühere Stand mit dem Nachtrag erhalten bleiben. Überschriebene Seiten verwandeln Geschichte in Gegenwart und erschweren die spätere Ursachenanalyse.

Ein AFRINIC-Fall innerhalb eines Versprechens für fünf RIRs

Das NRO-RPKI-Programm koordiniert. Es kann gemeinsame Definitionen, Vergleichbarkeit und technische Beratung organisieren. Es betreibt jedoch nicht AFRINICs Zertifizierungsstelle. AFRINIC stellt sein Trust-Anchor-Material aus und veröffentlicht es. Entwickler bestimmen das Abruf- und Akzeptanzverhalten ihrer Validatoren. Betreiber entscheiden, wie validierte Nutzdaten in ihre Routing-Politik einfließen.

Diese verteilte Kontrolle macht den Nachweis wichtiger. Ein NRO-Termin kann Arbeit ausrichten, aber er führt sie nicht aus. Ein gemeinsames Etikett darf daher nicht fünf unterschiedliche Erfolgskriterien verdecken – etwa Softwarebereitschaft bei einem RIR, erste Produktionsausstellung beim zweiten und gemessene Relying-Party-Aktualisierung beim dritten.

Der Befund ist eng zu lesen. AFRINICs Zertifikat ist eine reproduzierbare Beobachtung innerhalb einer gemeinsamen Zusage. Es beweist weder einen Defekt des AFRINIC-RPKI-Dienstes noch eine Falschdarstellung durch die NRO. Es zeigt, dass die öffentliche Beweiskette endet, bevor sich der Termin Ende 2025 mit einem akzeptierten Produktionszustand von AFRINIC verbinden lässt.

Die Lücke lässt sich schließen. Die NRO kann Definition, Status je RIR, Belegdatum und Ausnahmen ergänzen. AFRINIC kann seine Laufzeitpolitik und die nicht sensiblen Akzeptanzdaten der nächsten Ausstellung veröffentlichen. Der alte Stand sollte als Historie erhalten bleiben. Der Vertrauensanker selbst darf langweilig sein. Seine Rechenschaftskette sollte präzise werden.

Sources