要約

  • 第02版は、CAが現在の鍵だけでなく、ACMEアカウントが過去に使ったすべての公開鍵のSHA-256 JWK指紋と永続レコードを照合できるようにする。
  • 鍵のローテーションは旧秘密鍵による新規要求の認証を止めるが、その指紋で得たDNS認可までは自動的に失効させない。TXT削除、キャッシュ、persistUntil、認可期限は別の時計で動く。
  • 草案が示す即時の全アカウント停止策はアカウント無効化である。運用側は、一致した鍵世代、DNS観測、CAA、アカウント状態、再利用期限を一つの証跡に残す必要がある。

鍵管理画面には「ローテーション済み」、DNS画面には「レコードなし」と表示される。それでも、証明書発行の判断が止まったとは限らない。CAが削除前に有効なTXTを確認していれば、その検証結果はACME認可が切れるまで再利用できるからだ。

2026年9月20日付の第02版 ACME DNS Persistent Challenge は、この時間差を仕様として扱う。Datatrackerの履歴では、現在もI-D Existsの作業部会Internet-Draftである。本文の表記はStandards Trackだが、intended status、shepherd、Area Director、IESG段階はいずれも未設定だ。RFCでもLast Callでもなく、特定CAの導入証拠でもない。

提案は _validation-persist 配下に dns-persist-01 のTXT値を置く。そこには43文字のパディングなしbase64url SHA-256 JWK指紋と、ドメイン名・指紋・ACMEアカウントURLを束ねるハッシュが入る。指紋は RFC 7638、ハッシュ表現は RFC 6920 に基づく。

CAはまず現行鍵で値を計算し、一致しなければアカウントに保存された公開鍵履歴を新しい順にたどる。第01版との差分で加わった重要な要件は、対応サーバーがアカウントの存続期間中、使われた全公開鍵のSHA-256 JWK指紋を保持することだ。作業部会リポジトリは編集過程を示すが、採用や実装を保証しない。

目的は ACME の鍵更新と永続委任を両立させることにある。現在鍵だけを認めれば、通常のセキュリティ保守のたびにDNS担当者がレコードを作り直すことになる。保存されるのは公開指紋であり秘密鍵ではない。旧指紋は由来を識別できても、新しい注文に署名はできない。

しかし、この連続性には残存権限が伴う。K1の時点で得た検証は、K2へ移行しても有効な同一アカウントに属する。再検索が必要な場合でも、履歴にK1が残るため古いTXTが一致し得る。署名者の交代とDNS上の許可撤回は同義ではない。

TXTを消しても即時ではない。再帰リゾルバーはTTL満了まで古い応答を返せる。草案はDNS TTLと検証データ再利用期間を区別する。前者はキャッシュ、後者はCAの判断を制御する。persistUntilは認可上限を設けられるが、後から値を短くしたりレコードを削除したりしても、取得済み検証の期限を遡って短縮しない。

管理すべき時計は四つある。現在要求を認証できるアカウント鍵、権威DNSとキャッシュ、CAが検証済み支配を再利用できる認可期限、観測時点で記録されたpersistUntilである。一つの画面でこれらを「失効」にまとめると、実際の停止時刻を誤る。

即時に広く効くのはACMEアカウントの無効化だ。CAは永続検証を受け入れる前にアカウントがvalidであることを確認しなければならず、無効化は過去の公開鍵履歴より優先する。ただし一つのドメインではなくアカウント全体を止める。インシデント計画にはTXT削除とアカウント停止の両方が必要だ。

通常、ハッシュにはドメインが入る。domain_name=*を使えば、同じアカウントと鍵について複数ドメインで再利用できる。運用は軽くなる一方、ドメイン間の相関と被害範囲が広がる。ワイルドカードを含め、発行時に受け入れた識別子の正確な範囲を保存すべき理由である。

CAAは別の検査だ。RFC 8657のaccounturiは実際のアカウントURLを使うが、永続TXTではURLがハッシュに含まれる。TXT一致は CAA を代替せず、CAA許可も永続証拠を立証しない。

DNSSECも役割は限定される。利用可能なら検証し、試みて失敗すればチャレンジを失敗させるべきだと草案は述べる。RFC 4033が示す出所認証と完全性は重要だが、キャッシュ値が今も組織の意思か、アカウントを生かすべきかは決めない。

事前設定を別担当者に委ねることもできる。認証済みPOST-as-GETでアカウントがvalidと確認された後、公開アカウントURLと指紋だけを渡してTXTを作成できる。秘密鍵は不要だ。DNS運用者とACME管理者を分離できる分、誰が要求・承認・設置したかの記録が重要になる。

現時点の IANA ACMEレジストリ に dns-persist-01 はない。CA/Browser Forumの SC-088v3 はアカウント単位の永続TXT方式への業界関心を示す。ただし投票結果は、このIETF草案の導入や両制度の同一性を証明しない。

必要なのは認可の生涯を追えるレシートだ。FQDNと識別子範囲、レコードダイジェストと観測時刻、権威・再帰双方の証拠、TTLとキャッシュ期限、発行者、domain_name=*の有無、保護されたアカウント識別子、一致した現行または過去の鍵世代、アカウント状態、CAAとDNSSEC、persistUntil、認可期限、その結果を使った注文・発行時刻を結び付ける。

そうすれば、鍵更新後も履歴照合が許されたのか、権威側削除後にキャッシュが残ったのか、新規検証なしに旧認可が再利用されたのか、無効化が発行前に効いたのかを区別できる。今日のDNSだけで昨日の判断を説明する必要はなくなる。

草案は今後変わり得る。それでも統治上の結論は変わらない。永続認可は権限を一回のオンライン証明から管理された履歴へ移す。ローテーションは保守であり、撤回には今も生きている認可を狙う操作が要る。

出典