Zusammenfassung

  • Der am 17. September 2026 aktualisierte RPKI-Quartalsplan nennt zuerst OpenID Connect und neue API-Schlüssel, danach Compliance- und Audit-Arbeit. Die API für Resource Signed Checklists (RSC) ist nur bei freier Kapazität geplant, abhängig vom Fortschritt der ersten beiden Punkte. Eine Benutzeroberfläche soll nur bei Bedarf folgen.
  • In einem Bericht an die Routing Working Group vom Mai 2024 war noch von Signierung über API und Dashboard nach ASPA die Rede, eventuell früher bei Verzögerung des ASPA-Standards. Der archivierte Plan führte RPKI-2024#01 als zu untersuchenden Wunsch. Aus diesen Unterlagen folgt keine verpasste verbindliche Lieferfrist.
  • RFC 9323 beschreibt eine ressourcenbeschränkte Signatur über Dateiprüfsummen. Das RSC-Objekt darf nicht über das globale RPKI-Repository verteilt werden. Eine künftige Signier-API wäre deshalb nur der Anfang von Übergabe, unabhängiger Prüfung und Entscheidung der Gegenpartei.
  • Die geprüften Quellen belegen weder eine allgemein verfügbare RIPE-NCC-RSC-API noch einen Starttermin, Vorfall oder Schaden. Die Erkennung einschlägiger Erweiterungen in einer Bibliothek beweist keinen produktiven Signierdienst.

Eine Norm ist noch keine Schnittstelle

Der technische Ausgangspunkt ist solide. RFC 9323 definiert seit 2022 eine signierte Liste von Hashwerten, gebunden an einen begrenzten Satz von IP-Adressen oder AS-Nummern. Ein Empfänger kann damit kontrollieren, ob vorgelegte Dateien bytegenau zu einer durch eine Ressourcen-CA signierten Erklärung passen. Das kann bei der Mitnahme eigener IP-Adressen zu einem Cloudanbieter oder bei einer Interconnection-Anfrage helfen. Es ersetzt aber weder die Prüfung des Vertragspartners noch erzeugt die Veröffentlichung der Norm automatisch einen Dienst bei RIPE NCC.

Der aktuelle Plan macht diesen Unterschied ungewöhnlich deutlich. Die RPKI-Oberfläche soll OpenID Connect aus RIPE NCC Access verwenden; bestehende RPKI-API-Schlüssel sollen durch an das SSO angebundene Schlüssel ersetzt werden. Parallel arbeitet das Team an ISO 27001 für die Organisation und einem im Mai begonnenen neuen SOC 2 Type II Audit. Erst im dritten Punkt steht RSC-Unterstützung per API, mit dem ausdrücklichen Vorbehalt verfügbarer Teamkapazität. Für eine grafische Oberfläche will man später Nachfrage sehen. Weder ein RSC-Startdatum noch ein öffentliches Request-Schema wird genannt.

Es ist vernünftig, Identitäts- und Prüfgrundlagen vor eine neue Signaturart zu setzen. Die Frage ist nicht, ob RIPE NCC überhaupt priorisieren darf. Die Frage ist, wann ein Netzbetreiber oder Provider aus diesem Plan eine verlässliche Abhängigkeit für seinen eigenen Dienst ableiten kann. Solange die API nur ein bedingter Arbeitspunkt ist, kann eine Integrationszusage an Kunden nicht mit einem verfügbaren RIPE-NCC-Endpunkt begründet werden.

Der frühere Fahrplan hatte eine andere Reichweite

Im Mai 2024 beschrieb RIPE NCC gegenüber der Routing WG ein konkretes Beispiel: Der Inhaber eines Präfixes könnte eine vom Provider gestellte Aufgabe signieren und so für ein Bring-Your-Own-IP-Verfahren einen besseren Beleg liefern als eine beliebig weiterleitbare Erklärung. Die Nachricht schlug Unterstützung im Dashboard und in der API nach ASPA vor; falls dessen IETF-Last-Call nicht vorankäme, konnte RSC früher an die Reihe kommen. Im Planarchiv blieb daraus ein Community-Punkt, dessen Möglichkeiten untersucht und später beantwortet werden sollten.

Die neuere Planung verändert sowohl Reihenfolge als auch Umfang. Zuerst stehen Authentifizierung und Audit; danach eine mögliche API; die Oberfläche ist optional. Das ist kein Beweis für Wortbruch. Die Nachricht von 2024 war kein Vertrag, das Archiv meldete keinen Abschluss, und der Plan von 2026 spricht nicht von einer zurückgenommenen Funktion. Für Anwender ist die Änderung dennoch wesentlich: Eine frühere Projektidee darf nicht mehr als aktuelle Lieferzusage in ihre Architektur eingehen.

Die RPKI-Management-API-Dokumentation beschreibt die Verwaltung einer LIR-Zertifizierungsstelle und ihrer ROAs per Zugangsschlüssel. Sie bietet keinen öffentlichen Vertrag für RSC-Erzeugung. Damit ist nicht ausgeschlossen, dass es interne Versuche gibt; der öffentlich nutzbare Umfang wird dadurch aber nicht erweitert. Das Änderungsprotokoll von rpki-commons nennt 2024 eine erste Erkennung von RSC-bezogenen Erweiterungen. Ein Parser, der ein Format versteht, ist keine Betriebszusage für die Ausgabe des Formats.

Das signierte Objekt bleibt außerhalb des Welt-Repositories

Die Unterscheidung zur ROA wird an der Verteilung sichtbar. Die Nachricht von 2024 verwendet an einer Stelle eine weite Formulierung, die nach Veröffentlichung „im RPKI“ klingt. Einige Zeilen später erklärt sie genauer, dass RSCs gerade nicht im globalen RPKI-Repository liegen, sondern zwischen Signierer und Prüfer ausgetauscht werden. RFC 9323 ist hierbei die maßgebliche technische Quelle: Das einmal verwendete End-Entity-Zertifikat enthält keine Repository-Adresse; der globale Publikationsweg ist für RSCs ausgeschlossen.

Für einen künftigen API-Dienst genügte deshalb nicht die Meldung „Signatur erfolgreich“. Der Antragsteller müsste die .sig-Datei erhalten und mit den exakt zugehörigen Unterlagen an einen bestimmten Empfänger geben. Dieser müsste Zertifikatskette, Ressourcenbereich, Hashalgorithmus und die empfangenen Dateien prüfen. Dann erst entscheidet er, ob die Aussage seine Anforderungen für Kundenaufnahme, Interconnection oder eine andere Vereinbarung erfüllt. Die RSC ist keine ROA, keine BGP-Freigabe und kein Objekt, das alle Routenvalidatoren automatisch aus dem Repository laden.

Ein API-first-Start kann für erfahrene Betreiber sinnvoll sein. Er braucht aber eine klare Beschreibung von Antragsteller und Ressourcenumfang, Abruf des Ergebnisses, Fehlern, Gültigkeit und unabhängig reproduzierbaren Testfällen. Das sind Anforderungen an die spätere Abnahme, keine Feststellung eines heutigen Mangels. Der veröffentlichte Plan beantwortet sie für RSC noch nicht.

Wer unterschreibt, entscheidet nicht alles

Auch eine kryptografisch gültige Checkliste hat Grenzen. RFC 9323 nennt den Inhalt selbstbehauptet. Der Empfänger darf aus der Validierung nur auf ausreichende Kontrolle der ausstellenden CA schließen, nicht auf die bürgerliche Identität, Vollmacht oder rechtliche Eigentümerstellung des Signierers. Im Archiv verwendet RIPE NCC als mögliches Beispiel einen „Eigentumsnachweis“ für eine AS-Nummer. Diese lockere Beschreibung überschreibt die engere Aussage des Standards nicht.

Andere BTW-Artikel analysieren diese allgemeine Grenze zwischen Dateinachweis und Mandat bereits. Hier geht es um die RIPE-NCC-spezifische Betriebsfolge: Welche Arbeiten gehen vor, was würde zuerst ausgeliefert, und wie gelangt ein außerhalb des globalen Repositories ausgetauschtes Beweisobjekt zu seinem Prüfer? Nach dem geprüften Stand lässt sich nur sagen: Zwei Vorhaben laufen, RSC als API bleibt bedingt geplant, eine Oberfläche ist ungewiss. Ein tatsächlicher RSC-Zwischenfall oder ein gescheitertes Kundengeschäft ist nicht belegt.

Quellen