Zusammenfassung

  • RFC 8181 verarbeitet eine Anfrage mit mehreren Operationen atomar; der Erfolg belegt aber nur die Client-Server-Transaktion.
  • Das Manifest nach RFC 9286 bindet Namen und Hashes des aktuellen Objektsatzes, während RRDP Snapshots und Deltas mit Sitzung und Seriennummer verteilt.
  • Das Protokoll trennt die Zustände angefordert, vom Server übernommen, mit dem Manifest konsistent, öffentlich ausgeliefert und von einer RP beobachtet.

RPKI-Publikation wirkt wie ein einzelner Schritt: Objekt erstellen oder zurückziehen, an das Repository senden und auf Validatoren warten. Die Standards beschreiben jedoch eine Kette. Eine CA oder ihr Client stößt die Änderung über das Publikationsprotokoll an, der Server übernimmt die Transaktion, ein Manifest beschreibt den aktuellen Satz, ein Verteilungsdienst stellt den Repository-Stand bereit, und Relying Parties rufen ihn nach ihrem eigenen Zeitplan ab und validieren ihn.

RFC 8181 schützt die erste Grenze mit signierten Nachrichten. Eine Anfrage kann Publikationen und Rücknahmen bündeln; entweder gelingt alles oder nichts. Ersatz und Rücknahme tragen den Hash des am URI vorhandenen Objekts. Bei Abweichung kann der Server ablehnen, statt unerwarteten Zustand zu überschreiben.

Die Erfolgsantwort beweist, dass der benannte Server die authentisierte Gesamtanfrage angenommen hat. Sie beweist nicht, dass die öffentliche RRDP-Notification geändert wurde, rsync bereits neue Dateien liefert oder eine bestimmte RP sie geholt hat. RFC 8181 trennt die Client-Server-Publikation ausdrücklich von der öffentlichen Verteilung.

RFC 9286 definiert das Manifest als signiertes Verzeichnis der Dateinamen und Inhalts-Hashes am Publikationspunkt einer CA. Einzelne Signaturen erkennen nicht jede Ersetzung durch eine ältere gültige Version oder Löschung auf dem Transportweg. Der Vergleich von Abruf und Manifest kann bestimmte Auslassungen, Änderungen und Wiederholungen erkennen.

Der Umfang ist präzise: aktuelle von der CA ausgestellte Zertifikate, ihre neueste CRL und weitere zugehörige signierte Objekte. Teilen mehrere CA-Instanzen einen Punkt, beschreibt jedes Manifest nur die eigenen Produkte. Bei Abschluss einer Änderung muss ein neues Manifest mit aktualisierten Hashes vor nextUpdate publiziert werden.

RFC 8182 legt die Abfolge der Verteilung fest. Eine Benachrichtigungsdatei enthält Sitzungskennung und aktuelle Seriennummer; ein Snapshot zeigt den vollständigen Stand, jedes Delta genau einen Schritt mit neuen, ersetzten und zurückgezogenen Objekten. Die Seriennummer ist keine Weltuhr. Eine RP kann vor der Aktualisierung abrufen, Daten aus einem Cache erhalten, ein Delta ablehnen oder stattdessen den Snapshot neu laden.

Das Nachweisprotokoll hält zunächst Client und Server, Nachrichten-Hash, Tags, URIs, Vorgänger- und neue Hashes sowie Anfrage- und Antwortzeit fest. Danach folgen Publikationspunkt, Manifest-Hash, thisUpdate, nextUpdate, CRL und der darin aufgeführte Satz. Für die Verteilung werden URI der Benachrichtigung, Sitzung, Seriennummer und Hashes von Benachrichtigung, Delta und Snapshot erfasst. Die RP-Beobachtung nennt Beobachter, Softwareversion, Abrufzeit, Übertragungsweg und die Ergebnisse für Manifest, Satz und Validierung.

Die Zustände REQUEST_AUTHENTICATED, SERVER_COMMITTED, MANIFEST_COHERENT, PUBLIC_VIEW_OBSERVED, RP_OBSERVED und EXCEPTION_OPEN begrenzen jede Aussage. Eine alte RP-Sicht nach Erfolg kann zeitliche Reihenfolge sein; ein neuer Serial mit Manifestfehler bleibt dagegen eine Störung.

Die RFCs setzen keine weltweite Frist für alle RPs, legen private Caches nicht offen und definieren kein einheitliches Prüfschema für Betreiber. Fehlende Beobachtung bei einer RP beweist keine globale Abwesenheit; Beobachtung bei einer anderen keine allgemeine Konvergenz. Das Nachweisprotokoll verbindet die einzelnen Belege, ohne ihre Aussagekraft zu überdehnen.

Quellen