Zusammenfassung

  • Eine gültige RSC zeigt, dass eine Partei mit hinreichender Kontrolle über die ausstellende CA eine Liste signierte, die einen Ressourcen-Teilbestand mit Hashes digitaler Objekte verbindet. Sie beweist keine reale Identität, Eigentum, Organbefugnis oder Vollständigkeit.
  • Annahmeverfahren müssen CMS- und Zertifikatsprüfung, die konkrete Dateiübereinstimmung einschließlich Warnungen sowie die externe Identitäts- und Mandatsprüfung getrennt dokumentieren.

Betrachten wir eine illustrative Prüfung vor dem Erwerb von Netzwerkvermögen. Der Verkäufer liefert eine Adress-Tabelle, ein komprimiertes Anlagenverzeichnis und eine .sig-Datei. Das Werkzeug bestätigt beide Hashes, Zertifikatskette, CRL und den Ressourcen-Teilbestand.

Die Checkliste enthält einen dritten Eintrag, dessen Datei fehlt. Nach RFC 9323 müssen die beiden gelieferten Objekte deshalb nicht scheitern; die Implementierung sollte vor der längeren Checkliste warnen. Das Gremium folgert trotzdem Eigentum, Veräußerungsbefugnis und vollständige Offenlegung.

Die technische Prüfung war richtig. Die Schlussfolgerung überschritt ihren Gegenstand.

Was im Objekt steht

Die RSC ist ein CMS-geschütztes RPKI Signed Object. id-ct-signedChecklist verwendet die OID 1.2.840.113549.1.9.16.1.48. Das IANA-RPKI-Register führt Signed Checklist und .sig; der Medientyp lautet application/rpki-checklist.

Der Ressourcenblock enthält AS-Kennungen, IP-Blöcke oder beides. Jede Ressource muss Teilmenge der entsprechenden RFC-3779-Erweiterung im EE-Zertifikat sein; inherit ist verboten. Danach folgen Digest-Algorithmus und Einträge mit Pflicht-Hash und optionalem portablem Dateinamen. Benannte Einträge benötigen eindeutige Namen, unbenannte eindeutige Hashes.

Die Struktur bezeichnet Ressourcen und Bytes. Unternehmensname, Rolle, Vertrag und Eigentum gehören nicht dazu.

Vier getrennte Urteile

RFC 6488 verlangt DER-CMS, zulässige Attribute, genau ein passendes EE-Zertifikat, eine verifizierbare Signatur und einen gültigen Pfad zu einem RPKI Trust Anchor. Diese Prüfungen sind notwendig, aber ohne objektspezifische Regeln nicht hinreichend.

RFC 9323 ergänzt RSC-Syntax, Ressourcenbeziehung, Checklistenregeln und das Verbot einer SIA-Erweiterung. Das Zertifikat muss zum Prüfzeitpunkt gültig und nicht widerrufen sein. Ablauf oder Widerruf beendet die Gültigkeit eines zuvor gültigen Objekts.

Anschließend wird der Hash der gelieferten Bytes berechnet. Filename-aware verlangt genau einen Treffer mit identischem Namen. Filename-unaware verlangt genau einen Treffer ohne Namen. Die Moduswahl muss im Befund stehen.

Erst danach folgt das Geschäfts- oder Rechtsurteil: Wer übergab das Objekt, darf diese Person die Organisation binden und sind alle zwecknotwendigen Unterlagen vorhanden? Kein voriger Test beantwortet diese Fragen.

Der Digest versteht keine Aussage

Ein unverändertes falsches Dokument passt perfekt zu seinem Hash. Die Signatur konserviert Bytes, sie prüft weder Eigentum noch Richtigkeit. Umgekehrt können Zeilenende oder Zeichenkodierung bei semantisch gleichem Text einen anderen Digest erzeugen. RFC 9323 empfiehlt deshalb verlustfreie Kompression für Text, um unbeabsichtigte Kanonisierung zu vermeiden.

Auch ein Dateiname garantiert keinen Inhalt. Er verhindert bestimmte Vertauschungen, aber eine Datei namens Inventar muss nicht vollständig sein.

Protokoll-Teilmenge und geschäftliche Vollständigkeit

Nicht jeder Checklisten-Eintrag muss in einer Prüfung verwendet werden. Das erlaubt Empfängern, verschiedene Teilmengen zu prüfen. Überzählige Einträge lösen eine Warnung aus, nicht zwingend einen Fehler.

Vollständigkeit muss außerhalb der RSC definiert werden. Für einen Erwerb können Registrierungsrechte, Kundenzuordnungen, Sicherheiten, Streitigkeiten, Anlageneigentum, Vorfälle, Zugänge und Vollmachten verlangt sein. Die RSC belegt gelieferte Dateien innerhalb ihrer Liste; die Due-Diligence-Matrix bestimmt, was geliefert werden musste.

Der Bericht trennt Treffer, gelieferte Dateien ohne Treffer, Einträge ohne Datei und Anforderungen, die gar nicht in der RSC stehen.

CA-Kontrolle ist keine Identität

RFC 9323 bezeichnet die Daten als selbst behauptet. Der Relying Party darf nur schließen, dass hinreichende Kontrolle über die ausstellende CA bestand. Die übergeordnete CA prüfte den Listeninhalt nicht.

RFC 9255 stellt klar: Das I in RPKI steht für Infrastructure, nicht Identity. RPKI autorisiert Aussagen über Ressourcen und authentifiziert keinen realen Inhaber oder Geschäftsvorgang.

Bei Hosted RPKI kann ein Benutzer per Konto eine Signatur auslösen, ohne den privaten Schlüssel zu besitzen. Er kann Eigentümer, begrenzt befugter Netzadministrator, Dienstleister oder Angreifer sein. Selbst der legitime Administrator darf nicht zwingend Vermögen verkaufen.

Issuer- und Subject-Namen helfen nicht; RFC 6487 beabsichtigt sie nicht als beschreibende Identität. Handelsregister, Organbeschluss, Vollmacht, Vertrag oder andere exogene Autorität müssen Akteur, Organisation, Handlung, Zweck und Geltungszeit belegen.

Außerhalb des Repositories, gekoppelt widerrufbar

RSCs werden nicht über das öffentliche RPKI Repository verteilt. Ohne Kopie kann ein Dritter ihre Existenz nicht kennen. Seriennummernlücken oder unbekannte CRL-Einträge beweisen keine RSC.

Der Übergabekanal ist ein eigener Beleg. Authentifiziertes Portal, bekannte Mail und anonymer Link können identische Bytes mit anderem Absenderkontext liefern. Kanal und RSC-Validierung ersetzen einander nicht.

Ein einmaliges EE-Zertifikat erlaubt den Widerruf des einzelnen Objekts. Verwendet eine CA denselben Schlüssel für mehrere RSCs, können sie nicht einzeln widerrufen werden. Eine Effizienzentscheidung koppelt unabhängige Aussagen.

RFC 9589 verlangt signing-time, fordert aber keine korrekte Zeitangabe. Sie ist kein zuverlässiger Signaturzeitpunkt. Prüfzeit, Zertifikatsgültigkeit, CRL und Vertragschronologie bleiben getrennt.

Auch die Nichtaussage protokollieren

Der Annahmenachweis enthält RSC-Bytes und Hash, Kanal, OID, Zertifikat, Kette, CRL, Prüfzeit, Ressourcen, Algorithmus, Dateien, Namen, Modus, Treffer, ungenutzte Einträge, Warnungen, Identität, Mandat und Entscheidung. Er nennt ausdrücklich, was nicht bewiesen wurde: Eigentum, Wahrheit, Vollständigkeit, Vertretungsmacht, zuverlässige Zeit oder BGP-Ursprungsautorisierung.

Die Enge ist kein Mangel. Sie macht die RSC deterministisch. Der Empfänger bewahrt diese Stärke nur, wenn jede darüber hinausgehende Autorität einen eigenen Nachweis erhält.

Quellen