要約

  • RFC 9783 は PSA Initial Attestation 用の Entity Attestation Token を定義し、nonce、client ID、instance ID、implementation ID、ライフサイクル、ソフトウェア構成要素を限定された主張として運ぶ。
  • 保護された証拠は Verifier の評価に使えるが、Relying Party が登録、アクセス、保留、次の行為を認めるべきことまでは証明しない。

この RFC の要点は、技術的な真偽と行為の正当化を一つにしないことにある。RFC 9334 の RATS では、Attester が Evidence を出し、Verifier がそれを評価し、Relying Party が Attestation Result を自らの目的に用いる。RFC 9783 はその最初の材料を PSA 向けに相互運用可能にする。評価と利用者側の決定を省略する合格印を作るものではない。

nonce はよい境界の例である。プロファイルは一つの nonce を求め、長さを 32、48、64 バイトに定める。これにより報告は特定のチャレンジと結びつき、Verifier は古い報告の再利用ではなく新鮮な証拠かを確かめられる。だが、これは要求時点についての性質である。要求者がそのサービスを受ける権利を持つこと、運用者が同意したこと、現在の報告が長期の許可に値することは導かれない。鮮度は再送を防ぐための根拠であって、包括的な許可ではない。

client ID の範囲も同じように限定される。これは Initial Attestation を呼び出したセキュリティ・ドメインを表す。RFC 9783 は、一つのエンドポイントが別のドメインを装うことを防ぐため、Verifier がこれを確認しなければならないとする。ここでの不一致は重要な拒否理由になる。しかし一致して分かるのは、どの呼出し元ドメインかだけである。どのテナント、資産所有者、業務フローに特権を与えるかは、その後に別の規則で決める問題だ。呼出し元を分離することと、権限を配ることは異なる。

instance ID と implementation ID も混同してはならない。instance ID は特定の Initial Attestation Key とインスタンスを示す。implementation ID は個別インスタンスではなく、不変の PSA Root of Trust ハードウェア構成を示し、Verifier は Endorser から製造者情報や認証状態を探す手掛かりにできる。「どの実体がこの報告を出したか」と「どの実装が主張されているか」は別の問いである。どちらも価値があるが、「サービスは今何をすべきか」の答えではない。

ライフサイクルとソフトウェア構成要素についても、強いが狭い意味を守るべきだ。ライフサイクルには major と minor の状態があり、プロファイルは信頼すべきでない状態を示す。構成要素は PSA Root of Trust が測定した範囲でロードされたコード、設定などを表す。これらにより Verifier は拒否、より狭い評価、追加証拠の要求を正当化できる。それでも、ワークロードの現在目的、顧客の承認、運用者の命令権、実行後の効果までは示さない。

技術的に整ったトークンに対しても、Relying Party が否定することは正しい場合がある。Verifier が署名保護、nonce、ドメイン、実装、ライフサイクルを自身の方針どおりと評価しても、未承認の配備であれば登録を断り、Endorser 情報が揃うまで一時的なアクセスに留め、不可逆な行為には別承認を求められる。これはアテステーションの欠陥ではない。技術信号を現実の結果に変える責任を誰が負うかという設計である。

Heng Lu の最小初期仕様という考え方は、この抑制を支持する。共通の仕組みは、限られた共有主張を検査可能にし、将来の局所判断まで奪わないことで役に立つ。実行中のコードが報告を作成し検証できたことは、定義された仕組みが動いたことを示す。それだけでサービス、資本、または人への影響を決める権限にはならない。