Zusammenfassung

  • RFC 9674 verlangt für Snapshot- und Delta-URIs sowie alle HTTP-Redirect-Ziele denselben Origin wie für die RRDP Notification: Scheme, Host und Port müssen übereinstimmen.
  • Erreichbarkeit, gemeinsame Betreiberzuordnung, TLS und ein passender Datei-Hash verleihen einem anderen Origin keine Abrufbefugnis.
  • Der Origin-Test ist nur das Eingangstor. RRDP-Format, Session, Serial und Hash, danach Zertifikat, CRL, Manifest, Signed Object, validierter Cache, Router-Sitzung und Routing Policy bleiben eigenständig.

Das Dashboard meldete einen erfolgreichen Download und einen passenden Hash. Dieselbe Ansicht leitete daraus „RRDP gesund“ und „Router aktuell“ ab. Im Rohprotokoll lag dazwischen jedoch ein Redirect auf einen anderen Origin. Nach RFC 9674 musste die Sitzung verworfen werden, bevor über den Zustand des Routers überhaupt gesprochen werden konnte.

Der Fehler ist typisch für verdichtete Zustandsmodelle. Ein Endergebnis wird auf mehrere Subjekte verteilt, obwohl jeder Übergang eine eigene Autorität und einen eigenen Ausführungsnachweis besitzt.

Der Origin ist kleiner als die Organisation

RFC 6454 bestimmt einen Origin aus Scheme, Host und Port. Ein gemeinsamer Eigentümer oder ein gemeinsames Zertifikat gehört nicht zum Vergleich. http und https bleiben getrennt; zwei Hosts bleiben getrennt; 443 und 8443 bleiben getrennt.

RFC 8182 beginnt mit einer rpkiNotify-Adresse im SIA eines Ressourcenzertifikats. Die Update Notification nennt Session, Serial, einen Snapshot und mögliche Deltas. Hashes binden die referenzierten Dateien an den Index.

Die ursprüngliche Fassung untersagte Cross-Origin-Referenzen nicht ausdrücklich und schwieg zu HTTP-Redirects. RFC 9674 ergänzt deshalb Server- und Clientpflichten. Repository Server müssen Referenzen im Origin der Notification halten und dürfen nicht hinaus redirecten. Relying Parties müssen vergleichen, bei Abweichung ablehnen und sollten den Fund protokollieren.

Das ist kein allgemeines Browsermodell. Cookies, Skripte und CORS sind nicht Gegenstand der Regel. Entscheidend ist nur, dass ein über ein Zertifikat entdecktes Dokument keinen fremden URI-Principal zum Abrufziel machen darf.

Ein Redirect ist Teil des Beweises

RFC 9110 beschreibt Redirects als Aufforderung zu einer weiteren Aktion an einer anderen URI. Wer nur den letzten 200-Status speichert, entfernt die Aktion, an der RFC 9674 entscheidet.

Ein belastbares Protokoll enthält die SIA-URI, ihren normalisierten Origin, jede Snapshot- und Delta-Referenz, jeden HTTP-Status und Location-Wert sowie die Vergleichsentscheidung vor dem nächsten Request. Der passende Hash am Ende reicht nicht. Er beweist Bytes, nicht Abrufbefugnis.

Diese Unterscheidung schützt auch Ressourcen. Ohne Same-Origin-Grenze könnte ein Repository viele Clients veranlassen, Daten von einem anderen Repository abzurufen und dessen Last zu erhöhen. Der richtige Inhalt am falschen Principal löst dieses Problem nicht.

Same-Origin ist zugleich kein Qualitätsurteil über den Server. Ein erlaubter Origin kann fehlerhaftes XML, unpassende Serials oder einen Hash-Mismatch liefern. Autorität und Integrität sind verschiedene Kontrollen.

Nach dem Origin folgen die RRDP-Regeln

RFC 8182 verlangt eine wohlgeformte, schema-konforme Notification. session_id und Notification-Location gehören zusammen. Deltas müssen eine brauchbare Kette bilden. Snapshot und Deltas müssen den referenzierten Hashes sowie Session und Serial entsprechen.

Ein abgelehntes Delta kann zum Snapshot führen. Ein abgelehnter Snapshot macht RRDP unbrauchbar. Ein alternativer SIA Access Method eröffnet einen anderen Abrufweg, repariert aber nicht die verworfene Sitzung.

Auch ein vollständig synchronisiertes Repository ist noch kein validierter RPKI-Zustand. RFC 6480 trennt Ressourcenzertifikate, Signed Objects und das Repository. RFC 6487 definiert Zertifikate, CRLs und Pfadvalidierung. RFC 9286 gibt dem Manifest Nummern, Zeiten und ein Datei-/Hash-Inventar.

Ein Same-Origin-Snapshot mit richtigem Transport-Hash kann später an Zertifikat, CRL, Manifest oder Objektvalidierung scheitern. Der Ursprung eines Pakets ersetzt nicht die Prüfung seiner Behauptungen.

Ein validierter Cache ist noch kein Router

RFC 7115 bezeichnet tatsächlich verifizierte Objekte als validierten Cache. RFC 8210 definiert danach ein eigenes Cache-Router-Protokoll mit Version, Session und Serial. RFC 6811 liefert Origin-Validation-States, die erst lokale Routing Policy verwenden kann.

Die Nachweiskette lautet deshalb: Origin-Entscheidung, RRDP-Integrität, Objektvalidierung, validierter Payload, Router-Aufnahme, Policy-Entscheidung, ausgewählte Route und beobachteter Verkehr. Ein gemeinsames Grün kann nicht sagen, welches Subjekt gemeint ist.

Auch Incident-Sprache muss begrenzt bleiben. Ein Cross-Origin-Ereignis belegt eine Protokollverletzung, nicht automatisch Absicht oder Kompromittierung. Ein Same-Origin-Erfolg belegt keine Frische, Ehrlichkeit oder Weiterleitungswirkung.

Die Messung im RFC hatte ein Datum

RFC 9674 berichtet, dass in den untersuchten Archiven von Oktober 2021 bis Oktober 2024 keine Cross-Origin-URIs in Notifications beobachtet wurden. In einem weiteren Zeitraum 2024 nutzte ein Server einen Same-Origin-Redirect. Diese Daten stützten die damalige Deployability.

Sie sind keine aktuelle Weltvermessung. Zeitraum, Population und Fragestellung müssen an der Aussage bleiben. Dasselbe gilt für einen internen Test nach einem CDN- oder Portwechsel.

Die minimale Anfangsspezifikation hält die gemeinsame Pflicht klein und prüfbar. Die Realitätsebenen trennen Organisation, URI, Bytes, validiertes Objekt und Route. Der Vorrang laufenden Codes verlangt Ausführungsbelege von RP, Cache und Router.

RFC 9674 zieht eine harte Grenze um eine schmale Befugnis. Seine Wirkung wird schwächer, nicht stärker, wenn ein Dashboard daraus eine Aussage über das gesamte Routing-System macht.

Quellen