要約

  • 28日付の草案は、測定値が表すのはワークロードの種類であり、同じイメージで動く個々の実行体ではないと整理した。
  • 提案は、アテステーションで裏づけた鍵を使う方法と、その鍵にWIMSE証明書の継続的な名前を結び付ける方法を並べる。

合格印を押された二台の装置が並んでいる。検査表は同じ。片方にだけ秘密を渡した担当者が翌日戻ると、どちらが受取人だったかを検査表からは読めない。新しい草案が扱うのは、まさにこの識別の穴だ。

Tirumaleswar Reddyらの文書はSEATに向けた個人提案で、作業部会の採択済み方式ではない。本文はまず用途を分ける。承認済みイメージのどれか一つに秘密を渡すなら、種類の確認で目的を果たせる。特定の実行体に再接続するなら、種類だけでは手がかりが足りない。

第一案では実行体が保護された環境内で鍵を作る。その公開鍵をアテステーション証拠に載せ、TLSでも同じ鍵を提示する。生の公開鍵か自己署名証明書を使い、認証局による名前の発行は求めない。信頼の根は証拠に署名するアテステーション側にある。鍵の識別はできても、鍵を交換した後まで続く別のワークロード名は生まれない。

第二案は名前の持ち主を増やす。WIMSEの資格情報案に沿った証明書がワークロード識別子と鍵を結び、アテステーションが同じ鍵を実行環境に結ぶ。名前は鍵の更新をまたげる。ただしWIMSEの識別子は一つの実行体にも、複数の実行体が共有する論理的な仕事にも付けられる。粒度を決めるのは発行側の信頼領域だ。認証局による発行と失効の判断も運用に入り込む。

証明書が有効で、環境の測定も真正でも、組み合わせが許可済みとは限らない。ある名前のサービスに認められていないイメージで、その名前の証明書を使う余地があるからだ。草案は必要な場合、接続を受ける側が名前と測定値を一緒に評価するよう求める。さらに鍵の所持証明だけでは、その秘密鍵が保護領域で作られ、外へ出せない状態にあることまでは示せない。

RFC 9334が分けた証拠の作成、評価、利用判断のうち、最後の判断がここで重みを持つ。誰が名前を付け、その名前にどの実行環境を許したのか。機械が正しいというだけでは答えにならない。