要約

  • 認識された accounturi は要求アカウントを、validationmethods は利用できる検証方式を、そのパラメータを含む issue または issuewild プロパティの中で制限する。
  • パラメータ対応は CA ごとに任意だが、一つの CA 識別ドメインを使う発行システム群は、対応するパラメータを一貫して認識しなければならない。
  • CAA は現在の発行認可であり、既存証明書の検証や失効ではない。移行中の許容期間に発行された証明書は、DNS を締めた後も残り得る。

移行計画には、しばしば二つの善意が衝突する。セキュリティ担当は新しいアカウントと検証方式だけを許したい。更新担当は、切替に失敗しても証明書を失わないよう旧経路を残したい。両者を同じ CA 名の下に置くだけでは両立にならない。どの入口でも同じ制約が同じ判断を生むことを示す必要がある。

基礎となる RFC 8659 で、CAA は CA に対する発行時の認可を表す。ブラウザーが既発行証明書を受け入れるかを決める仕組みではない。問い合わせは CAA 検索中の別名をたどり、最初の空でない RRset まで名前を上がり、要求された全ての名前を調べる。後から記録を変更しても、既発行証明書が自動的に失効するわけではない。

RFC 8657 の accounturi は、含まれる issue または issuewild を指定アカウントに絞る。CA 識別ドメインとの一致は別に必要である。パラメータがなければ、そのプロパティでは任意のアカウントが候補になる。複数指定、無効な URI、CA が認識しない URI は、そのプロパティを認可に使えなくする。

この URI は公開識別子であり、秘密の資格情報ではない。ACME 対応実装は ACME アカウントオブジェクトの URI を認識し、非 ACME 系は別の URI を割り当て得る。URI を知ることと、アカウント鍵を制御することは同じではない。

validationmethods は、カンマ区切りの方式から実際に使えるものを限定する。空の一覧は方式を一つも許さない。ACME 方式には登録済みラベルがあるが、非 ACME の方式は CA 固有名を必要とし得る。したがって、DNS に正しい文字列があるだけでは効力を証明できない。

パラメータ認識は任意であり、CA ごとに異なる。ドメイン保有者は明示的な対応表明を確認すべきだ。Let's Encrypt は letsencrypt.org、アカウント URI の形式、http-01、dns-01、tls-alpn-01 への対応を公開している。この文書は有用な境界情報だが、各バックエンドの独立監査でも、他 CA の対応証明でもない。

同じ識別ドメインを共有した後は任意ではない部分がある。RFC 8657 は、そのドメインを使う全発行システムが同じパラメータを一貫して認識するよう求める。ACME と非 ACME の併存、企業統合で合流したシステムも想定されている。整合できなければ、異なる CA 識別ドメインを使える。共通ドメインで対応を掲げながら、旧経路だけ別の意味を残すことはできない。

統合はアカウント URI の衝突も生む。一つの CA が認識する全識別ドメインを通じて URI は曖昧であってはならない。二つの旧系が同じローカル番号を持つなら、権威部分を含む URI が出所を保つ助けになる。無関係の CA に共通アカウント基盤を求める規定ではない。

DNS 側にも迂回路がある。CAA の認可は加算的なので、厳しいプロパティは、同じ CA を無条件で許す別の適用可能なプロパティを打ち消さない。ワイルドカードでは issuewild が存在すると issue は使われず、通常名では issue が使われる。片方だけの更新試験では不十分である。

critical フラグも万能な強制ではない。未知または未対応のプロパティタグに関する規則であり、issue 内の未知パラメータを理解させるものではない。タグの認識とパラメータの認識を分けなければならない。

時間差も移行設計に入る。ドメイン認可と証明書発行は同時とは限らない。短い認可期間や発行時に近い CAA 再確認は露出を減らす案だが、RFC の約一時間という例は普遍的期限ではない。緊急時に一時的な広い認可を置けば、その間の証明書は閉鎖後も有効であり得る。

だから「新経路で更新できた」は半分の結果にすぎない。関連 RRset、DNSSEC 検証、別名と委任、適用プロパティ、CA 識別子、アカウント URI、方式、発行入口、判断時刻、発行証明書を一つの記録に結ぶ必要がある。

出典

  1. RFC 8657 — Account URI と ACME 方式を結ぶ CAA 拡張
  2. RFC 8659 — DNS Certification Authority Authorization リソースレコード
  3. Let's Encrypt — CAA ドキュメント
  4. Heng Lu — インターネットガバナンス中核のエージェンシー問題
  5. Heng Lu — BTW Media が存在する理由と、提言でなく現実を製品とする理由