要約

  • IESG は 2026 年 7 月 30 日、draft-ietf-acme-device-attest を Proposed Standard として承認した。第 10 版は RFC Editor の処理中であり、最終 RFC 番号や実装状況はまだ前提にできない。
  • device-attest-01 は Order の識別子、アテステーション内の公開鍵、CSR の公開鍵を結べる。ただし強度は形式、証明主体、token のみかアカウントに結ばれた key authorization かで変わる。
  • この証拠は一回の発行を認可する。端末の健康状態を更新し続けるわけではなく、プライバシーを重視した証明書はハードウェア識別子を含まないこともある。

「証明済み」の内訳

有効な証明書を見た運用者は、その端末も現在安全だと考えやすい。だが証明書チェーンが直接語るのは、発行者がある公開鍵と名前を一定期間結び付けたことだ。どの challenge が終わり、どの装置が鍵を作り、どの姿勢情報が検査されたかは別の記録になる。

承認済み拡張は permanent-identifier、hardware-module、device-attest-01 を ACME に加える。前者は一般に製造者が与えた端末識別子、次は暗号モジュールの種類とシリアル番号である。IANA の表にはすでに RFC-to-be の参照付きで掲載されている。これは名前空間の事実であって、製品導入の証拠ではない。

サーバーは新しい token を出す。通常、クライアントは token と ACME アカウント鍵のサムプリントから key authorization を作り、形式固有のアテステーションで覆う。サーバーは値、装置識別子、信頼チェーンを検証する。

発行には三つの一致が要る。証明主体がサーバー方針で信頼され、アテステーションの公開鍵が CSR の公開鍵と一致し、アテステーションの装置識別子が Order と一致することだ。識別子を CSR と証明書にも載せるなら、バイト単位で同じでなければならない。

一方、外部証明主体が ACME アカウント鍵の利用前に署名する形式もある。この場合は token だけを覆う。新鮮さは得られるが、アカウント鍵への結合は得られない。両者を同じ attested フラグへ畳むべきではない。

提示された challenge と完了した challenge

混在する端末群の移行のため、同じ authorization に device-attest-01 と別の challenge を並べられる。いずれか一つの完了で authorization が満たされる。従って「サーバーがアテステーションを提示した」は「この Order がアテステーションを通った」と同義ではない。

External Account Binding は企業 CA が受け付けるアカウントを制限する仕組みで、これも別の境界にある。アカウントの事前許可は、CSR の鍵が申告されたハードウェアにあることを証明しない。端末証明も、後日のアカウント権限を固定しない。

下流サービスが証明済み発行に特別な権限を与えるなら、完了した challenge、形式、証明主体、結合方式を示す認証済み受領証が必要になる。

物理 ID を証明書から外す理由

第 10 版は、この二種類の識別子を CSR から省けるよう RFC 8555 の条件を更新する。プライバシー重視のサーバーは、識別子を含む CSR を拒否することさえできる。CA は物理装置の証拠を内部の発行判断に使い、証明書には論理的なワークロード ID だけを載せられる。

永続的なシリアル番号を証明書へ入れると、更新や複数サービスへの提示を長期にわたり関連付けられる。Certificate Transparency や外部の相手に渡れば、開示は事実上取り消せない。端末交換までサービス ID の変更にしてしまう危険もある。

逆に、識別子を載せなかった証明書から、relying party がアテステーションを推測してはいけない。形式、主体、検査したファームウェア、実際に使った challenge は、明示的な発行受領証なしには分からない。

姿勢情報には観測時刻がある

ペイロードはファームウェア、起動状態、OS、保護レベルを含みうる。CA はそれを理由に拒否できるが、草案は全形式共通の検証手続きを定義しない。TPM、TEE、OS 保護型キーストアの保証は同じではない。

十分に検証した属性でも、challenge 実行時点の観測である。証明書が有効な間に、設定、保管者、アカウント方針、trust store は変わりうる。失効は一部を扱えるが、証明書を継続的リモートアテステーションへ変えるものではない。

Heng Lu の現実レイヤーで整理すれば、IESG 承認、IANA 登録、challenge 成功、証明書発行、現在姿勢、アクセス判断は別の受領証になる。それぞれを狭く読む方が、運用に使える。

資料