Zusammenfassung

  • FCI.DelegatedCredentials meldet eine Obergrenze und optional einen Verschlüsselungsschlüssel; MI.DelegatedCredentials transportiert Nachweise und gegebenenfalls private Schlüssel, jedoch keine Installationsbestätigung einzelner Endpunkte.
  • Die gemeldete Zahl muss nicht der Serverzahl entsprechen. Ein Nachweis kann auf mehreren Endpunkten liegen, während private Schlüssel entweder lokal entstehen oder als JWE übertragen werden.
  • Eine belastbare Aussage verbindet Zertifikatsbefugnis, Schlüsselherkunft, Metadatenversion, Knotenstatus, Routingentscheidung, Client-Angebot, Signaturalgorithmus, Handshake, Rückfallpfad und HTTP-Ergebnis als getrennte Belege.

Zentrale Vollständigkeit kann dezentrale Unvollständigkeit verdecken

Ein Upstream-CDN erstellt rechtzeitig neue delegierte Berechtigungsnachweise. Das Downstream-CDN ruft das Metadatenobjekt ab; Prüfsumme und Schema stimmen. Der zentrale Vorgang ist abgeschlossen. Dennoch kann ein Edge in einer kleinen Region den neuen Schlüssel nicht entschlüsseln, ein anderer Prozess die Konfiguration nicht neu laden und ein dritter nur über den herkömmlichen Zertifikatspfad antworten.

Wer die erfolgreiche Abholung als globale Bereitstellung verbucht, verliert genau die Information, die später für eine Störung gebraucht wird. RFC 9677 verlangt diese Gleichsetzung nicht. Es löst ein engeres Problem: Wie können zwei CDNs die in RFC 9345 definierten kurzlebigen Berechtigungsnachweise über standardisierte CDNI-Objekte austauschen?

Die Begrenzung ist eine Stärke. Der langfristige Zertifikatsschlüssel muss nicht über jede Betriebsgrenze wandern. Der kurzfristige delegierte Schlüssel bleibt dennoch ein wirksames Geheimnis, dessen Herkunft, Verteilung und Verwendung nachweisbar sein müssen.

Eine FCI-Zahl ist weder Reservierung noch Bestandsaufnahme

Über FCI.Metadata kann das Downstream-CDN Unterstützung für MI.DelegatedCredentials ankündigen. FCI.DelegatedCredentials ergänzt die maximal unterstützte Zahl und kann den öffentlichen PrivateKeyEncryptionKey als JWK enthalten.

Die Zahl steuert, wie viel Material das Upstream-CDN sinnvoll bereitstellt. Laut RFC entspricht sie typischerweise, aber nicht zwingend der Zahl vorgesehener Server. Das Downstream-CDN darf denselben Nachweis auf mehrere Endpunkte verteilen oder jedem einen eigenen zuordnen.

Aus „zehn unterstützt“ folgt daher weder „zehn Server vorhanden“ noch „zehn Plätze frei“ oder „zehn Endpunkte aktiv“. Auch Footprint, Rollout-Stand und tatsächliche Nutzung bleiben offen. Eine Kapazitätsmeldung direkt in eine Konvergenzquote umzudeuten, erzeugt einen nicht übertragenen Sachverhalt.

Zwei Schlüsselwege brauchen zwei Beweisketten

Das MI-Objekt enthält ein Array base64-codierter CertificateEntry-Strukturen mit dem delegierten Nachweis. Der zugehörige private Schlüssel ist optional. Wird er übertragen, muss er in einer kompakten JWE liegen und für den vom Downstream angekündigten Schlüssel verschlüsselt sein.

Fehlt er, kann das Downstream-CDN das Schlüsselpaar selbst erzeugt und den öffentlichen Teil außerhalb von CDNI an das Upstream-CDN gegeben haben. Dann verlässt das Geheimnis seine Domäne nicht. Dafür muss die außerhalb des Protokolls übermittelte Anfrage eindeutig mit lokalem Schlüssel und späterem Nachweis verknüpft werden.

Beim Transportweg zählen Erzeuger, JWE-Empfänger, Entschlüsselungskomponente und Secret Store. Beim lokalen Weg zählen Schlüsselgenerierung und Authentizität der öffentlichen Anfrage. Der gemeinsame Status „empfangen“ löscht diese entscheidenden Unterschiede.

Die JWE schützt die Strecke, nicht sämtliche Vergangenheit

RFC 9677 empfiehlt, private Schlüssel nicht durch MI zu senden. Falls es geschieht, muss der Verschlüsselungsschlüssel mindestens gleich stark sein. Die Hülle schützt vor Klartext auf der Übertragungsstrecke, bietet aber keine Forward Secrecy. Wird der Entschlüsselungsschlüssel später kompromittiert, können aufgezeichnete alte JWEs offengelegt werden.

Die kurze Gültigkeit begrenzt den Zeitraum, in dem das gestohlene Paar zur Identitätsvortäuschung taugt. Sie beweist keine Löschung von Kopien, keine Unversehrtheit des JWK und keine sichere Hardware-Importgrenze. Historischer Ciphertext bleibt Teil der Untersuchung.

Ein sicheres Journal enthält Fingerprints, Schlüsselkennungen, Algorithmen, Zeiten und Prüfentscheidungen, nie das Geheimnis selbst. Es trennt außerdem einen syntaktisch gültigen Nachweis von einem Endpunkt, der tatsächlich mit dem passenden privaten Schlüssel signieren kann.

Der Client setzt Bedingungen, die die Übergabe nicht kennt

Nach RFC 9345 muss der Client die Erweiterung und geeignete Signaturverfahren anbieten. Ohne dieses Angebot darf der Server keinen delegierten Nachweis senden. Zertifikatskette und erwartete Dienstidentität werden weiterhin geprüft; hinzu kommen Delegationssignatur, Gültigkeit und Übereinstimmung mit CertificateVerify.

Standardmäßig gilt höchstens sieben Tage, niemals länger als das delegierende Zertifikat. Der Nachweis ist außerdem an ein Signaturverfahren gebunden. Ein korrekt übertragenes Objekt kann damit beim Client wegen Zeit, Algorithmus, Zertifikatsmerkmal oder Identität scheitern.

Selbst bei kompatiblem Client kann der Server auf die Verwendung verzichten. Für ältere Clients und Störungen können normales Zertifikat oder Remote Signing bestehen bleiben. Eine erfolgreiche TLS-Verbindung belegt Erreichbarkeit, aber ohne Handshake-Daten nicht die Verwendung des delegierten Pfades.

Zwischen Abruf und Handshake liegt der eigentliche Rollout

Der beispielhafte Ablauf nennt Fähigkeitsmeldung, MI-Abruf, Client-Verbindung und Erneuerung. Eine normative Nachricht „alle Edges installiert“ gibt es dazwischen nicht. In diesem Raum arbeiten Validierung, Entschlüsselung, Geheimnisspeicher, Konfigurationsbau, gestaffelte Ausbringung, Prozess-Neuladen, Gesundheitsprüfung und Traffic-Umschaltung.

Eine angenommene Queue-Nachricht ist keine Ausführung. Gespeichertes Material ist nicht zwingend aktiv. Ein aktiver Schlüssel wird nicht zwingend geroutet. Ein ausgewählter Server trifft nicht zwingend auf einen kompatiblen Client. Jede Verbindung in der Kette benötigt einen eigenen Beleg.

Der Flottenstatus muss deshalb seinen Nenner nennen: Zielendpunkte, ausgenommene und entleerte Knoten, letzte Beobachtung, installierter Fingerprint, Aktivierung und Routing. Eine hohe Prozentzahl ohne diese Liste kann den einzigen noch riskanten Produktionsknoten verbergen.

Ablauf macht aus verborgenem Rückstand sichtbare Ablehnung

Das FCI-Objekt regelt keine Erneuerung. Das Upstream-CDN soll gelieferte Nachweise und deren Ablauf überwachen und rechtzeitig ersetzen. Besitzt ein Downstream-Server nur abgelaufene Nachweise, muss er neue Verbindungen ablehnen, die einen aktuellen benötigen.

Diese Ablehnung ist lokal eindeutig, aber keine Aussage über die gesamte Flotte. Andere Edges können den Nachfolger besitzen, noch im Überlappungsfenster liegen, den Rückfallpfad verwenden, entleert oder unerreichbar sein.

Kurzlebigkeit reduziert die Missbrauchsdauer und erhöht die Zahl der Rotationen. Jede Rotation aktiviert selten getestete Abhängigkeiten. Das SLO sollte daher Nutzbarkeit des Nachfolgers im gesamten noch gerouteten Zielbestand vor Ende des Vorgängers messen, ergänzt um einen verifizierten Rückfall für inkompatible Clients.

Zehn Belege bilden die operative Aussage

Erstens: delegierendes Zertifikat mit Identität, Fingerprint, Erlaubnis und Gültigkeit. Zweitens: delegierter Nachweis mit öffentlichem Schlüssel, Verfahren, Fingerprint und Ablauf. Drittens: Herkunft des privaten Schlüssels. Viertens: genaue FCI-Version, Footprint, Obergrenze und Verschlüsselungsschlüssel.

Fünftens: Abruf und Integrität der genauen MI-Version. Sechstens: Validierung und Installation je Zielendpunkt. Siebtens: Konvergenz samt alten, fehlerhaften, entleerten und im Rückfall befindlichen Knoten. Achtens: Routingentscheidung zum konkreten Edge.

Neuntens: beobachteter Handshake mit Client-Angebot, TLS-Version, Algorithmus, Kette, Erweiterung und Prüfergebnis. Zehntens: HTTP- und Anwendungsergebnis. Das RFC definiert wichtige Teile, nicht die ganze Leiter. Kein Beleg darf in den nächsthöheren umbenannt werden.

Teilfehler vor dem Ernstfall üben

Fehlt die Fähigkeitsmeldung, ist ein ausdrücklich unterstützter Pfad zu wählen. Reicht die Obergrenze nicht, wird die Menge verkleinert oder die Topologie geändert; eine Reservierung darf nicht behauptet werden. Fehlt der passende Schlüssel oder scheitert JWE, gehört das Objekt in Quarantäne.

Bei gemischter Flotte werden alte Knoten entleert oder über einen geprüften Rückfall abgesichert. Canaries umfassen Clients mit und ohne Erweiterung, verschiedene Verfahren, bald ablaufende Nachweise und jede Rollout-Kohorte. Erfolg über das normale Zertifikat bleibt Rückfallerfolg und zählt nicht als delegierte Bereitstellung.

Bei Verdacht auf kompromittierte Empfängerschlüssel müssen Schlüssel und Nachweise rotiert sowie historische JWE-Aufzeichnungen bewertet werden. Sieben Tage ersetzen keinen Incident-Prozess.

Die präzise Grenze macht den Standard belastbar

RFC 9677 stellt keine Zertifikate aus, widerruft nichts, wählt keine Route, attestiert keine Flotte und beweist keine Inhaltsauslieferung. Es standardisiert einen sensiblen Austausch, der andernfalls proprietär und schwerer prüfbar wäre.

Heng Lus Gedanken zu Realitätsebenen und Running-Code-Primat passen hier unmittelbar: Konfigurationsabsicht, Zustand des laufenden Systems und Kundenergebnis sind drei verschiedene Tatsachen. Die minimale gemeinsame Spezifikation koordiniert das Gemeinsame; Rollout, Rückfall, Beweisaufbewahrung und Incident-Autorität bleiben ausdrücklich lokal.

Die Übergabe darf als Übergabe gemeldet werden. Für „am Edge eingesetzt“ müssen Edge und Client selbst sprechen.

Quellen