要約

  • RFC 9246では、CDNIの通常のリダイレクトで作るトークンは、既存のexpとnbfの値を変更せずに保つ。元にない両項目を追加することも認められない。
  • 発行者、発行時刻、適切な宛先やURIの情報は変更できる。署名が新しいことは、アクセス期間を新しく与えた証拠ではない。
  • セグメント用トークンの更新は明示的に有効にする別の仕組みで、検証時刻とcdnietsから次の期限を計算する。
  • 個々のトークンにexpが必ず含まれるわけではない。受け入れ条件、鍵への信頼、実際に行う要求ごとの検証も期限の効力を左右する。
  • 本稿は公開済み仕様に基づく分析であり、CDNの不具合を再現した報告でも、実装の普及率や事故頻度の測定でもない。

経路を変えるための署名

コンテンツ提供者が要求を許可し、上流のCDNが配信に適した下流のCDNを選ぶ。下流は別の発行者を信頼しているかもしれず、要求先のURIも変わる。そこで上流が新しいトークンに署名する。この手順自体は自然な協調だ。

ただし、新しく作られたトークンを見ただけで、アクセスの許可がその瞬間から始まったと判断してはならない。新しい発行時刻は、新しい署名付きの形式を作った時刻を示す。そこに収めた許可の期限まで新しくするとは限らない。

配信の成功、正しい宛先、有効な署名は、いずれも重要な確認結果である。それでも、期限を延ばす権限があったかどうかは別に残る。信頼された署名者が誤った変換をしても、暗号学的な検証が成功する場合はある。

RFC 9246は、通常のリダイレクトについてこの境界を明記している。すでにある有効期限は同じ値のまま引き継ぐ。配信経路で消費した時間を、新しい署名によって取り戻す仕組みではない。

公開された仕様の範囲

RFC 9246は2022年6月に発行されたIETFの標準化過程に属する文書で、RFC Editorの記録ではProposed Standardである。JWTに署名してURI Signingを行い、相互接続されたCDNで要求ごとのアクセスを制御する方法を定める。単一CDNで利用する構成も排除しない。

これは、すべてのCDN製品が同じ機能を実装しているという調査結果ではない。公開された処理規則と、各配信環境での対応状況は区別する必要がある。鍵の設定、受け入れ条件、更新の有効化、検証の設定によっても結果は変わる。

また、コンテンツ保護そのものではない。期限は今後の要求を受け入れる条件になり得るが、すでに渡したデータを回収するものではない。期限切れを、受信者の手元にある複製が消えたことと同一視できない。

仕様は、宣言項目を実装として処理できることと、個々のトークンに必ず含めることも分けている。URIコンテナーは必須だが、expやnbfは個別のトークンでは任意である。expが届いたら無視してよい、という意味ではない。

すべての初期トークンに期限が必要なサービスなら、その条件を入口の受け入れ方針として明示する必要がある。「CDNIに準拠している」という説明だけでは、その条件まで満たしたことにならない。

期限の値を保存する

第2.1.4節では、受け取ったJWTにexpがある場合、リダイレクト用に作る後続JWTにもexpを含め、その値を変えないよう要求する。元のJWTにexpがなければ、通常のリダイレクトで追加してはならない。

検証側は、要求時刻がexpと等しいか、それより後なら拒否する。届いたexpを検証できない場合も拒否が必要だ。項目が存在することを確認しただけでは、期限を適用したことにならない。

nbfは、いつから受け入れられるかを示す。すでにある値はリダイレクトで保ち、ない値を追加しない。nbfより前の要求は拒否し、等しい時刻ならこの開始条件を満たす。expとの等号の扱いは違う。

期限のないトークンに短いexpを足す方が安全に見えることもある。しかし、リダイレクトは受け取った許可を経路に合わせて移す操作であり、宣言項目全体を作り直す権限ではない。入口の方針に合わないなら、その境界で拒否するか、本当に許可できる相手から別の新しい許可を得る。

後者は、新しく認められた要求であって、元の許可を通常どおり転送したという説明とは異なる。数字が短くなったか長くなったかの前に、どの操作を行ったのかが必要になる。

新しい発行時刻と古い期限は両立する

iatはJWTの発行時刻を示す。CDNIでは元にiatがある場合、新しいリダイレクトJWTを生成した時刻に更新する。元になければ追加できる。したがって、新しいiatと変わらないexpが同居するのは、正しい変換の結果になり得る。

issがある場合も、リダイレクトするCDNを発行者として示すよう変える。下流には、信頼する発行者と鍵の対応が事前に必要であり、項目の発行者と実際の署名鍵を照合する。未知の名前が署名付きで届いたからといって、信頼が新しく生まれるわけではない。

audは、要求を処理するよう設定された配信の連鎖の識別情報に合わせて変更できる。URIコンテナーも、リダイレクト先のURIに合わせられる。それぞれ、次の相手が何を検証すべきかを表すための変更だ。

これらの許可は、ほかのすべての項目まで自由に変更できるという意味ではない。iatは新しい形式の年齢を示し、expはアクセスに付いた時間条件を示す。「今から一定時間」と機械的に結び直すと、経路変更を期間の再付与に変えてしまう。

JWSは署名やメッセージ認証コードによる完全性の仕組みを提供する。JWTのベストプラクティスは、アルゴリズム、発行者、受信者などの適切な検証を求める。有効な署名を確認しても、その署名者にあらゆる期限変更を認めたことにはならない。

鍵の配布と信頼の確立は、この仕様だけで全部決まるわけではない。公開鍵なら検証と署名を分けられるが、共有の対称鍵を持つ相手はトークンを作ることもできる。仕様は互換性のために共有鍵を扱うものの、推奨しない。非対称鍵でも、信頼した署名者の操作範囲は明確にする必要がある。

経路で使った時間の例

論理時刻六十を期限とする初期トークンを考える。最初のCDNが十でリダイレクトし、次のCDNが二十で再び経路を変える。発行者やiat、必要なURIの情報は変わるが、通常のリダイレクトでexpは六十のままだ。

六十五で届いた要求は、この期限条件を満たさない。二つ目のCDNが自分の時刻二十に六十を加え、八十へ変更したら、経路選択ではなく期間の延長をしている。署名や宛先が正しくても、その変換の意味は違う。

これは特定のCDNで確認した事故ではない。公開された規則が区別する二つの計算を示すための仮定である。新しい署名の時刻から期限を作ることと、元の絶対時刻を引き継ぐことは一致しない。

検証時の解釈も確認が必要だ。一般のJWTではexpやnbfに少しの時計ずれの許容を設けられるが、RFC 9246の用途では認められない。別用途向けのライブラリー既定値を、そのままCDNIのアクセス許可にしてはならない。

関連システムは時刻を同期し、仕様はNTPを推奨する。HTTPのやり取りや一時的な遅延を考え、最初の許可期間に現実的な余裕を置くことはできる。検証側が独自に隠れた延長を加えるのは別の判断だ。時計の同期は、遅れた経路に時間を返すためではない。

セグメントの更新は別の権限

分割された動画では、次に要求されるセグメントをいつも予測できるわけではない。再生位置を変えたり、表現を切り替えたりする。全セグメントに長期間有効な署名URIをあらかじめ用意する方法には、必要以上に広い利用時間を与える問題がある。

Signed Token Renewalは、正しく検証してセグメントの取得が成功した後、関連する次のリソース用のトークンを渡す仕組みだ。cdnietsは検証時刻に加える秒数で、次のexpを計算する。更新を使う場合には、伝送方法を示すcdnisttも必要になる。

五十五で検証し、cdnietsが三十なら、次の期限を八十五と計算できる。この例は明示的に有効にした更新の計算であり、通常のリダイレクトが元の六十を八十五へ変えてよい理由ではない。

伝送は無効、cookie、クエリーの方式を持つ。値ゼロは無効を示す。更新が不要なら、仕様は該当する二つの項目を省略するよう勧める。トークンに署名できることから、更新権限まで暗黙に推定しない。

セグメント間の短い更新可能期間は、番組や資格の絶対的な終了時刻を自動で表すわけでもない。両方が必要なら、追加条件をどこで適用するか合意が必要だ。本稿が新しい標準項目を作るという提案ではなく、すべてのセグメントを提供者が中央で承認するという要求でもない。

下流は、委ねられた範囲で検証と更新を自律的に行える。重要なのは、期間の継続を認めた操作なのか、受け取った許可の経路を変えただけなのかを、参加者が区別していることだ。

届け方はリソースの許可範囲ではない

更新したトークンをcookieで返す場合、cdnistdによる深さは、クライアントが後でトークンを付けるパスの関連付けに使われる。項目がない場合はゼロとなり、ゼロではすべてのパスへの返送が示され得る。それでもURIコンテナーの制限はなくならない。

異なるドメインのcookieに関する制約で、クエリーによる伝送が必要になる場合もある。記述された更新方式は、マニフェストとセグメントを同じドメインから配信し、ドメイン間のリダイレクトはマニフェスト取得時に行う構成を前提にする。

クライアントがどこに証明を添えるかと、証明が何の取得を許すかは別だ。便利なcookieがあることから、関係のない相手にアクセス権を届けたり受け入れさせたりできるとはいえない。

URIコンテナーの比較では、署名パッケージを除いた要求URIのパーセント符号化された形を使う。許可された内容へ到達するための書き換えと、追加のリソースへ対象を広げることも分ける。ほかの制限がない広いワイルドカードは、強すぎる通行証になり得ると仕様は警告している。

署名が見えることと検証が走ること

URI Signingのメタデータには、検証を適用するenforceがあり、既定値は真だ。偽の場合、URIに署名が含まれていても下流は検証しない。署名付きURLを見ただけでは、意図した条件のチェックが実行された証拠にならない。

発行者のリストが空の場合も、インターネット上の全発行者を信頼するという意味ではない。信頼された発行者の鍵ストアにある相手が対象になる。既定値の実効性は、独立して確立した信頼の境界に依存する。

CDNIのフレームワークとメタデータ、能力の通知、要求の経路選択は、対応可能な下流を選ぶために協調する。地理的な適合や対応能力の広告は、特定の要求で期限を保存し、検証を適用したことまで証明しない。

jtiも文字列だけでは再利用を防げない。存在する値はリダイレクトで保ち、ない場合は追加しない。仕様は、同じ内容での既使用状態を調べるための記憶を求める。保持範囲や削除時期が必要であり、期限のない有界な記憶では、いずれ識別子の再利用が可能になり得る。

共通の識別子があるだけで、全CDNにまたがる一回限りの利用記録が自動で生まれることもない。新しい署名は、過去の利用や経過時間、必要な検証を消去するものではない。

適用した検証や拒否理由のログは、要求の処理を裏付ける手掛かりになる。ただし、成功の表示一つはすべてのチェックの証拠ではない。調査のために実際に利用できるトークンや個人情報を露出させる必要もない。

本稿の根拠は公開済みの仕様であり、実際の障害や普及範囲の測定ではない。heng.luの最小初期仕様、各現場での将来判断、自発的な採用という考え方は、限定した共通の約束と参加者の自律性を両立させる統治の視点だ。JWTの処理規則の代用ではなく、許可の時間境界を勝手に動かさずに協調するための視点として用いる。

出典