Zusammenfassung

  • RFC 9323 von Job Snijders, Tom Harrison und Ben Maddison ermöglicht den Nachweis, dass ein für eine bestimmte Teilmenge von IP-Adressen oder AS-Nummern autorisierter Schlüssel eine Liste mit den exakten Hashes ausgewählter Dateien signiert hat.
  • Eine gültige RSC bestätigt weder eine natürliche Person noch gesellschaftsrechtliche Vertretungsmacht, inhaltliche Wahrheit, Rechtmäßigkeit oder eine Pflicht zur Annahme eines BYOIP- oder Interconnection-Antrags. Diese Entscheidungen brauchen eigene Belege.

Ein richtiger Hash ist noch keine richtige Entscheidung

Beim Bring Your Own IP übergibt ein Kunde einem Cloud- oder Hosting-Anbieter Unterlagen zu Adressraum, den der Anbieter künftig ankündigen soll. Der Empfänger möchte ausschließen, dass Briefe, Formulare oder Konfigurationen unterwegs vertauscht wurden. Außerdem soll das Paket maschinenlesbar mit den betroffenen Ressourcen verbunden sein.

Selbst perfekte Antworten auf beide Fragen reichen nicht für die Freigabe. Gehört der Absender zum Kundenkonto? Darf diese Person das Unternehmen binden? Ist das Dokument noch aktuell? Wird das Präfix bereits anderswo genutzt? Ist die geplante Routing-Änderung sicher?

RFC 9323, seit November 2022 ein IETF Proposed Standard, bearbeitet bewusst nur den kryptografisch greifbaren Teil. Job Snijders, Tom Harrison und Ben Maddison definieren die RPKI Signed Checklist, kurz RSC. Das CMS-Objekt enthält Internet-Nummernressourcen, einen Digest-Algorithmus und eine Liste von Hashes externer Dateien.

Die Dateien selbst bleiben außerhalb. Der Empfänger berechnet ihre Hashes neu und sucht die passenden Listenelemente. Ein Erfolg bedeutet: Ein im gewählten RPKI-Vertrauensmodell für diese Ressourcen autorisierter Schlüssel hat eine Liste signiert, die genau auf diese Bytes verweist.

Er bedeutet nicht, dass der Text wahr ist, die Person eine Firma vertreten darf oder der Empfänger handeln muss. Gerade diese sprachliche Disziplin macht aus der RSC einen belastbaren Baustein.

Der IETF Datatracker dokumentiert Snijders' Arbeiten zur Routing-Sicherheit. OpenBSD nennt ihn als einen der Hauptentwickler von rpki-client und Betreuer der portablen Fassung. Das wiederkehrende Muster ist eine prüfbare, begrenzte Aussage anstelle eines universellen Vertrauensversprechens.

Was die Liste tatsächlich enthält

Eine RSC muss mindestens einen IP-Adressblock oder eine AS-Kennung angeben. Dazu kommen ein Hash-Algorithmus und ein oder mehrere Listenelemente. Jedes Element enthält einen Digest; ein Dateiname ist möglich, aber nicht zwingend.

Die aufgelisteten Ressourcen müssen eine Teilmenge der Ressourcen im eingebetteten End-Entity-Zertifikat sein. Ein Schlüssel kann seinen Zuständigkeitsbereich nicht dadurch vergrößern, dass er ein fremdes Präfix in die Liste schreibt. Überschreitet die RSC den Zertifikatsumfang, muss die Validierung scheitern.

Der Hash bindet die Signatur an eine exakte Bytefolge. Schon eine geänderte Zahl, Zeichencodierung oder Anlage erzeugt gewöhnlich einen anderen Wert. So lässt sich Austausch erkennen. Ob ein Satz sachlich richtig oder ein Formular rechtlich ausreichend ist, kann der Digest nicht beurteilen.

Der Dateiname wird getrennt behandelt. Bei namenssensitiver Prüfung müssen Name und Hash passen. Bei namensunabhängiger Prüfung darf das passende Element keinen Namen tragen. Ein Verfahren entscheidet damit ausdrücklich, ob die benannte Akte oder nur ihr identischer Inhalt attestiert werden soll.

Ein Name wie authorization.pdf klingt überzeugend, ist aber keine Vollmacht. Umgekehrt kann dieselbe Bytefolge umbenannt werden. Die RSC verhindert, dass ein freundliches Etikett den Beweis ersetzt.

Ein Einmalzertifikat ist kein Firmenausweis

Für jede RSC werden ein neues Schlüsselpaar und ein einmaliges End-Entity-Zertifikat erzeugt. Nach der Signatur wird der private Schlüssel vernichtet. Das Zertifikat enthält keine SIA-Erweiterung, weil das Objekt nicht aus dem öffentlichen RPKI-Repository bezogen werden soll.

Diese Konstruktion erschwert die Wiederverwendung als dauerhafter Login, Personalausweis oder Firmensiegel. Das Zertifikat dient einem signierten Objekt und einem begrenzten Ressourcenbereich. Ablauf oder Widerruf können die Bewertung später ändern.

RFC 6480 zieht die grundlegende Grenze. Ressourcenzertifikate verbinden einen öffentlichen Schlüssel mit IP-Adressen oder AS-Nummern, bescheinigen jedoch nicht die beschreibende Identität des Subjekts. Die RSC hebt diese Grenze nicht auf.

RFC 9255 warnt ausdrücklich davor, RPKI-Zugangsdaten zur Authentifizierung realer Dokumente oder Geschäfte zu verwenden. Ein Ressourcenverwaltungskonto kann bei einem technischen Administrator mit engem Auftrag liegen. Ressourcenkontrolle ist keine gesellschaftsrechtliche Vollmacht.

Ein Unternehmen kann die ROA-Pflege an sein Netzteam oder einen Dienstleister delegieren, ohne Vertrags- oder Beschaffungsbefugnisse zu übertragen. Wer beide Rollen gleichsetzt, beschleunigt mit korrekter Kryptografie einen institutionell falschen Schluss.

Validierung als nachvollziehbare Kette

Zunächst prüft der Empfänger CMS-Hülle, Zertifikatspfad, Ressourcenbegrenzung und die objektspezifischen Regeln von RFC 9323. Danach berechnet er für jede ausgewählte Datei den Hash und sucht das passende Element.

Im namenssensitiven Modus müssen Name und Digest exakt passen. Im anderen Modus muss das gefundene Element namenlos sein. Der Empfänger darf weniger Dateien prüfen, als die Liste enthält. Nicht verwendete Elemente sind kein fataler Fehler, sollen aber eine Warnung auslösen, damit fehlende Anhänge untersucht werden.

RFC 6488 erklärt die allgemeinen Prüfungen für notwendig, aber nicht hinreichend. Jeder Objekttyp braucht eine eigene semantische Validierung. RFC 6487 beschreibt Ressourcenzertifikate, RFC 9286 aktualisiert den Validierungsalgorithmus.

Eine intakte CMS-Struktur bewertet kein externes Dokument. Auch ein optionales Signing-Time-Attribut ist nicht automatisch ein maßgeblicher Transaktionszeitpunkt. Wird ein belastbarer Eingangszeitpunkt benötigt, muss ein dafür vorgesehenes Empfangsprotokoll ihn liefern.

Ein gutes System speichert deshalb getrennte Ergebnisse: Signatur gültig, Ressourcen enthalten, Bytes identisch, Identität geprüft, Vertretungsmacht bestätigt, Compliance erfüllt und Betrieb freigegeben. Einige können positiv sein, während andere offen oder abgelehnt bleiben.

Bewusst nicht im globalen Repository

RFC 9323 untersagt die Verteilung von RSCs über das globale RPKI-Repository-System. Der Transport bleibt außerhalb des Formats und kann per HTTPS, E-Mail, Wechselmedium oder über einen anderen vereinbarten Kanal erfolgen.

Das RPKI-Register der IANA weist der Signed Checklist die OID 1.2.840.113549.1.9.16.1.48 und die Endung .sig zu. Diese Koordinaten helfen Software, erzeugen aber weder ein zentrales Postfach noch eine Annahmepflicht.

Die fehlende Weltöffentlichkeit schützt Geschäftskontext. BYOIP- und Interconnection-Unterlagen gehören zu bestimmten Parteien. Eine globale Veröffentlichung der Verbindung zwischen Ressourcen und Anträgen könnte Kundenbeziehungen offenlegen, ohne die Routenursprungsvalidierung zu verbessern.

Der gewählte Übertragungsweg muss weiterhin Authentisierung, Vertraulichkeit, Aufbewahrung und Schadsoftwareprüfung leisten. Die RSC erkennt passende Bytes. Sie beweist nicht, wer das Mail- oder Webkonto bediente, und garantiert keine vollständige Lieferung.

Anbieter können daher eigene Upload-Kanäle, Dateigrenzen und Prüfverfahren betreiben. Die gemeinsame Semantik der Checkliste erleichtert Interoperabilität, ohne die Verantwortung für den Kundenprozess zu zentralisieren.

Der Empfänger behält das Nein

Liegt eine gültige RSC für ein Präfix vor und stimmen die BYOIP-Unterlagen, besitzt der Anbieter einen wichtigen Ressourcen- und Integritätsnachweis. Konto, Person, Delegation, Vertrag, Regulierung, aktuelle Präfixnutzung und Betriebssicherheit sind weiterhin offen.

Identität stammt aus der Kundenprüfung. Vertretungsmacht folgt aus Delegations- und Rechtsunterlagen. Der Zweck steht im Vertrag. Aktueller Ressourcen- und Routing-Status benötigt Register- und Netzdaten. Filter, Tests, Überwachung und Rückfallplan tragen die Betriebsfreigabe.

Eine kryptografisch gültige RSC darf deshalb aus einem dokumentierten Geschäftsgrund abgelehnt werden. Identische Dateien können veraltet sein, und ein legitimer Ressourcenadministrator kann für das Geschäft unzuständig sein. Der Empfänger widerspricht der RPKI damit nicht.

Sichere Automatisierung führt Syntax-, Zertifikats-, Ressourcen-, Signatur-, Hash- und Namensprüfungen vollständig aus. Anschließend verarbeitet sie die Ergebnisse in eigenständigen Identitäts-, Geschäfts- und Betriebsregeln. Auch diese Regeln können automatisch sein; ihre Autorität muss jedoch sichtbar getrennt bleiben.

Die Trennung erleichtert Fehleranalyse. Ein Hashfehler verweist auf Paket oder Transport, eine Ressourcengrenze auf die Zertifikatskette, ein Identitätsfehler auf den Kundenprozess und ein Routing-Risiko auf den Betrieb. Ein einziges grünes Symbol würde diese Information vernichten.

Implementierung statt Wunschbild messen

Eine veröffentlichte RFC und eine IANA-Zuweisung bedeuten noch keine allgemeine Verfügbarkeit. Der RPKI-Quartalsplan des RIPE NCC führt RSC-API-Unterstützung als für das dritte Quartal 2026 geplante, von der Community gewünschte Arbeit. Eine spätere Benutzeroberfläche hängt von Nachfrage und Kapazität ab.

Das ist ein Implementierungspfad, kein Nachweis flächendeckender Einführung. Nutzer müssen reale Portale, APIs, Validatorversionen, Algorithmen, Warnungen und Annahmeregeln prüfen.

Tests sollten Ablauf, Widerruf, Ressourcentransfer, fehlende Dateien, Umbenennung, doppelte Hashes, Teilprüfung und unbekannte Algorithmen umfassen. Entscheidend ist der organisatorische Test: Der RPKI-Administrator ist echt, besitzt aber keine geschäftliche Vollmacht.

Das MENOG-Profil verortet Snijders in der Routing- und Peering-Praxis. Dazu passt ein Standard, der unabhängigen Parteien einen kleinen gemeinsamen Beweis gibt und ihre lokale Entscheidung nicht übernimmt.

Eine starke Aussage, weil sie enden kann

Ein Digest kennt Bytes. Ein Ressourcenzertifikat kennt die Beziehung eines Schlüssels zu Nummernressourcen innerhalb eines Vertrauensmodells. Zusammen beantworten sie eine begrenzte, wertvolle Frage.

Der Absender gewinnt einen portablen Nachweis, der Empfänger eine reproduzierbare Prüfung. Beide können Identität, Absicht, Aktualität, Vollständigkeit und Risiko mit den jeweils passenden Belegen weiter untersuchen.

Job Snijders und seine Mitautoren haben institutionelles Vertrauen nicht abgeschafft. Sie haben markiert, wo eine Maschine verantwortlich urteilen kann. Die RSC signiert Bytes statt Wahrheit. Gerade diese Grenze macht sie automatisierbar.

Quellen