Zusammenfassung

  • Das optionale Feld rtt in RFC 9891 ist ein Hinweis des Clients auf die erwartete DTN-Rundlaufzeit. Der ACME-Server wählt das tatsächliche Antwortintervall, wendet netzspezifische Grenzen an und prüft die Antwort gegen die Lebensdauer des ursprünglichen Challenge Bundles.
  • Eine rechtzeitige, integritätsgeschützte Antwort belegt Kontrolle über eine Node ID für genau diese Challenge und Serverpolicy. Sie belegt weder dauerhaftes Eigentum noch künftige Erreichbarkeit, Zertifikatsausstellung, Installation, TCPCL-Sitzung oder Anwendungserfolg.

Im Auftragsdatensatz stand eine Rundlaufzeit von 300 Sekunden. Das Betriebsprotokoll machte daraus eine genehmigte Prüfzeit von fünf Minuten. Damit verwandelte es Wissen über einen erwarteten Pfad in Autorität über die Uhr des Prüfers.

RFC 9891 erweitert ACME um die Identifikatorart bundleEID und die Challenge bp-nodeid-00. Ein ACME-Server sendet über seinen BP Agent ein Challenge Bundle an die beanspruchte DTN Node ID. Der vorbereitete Agent des Clients erzeugt eine gebundene Antwort und schickt sie als Response Bundle zurück.

Das Verfahren ist experimentell. Es soll automatisierte Zertifikatsvalidierung in Netzen untersuchbar machen, in denen lange Unterbrechungen normal sein können. Gerade deshalb trennt es die Beschreibung einer erwarteten Verzögerung von der Entscheidung, welche Verzögerung der Verifier akzeptiert.

Eine Schätzung hat keine Weisungsbefugnis

Der Client darf im Response Object eine erwartete RTT in Sekunden angeben. Der Text bezeichnet sie ausdrücklich als nicht autoritativen Hinweis. Der Server soll gewöhnlich das Doppelte der RTT als Ausgangspunkt verwenden und netzspezifische Unter- und Obergrenzen anwenden. In einem ausschließlich terrestrischen DTN sollte die Obergrenze sechzig Sekunden nicht überschreiten.

Andere Netze können andere Grenzen brauchen. Die Zuständigkeit ändert sich nicht. Der Client kennt geplante Kontakte und lokale Pfade; der Server kennt seine Kapazität, Aufbewahrung von Challenge-Zustand, Missbrauchsrisiken und CA-Policy.

Bevor der Client die Validierung freigibt, muss sein BP Agent antwortbereit sein. Weil der konkrete Bundle-Pfad nicht feststeht, soll die Schätzung pessimistisch ausfallen. Der Client besitzt damit die Verantwortung für Vorbereitung und Informationsqualität, nicht für die Annahmefrist.

Maßgeblich bleiben Erstellungszeit und Lifetime des Challenge Bundles. Das Response Bundle enthält zwar seine eigene Erstellungszeit und Restlebensdauer. Der Server vergleicht den Eingang jedoch mit dem ursprünglichen Fenster. Eine Rückantwort kann ihre eigene Verspätung nicht durch eine großzügigere Lifetime heilen.

Ein längeres Fenster erhöht die Chance für intermittierende Nodes, bindet aber Zustand und vergrößert die DoS-Fläche. Ein kurzes Fenster schützt Ressourcen, schließt aber reale DTN-Pfade aus. Diese Abwägung darf nicht unbemerkt in einem vom Antragsteller gelieferten Feld verschwinden.

Der Nachweis entsteht aus zwei Kanälen

Eine beliebige Rückantwort reicht nicht. token-chal gehört zur ACME-Autorisierung und bleibt auf dem ACME-Kanal. Alle Bundles einer Challenge teilen es. Jedes Challenge Bundle erhält zusätzlich ein eigenes token-bundle, das auf dem BP-Pfad sichtbar ist.

Der antwortende Agent verbindet beide Token mit dem Thumbprint des ACME-Kontos und berechnet die Key Authorization. Im Response Bundle liegt ihr Digest. Wer nur den BP-Pfad beobachtet, kennt nicht das ACME-Token. Wer nur den ACME-Datensatz kennt, belegt nicht den Empfang dieses Bundles.

Für jede Perspektive prüft der Server den rechtzeitigen Eingang, die Übereinstimmung der Source Node ID, einen vertrauenswürdigen Block Integrity Block über Primary Block und Payload, beide Token, einen angebotenen Hashalgorithmus und den erwarteten Digest. Fehlt eine Bedingung, scheitert diese Perspektive. Auch eine ausbleibende Antwort ist ein Fehlschlag.

Die Ursachen bleiben verschieden: Routing, Uhr, Agent-Konfiguration, Vertrauensregel, Algorithmus oder Tokenkorrelation. Wer nur invalid speichert, verliert die Grundlage für eine sinnvolle Wiederholung.

Auch Erfolg bleibt eng. Er bindet Kontoschlüssel, Autorisierung, Node ID und ein zeitlich begrenztes Ereignis. Er behauptet keine globale Namenseindeutigkeit und keine dauerhafte Kontrolle.

RFC 9171 definiert eine Node ID als Singleton Endpoint ID, die einen BP Node identifizieren kann. Sie ist nicht garantiert weltweit eindeutig; ein Node kann mehrere besitzen. Eine Administrative EID ist innerhalb eines bestimmten URI-Schemas für den Node eindeutig.

Das IANA-ACME-Register und das IANA-Bundle-Protocol-Register koordinieren bundleEID, bp-nodeid-00, den Verwaltungsrecord und die Schemata dtn und ipn. Sie schaffen gemeinsame Protokollbedeutung, beobachten aber weder Zuteilung noch Route oder Organisationsberechtigung.

Mehrere Perspektiven sind noch keine unabhängigen Wege

Der Server kann Bundles aus mehreren Quellen oder über mehrere Routen senden. Jedes erhält ein eigenes Token, sodass Beobachtungen getrennt bleiben. Die Methode kann einen Angreifer auf einem einzelnen Pfad erschweren. Sie garantiert nicht, dass die Pfade tatsächlich verschieden sind; mehrere Perspektiven können denselben Gateway durchlaufen.

RFC 9891 überlässt die Gesamtentscheidung der Serverpolicy. Als mögliche Regel wird empfohlen, dass die primäre Perspektive erfolgreich sein muss und höchstens eine sekundäre scheitern darf. Welche Perspektive primär ist, ist ebenfalls Implementierungssache.

Das endgültige valid ist daher eine policybewertete Beobachtung. Ohne Einzelresultate und Policyversion kann ein Prüfer nicht erkennen, ob alle Wege funktionierten oder ein erlaubter Fehler vorlag. Zwei CAs können dieselben Messungen verschieden bewerten.

Ein Integrity Gateway kann die Quelle mit lokalen Mitteln prüfen und einen BIB hinzufügen. Der Empfänger muss konfigurieren, für welche Node-ID-Muster er dieser Security Source vertraut. Kryptografie bewahrt die Aussage des Gateways; sie erfindet nicht seinen Mandatsbereich.

Der experimentelle Charakter trifft genau diese offenen Fragen: Wie wird Naming Authority zwischen Organisationen zugeteilt? Wie delegiert eine CA Vertrauen an einen Gateway? Wie nützlich ist Multi-Perspective Validation in realer Topologie? Ein standardisierter Versuch ist kein vorweggenommenes Ergebnis.

Heng Lus Minimum Initial Specification and Localized Future Decision bietet dafür die passende Ordnung. Gemeinsam müssen Token, Vergleich, Integrität und Zeitstruktur sein. Akzeptierte Verzögerung und interorganisatorisches Vertrauen bleiben lokale Entscheidungen der Risikoträger.

Hinter valid folgen weitere Schwellen

RFC 8555 trennt Challenge, Autorisierung und Order. Eine erfolgreiche Challenge macht eine Autorisierung für einen begrenzten Zeitraum gültig. Sie ist kein ausgestelltes Zertifikat.

Ein Antrag nach RFC 9891 kann NODE-ID, DNS-ID und IP-ID kombinieren. Jede Identität muss validiert werden. Danach gelten weiterhin CA-Policy, Key Usage und Algorithmen. Der richtige DTN-Digest zwingt nicht zur Ausstellung.

RFC 9174 beschreibt die spätere Verwendung im TCP Convergence Layer. Ein Zertifikat kann NODE-ID und id-kp-bundleSecurity enthalten. Ein Peer kann Netzwerkidentität, Node ID oder beide prüfen und eine Sitzung bei Fehlschlag beenden.

Wie das Zertifikat in den BP Agent gelangt, lässt RFC 9891 der Implementierung. Autorisierung, Ausstellung, Installation, TLS-Auswahl, TCPCL-Sitzung, Bundle-Weiterleitung und Anwendungseffekt sind deshalb getrennte Datensätze.

RFC 9172 liefert BPSec. Ein erfolgreicher BIB-Nachweis schützt die abgedeckten Daten unter einem Kontext. Ob die Security Source für diesen Ursprung sprechen darf, entscheidet die Policy.

Heng Lus Running Code as Primary Evidence trennt die spezifizierte Möglichkeit von der ausgeführten Wirklichkeit. Reality Layers and Symbolic Power zeigt, wie ein valid ohne Zeit, Objekt und Perspektiven zur übergroßen Autorität wird.

Der Client schätzte die Verzögerung. Die Schätzung verbesserte die Planung. Das Prüfzeitfenster blieb beim Server, weil dort auch die Verantwortung für den Nachweis lag.

Quellen