要約

  • ACME作業部会は2026年9月21日、draft-ietf-acme-profiles-02をIESGへ提出した。現在の「Publication Requested」は審査の入口であり、IESG承認やRFC発行ではない。
  • newOrder.profileは注文の制御を明示する一方、非公開profile、アカウント資格、途中の提供停止を認めている。名称は選択子であって発行済み証明書の受領書ではない。

同じprofile名について、三つの正当な状態があり得る。現在のDirectoryに掲載されている。掲載されていないが、事前の私的合意に基づいてサーバーが受け付ける。注文作成時には受理されたものの、finalize時点でCAが発行を続けられず、invalidProfileが返る。

この幅は仕様の欠陥ではない。証明書の機能選択をCSRの暗黙的な表現から注文の明示的な制御へ移しながら、CA固有の政策と時間変化を残す設計である。運用上の誤りは、その名前を政策全体の代用物にしてしまうことから始まる。

文書の現在地を正確に読む

Datatrackerでは9月21日、作業部会の状態がWorking Group Last Callから「Submitted to IESG for Publication」に変わった。IESG側は「Publication Requested」、想定ステータスはProposed Standard、担当Area DirectorはDeb Cooleyで、telechatの日付はない。Mike Ounsworthが作業部会を代表して発行を要請した。

これは重要な手続き上の前進だが、承認ではない。第02版はまだInternet-Draftである。shepherd write-upは、提案が単純と見なされ強い賛同の返信が少なかったため、合意をweak consensusと表現している。争いや上訴は報告されていない。実装一覧とLet’s Encryptでの配備は実装経験を示すが、業界全体への普及率を示さない。

profileが変える場所

RFC 8555のACMEでは、注文を作成した後にfinalizeへCSRを送る。新しい草案はDirectory metadataに任意のprofilesオブジェクトを追加する。キーはそのサーバーで一意の短い識別子、値は人が読む説明へのURLで、data URLも利用できる。

クライアントはnewOrderにprofile文字列を入れられる。サーバーが受理すれば、返されたOrderにも名称が記録される。機能選択がCSRより前に確定し、CSRは公開鍵とsubjectAltNameを担う。草案は、CAの政策処理でASN.1の解析やコピーを減らせる可能性を挙げる。

ただし、アカウント管理と識別子検証は変わらない。名称の世界共通レジストリも作られない。意味の範囲はDirectoryのURL、取得時刻、説明内容、アカウント文脈で決まる。

広告、資格、受理、発行を分ける

profileが注文と両立しない場合、サーバーはinvalidProfileを返さなければならない。草案は、TLSサーバー認証用profileでメール識別子を申請する場合や、アカウントがallowlistの対象外である場合を例示する。Directoryに名前があることは、すべてのアカウントへの利用許可ではない。

逆に、名前がないことが絶対的な禁止を意味するわけでもない。クライアントは非掲載名を要求すべきではなく、サーバーも通常は拒否すべきだが、草案は例外的な受理を認める。例は、帯域外で合意した私的profileと、大量失効後の旧証明書置換である。

要求で省略した場合も、profile選択がなかったとは限らない。対応サーバーには自ら選んで注文へ関連付けることが推奨される。要求だけでなくOrder応答を保存する理由がここにある。

さらに、注文受理は発行完了ではない。CAがfinalizeまでにそのprofileで発行する意思を失った場合、invalidProfileを返す必要がある。草案は既存注文の期限切れを待ってから停止するよう推奨するが、政策変更を完全には排除しない。

一事業者の名称も時間で変わる

Let’s Encryptは、現時点の正規リストとして各環境のDirectoryを確認するよう求め、profileによっては環境差やallowlist制限があると説明する。classic、tlsserver、shortlivedでは、認証再利用期間、注文寿命、証明書寿命、識別子、証明書フィールドが異なる。

tlsclientは2026年7月8日以降利用できない。tlsserverは5月13日に45日証明書へ移行し、classicにも将来の短期化計画がある。これはLet’s Encryptの運用が変化する証拠であり、他のCAが同名・同義である証拠ではない。

段階ごとの証拠を残す

最初にDirectoryの生データ、URL、取得時刻を保存する。次に説明URLと読んだ内容のハッシュを残す。その後、CA endpoint、アカウント、識別子、要求名、資格判断、profileを反映したOrder応答を一つの取引として結ぶ。

finalizeではCSRの指紋、応答状態、ACME problem typeを別に記録する。発行されたなら証明書の指紋と解析属性を保存する。配備まで証明する必要がある場合は、観測時刻と場所を含む実サービス上の証明書をさらに記録する。

Directoryは権利ではなく、Orderは証明書ではなく、証明書は配備の証拠ではない。この区別が、短い名前を有用な関連キーに保ち、永続的な保証へ誤変換することを防ぐ。

出典

  1. Datatrackerの現行状態
  2. 文書履歴
  3. draft-ietf-acme-profiles-02
  4. ACMEリストへの発行要請
  5. Document shepherd write-up
  6. RFC 8555
  7. Let’s Encryptのprofile文書
  8. ACME Profilesの告知
  9. 証明書寿命の計画
  10. ACME作業部会のLast Call告知
  11. Working Group Last Callの終了
  12. Boulder実装トラッカー
  13. IETF 126 ACME議事録