要約

  • IESGは2026年9月2日、draft-ietf-lamps-csr-attestation第29版の最終意見募集を開始し、締切を9月16日とした。目標はProposed Standardだが、現時点では承認済みRFCでも導入実績でもない。
  • PKCS #10またはCRMFの申請に複数の証明を同梱できても、CSRの鍵、HSM、所有情報、端末状態、鮮度が同じ申請取引を指すことを確認する責任はCA/RAに残る。

草案が示す例は、実装の盲点をよく表している。鍵がHSM内で生成されたという記録、プラットフォームが会社所有であるという記録、プラットフォームが既知の良好状態にあるという記録。この三つは単独では正しくてもよい。しかし、CSRの秘密鍵を保持するHSMが、その会社所有かつ測定済みのプラットフォーム上にあるとは、まだ証明されていない。

第29版が標準化しようとする器は小さい。AttestationStatementは型を示すOIDと声明本体を持つ。AttestationBundleは一つ以上の声明と、任意の証明書を持てる。申請はid-aa-attestationを用い、PKCS #10属性またはCRMF拡張として一つのトップレベルbundleを運ぶ。

これは証拠を配送する仕組みであって、関係を自動生成する仕組みではない。任意の証明書は検証パスの構築に使えるが、bundle内にあるだけで順序、正しい信頼アンカー、適用すべき発行方針まで決まるわけではない。パース成功、パス検証、発行許可は別の判断だ。

さらに草案は個々の証明形式を定義せず、新たな形式レジストリも設けない。OIDと形式は別の標準やベンダー仕様に依存する。したがってOIDは振り分け情報であって、真実性の印ではない。デコード、署名検証、署名者への信頼、CSR公開鍵との同一性、発行の正当化は、それぞれ独立して確認されなければならない。

同じOIDを複数のVerifierが受け付ける場合、振り分けにも曖昧さが生じる。草案は別OIDの利用や、形式側で明確に定義したラッパーのヒントを示す。ヒントが認証対象外なら、設定ミスや攻撃によって、同じ証拠がより緩いVerifierへ送られる恐れがある。

結合の起点はCSR公開鍵である。proof of possessionは、申請プロトコル上で対応する秘密鍵を制御していることを示す。しかし、鍵の生成場所、エクスポート可否、装置の所有者、装置の健全性、証明書を受け取る権利までは示さない。

HSMの声明が有効でも、そのHSMとプラットフォームを結ぶ安定した識別子が必要だ。所有記録は同じプラットフォームを対象とし、有効期間が測定時点を覆わなければならない。状態測定も同じ対象と測定エポックに結び付かなければならない。名前が似ている、同じメーカーである、同じ申請者が提出した、という事情は代替にならない。

鮮度は時間の幅を狭めるが、対象の同一性を作らない。付随する鮮度草案では、CMPは取引コンテキスト、ESTは同じTLSセッションまたは保持したHTTP状態を用いて、nonce交換とCSRを対応付ける。CA/RAが対応を確認できないなら、両者を関連ありとして扱ってはならない。

鮮度を要求するnonceは8から64オクテットで、長さゼロは鮮度を要求しない意味になる。主Attesterが同じnonceを下位のAttesterへ渡し、複数のEvidenceに共通の挑戦を使うこともできる。それでも、すべてが同じ鍵や端末について答えたことにはならない。

RFC 9334も、鮮度を状態の永続保証とはしていない。Evidence生成後に装置の設定、所有、ソフトウェア、攻撃状態は変わり得る。測定はある時点の事実であり、長期間使われる証明書とは時間軸が異なる。

最終判断がCA/RAに残る理由はここにある。CA/RAは、受け入れる形式、信頼アンカー、参照値、評価規則、発行プロファイルを選ぶ。複数方針の一つに照らして証拠を評価することも、該当方針に不要なら捨てることもできる。草案は要件をcertification practice statementに記載するよう勧める。

監査記録には方針の版も必要だ。CSRのハッシュと公開鍵、声明の原文、署名者、Verifierの版、参照値、nonceと取引コンテキスト、所有記録、評価結果、採用した方針、発行を許可した主体を保存して初めて、後から判断を再構成できる。

一方、これらを公開証明書に詰め込むべきではない。ハードウェア識別子、ファームウェア、パッチ、所有情報は運用や供給網の機微を漏らす。草案は証明情報を発行証明書へ複写することを推奨していない。ただし申請ログや保存bundle、Verifier記録のリスクまで消えるわけではない。

Heng Luの現実階層で見れば、草案公開、構文解析、署名検証、評価合格、発行、配備、依存当事者による受容は別々の現実である。見栄えのよい成功記録を足し合わせても、欠けた関係は生まれない。共有仕様は器と最低限の結合規則を与えられるが、運用上の真実は、責任を負うCA/RAが実行記録で示すほかない。

出典