Résumé

  • Un jeton créé pour une redirection CDNI doit conserver sans modification les valeurs exp et nbf déjà présentes. La redirection ne peut pas introduire ces attributs lorsqu’ils étaient absents.
  • Le signataire et la date d’émission peuvent changer pour adapter le jeton au prochain destinataire. Cette fraîcheur cryptographique ne représente pas une nouvelle durée d’accès.
  • Le renouvellement des jetons de segments est une opération distincte, explicitement activée, qui calcule une prochaine échéance à partir du moment de vérification et de l’intervalle prévu.
  • L’expiration reste facultative dans un jeton individuel du profil. Les exigences d’acceptation, la confiance dans les clés et l’exécution effective des contrôles ne peuvent donc pas être déduites d’une signature visible.
  • Cette analyse repose sur les textes publiés, non sur une anomalie reproduite chez un fournisseur ou une mesure de leur adoption.

Le trajet avance, pas l’échéance

Un réseau de livraison reçoit une demande, choisit un partenaire capable de servir le contenu, puis signe une adresse adaptée à ce partenaire. Le prochain réseau voit un jeton récent, émis par un acteur qu’il connaît. Le service paraît fonctionner exactement comme prévu. Pourtant, une question indépendante demeure : la durée d’accès a-t-elle suivi le trajet sans être rallongée ?

La distinction est facile à perdre lorsqu’un même composant sait produire plusieurs sortes de jetons. Il peut créer un objet destiné à une redirection, en créer un autre pour poursuivre une lecture segmentée, et utiliser dans les deux cas les mêmes mécanismes de signature. Un objet neuf ne dit pas, à lui seul, quelle opération a été autorisée.

Le risque n’est donc pas seulement une signature invalide. Une signature valide peut authentifier une transformation qui ne respecte pas l’accord initial. La responsabilité se situe entre le choix d’un nouveau destinataire et le maintien des limites attachées à la demande.

Le profil défini par RFC 9246 apporte une réponse précise pour la redirection ordinaire : une échéance déjà présente doit rester identique. Le temps passé à traverser les réseaux n’est pas remboursé par chaque nouvelle signature.

Un profil publié, pas une règle générale de tous les JWT

RFC 9246, publié en juin 2022, est un document IETF de la filière de normalisation, classé Proposed Standard. Il décrit un profil de JWT signés pour contrôler l’accès aux contenus entre réseaux de livraison, ainsi que dans certains déploiements à réseau unique. Il ne constitue pas un inventaire des fonctions effectivement proposées par tous les opérateurs.

Son objet est l’autorisation des demandes de contenu. Ce n’est pas un système de protection des œuvres déjà remises au lecteur, ni une manière de récupérer les octets après livraison. Confondre accès et protection du contenu conduirait à promettre plus que le mécanisme ne peut faire.

Le profil utilise les attributs de JWT, mais fixe ses propres règles d’application. Il impose aux implémentations de savoir traiter les attributs qu’il définit, sans rendre chacun obligatoire dans tous les jetons. Le conteneur d’URI est obligatoire. L’échéance exp et la borne nbf ne le sont pas dans chaque objet individuel.

Cette différence évite deux erreurs. La première serait de conclure qu’une implémentation peut ignorer exp quand il est présent. La seconde serait de prétendre que tous les jetons conformes possèdent nécessairement une expiration. Les exigences d’un service doivent préciser les attributs qu’il demande à l’entrée ; elles ne peuvent pas être remplacées par une lecture trop large de la règle de conservation.

Conserver signifie ici garder la valeur

Lorsqu’un JWT reçu contient exp, celui produit pour une redirection CDNI doit aussi contenir exp et conserver exactement sa valeur. Si exp était absent, la redirection ne doit pas en ajouter. Le destinataire doit rejeter une demande dont le moment est égal ou postérieur à l’échéance, ainsi qu’un jeton dont il ne sait pas vérifier l’expiration présente.

La règle nbf suit le même principe de conservation : une valeur présente reste la même, une valeur absente n’est pas ajoutée. Une demande avant cette borne doit être refusée. L’égalité avec nbf permet l’accès sous cette condition, alors que l’égalité avec exp le ferme.

Pourquoi interdire même l’ajout d’une expiration courte à un jeton qui n’en avait pas ? Parce qu’une redirection n’est pas un mandat de réécriture générale. Un réseau peut avoir une politique locale exigeant une durée explicite avant d’accepter le jeton initial. Dans ce cas, il doit appliquer cette politique à la bonne frontière. Transformer discrètement un objet non acceptable en un nouvel accord apparent ne résout pas la question de l’autorité.

Le service peut obtenir un nouveau droit auprès de l’acteur habilité à l’accorder. Cette démarche reste distincte d’une redirection du droit reçu. Il faut connaître la nature de l’opération avant de juger la valeur qu’elle produit.

Trois changements possibles ne donnent pas un quatrième pouvoir

La redirection peut légitimement changer plusieurs éléments. Un iss déjà présent doit identifier le réseau qui signe la nouvelle redirection ; un iss absent peut être ajouté. Un iat déjà présent doit indiquer le moment de création du nouveau JWT ; il peut également être ajouté s’il était absent.

L’audience peut être adaptée à une identité prévue dans la chaîne de traitement. Le conteneur d’URI peut suivre l’adresse vers laquelle la demande est redirigée. Ces changements servent à rendre le jeton pertinent pour le prochain destinataire et pour le contenu demandé.

Ils ne donnent pas le pouvoir de changer exp. Un iat récent renseigne sur l’âge du nouvel objet signé. Il ne mesure pas la durée restante du droit d’accès. Un jeton émis plus tard avec une échéance inchangée n’est pas contradictoire : il montre précisément que la nouvelle enveloppe respecte l’ancienne limite.

Les outils cryptographiques authentifient cette enveloppe. La vérification de la signature, des algorithmes, de l’émetteur et de l’audience est indispensable. Elle ne suffit pas à établir qu’un signataire de confiance avait le droit de modifier chaque attribut.

La distribution des clés et l’établissement de la confiance ne sont pas entièrement définis par ce profil. Une clé publique peut servir à vérifier sans permettre de signer. Une clé symétrique partagée donne aussi la capacité de produire des jetons. Le profil conserve cette possibilité pour la compatibilité, mais la déconseille. Dans les deux cas, la portée de l’autorité accordée au signataire reste une décision à encadrer.

Un exemple de délai consommé

Prenons une chronologie purement analytique. Le jeton initial expire au temps soixante. Une première redirection a lieu à dix, une seconde à vingt. Les émetteurs et dates d’émission changent, mais les jetons de redirection conservent l’échéance soixante. Au temps soixante-cinq, cette condition d’accès n’est plus satisfaite.

Si le second réseau choisissait quatre-vingts en ajoutant soixante à sa propre date d’émission, il aurait créé une extension. Le calcul pourrait ressembler à une pratique ordinaire de création de jetons ; dans cette opération précise, il contredirait la règle de conservation. Cet exemple ne décrit aucun incident observé.

La même attention s’applique aux bibliothèques. JWT autorise dans son cadre général une petite tolérance pour les décalages d’horloge. Le profil CDNI interdit cette tolérance pour exp et nbf. Un paramètre de bibliothèque utile dans une autre application ne peut pas devenir une extension silencieuse de l’accès CDNI.

Les systèmes doivent synchroniser leurs horloges ; le profil recommande NTP. Il faut également choisir une durée initiale assez réaliste pour les échanges HTTP et les aléas du réseau. Prévoir cette durée au départ et accorder une marge cachée lors de la vérification sont deux décisions différentes.

Le renouvellement répond à une autre nécessité

Pour un contenu segmenté, le lecteur ne demande pas forcément les ressources dans l’ordre prévu. Il peut avancer dans la vidéo ou changer de représentation. Des adresses signées pour chaque segment et valables pendant toute la lecture peuvent élargir inutilement la fenêtre d’utilisation.

Signed Token Renewal permet au réseau, après vérification correcte et livraison réussie d’un segment, de remettre un jeton destiné à l’accès suivant. Le profil utilise cdniets pour calculer la nouvelle valeur exp : l’intervalle s’ajoute au moment de vérification. Le mécanisme requiert aussi cdnistt, qui précise le transport.

Ainsi, une vérification au temps cinquante-cinq avec un intervalle de trente produit une prochaine échéance de quatre-vingt-cinq. Ce calcul illustre un renouvellement expressément activé. Il ne permet pas de remplacer l’échéance soixante d’une redirection ordinaire par quatre-vingt-cinq.

La différence est institutionnelle autant que technique. Dans un cas, un acteur transmet un droit en adaptant son chemin. Dans l’autre, il exerce une autorité distincte de continuation, définie par le mécanisme et la politique convenus. Il ne peut pas rebaptiser toute signature récente « renouvellement » pour justifier une extension imprévue.

Une fenêtre renouvelable entre segments ne définit pas automatiquement une fin absolue de programme ou d’abonnement. Si le service exige aussi cette borne, les participants doivent préciser où elle est vérifiée. C’est une proposition d’organisation locale, non un nouvel attribut standard inventé pour l’occasion ou une obligation d’approbation centrale de chaque segment.

Le transport ne fait pas l’autorisation

Le transport de renouvellement peut être désactivé, assuré par cookie ou porté dans la requête. La valeur zéro signifie qu’il n’est pas activé ; le profil recommande d’omettre les attributs de renouvellement si l’on ne souhaite pas cette fonction.

L’association d’un cookie à certains chemins utilise la profondeur cdnistd. Une profondeur absente vaut zéro ; zéro peut conduire le client à renvoyer le jeton pour n’importe quel chemin. Cela ne supprime pas la restriction du conteneur d’URI. L’endroit où le client renvoie une preuve et les ressources que cette preuve autorise sont des périmètres différents.

Les restrictions de cookies entre domaines peuvent nécessiter le transport dans la requête. Le mécanisme décrit suppose que manifeste et segments soient livrés depuis le même domaine, la redirection entre domaines intervenant lors de la récupération du manifeste. Rien ne donne à un cookie le droit de transporter automatiquement une autorisation vers un destinataire sans rapport.

Le conteneur doit correspondre à l’URI demandée après retrait du paquet de signature, dans sa représentation avec encodage en pourcentage. Modifier la destination pour atteindre le contenu autorisé n’est pas élargir arbitrairement l’ensemble des ressources permises. Un conteneur très large sans autres contraintes peut devenir un passe-partout ; le profil déconseille ce cas.

Une URL signée ne prouve pas que le contrôle a eu lieu

La politique arrive aussi par les métadonnées CDNI. Le drapeau de contrôle de signature vaut vrai par défaut. Lorsqu’il vaut faux, le réseau aval ne vérifie pas le jeton, même si l’URL en contient un. L’apparence d’une adresse signée ne prouve donc pas l’exécution des contrôles attendus.

Une liste d’émetteurs vide ne signifie pas davantage accepter n’importe quel signataire. Elle autorise les émetteurs du magasin de clés de confiance. La valeur par défaut dépend toujours d’une confiance déjà établie.

Les interfaces de capacités et de routage permettent de choisir un réseau capable de traiter le mécanisme. Sa disponibilité géographique et son annonce de capacité ne prouvent pas la conservation des bornes dans une demande particulière. Les observations d’application du contrôle et de refus, prévues dans la journalisation, peuvent aider à le vérifier.

Pour jti, la présence d’un identifiant ne suffit pas non plus. La redirection conserve sa valeur lorsqu’elle existe, sans en ajouter si elle était absente. Le profil exige la vérification de l’état d’utilisation pour le même contenu. Stockage, rétention et périmètre sont nécessaires ; sans échéance, une mémoire bornée peut finalement permettre une réutilisation. Un identifiant commun ne crée pas spontanément un registre mondial de consommation unique.

L’analyse porte sur les obligations publiées et les questions de coordination qu’elles rendent visibles. Aucun défaut fournisseur, taux d’incident ou soutien universel n’a été mesuré. Une coopération locale reste possible : chacun choisit sa route et sa mise en œuvre dans un accord limité, sans déplacer la borne temporelle sous couvert de transmettre la demande.

Sources