Zusammenfassung

  • Die aktuelle Dokumentation der RPKI Management API des RIPE NCC beschreibt eine LIR-spezifische Schnittstelle, über die Zertifizierungsstelle und ROAs mit einem API-Zugriffsschlüssel verwaltet werden.
  • Der RPKI-Plan für das dritte Quartal 2026 führt OpenID-Connect-basierte, in RIPE NCC Access integrierte Schlüssel als „Planned“, nicht als eingeführte Funktion.
  • Derselbe Plan sagt, ein vorgeschlagener RPKI-Beacon sei nicht hinzugefügt worden, weil die verwendete API ROAs für den gesamten RIPE-NCC-Adressraum hätte bearbeiten können. Das betrifft den verworfenen Beacon-Pfad.
  • Kontobindung, Schlüssel-Lebenszyklus und die ressourcenbezogene Befugnis für eine einzelne ROA-Änderung sind unterschiedliche Nachweisobjekte.

Ein authentifizierter Aufruf beschreibt nicht seine gesamte Befugnis

Die RPKI Management API grenzt die heutige Schnittstelle klar ein. Ein LIR kann seine Zertifizierungsstelle und seine ROAs über einen API-Zugriffsschlüssel verwalten. Die Dokumentation nennt Ressourceninformationen, das Anlegen von ROAs und das Einrichten von Warnungen. Der Wert eines neuen Schlüssels wird nur einmal angezeigt, gespeichert wird ein Hash, und nicht mehr benötigte Schlüssel können widerrufen werden.

Das sind nützliche Aussagen über Zugang und Produktverhalten. Sie sind kein Beleg für die Autorisierung einer einzelnen späteren Änderung. Ein Schlüssel kann einem Konto zugeordnet sein, ohne dass damit feststeht, welche zertifizierte Ressource umfasst war, welche Operation beantragt wurde, welcher ROA-Zustand zuvor bestand oder welches Ergebnis eintrat. Aus „der Aufruf war authentifiziert“ darf nicht stillschweigend „Umfang, Befugnis und Zustandswechsel sind bewiesen“ werden.

RIPE-843 setzt eine weitere Grenze. API-Schlüssel sind dort an ein bestimmtes RIPE-NCC-Access-Konto gebunden und können deaktiviert werden, wenn dieses Konto deaktiviert wird oder die Person in der betreffenden Anwendung keine Kontoberechtigung mehr hat. Das ist eine Regel für den Lebenszyklus einer Identität. Es ist kein öffentliches Protokoll für die Ressourcenermächtigung jedes einzelnen Requests.

Geplante Identität, abgelehnter Umfang

Auf der Seite RPKI Quarterly Planning plant der RIPE NCC, die derzeitigen RPKI-API-Schlüssel durch OpenID-Connect-basierte Schlüssel zu ersetzen und ihre Verwaltung im RPKI-Dashboard zu ergänzen. Der veröffentlichte Status lautet „Planned“. Es gibt dort weder ein Einführungsdatum noch ein endgültiges Token-Design oder ein öffentliches Format für Änderungsereignisse.

Die gleiche Seite dokumentiert jedoch eine präzise Begrenzung: Ein vorgeschlagener RPKI-Beacon konnte noch nicht hinzugefügt werden, weil die dafür verwendete API das Bearbeiten von ROAs für den gesamten RIPE-NCC-Adressraum erlaubt hätte. Das war nicht akzeptabel. Diese Aussage gehört ausschließlich zum vorgeschlagenen und nicht akzeptierten Beacon-Pfad. Sie belegt weder eine entsprechende Funktion der gewöhnlichen Management API noch einen Schlüsselvorfall, eine unberechtigte ROA oder ein Routingereignis.

Gerade deshalb lässt sich die geplante OIDC-Umstellung nicht auf eine bequemere Anmeldung reduzieren. Eine integrierte Identität kann Schlüsselverwaltung verbessern. Sie beantwortet nicht automatisch die andere Kontrollfrage: Welche Ressource und welche Operation durfte ein zustandsändernder Request berühren?

Ein begrenzter Umfangsbeleg genügt

Es wäre weder nötig noch klug, Geheimnisse, Präfixe, ASNs, rohe API-Aufrufe oder Konfigurationen zu veröffentlichen. Das könnte operative Risiken schaffen, ohne die Entscheidung zu erklären. Ein schlanker, datensparsamer Umfangsbeleg kann mehr leisten.

Für eine wesentliche ROA-Änderung könnte er die Version von Zugriffsrichtlinie und Implementierung, eine nicht geheime Akteurs- oder Clientklasse, den Kontokontext, eine begrenzte Menge berechtigter Ressourcen oder einen geschützten Digest, die beantragte Aktion, geschützte Vorher- und Nachherzustände, Entscheidungs- und Ausführungszeit, Ergebnis, gegebenenfalls eine spätere Publikationsbeobachtung sowie die Korrektur- oder Ersetzungshistorie festhalten. Er bewahrt die Form der Befugnis, ohne die Ressourcen eines Halters preiszugeben.

Dies ist ein redaktioneller Entwurf, keine Anforderung des RIPE NCC. Aus dem Fehlen eines öffentlichen Details folgt nicht, dass interne Kontrollen fehlen. Die Quellen zeigen aber, dass eine geplante Identitätsmethode, ein Kontostatus und der Umfang einer einzelnen Zustandsänderung nicht dieselbe Frage sind.

Quellen