Zusammenfassung

  • RFC 9246 verlangt bei Tokens für eine CDNI-Weiterleitung die unveränderte Übernahme vorhandener exp- und nbf-Werte. Fehlten die Angaben, darf die Weiterleitung sie nicht ergänzen.
  • Aussteller, Ausstellungszeit und geeigneter Empfänger- oder URI-Kontext können wechseln. Eine frische Signatur bedeutet keine neue zeitliche Erlaubnis.
  • Segmenttokens werden durch eine gesondert aktivierte Erneuerung fortgeschrieben. Der nächste Ablaufzeitpunkt ergibt sich aus Prüfzeit und cdniets, nicht aus einer beliebigen Weiterleitung.
  • exp ist im einzelnen Token optional. Annahmebedingungen, vertrauenswürdige Schlüssel und tatsächlich ausgeführte Prüfungen bleiben deshalb eigenständige Voraussetzungen.
  • Die Zeitbeispiele sind Analyse veröffentlichter Regeln, kein nachgewiesener CDN-Fehler, keine Häufigkeitsmessung und kein Beleg für universelle Implementierung.

Eine Weiterleitung ist kein Zeitguthaben

Der Inhaltanbieter erlaubt einen Zugriff, und das zuerst angesprochene CDN sucht einen besser geeigneten Auslieferungspartner. Dieser Partner kann einem anderen Aussteller vertrauen und eine andere URI benötigen. Ein neu signiertes Token ist dann ein sinnvoller Bestandteil des Übergangs.

Der neue Gegenstand darf jedoch nicht mit einer neuen Erlaubnis verwechselt werden. Seine Signatur kann gültig, sein Aussteller bekannt und seine Ausstellungszeit sehr jung sein. Trotzdem kann die mitgeführte Zugriffserlaubnis zu einem früher festgelegten Zeitpunkt enden.

Das ist keine Frage, die Kryptografie allein löst. Ein vertrauenswürdiger Signierer kann eine unzulässige Friständerung korrekt signieren. Die Prüfung bestätigt dann, wer den Inhalt verantwortet; sie beantwortet noch nicht, ob gerade diese Operation die Änderung erlaubte.

RFC 9246 begrenzt die normale Weiterleitung ausdrücklich. Ein vorhandener Ablaufzeitpunkt wird mit demselben Wert übernommen. Auf dem Weg verbrauchte Zeit bleibt verbraucht. Das Recht, den nächsten Auslieferungsort zu wählen, umfasst nicht automatisch das Recht, die Zugriffsdauer erneut zu vergeben.

Ein veröffentlichtes Profil mit begrenzter Aussage

RFC 9246 erschien im Juni 2022 als IETF-Dokument auf dem Standards Track. Der RFC Editor führt den Status Proposed Standard. Das Profil verwendet signierte JWTs für anfragebezogene Zugriffskontrolle zwischen verbundenen CDNs und lässt auch den Einsatz innerhalb eines einzelnen CDN zu.

Dieser Status ist kein Produktverzeichnis. Ob eine konkrete Umgebung das Profil unterstützt und wie sie Schlüssel, Annahme, Erneuerung und Prüfung konfiguriert, ist gesondert zu klären. Hier wurde weder eine Lieferantenabdeckung erhoben noch ein Verhalten in einem bestimmten CDN experimentell gemessen.

URI Signing ist außerdem kein Schutz bereits ausgelieferter Inhalte im Sinne von DRM. Es kann die Annahme nachfolgender Anfragen beschränken, holt aber keine Bytes zurück. Ein abgelaufenes Token bedeutet nicht, dass ein Empfänger seine erhaltene Kopie verloren hat.

Das Profil unterscheidet Implementierungspflicht und Verwendungspflicht. Die definierten Angaben müssen unterstützt werden, sind aber nicht sämtlich in jedem einzelnen JWT erforderlich. Der URI-Container ist obligatorisch; exp und nbf sind im einzelnen Token optional.

Optional bedeutet nicht, dass ein empfangenes exp ignoriert werden darf. Es bedeutet aber, dass ein Ablaufdatum nicht durch bloße Profilkonformität garantiert ist. Ein Dienst, der es in jeder ursprünglichen Erlaubnis benötigt, muss diese Annahmebedingung ausdrücklich festlegen.

Erhalten heißt: denselben Zeitpunkt erhalten

Abschnitt 2.1.4 schreibt vor, dass ein JWT für die nachfolgende CDNI-Weiterleitung ein vorhandenes exp enthalten und dessen Wert unverändert übernehmen muss. Fehlte exp im empfangenen JWT, darf die gewöhnliche Weiterleitung es nicht hinzufügen.

Der Prüfer muss die Anfrage ablehnen, wenn ihre Zeit exp erreicht oder überschritten hat. Er muss auch ablehnen, wenn er ein vorhandenes exp nicht prüfen kann. Das bloße Auffinden eines Feldes ist noch keine Anwendung seiner Bedingung.

nbf markiert den Beginn der zulässigen Nutzung. Auch hier bleibt ein vorhandener Wert gleich und ein fehlender wird nicht ergänzt. Vor nbf ist die Anfrage abzulehnen, bei Gleichheit ist diese Startbedingung erfüllt. Die Gleichheit mit exp schließt das Fenster dagegen bereits.

Ein fehlendes Ablaufdatum durch ein kurzes zu ergänzen kann auf den ersten Blick vorsichtig wirken. Die Weiterleitung ist jedoch keine allgemeine Vollmacht zur Neuformulierung des empfangenen Rechts. Selbst eine scheinbar engere zusätzliche Bedingung verändert, wer diese Bedingungen festgelegt hat.

Eine lokale Eingangspolitik kann ursprüngliche Tokens ohne erforderliches exp zurückweisen. Ein wirklich befugter Akteur kann eine gesonderte neue Erlaubnis geben. Das ist etwas anderes als die normale Weiterleitung der bestehenden Erlaubnis. Die Art des Vorgangs muss feststehen, bevor die Zahlen bewertet werden.

Ein neuer Aussteller darf nicht alles neu entscheiden

Ein vorhandenes iss bleibt bei der Weiterleitung vorhanden, verweist dann aber auf das weiterleitende CDN als neuen Signierer. Der Empfänger benötigt eine zuvor vertrauenswürdig festgelegte Zuordnung akzeptierter Aussteller zu Schlüsseln und muss sie mit der tatsächlich verwendeten Signatur abgleichen.

Ein vorhandenes iat wird auf die Erzeugungszeit des neuen JWT gesetzt; ein fehlendes kann hinzugefügt werden. aud lässt sich für eine vorgesehene, konfigurierte Identität der Verarbeitungskette anpassen. Der URI-Container kann zur Weiterleitungs-URI passend geändert werden.

Diese konkreten Anpassungsrechte machen andere Angaben nicht frei veränderbar. Ein neues iat und ein altes exp können zusammen genau das richtige Resultat sein. Das Alter der neuen signierten Hülle ist nicht die verbleibende Dauer des mitgeführten Zugriffsrechts.

Ein allgemeiner Ausstellungsbaustein kann gewohnt sein, von der aktuellen Zeit einen Standardzeitraum auszurechnen. Bevor er für eine Weiterleitung eingesetzt wird, muss klar sein, ob er ein ursprüngliches Recht ausstellt, ein vorhandenes Recht weiterleitet oder ausdrücklich delegierte Erneuerung ausübt.

JWS liefert die Integritätsmechanismen, und die JWT-Sicherheitsempfehlungen verlangen angemessene Prüfungen von Algorithmus, Aussteller, Publikum und Kontext. Eine gültige Signatur eines bekannten Schlüssels beweist dennoch keine unbegrenzte Änderungsbefugnis.

Schlüsselverteilung und Vertrauensaufbau sind nicht vollständig durch dieses Profil geregelt. Öffentliche Schlüssel erlauben Prüfung ohne Signaturrecht. Ein gemeinsamer symmetrischer Schlüssel ermöglicht seinem Besitzer auch das Ausstellen. Das Profil unterstützt ihn aus Kompatibilitätsgründen, empfiehlt ihn aber nicht. Auch asymmetrische Schlüssel erübrigen keine Begrenzung der Befugnisse eines bereits vertrauenswürdigen Signierers.

Ein späteres Token kann früher enden

Nehmen wir eine rein analytische Zeitskala. Die ursprüngliche Erlaubnis endet bei sechzig. Ein CDN leitet bei zehn weiter, ein weiteres bei zwanzig. Aussteller, iat und passende URI können wechseln; exp bleibt in den normalen Weiterleitungstokens sechzig.

Bei fünfundsechzig erfüllt eine Anfrage diese Zeitbedingung nicht mehr. Würde der zweite Signierer zu seinem Zeitpunkt zwanzig nochmals sechzig addieren und achtzig eintragen, verlängerte er die Erlaubnis. Signatur und Adresse könnten richtig sein, während die Transformation falsch ist.

Das Beispiel berichtet keinen beobachteten Anbieterfehler. Es macht den Unterschied zwischen einem übernommenen absoluten Zeitpunkt und einem nach jedem Übergang erneut vergebenen Zeitraum sichtbar.

Die Interpretation beim Prüfer ist eine unabhängige Frage. Allgemeines JWT erlaubt etwas Spielraum für Uhrabweichungen bei exp und nbf. Das CDNI-Profil verbietet diesen Spielraum. Ein korrekt übernommener Zahlenwert kann dennoch zu weit akzeptiert werden, wenn eine Bibliothek ungeprüft ihre Voreinstellung für einen anderen Anwendungsfall nutzt.

Die beteiligten Systeme müssen ihre Zeit synchronisieren; das Profil empfiehlt NTP. Ein ursprüngliches Zeitfenster muss reale HTTP-Austausche und vorübergehende Netzprobleme berücksichtigen. Diesen Spielraum im vereinbarten Recht vorzusehen ist etwas anderes als eine versteckte Zugabe jedes Prüfers. Zeitsynchronisierung erstattet keine Routendauer.

Warum Segmenterneuerung etwas anderes ist

Bei segmentierten Inhalten steht die nächste Anfrage nicht immer fest. Ein Player kann springen oder die Darstellung wechseln. Jede mögliche Segment-URI vorab für die ganze Wiedergabezeit zu signieren kann unnötig lange Nutzungsfenster schaffen.

Signed Token Renewal erlaubt dem CDN, nach korrekter Prüfung und erfolgreicher Segmentauslieferung ein Token für den nächsten Zugriff auf zusammengehörige Ressourcen zu liefern. cdniets bezeichnet Sekunden, die zum Prüfzeitpunkt addiert werden, um das nächste exp zu berechnen. Dazu gehört cdnistt als Angabe des Transports.

Wird bei fünfundfünfzig geprüft und beträgt das Intervall dreißig, kann der nächste Ablaufzeitpunkt fünfundachtzig sein. Das ist die Rechnung einer ausdrücklich eingeschalteten Erneuerung. Sie rechtfertigt nicht, bei einer normalen Weiterleitung exp sechzig zu fünfundachtzig zu machen.

Der Transport kann ausgeschaltet sein, ein Cookie oder die Query verwenden. Null kennzeichnet die ausgeschaltete Funktion. Wird keine Erneuerung gewünscht, empfiehlt das Profil, das entsprechende Angabenpaar wegzulassen. Signaturfähigkeit allein ist keine stillschweigende Fortsetzungsbefugnis.

Ein rollierendes Fenster zwischen Segmenten legt auch keinen absoluten Programm- oder Berechtigungsabschluss automatisch fest. Benötigt ein Dienst beides, muss vereinbart werden, wo die zusätzliche Bedingung durchgesetzt wird. Diese Governance-Frage erfindet kein neues standardisiertes Feld und verlangt keine zentrale Online-Freigabe jedes Segments.

Lokale Erneuerung bleibt innerhalb der ausdrücklich delegierten Bedingungen möglich. Unzulässig ist die begriffliche Abkürzung, jede neue Signatur als Erneuerung auszugeben, um einen nicht vorgesehenen Zeitgewinn zu erklären.

Transportpfad ist nicht Ressourcenrecht

cdnistd verknüpft ein nachfolgendes Token mit einer Pfadmenge, wenn der Transport diese Zuordnung unterstützt. Ohne Angabe gilt null; null kann die Rücksendung auf jedem Pfad vorsehen. Der URI-Container begrenzt den autorisierten Inhalt weiterhin.

Domainübergreifende Cookie-Beschränkungen können Query-Transport erfordern. Der beschriebene Erneuerungsablauf erwartet Manifest und Segmente auf derselben Domain und führt Domainwechsel beim Manifestabruf durch. Ein bequemes Cookie schafft kein Zugriffsrecht bei sachfremden Empfängern.

Zur Containerprüfung dient die angefragte URI nach Entfernung des Signaturpakets in prozentkodierter Form. Eine Adresse anzupassen, um den erlaubten Inhalt zu erreichen, ist nicht gleichbedeutend mit einer Erweiterung auf zusätzliche Ressourcen.

Ein sehr weiter Container ohne weitere Bedingungen kann zu einem übermächtigen Zugangsmittel werden; das Profil warnt vor diesem Wildcard-Fall. Das macht nicht alle signierten URIs gleich riskant. Entscheidend sind die tatsächlich verwendeten Bedingungen und die Annahmeregeln.

Sichtbare Signatur, unsichtbare Ausführung

CDNI teilt die Verteilungspolitik des Inhaltanbieters und ihre Umsetzung durch kooperierende Netze. Metadaten, Fähigkeitsangaben und Routing helfen, einen geeigneten Empfänger auszuwählen. Geografische Eignung oder beworbene Unterstützung ist kein Nachweis des konkreten Anfrageablaufs.

Die URI-Signing-Metadaten enthalten enforce mit dem Standardwert wahr. Bei falsch prüft das empfangende CDN das Token nicht, selbst wenn die URI eine Signatur enthält. Eine beobachtete signierte Adresse belegt daher nicht, dass die erwarteten Kontrollen ausgeführt wurden.

Eine leere Ausstellerliste vertraut auch nicht dem ganzen Internet. Sie akzeptiert Aussteller aus dem vertrauenswürdigen Schlüsselspeicher. Der Standardwert setzt eine unabhängig eingerichtete Vertrauensgrenze voraus.

jti bringt eine Zustandsabhängigkeit hinzu. Ein vorhandener Wert wird übernommen, ein fehlender nicht hinzugefügt. Das Profil verlangt Speicherunterstützung und Ablehnung erneuter Verwendung für denselben Inhalt. Ein Identifikator allein verhindert keine Wiederholung.

Aufbewahrung, Inhaltsumfang und Bereinigung sind entscheidend. Ohne exp kann ein begrenzter Speicher jüngst verwendeter Werte später eine Wiederverwendung zulassen. Ein gemeinsamer Identifikator schafft keine automatisch abgestimmte globale Einmalnutzungsbuchhaltung aller CDNs.

Protokollierte Anwendung und Ablehnungsgründe können die Prüfung einer Transformation stützen. Ein Erfolgsmerkmal beweist nicht jede Bedingung, und die Diagnose muss dafür keine verwendbaren Zugangstokens oder persönlichen Daten offenlegen.

Die Grundlage ist veröffentlichte Spezifikation und Analyse, keine Fehler- oder Verbreitungsmessung. Ein minimaler gemeinsamer Ausgangsvertrag, spätere lokale Entscheidungen und freiwillige Annahme bieten den Governance-Rahmen. Sie ersetzen keine JWT-Semantik, sondern erhalten autonome Auslieferungsentscheidungen innerhalb einer expliziten Grenze.

Quellen