要約

  • RFC 9999は、Evidence、Endorsements、Reference Values、Attestation Results、Appraisal PoliciesをCBOR、JSON、JWT、CWT、X.509で扱うための自己記述型CMWを定めた。
  • Record、Tag、Collectionという形は型と構造を与えるが、真正性、完全性、機密性、複数部品の同一装置への帰属、アクセス許可を与えない。
  • 一台の複合装置を表すCollectionでは、すべてのEvidenceを暗号学的に結合し、その後にVerifierが評価し、Relying Partyが用途別の行動を決める必要がある。

データセンターの受け入れ検査を考える。サーバーのCPUはブート状態を報告し、SmartNICはファームウェアを報告し、GPUは独立した実行環境について証拠を出す。収集機能は三つを一つのCollection CMWに収め、Verifierへ送る。

ここでSmartNICの項目だけを、別の健全な装置から得た有効なEvidenceに差し替える。各項目の署名は通る。メディアタイプも正しい。Collectionの構文も正しい。それでも、この集合は目の前の一台を表していない。項目間の帰属を保証する結合がなければ、正しい三つの検証結果から、誤った一台分の結論を作れてしまう。

2026年7月にIETF Standards Trackとして公開されたRFC 9999は、RATS Conceptual Message Wrapper（CMW）を定義する。狙いは、RATSの概念メッセージを個別のプロトコルやシリアライズ方式から切り離し、共通の外形で運び、適切な処理系へ渡せるようにすることだ。ラッパーは可搬性を作る。中身の真実性までは作らない。

型の識別は評価ではない

RFC 9334では役割が分かれている。AttesterがEvidenceを作る。VerifierはEvidenceをEndorsements、Reference Values、Evidence用のAppraisal Policyと照合し、Attestation Resultを出す。Relying Partyはその結果を、Attestation Results用の自らの方針に従って利用する。

RFC 9999のindビットマップは、Reference Values、Endorsements、Evidence、Attestation Results、Appraisal Policyを0から4の位置で示す。Record CMWは、メディアタイプまたはCoAP Content-Format、値のバイト列、必要ならこの指示値を持つ。

この情報は処理先を選ぶために有用だ。だが、Evidenceという型だと分かったことは、そのEvidenceが新鮮で正しいことを意味しない。Endorsementの発行鍵が信頼できるとも、Reference Valueが現在の承認状態を表すとも限らない。Attestation Resultも、別のVerifier方針で作られたなら、現在の用途には足りないかもしれない。

CMWの中核処理は、内部形式を理解せず、型に応じたプラグインへ不透明な値を渡せる。これは実装上の強みである。同時に権限の境界でもある。デマルチプレクサが持つのは「どこへ渡すか」という権限であり、「この装置を許可する」という権限ではない。

Collectionは一台という意味ではない

CMWは木構造をとる。RecordとTagが葉になり、Collectionが複数のCMW項目をラベル付きで保持する。Collectionの中にCollectionを置くこともできる。異なる形式の証拠を一つの運搬単位にまとめられるため、CPU、SmartNIC、GPUのような異種部品には適している。

しかし規格上、Collectionは複数種類の概念メッセージを混在させてもよく、複数装置に関する項目を同時に運んでもよい。したがって「Collectionを受信した」から「一台分の完全なEvidenceを受信した」へは飛躍できない。

任意の__cmwc_tはURIまたはOIDで集合の型を示し、ラベルを解釈する名前空間を与える。期待される組み立てを表すために使えるが、それ自体は署名ではない。保護されていない型名は、集合が何であるべきかという主張であって、実際にその通りである証明ではない。

再帰構造には深さ制限も必要になる。規格は実装が上限を設けることを認める。入口のゲートウェイが一段しか見ず、奥のVerifierが四段を処理する構成では、同じオブジェクトに異なる意味が生じる。最大深度、未知の型、過剰な項目数に対する動作は、ホストプロトコル全体で合わせなければならない。

暗号の対象範囲を一語で潰さない

RFC 9999は、CMW単体には真正性、完全性、機密性がないと明記する。CBOR形式ならCOSE_Sign1、JSON形式ならJWSで署名でき、JWTやCWTのcmw claimとして運ぶこともできる。できることと、自動的に保証されることは別だ。

一台の複合装置についてCollectionを使う場合、内部のすべてのEvidenceは暗号学的に結ばれなければならない。Collection全体への署名でもよい。共通の識別子やnonce、項目間の署名、ハッシュ連鎖でもよい。重要なのは、健全な別装置の証拠を差し込んでも成立しない関係を作ることである。

外側の署名だけでは不足する場合がある。収集デーモンが署名したことは分かっても、そのデーモンが装置のRoot of Trustに結び付くとは限らない。全項目に同じ製造番号が書かれていても、誰でもその番号を書けるなら意味は弱い。共通nonceも、認証された経路で各Attesting Environmentに届き、各応答がnonceを署名対象に含めて初めて同じセッションを示す。

運用記録には「署名有効」だけでなく、原文Collectionのハッシュ、外形、集合型、ラベル、各項目のメディアタイプと指示値、署名者、鍵識別子、新鮮性情報、装置結合方式、ネスト深度、検証ログを残す必要がある。そうしなければ、保護されたのが各葉なのか、集合の構成なのか、外側のJWTだけなのかを後で区別できない。

運搬先が変われば、保護の意味も変わる

RFC 9999はapplication/cmw+cbor、application/cmw+json、application/cmw+cose、application/cmw+jwsを登録し、JWT/CWTのclaimとX.509拡張も用意した。同じ概念メッセージをAPI、制約環境、証明書などへ持ち込める。

一方、JWSがCollectionを署名していても、後で取り出して保存した内部Evidenceまでは保護しないことがある。JWTの発行者を確認しても、内部のEvidence生成者は別かもしれない。TLSは通信区間を保護するが、転送された内包物の原発行者を保証しない。CBORをJSONへ変換すれば意味が保たれても、元のバイト列に対する署名と法証性を失い得る。

だからホストプロトコルは、許すメッセージ種別と組合せ、必要な保護、CMWとの接続点、双方のセキュリティモデルの相互作用を定義しなければならない。「ペイロードはCMW」とだけ書く仕様は、構文を選んだだけで、信頼モデルを選んでいない。

X.509拡張のcritical指定は、その差を端的に示す。通常はcriticalにしない。しかし、CMWがリソースアクセスの必須条件で、古いRelying Partyが未対応拡張を無視して制御を迂回する恐れがあるなら、criticalにしてよい。未対応の実装を止めるか、証明条件なしで進ませるかという決定である。

公開証明書にはプライバシー問題もある。Evidenceには個人情報だけでなく、HSMの型式やパッチレベルが含まれ得る。申請者がCAへ提示した情報を、公に配布される証明書へ収録してよいとは限らない。RFC 9999は、第三者から得たEvidenceを公表する場合、CAの認証実施規定で条件を明確にするよう求める。

結果トークンは最終判断者ではない

Verifierが肯定的なAttestation Resultを出すと、ゲートウェイはそれを許可命令として扱いたくなる。だがRFC 9334は、Evidenceを評価するVerifier Ownerと、結果を用途に適用するRelying Party Ownerを分ける。

同じ有効な結果でも、監視テレメトリなら許可、管理面なら隔離、鍵署名なら拒否という判断があり得る。要求された操作、ネットワーク区画、結果の有効期間、例外承認はRelying Party側の事実である。

再現可能な台帳は、Evidenceと結合記録、EndorsementとReference Valueの版、Verifier方針と結果、Relying Party方針と要求操作、最終行動を連結して保存する。一つの真偽値へ圧縮すれば原因が消え、結果トークンだけ残せば、誰がどの権限で行動を決めたかが消える。

Lu HengのRunning-Code Primacyをここへ当てると、正式なラッパーは重要な来歴だが、処理系、Verifier、アクセス制御が実際にどう動いたかを上書きできない。Minimum Initial SpecificationとしてCMWの薄い共通文法を採用し、結合、許可する組合せ、結果の使い方は現場で明示する。Reality Layersの観点では、型、署名、評価結果、実行されたアクセスは四つの別の現実である。