要約

  • draft-ietf-acme-pop-00 は、証明書公開鍵を newOrder の popKey で宣言し、注文専用の pop 認可で所持を確認する任意の経路を定める。
  • 証明は解析後のJSONではなく、JWS payloadを復号した正確なバイト列のSHA-256に結び付く。
  • 鍵所持とDNS名などの識別子支配は別の認可であり、両方が有効にならなければ注文はreadyにならない。
  • ML-KEMではサーバーが生成したciphertextをクライアントがdecapsulateし、注文ハッシュのHMACを返す。サーバーも同じMACを作れるため、第三者検証可能な否認防止にはならない。
  • 第00版はStandards Trackを意図するInternet-Draftであり、RFC、実装報告、相互運用結果、導入実績ではない。

同じ「所持」でも証跡は同じではない

署名鍵の経路では、クライアントは固定のドメイン分離文字列、新しい32バイトの popNonce、注文ハッシュを連結したメッセージに署名する。公開鍵とtranscriptを持つ第三者は、その署名を後から検証できる。

KEM鍵は署名できない。そこでサーバーが popKey に対してML-KEM.Encapsを実行し、新しい challenge_ciphertext を提示する。秘密鍵を持つクライアントはdecapsulationで共有秘密を得て、HKDF-SHA-256で mac_key を導出し、注文ハッシュのHMACを返す。

正しい応答は、クライアントがdecapsulation能力を持つことをサーバーに示す。しかしサーバーはencapsulation側として同じ共有秘密とMACを知っている。後日その記録を第三者へ渡しても、「クライアントだけが作成できた応答」とは証明できない。

この差は失敗ではない。ACMEサーバーがその場の relying party である発行判断には適している。ただし、内部ログと独立証拠を同じ言葉で扱ってはならない。

証明は注文の正確なバイトに属する

草案は raw_newOrder を、JWS payloadをbase64url復号して得た、JSON解析前のバイト列と定義する。newOrder_hash はそのSHA-256である。サーバーがJSONを読み、別の並びや空白で再度serializeした値を使うことは禁止される。

この規則によって、証明の対象は曖昧な「同じ意味の注文」ではなく、実際に送られた注文になる。重複キーなどで一意の解釈ができないJSONは拒否する。識別子、popKey、profileその他の一バイトでも変われば、証明の文脈が変わる。

サーバーは受け入れた popKey、注文ハッシュ、専用の pop 認可、一つの pop-01 challengeを原子的に保存する。ML-KEM.Encapsで内部エラーが起きた場合は、部分的な注文や秘密状態を残してはならない。

空の識別子は空の権限ではない

クライアントは popKey と同時に、値が空文字列の pop 識別子を一つだけ送る。これは証明書に入る名前ではなく、鍵や鍵ハッシュも運ばない。所持確認を独立した認可として作るためのプロトコル上の印である。

DNS、メールなどの証明書識別子は、従来のACME challengeで別に検証される。秘密鍵を持つことはDNS支配を意味しない。DNS challengeに成功することも、注文で指定した秘密鍵を持つことを意味しない。

注文は両方をANDで組み合わせる。device attestation、RATS、certificate profileを追加しても、それぞれの命題は独立している。これは検査を増やすための複雑さではなく、一つの成功状態に複数の権限を洗い込まないための分離である。

アカウント鍵と証明書鍵も分離される

ACMEアカウント鍵はプロトコルメッセージを認証する。popKey は証明書に入る予定の鍵である。草案は両者を正規化したDER SPKIで比較し、同じ鍵なら拒否する。

この分離は運用権限を示す。アカウント鍵は注文を作り、challenge応答を送り、場合によっては証明書の失効やSTAR注文のキャンセルを行う。証明書鍵は実際のサービスで使う。保管場所、担当者、回復手段、ローテーション周期が同じである必要はない。

特にKEM証明書鍵は署名できないため、RFC 8555が認める証明書秘密鍵による失効要求を使えない。アカウント鍵を失えば、ACME内の失効経路が消える場合がある。短命証明書、事業者のアカウント回復、CAが別に運用するCRLやOCSPは代替策だが、自動的には存在しない。

STARでは停止権限が一か所に集まる

CSRを使わないSTAR注文では、最初の popKey が自動更新期間を通じて使われ、更新ごとに pop-01 をやり直さない。鍵を変えるには新しい注文が必要になる。

STAR証明書はSTARの仕組みで個別失効できず、アカウント鍵で注文をcancelすることが将来の発行を止める手段になる。KEM鍵自身は失効要求へ署名できない。そのためアカウント鍵が唯一のプロトコル内停止点になる。

鍵を失った後も更新が注文のend-dateまで続く可能性がある。自動化の効率を評価するときは、正常時の更新回数だけでなく、制御を失ったときの最大継続時間を測る必要がある。

{} に到達するまでに判断は終わっている

すべての認可が有効になると、finalize payloadは空のJSONオブジェクトになる。CAは受理済み popKey と暗号学的に同等な公開鍵を証明書へ入れ、認可された識別子を使う。subject、validity、Key Usageやその他の拡張はCAポリシーまたは選択されたprofileが決める。

その後のinstallation、秘密鍵との対応、全レプリカへの反映、relying clientの受理は別の現実である。challenge成功は完了時点の所持を示すだけで、継続的なcustodyやサービス成功を証明しない。

第00版は2026年9月1日に公開され、2027年3月5日に失効予定である。特定のCAやクライアントの対応、実際の発行、相互運用、事故、普及率は確認も主張もしていない。