要約

  • アプリ、OS、ファームウェア、ハードウェアを別々の事業者が担う装置では、信頼済みEndorserの一覧だけでは各主体の発言範囲が分からない。
  • OSベンダーの署名が真正でも、ハードウェアについての主張は委任範囲外になり得る。
  • 第11版は範囲の結び付きを評価ポリシー、Evidence、または両方に置けるため、判定には実際に使った結び付きを残す必要がある。

遠隔アテステーションの事故は、偽造された署名から始まるとは限らない。全員が本物で、全ての証明書が有効でも起こる。OSベンダーがハードウェアの性質を述べ、その主張をVerifierが受け入れたとき、壊れているのは暗号ではなく担当範囲だ。

RATS Endorsements 第11版は、装置をアプリ、OS、ファームウェア、ハードウェアのTarget Environmentに分ける。各層の供給者は、自らの環境について追加のclaims setを提供できる。ただし、Verifierが「信頼するEndorser群」を持つだけでは足りない。どのEndorserが、どのTarget EnvironmentについてEndorsementを出せるのかを区別しなければならない。

草案の例は、OS EndorserをOSについて信頼しても、ハードウェアについては信頼しないというものだ。これは評価点ではなく、入力を受け付ける前の権限境界である。署名検証は発信者を確かめる。発信者がその層を語れるかどうかは別の規則が決める。

規則の置き場所も一つではない。Appraisal Policy for Evidenceに持たせてもよい。Evidence自身が、追加主張を許すEndorserを示してもよい。双方を組み合わせることもできる。したがって、Endorsementのバイト列だけを保存しても、後から採用理由を再現できない。

同じ署名済みメッセージを二つのVerifierに渡しても、層の識別、ポリシーの版、Evidence内の指定が異なれば結果は分かれ得る。その差を「実装差」で済ませると、誰に何を委任したかが監査から消える。

RFC 9334の役割分離は、この問題を理解する土台になる。Endorserは主張を供給する。Verifier OwnerはEvidenceの評価ポリシーを管理する。Relying Party OwnerはAttestation Resultを使って行動するかを決める。情報源、評価、実行は別々の権限だ。

条件付きEndorsementのmatching policyも最終判断ではない。条件に合うclaims setを入力へ加える処理は、その主張が適用可能かを決めるだけで、装置の信頼性を決めない。しかも、そのEndorserが対象層を語る資格まで与えるものではない。

識別子と鍵の検索にも限界がある。RFC 9711のUEIDはAttesterを識別し、検証鍵を探す手掛かりになり得る。しかし第11版は、鍵がインスタンス、クラス、その他のclaimsのどこまで適用されるかを個別手順に委ねる。鍵が見つかったことと、装置全体への発言権は同義ではない。

再現可能な記録には、Evidenceの鮮度、Endorserの身元と検証経路、Target Environmentの識別と階層、当該Endorserに当該層とclaims classを許す規則、採用したEndorsementの版、Verifierとポリシーの識別、Relying Partyの決定と実際の効果が必要になる。

文書履歴では、第11版はIESG Evaluationにあり、2026年10月8日のtelechat議題に載っている。第09版との差分は確認できるが、第11版テキストはなおInternet-DraftでありRFCではない。

CoRIM 第11版はEndorsementsとReference Valuesの具体的なモデルを示す。それを採用しただけで、層ごとの委任が正しく保存・実行された証拠にはならない。

出典