Summary

  • 11月2日付のIETF個人草案は、ESTに遠隔アテステーションを組み合わせ、資格情報の新規発行と既存情報の取得を扱う。
  • ESTクライアントとサーバーは証拠や応答を運ぶ役目に限られる。証拠を評価する検証者と、発行・引き渡しを許可する機関や保管庫が判断を担う。

申請書を受け取る窓口は、許可を出す役所ではない。ESTの遠隔アテステーションを扱う新草案は、その当たり前をプロトコルの境界にした。ESTのクライアントとサーバーは鍵、証拠、証明書署名要求を作れず、鮮度確認用の値も発行できない。証拠の評価や資格情報の発行・引き渡しの承認も禁じる。サーバーが前の要求と鮮度確認用の値を照合できても、それは処理の対応付けにすぎないと明記する。

新規発行では、ワークロード自身が署名鍵と証明書署名要求を用意し、稼働状態の証拠を結び付ける。検証者が証拠を評価し、資格情報の発行機関が秘密鍵の保持を確かめたうえで、評価結果と自らの方針に従って発行を決める。ESTは往復の通路になる。通路の管理者に発行権が生まれるわけではない。

既存の資格情報を取り出す手順では、ワークロードが復号用の鍵を作り、公開鍵を証拠に含める。秘密情報の保管庫は検証結果から許可された資格情報群を選び、公開鍵に向けて束を暗号化する。中継するEST側はその容器を不透明なものとして扱う。受け取ったワークロードは宛先、鮮度情報、資格情報のヒントを確認してから開く。ヒントは保管庫の方針で許された範囲を選ぶ材料にはなるが、許可の範囲そのものは広げられない。

複数の実行インスタンスに同じ資格情報を配れば配布は楽になる。その代わり、後から一つの署名をどのインスタンスが行ったか追えなくなる、と草案は書く。必要ならインスタンスごとに別の鍵を持たせ、同じ身元の主張を載せるか、署名を一カ所で行う。保管庫の設計が監査の粒度を決める以上、これは事故後に付け足せる設定ではない。

IETFの登録情報では、文書は個人提出の草案だ。記載された通信例は実装間の相互運用を証明していない。中継サーバーが資格情報の種類や鍵の結び付けを変えたとき、発行機関や保管庫が拒否する実装試験が次の判断材料になる。草案が先に確定したのは、誰が配送し、誰が決裁するかという線引きである。