要約

  • RFC 9597はCOSEヘッダーパラメーター15にCWTクレームのマップを置き、暗号化、分離署名、非CWTペイロードでも先行参照できるようにした。
  • 先に読んだissuerで鍵候補を探すことはできても、暗号処理が終わるまでは経路も識別も暫定であり、後から確認または撤回しなければならない。
  • ヘッダーとCWTペイロードに同じクレームがあれば通常は一致確認が必要だが、一致は真実性、鍵の権限、プライバシー、認可を証明しない。

受信機は暗号化されたCOSEオブジェクトを前にしている。中身は読めない。だが、ヘッダーにはissuerがある。そこでissuer別の鍵ディレクトリーを選び、候補を取得し、処理スロットを予約する。ここまでは合理的だ。

問題は、そのissuerをいつ確定情報に昇格させたかである。署名が失敗した後もテナント名、キャッシュ、課金メタデータが残るなら、暗号検証はオブジェクトを拒否しただけで、先行クレームが作った現実を拒否していない。

RFC 9597は、CWTクレームを任意のCOSE構造のヘッダーに入れる標準表現を定めた。暗号化CWTだけでなく、分離署名や、CBORですらないペイロードにも使える。標準が提供するのは先行可視性の共通形式であって、先行信頼の許可ではない。

ラベル15は名前の衝突を防ぐ

COSEヘッダーパラメーターとCWTクレームは、どちらも小さな整数を使う。CWTの各キーをそのままCOSEヘッダーへ持ち込めば、二つの番号空間が衝突する。そのためRFC 9597は、IANAのCOSEレジストリーに「CWT Claims」をラベル15として登録し、その中を一つのマップにした。内側のキーはIANA CWTレジストリーに従う。

RFC 8392のissuer、subject、audience、expiration、not-before、issued-at、token identifierが代表例である。RFC 8610のCDDLはマップの形を記述する。

レジストリーが整えるのは名前である。どのクレームを必須にし、誰が表明でき、どの操作に使うかはアプリケーションが決める。ラベル15があるからといって、ペイロードがCWTであるとも限らない。画像やファームウェアをCOSEで署名し、鍵探索用のissuerだけを外側に置くこともできる。

保護された値にも権限審査は残る

RFC 9052はprotected mapとunprotected mapを分ける。RFC 9597はCWT Claimsをprotected側に置くことを推奨し、両側を通じて一度しか出現させない。

受信側は「推奨」を受信事実に読み替えてはならない。unprotected側に来た場合、拒否するのか、信用しない探索ヒントに限定するのかをプロファイルで決める必要がある。決めなければ、実装のフォールバックが政策になる。

protected側で暗号検証に成功しても、証明されるのは特定バイト列と鍵の関係である。その鍵がこのオブジェクト種別についてissuerを名乗る権限を持つこと、audienceがこのサービスを含むこと、期限が有効であること、業務操作を認可することまでは証明しない。

解釈の根拠も保護対象でなければならない。RFC 9597は自然な文脈がない場合、RFC 9596のtypを推奨する。タイプは検証契約を選び、その契約がクレームを読む。クレームだけがprotectedで、意味を選ぶ情報が改変可能なら、決定全体は保護されていない。

先行処理には越えてはならない線がある

issuerを使った鍵探索は、標準の具体例である。検証鍵を得るにはissuerが必要で、issuerを信じるには検証が必要という循環がある。この循環を理由にissuerへ権限を与えるのではなく、検証前の処理を狭くする。

未検証issuerは候補ディレクトリーを選べる。隔離キューや小さな計算予算も選べる。しかし、永続的なテナント作成、無制限な外部検索、請求先の確定、共有キャッシュへの書き込み、外部状態変更を許してはならない。

暫定レシートには、受信した完全なバイト列、ラベル15の保護位置、値、選択した枝、探索要求、候補鍵を残す。最終レシートには、暗号結果、解釈元、プロファイル版、ペイロードとの照合、audienceと時刻、ローカルポリシー、動作と結果を追加する。

RFC 9597は、未検証情報に基づく暫定判断を、暗号処理後に確認するよう求める。失敗時のテストこそ重要だ。探索成功後の署名失敗、正しいissuerと誤ったtype、別の分離ペイロードで、暫定状態が消えることを確認する。

Heng LuのRunning-Code Primacyをここへ当てると、仕様の「後で確認する」より、実際のロールバック記録が強い証拠になる。

二つのコピーが違えば、二つの権限が生まれる

RFC 7519はJWTとJOSEで類似の仕組みを定めていた。RFC 9597は、CWTのヘッダーとペイロードに同じクレームがある場合、アプリケーション固有の別ルールがなければ値の一致を検証するよう求める。

この照合は、入口がissuer Aで鍵を選び、奥のサービスがissuer Bで認可する混乱を止める。別ルールを使うなら、どのコンポーネントがどちらを読み、各コピーがどう保護され、差異がなぜ安全なのかを、プロファイル版とともに示す必要がある。

同じ値でも正しいとは限らない。二つとも期限切れ、二つとも別audience、二つとも権限のない鍵による表明かもしれない。RFC 8725が求める明示的な検証規則は、コピー一致の後にも必要である。

暗号化の外へ出した時点で公開範囲が変わる

ヘッダーで先に見えるクレームは暗号化されない。issuerは組織を、subjectは人や機器を、audienceは利用先を、token identifierは行動の連結可能性を示し得る。デバッグのため全クレームを複製すれば、暗号を破らずにプライバシーを失う。

必要なのは、先行処理に必要な最小の値だけである。ネットワーク観測者、プロキシ、キュー、ログ、トレース、キャッシュ、エラー応答のうち誰が見るか、保存期間は何か、安定subjectを短期の経路クラスに置き換えられないかを決める。署名成功は公開同意ではない。

これはHeng LuのMinimum Initial Specificationにも沿う。共通層はコンテナと照合の最小規則に留め、開示と認可は実行主体のローカル決定にする。

分離ペイロードでは取得履歴も証拠になる

COSEはdetached contentを扱えるが、RFC 9052は変更なく運ぶ責任をアプリケーションに置く。正しいissuerと有効なCOSE構造だけでは、検証対象のファイルが正しいことを証明できない。

取得先、取得時の文脈、実バイトまたはハッシュ、COSEオブジェクトとの結合結果を残す。さもなければ、正しい先行ヒントが別トランザクションの内容へ接続される。

最終的に言えるのは、クレームが見えた、この値と解釈がこの検証済みオブジェクトに保護された、ペイロードのコピーが規則を満たした、ローカルポリシーが許可した、動作と結果が観測された、という順序である。Reality Layersは、この文を一語に圧縮しないための規律である。

情報源