要約

  • Authorization Domain Name（ADN）は、公開信頼TLS証明書を申請したFQDNについて、認証局が実際に管理権限を検証する名前である。申請名そのものとは限らない。
  • 旧定義には、左側ラベルを先に落とし、その後CNAMEをたどれるという危険な解釈があった。これでは別名の宛先を管理する事業者の権限が、顧客側のサブドメインまで広がったように扱われかねない。
  • SC101は検証方法を最初に選び、その方法がCNAME追跡やラベル削除を許すかを決め、両方を使う場合はCNAMEを先にする手順を明文化した。
  • ただし現行v2.2.9は2026年11月15日まで、現行節とv2.2.7の同じ節のどちらにも従えるとしている。移行期の発行証拠は規則版とADNに至る全経路を示さなければならない。

「現行版に準拠」では実行された規則を特定できない

TLS Baseline Requirements v2.2.9は2026年8月6日付である。改訂履歴にはSC101によるAuthorization Domain Nameの明確化が記され、関連日程表では11月15日が新しい導出要件の遵守日になっている。

重要なのは第3.2.2.4節の移行文である。11月15日より前は、CAは現行節に従っても、v2.2.7の第3.2.2.4節に従ってもよい。当日以降は現行節を使わなければならない。旧版利用は黙認でも執行猶予でもなく、新版の中に書き込まれた期限付きの正規経路だ。

そのため、9月に「v2.2.9準拠」とだけ記録しても、新手順の採用を証明したことにはならない。現行文書を引用しながら、その文書が許す旧節を使うこともできる。文書の識別子と、検証エンジンが選んだ分岐は別の情報である。

SC0101v2の投票記録では、参加した証明書発行者27組織が全て賛成し、証明書利用者側のApple、Google、Microsoft、Mozillaも全て賛成した。反対と棄権はなく、定足数17を満たしたとされる。6月12日から19日の討議、23日から30日の投票を経て、知的財産権のレビューは8月6日に終わった。

これは規範が成立した証拠である。各CAの検証コード、設定、試験、CP/CPS、全本番ノード、監査サンプルが同日に切り替わった証拠ではない。投票と実装は、それぞれ別の台帳を持つ。

CNAMEの宛先を管理しても顧客の名前空間は得られない

CAは証明書に含めるFQDNを受け取り、認められた方法で申請者の管理権限を確かめる。その証明対象となる名前がADNである。一部の方法では、DNSの別名をたどったり左端のラベルを削ったりして、申請名からADNを導出できる。

こうした柔軟性は、ホストごとに同じ証明を繰り返す負担を減らす。しかしDNSの技術的な到達先と、名前空間の管理権限を混同すれば、利便性が越権へ変わる。

SC101の説明によると、旧定義はADNの説明と導出命令を一つに詰め込み、操作を単独で使うのか、順番に使うのか、繰り返せるのかが曖昧だった。問題となる読み方では、申請FQDNの左側ラベルをまず削り、それから一つ以上のCNAMEをたどれる。

例えばexample.comがexample.orgを指すCNAMEであっても、example.orgの運用者がblog.example.comを管理することにはならない。ところがblogを先に落としてから別名を追えば、宛先側の管理証明が顧客サブドメインにも通用するように見える。投票文書はCDN事業者を、この構造が問題になる当事者の例として挙げる。

文書は特定のCDNやCAが実際に悪用したとは述べていない。誤発行の一覧も示していない。したがって、ここで扱えるのは規則の一解釈が作った潜在的な権限拡張であり、発生済みインシデントではない。

SC101は処理順を監査可能な形にした

新しい手順では、最初に検証方法を選ぶ。選択した方法によって、CNAMEをたどれるか、ラベルを削れるか、両方可能か、どちらも不可かが決まる。実名そのものではなく、アンダースコア付きの技術名で検証する方法に、別の方法と同じ権限を自動的に与えてはならない。

両操作が認められ、実際に両方使う場合は、CNAMEチェーンを先に処理し、その後で左側ラベルを削る。この順番なら、先行する削除によって別名先の権限が膨らむことを防げる。得られた名前がADNとなり、選択済みの方法はそのADNの管理を証明する。

実装者は全文と方法表に従う必要がある。本稿の要約は仕様書の代わりではない。ただし、ログに必要な中間状態は見える。入力FQDN、選択方法、許可された変換、観測したCNAMEチェーン、削除した各ラベル、最終ADN、使った証拠である。

規則の成立過程にも固定可能な記録がある。投票は特定のGitHub比較を示し、文書一覧は現行版と旧版を残している。6月18日の議事録からは、v2で別条項の発効日を加えた経緯も確認できる。これらは規範の由来を示すが、ある証明書発行時にどの分岐が実行されたかは示さない。

移行レシートには結果ではなく経路を残す

「検証成功」という一ビットの結果では、二つの規則が併存する期間を監査できない。少なくとも次の情報を一つの発行記録として結ぶ必要がある。

発行時刻 + 申請FQDN + 選択した検証方法 + BR版/節 + CNAME観測値とチェーン + 順序付きラベル削除 + 最終ADN + 検証証拠の識別子と時刻 + CP/CPS版 + 実装/設定版 + 試験または監査参照 + 例外

発行時刻は当時選択可能だった規則を確定する。申請FQDNとADNの組は権限境界の移動を示す。検証方法は許された変換を決める。BR版はv2.2.7経路かv2.2.9経路かを明示する。CNAME観測値は、後で変わり得るDNSをその時点で固定する。CP/CPSは宣言された手順を、実装と設定は実行可能だった手順を表す。

レシートは永続的な発行IDまたは証明書IDへ結び付ける。可能ならハッシュで後日の差し替えを検知できるようにする。チャレンジの秘密や運用上の機微を公開する必要はない。権限を持つ監査者が現在のDNSを見て過去を推測せずに済むことが目的だ。

これはDaniel Kadeが提案する分析上の統制であり、CA/Browser Forumが定めた隠れた必須項目ではない。Baseline Requirementsには既に記録、方針、監査の義務がある。本稿は、二つのアルゴリズムから選べる例外的期間には、その選択を識別できなければ既存の証拠も意味を失うと論じている。

CP/CPSは方針を語るが一件の処理を再生しない

CAはCertificate PolicyとCertification Practice Statementで公の実務を示す。RFC 3647はその一般的な構成枠組みである。改訂文書には、先行採用日、対象方法、ロールバックの扱いなどを書ける。

しかし文書はコードではない。最後の本番ノードより先に改訂される場合も、実装の後から公開される場合もある。段階配備なら同じ時点に複数状態が生じる。障害時の予備系や、期限前に開始して期限後に再試行したジョブもある。宣言、配備、個別発行の三記録を結ばなければ、「行う予定だったこと」が「実際に起きたこと」の代わりになってしまう。

共通要件とルートプログラムの執行を分ける

Baseline Requirements自身が、公開信頼TLSにとって必要だが十分ではなく、利用者側ソフトウェア供給者が採用・執行して初めてCAに強制されると説明している。Forumは共通の基準を作る。個々のルートプログラムは自製品の信頼を決める。

Mozilla Root Store Policyは共通要件を取り込みながら、Mozilla独自の優先・追加規則を保つ。Apple Root Program Policyも独自のプログラム層を公開している。ここでの引用は権限を区別するためで、両社のSC101対応を評価するためではない。

Forumの採決、CAのCP/CPS、検証エンジンの一回の実行、ルートプログラムの執行判断は同じものではない。EntrustとGoogleの権限を中心にした既存ドラフトは最後の層を扱う。本稿が扱うのは、その手前にある「この発行は二つの許可経路のどちらを通ったか」である。

公開情報で分かる範囲

公開資料からは、現行版、移行選択肢、締切が分かる。各CAの全配備状態までは分からない。実装発表がないことは未対応の証明ではない。一方、v2.2.9準拠という一般表明も、新手順を早期導入した証明ではない。

個別記録がなければ、結論は「適用版を確認できない」にとどめるべきだ。違反とも移行済みとも推定しない。

出典