要約

  • RFC 9999は、RATSのEvidence、Attestation Results、Endorsements、Reference Values、Appraisal Policiesを、CBOR、JSON、JWT、CWT、X.509、HTTP、MIME、CoAPの間で扱うための自己記述型ラッパーを定める。
  • Record、Tag、CollectionというCMWの形は、内容の識別と振り分けを可能にするが、単独では真正性、完全性、機密性、鮮度、意味評価、認可を与えない。
  • 一つの複合デバイスまたは階層デバイスを表すCollectionでは、各Evidenceを暗号学的に結合する必要がある。個別に有効な署名だけでは、同じ装置・同じ時点・同じ取引に属することを証明できない。

交換作業を終えたばかりのサーバーが、本番ネットワークへの復帰を申請した。検証システムには、CPU、SmartNIC、GPUという三つの項目を持つCollectionが届く。形式はすべて既知で、内部署名も通る。画面上では、三つの緑が一台の緑に見える。

しかし交換前に保存されたGPUのEvidenceと、予備機に載った健全なSmartNICのEvidenceを混ぜても、各署名は壊れない。CPUのEvidenceだけが申請中のサーバーに由来することもあり得る。偽造された事実は一つもない。それでも、組み立てられた「健全な一台」は現実に存在しない。

RFC 9999は、2026年7月にIETF Standards Trackとして公開されたRATS Conceptual Message Wrapper（CMW）の仕様である。狙いは明快だ。リモートアテステーションには複数の概念メッセージ、クレーム形式、シリアライズ、搬送プロトコルがある。新しい方式が増えるたびに受け側のプロトコル本体を書き換えるのではなく、型を明示した共通の包みで受け渡したい。

この標準化は強力だが、権限の範囲は狭い。CMWは「どの処理系に渡すべきか」を示す。「何を信じ、何を許可するか」は示さない。

RATSは評価と認可を分けている

RFC 9334では、AttesterがEvidenceを作り、VerifierがEndorsements、Reference Values、Appraisal Policyと突き合わせてAttestation Resultsを作る。その結果を受けたRelying Partyが、自身のポリシーでアクセス、鍵の解放、コマンド受理などを決める。

CMWはこの分業を保ったまま、メッセージの外形を共通化する。Record CMWはtype、不透明なvalue、必要な場合のindから成る。indはReference Values、Endorsements、Evidence、Attestation Results、Appraisal Policyのいずれが含まれるかを示せる。Tag CMWはRFC 9277の変換を使い、CoAP Content-FormatからCBORタグを導く。Collection CMWはラベル付きのCMWをまとめ、さらに別のCollectionを内包できる。

IANAのRATS Parametersは指示ビットを調整し、RFC 9711はEntity Attestation Tokenを、RFC 9782はEATのメディアタイプを定める。登録された型によって、コア処理は適切なプラグインを選べる。

だが型は配送先であって、信用状ではない。Evidenceという指示は、その値がRATSフローで果たす役割を記述するだけだ。発行者が正当か、クレームが真か、プロファイルが運用ポリシーに合うかまでは証明しない。IANA登録も識別子の衝突を避ける仕組みであり、実装、採用、信頼の保証ではない。

「署名済み」では範囲が足りない

RFC 9999はCMWをセキュリティ形式ではなく、カプセル化形式だと明記する。Record、Tag、Collectionだけでは、真正性、完全性、機密性は得られない。

保護は内側の概念メッセージに存在するかもしれない。CBORのCMW全体をRFC 9052のCOSEで保護したり、JSONのCMWをRFC 7515のJWSで署名したりできる。安全なチャネルは転送中のデータを守り、challenge-responseはreplayに対処できる。

それぞれが証明する範囲は違う。チャネル認証は一回の接続主体を示しても、保存後のオブジェクトに由来を残すとは限らない。各メンバーへの署名は個々のバイト列を守っても、構成関係を守らない。Collection全体への署名は構成を固定できるが、その鍵が構成を主張する権限を持ち、署名対象のプロファイルが関係を定義している必要がある。

RFC 9781のUCCSは、名称どおり保護されていないCWT Claims Setである。CMWに入れれば識別しやすくなるが、真正性は追加されない。必要なら外側に保護を加える。この例は、ラッパーとセキュリティ境界を混同しないためのよい基準になる。

運用ログには、単なる「署名済み」ではなく、どのバイト、どの階層、どの鍵用途、どの信頼アンカー、どの保存・転送経路まで保護が続くのかを残さなければならない。

一台を名乗るなら、メンバーを結合する

複合デバイスでは、CPU、SmartNIC、GPUが別々のAttesting Environmentを持ち得る。ルーターでは、シャーシ、主制御部、ラインカードが個別にEvidenceを出すことがある。階層型の起動では、前段が後段を測定する。

Collection CMWは異なる形式を一緒に運べる。ところが一つの複合または階層デバイスのEvidenceとして使う場合、RFC 9999は全メンバーを暗号学的に結合するよう求める。外部のオブジェクト保護も、メンバー間のリンクもなければ、侵害された部品のEvidenceを健全な別装置のEvidenceと差し替えられる。

結合方法は一つではない。Collection全体を署名してもよい。共通識別子やnonceを使ってもよい。メンバー間で署名やハッシュをつないでもよい。ホストプロトコルが別の方法を定義してもよい。確認すべきなのは方式名ではなく、検証されたスコープが各メンバーを主張対象、トポロジー世代、取引に本当に結び付けるかである。

Collectionが常に一台を表すわけでもない。EndorsementsやReference Valuesをまとめたり、複数デバイスに関するメッセージを同居させたりできる。メンバーの順番に意味はなく、ラベルはそのCollection内でしか一意ではない。gpuやslot-1の意味は、Collection typeまたはassembly profile、実機インベントリ、装置ID、世代情報によって初めて固定される。

入れ子の自由には計算量の上限が要る

Collectionは再帰的に入れ子にできる。階層を自然に表現できる一方で、深さ、メンバー数、総バイト数、Base64処理、署名検証、外部参照の呼び出しが同時に増える。

RFC 9999は実装が最大深度を制限できるとしているが、その通知や交渉方法の詳細は範囲外に置く。したがって本番側が、総サイズ、要素数、深さ、暗号演算回数、ハンドラ時間、外部照会数を事前に決める必要がある。デコーダを選べたことは、無制限の資源利用許可ではない。

未知の型に対する挙動も役割ごとに違う。保管サービスは不透明なオブジェクトをそのまま保存できる。認可サービスは、未知の必須メンバーを無視して「複合デバイスを評価済み」としてはならない。「不正」「未対応」「欠落」「プロファイル上は任意」を別の状態として扱う必要がある。

型、ハンドラの版、対応プロファイル、アルゴリズム、資源予算、失敗時の挙動を一組で管理して初めて、拡張性が安全な互換性になる。

鮮度はデコード結果からは分からない

署名が正しいEvidenceでも、ファームウェア更新や部品交換の前に作られたものなら、現在の状態を語れない。RFC 9334は鮮度を別の制御として扱い、同期時刻、nonce、epoch IDを挙げる。

CMWはそれらを用いるメッセージを運べるが、すべてのメンバーが同じchallengeに応じたとは保証しない。CPUがnonce A、SmartNICがnonce B、GPUが時刻だけに結び付く場合、一つの取引として受け入れるかはassembly profileとVerifierポリシーの仕事である。

challenge、発行者、有効窓、時計前提、epoch、対象メンバーを保存しなければ、あとから「署名は有効だった」以上の再現ができない。

そしてVerifierの評価が終わっても、Relying Partyの認可は残る。保守ネットワークへ入れる健全性と、顧客データを読む権限や本番リリースを署名する権限は別だ。Attestation Resultを携帯できるからこそ、誰向けに、どのポリシーで、いつ作られたかを失ってはならない。

X.509に載せると秘密が配布物になる

RFC 9999はCMWをX.509証明書、CSR、CRLに含める方式も定める。既存のPKIX経路を使える反面、短命な交換内にあったハードウェア情報が長期間配布される可能性がある。

コード署名証明書を申請する者は、CAにはHSMのモデルやパッチレベルを示しても、証明書を受け取る全員への公開は望まないかもしれない。RFC 5280は証明書と拡張の一般規則を定めるが、その公開同意は作らない。RFC 3647は証明書ポリシーとCPSの枠組みを与える。RFC 9999は、第三者から受け取ったEvidenceを公開証明書に含める条件をCPSで明確にするよう求める。

必要なのは、発行前のクレーム最小化、対象読者、保持期間、プロファイル審査、公開権限である。証明書を失効させても、すでに複製された情報は回収できない。

形式の先にある実行経路を確認する

Heng LuのRunning-Code Primacyを当てはめると、見るべきものは実行された連鎖になる。どのパーサーとハンドラが動き、どのバイトと鍵が検証され、結合と鮮度がどう成立し、どのポリシーがどの結果を出し、現実にどの操作が行われたか。

最小の共通仕様と将来判断のローカル化という考え方は、CMWとレジストリの役割を狭く保つ。互換性は共有し、健全性基準、認可、損失責任は明確なローカル所有者に残す。

現実の層を分ければ、CMW準拠、暗号保護、意味評価、実際の効果が別々の判定だと分かる。緑の一灯にまとめないことが、運用可能性の条件である。