要約

  • IETFは10月27日付のdns-account-01草案を、11月10日までの最終意見募集に入れた。
  • 提案はACMEアカウントごとにDNS検証名を分け、同一ドメインを扱う複数の拠点が並行して証明書を取得できるようにする。

クラウドを移す日は、旧拠点にも新拠点にも「もう少し動いていて」と頼むことになる。両方が同じドメインの証明書を更新したい。ところが現行のACME規格RFC 8555で使うdns-01の検証先は、そろって_acme-challengeだ。各拠点が別々の検証サービスへCNAMEで委任しようとすると、一つの名前に二本のCNAMEは置けない。移行計画の立派な二本立てが、DNSの玄関先で一列になる。

ACME作業部会の草案は、アカウントごとに玄関の住所を増やす。ACMEアカウントのURLから短いラベルを作り、_acme-challengeの前に置く。認証局は署名された要求にあるアカウント識別子からその住所を再計算し、当該TXTレコードに今回のチャレンジに対応する値があるか調べる。旧拠点と新拠点は相手のDNS設定を上書きせずに動ける。

住所の作り方は細かい。アカウントURL全体をSHA-256でハッシュし、先頭10バイトをBase32にする。住所はアカウントの鍵ではなくURLに結び付くため、通常の鍵更新では変わらない。一方、TXTに置く応答は新しいトークンとアカウント鍵に依存する。長く使う案内板と、その都度書き換える返答を分けた設計だ。

便利さの裏で、ドメイン管理者の台帳が忙しくなる。複数の地域、CDN、移行先それぞれに検証の入口を認めたなら、その入口を誰が承認し、どのアカウントが使い、いつ閉じるのかを追わなければならない。旧事業者の契約書に「終了」と書いても、DNSに残った委任は契約書を読まない。

草案はアカウントURLの変更にも注意を促す。認証局側でホスト名やパスなどを変えると、事前にDNSへ用意したラベルと食い違う。サーバーには識別子の維持を勧め、移行が必要なら過去のURLも受け付けるよう求める。完了したチャレンジのTXTをクライアントが片付けることも勧めている。

Datatrackerの記録によると、版数は-04、意見募集の期限は11月10日。採用されればIANAのACME検証方法一覧に加える提案だ。呼び鈴を増やす設計は、いま公開の審査台にある。