要約

  • draft-ietf-lamps-csr-attestation-29 は、CAまたはRAがCSR内の追加アテステーションを発行方針に照らして検証する道と、処理せず捨てる道の両方を残している。
  • 機微な端末証拠を公開証明書へ写さないという設計は妥当だが、その結果、証明書だけではどの評価が発行判断を支えたか分からない。CSR、評価結果、発行物を結ぶ保護された「発行証拠レシート」が監査上の空白を埋められる。

公開証明書からは見えない前史

IETFは9月2日、LAMPS作業部会のCSRアテステーション案について最終意見募集を始め、意見期限を9月16日とした。対象は第29版であり、データトラッカー上ではなお審査中だ。9月6日にはARTARTレビュー担当が割り当てられ、状態は「IANA Review Needed」とされている。履歴も、これが承認済みRFCではないことを示す。

この案が扱うのは、PKCS #10のCSRやCRMFの証明書要求に追加のアテステーション情報を添える仕組みだ。AttestationBundle には一つ以上の声明と、必要に応じて証明書群が入る。少なくとも一つの声明は、CSRの公開鍵に暗号学的に結び付いたアテステーションを含むことが推奨される。

しかし、運ばれた情報と、採用された情報は同じではない。草案はCAまたはRAに、発行方針のためアテステーションを検証する選択肢を与えると同時に、処理せず破棄することも許す。受理または要求するCAは、その運用をCPSに記すことが推奨される。つまり、同じ形式のCSRを受け取っても、ある発行者は評価し、別の発行者は読み飛ばし得る。

複数の正しい声明でも、対象が同じとは限らない

束の中にある各声明が個別に正しくても、それだけで一つの端末、一つの鍵、一つの現在状態を指すとは限らない。鍵への結合、端末やプラットフォームをまたぐ対応付け、鮮度の判断はCAまたはRAの責任として残る。古い証拠や結論不能の証拠を無視できることも、判断の幅を広げる。

この境界は、RATSアーキテクチャが区別するEvidence、Appraisal Policy、Attestation Resultとも整合する。さらに別のIETF鮮度草案がnonceや時刻に関する仕組みを検討しているのは、アテステーションが「いつの状態か」を後付けで自明にはできないからだ。

第28版から第29版への差分は、最終意見募集前の編集と明確化を追うには有用だ。ただし、CA/RAが検証するか破棄できるという中心的な境界を第29版が初めて発明した、と読むべきではない。第28版にも同じ設計の流れがある。

プライバシーを守りながら判断を残す

草案は、ハードウェア構成、パッチ状態、所有関係などを明らかにし得るアテステーションを、公開される証明書へコピーすることを推奨しない。再公開が必要なら、機微情報を除くべきだとする。これは欠陥ではなく、公開資格情報を端末台帳に変えないための重要な制約である。

ただし、非公開と無記録は別だ。運用者が残せる最小限の発行証拠レシートには、正規化されたCSRのハッシュ、評価したアテステーション束のハッシュ、適用した方針と版、鮮度判定、鍵やプラットフォームの結合結果、例外処理、発行証明書の指紋、決定時刻を含められる。生の端末証拠はアクセス制御された保管先に置き、レシート自体も保持期間と閲覧権限を限定する。

これはIETF案、CA/Browser Forum、または個別のCA/RAが定めた要件ではない。とりわけCA/Browser Forumのコード署名要件を、CSRアテステーション草案の採用証拠と取り違えてはならない。ここでのレシートは、Daniel Kadeによるガバナンス上の提案である。

情報源