要約

  • SC100は、参加した証明書発行者22社と証明書利用者3社が全て賛成し、反対・棄権なしで投票要件を満たした。ただし2026年8月31日時点ではIPR審査が続いており、終了予定は9月5日19時UTCである。
  • 草案は既存のDNSSEC要件を集約する。該当するドメイン制御検証とCAA問い合わせではプライマリ・ネットワーク・パースペクティブがDNSSECを実行しなければならない。リモート・パースペクティブでの実行は任意である。
  • MPICはDNSSECの複製ではない。複数の遠隔観測がプライマリの判断を発行前に裏付ける仕組みであり、暗号検証の有無は各パースペクティブについて別に記録すべきである。
  • 草案は完全なDNS検索情報を特定のログ・自己監査範囲から除外しつつ、遵守を検証できる十分な情報の保持を求める。最小証拠は、時間範囲を持つリゾルバー制御レシートと、プライマリを名指す発行レシートの結合である。

全会一致でも、まだ現行規則ではない

SC100の公式ページには、22の発行者による賛成票と、Apple、Cisco Systems、Mozillaによる三つの利用者側賛成票が記録されている。反対と棄権はゼロで、定足数15も満たした。

しかし投票と最終化は同じ出来事ではない。同ページのIPRレビューは8月6日19時UTCに始まり、9月5日19時UTCまで続く。この間、メンバーは実施に不可欠な特許請求を除外する通知を提出できる。8月13日の議事録も、SC100がIPRレビューに入ったと記すにとどまる。

文書番号だけを見ると誤認しやすい。SC100の変更受入れ版は2.2.9、日付は8月6日である。現在のTLS Baseline Requirementsも2.2.9で同日付だ。だが現行版の改訂履歴はSC101で終わり、SC100は載っていない。文書一覧が示す公開版と、表紙にDRAFTとある審査添付文書は、番号が同じでも権威状態が異なる。

したがって「2.2.9に準拠」という記録だけでは足りない。現行Final Guidelineなのか、SC100 Draft Maintenance Guidelineなのか、将来の組込み版なのかを、状態、URL、ハッシュで特定する必要がある。

さらに投票文は、SC100に発効日を置かない理由を、既存要件の変更ではなく明確化と集約だと説明する。本稿は新義務の施行を告げるものではない。既にある義務を、役割に結びつけて証明する方法を問う。

DNSSECのMUSTには実行者がいる

基礎となるSC085v2は、2026年3月15日から、プライマリ視点による該当のドメイン制御検証とCAA検索でDNSSEC検証を要求した。現行2.2.9にも要件は存在するが、複数箇所に分かれている。

SC100草案は、これを提案§4.2.2.2にまとめる。プライマリ視点が用いるリゾルバーは、RFC 4035 §5の検証を行い、NSEC3とSHA-2を扱い、RFC 6840 §4の安全上の論点を適切に処理しなければならない。

適用範囲も役割ごとに読める。プライマリ視点は、ドメイン認可・制御とCAA処理に関連するDNS問い合わせ全体でDNSSECを実行する。残るメール方式には部分例外があり、Authorization Domain Nameを得るCNAME、CAA、TXTは必須、その他はSHOULDとなる。それ以外の方式とCAAでは、ローカルポリシーで検証を無効化できない。プライマリで観測したSERVFAIL等のDNSSECエラーを、例外の境界を超えて発行許可として扱えない。

リモート視点ではMAYである。IANAルート信頼アンカーまで検証してもよいが、全リモートへの義務ではない。任意であることは欠陥の認定ではなく、実行したことも全体の遵守証明ではない。

ここで必要なのは状態だけでなく、状態を生成した役割だ。Secureという値があっても、それがプライマリ、リモート、試験環境のどこから来たか不明なら、規範上のMUSTを履行した証拠にならない。

MPIC定足数とDNSSEC実行数を混ぜない

SC067v3が導入したMPICは、同一長プレフィックスのBGP攻撃がドメイン検証を欺くのを難しくするため、リモート視点からプライマリ判断を裏付ける。

DNSSECは別の軸である。リゾルバーが署名データや認証された不存在を暗号学的に検証できるかを扱う。RFC 4035のSecure、Insecure、Bogus、Indeterminateは検証状態であって、観測地点の独立性、MPIC参加、最終発行判断を示さない。

SC100草案内の段階表では、2026年6月15日から少なくとも四つのリモート視点、所定の定足数、二つ以上のRIRサービス地域の裏付けが必要である。12月15日から最低数は五つになる。これはリモート観測の数であり、DNSSECを義務づけられたリゾルバーの数ではない。

したがって各行に二つの評価が要る。一つはMPICの「裏付けた／裏付けなかった」。もう一つはDNSSECを「実行した／許容された範囲で実行しなかった」、実行した場合のRFC状態である。未実行をInsecureと書けば、プロトコル上の意味を偽る。プライマリ結果をリモート行へコピーすれば、独立観測を偽る。

十分な情報は、完全なデバッグログではない

SC096は、DNSSEC検証を広範なDCV/CAAログから外した。リゾルバーは詳細ログを前提に作られておらず、変更管理ログで制御の有効化を確認できる、という説明だった。

SC100の§4.2.2.2.7案は、DNSSECに関するDNS検索情報の全量を§8.7自己監査と§5.4.1ログの範囲外に置く。一方で、その除外にかかわらず、同節の遵守を検証できる十分な情報をCAが保持しなければならないとする。

7月16日の議事録によれば、残った争点は特定のログ方式を規定するかだった。結論は方式を固定せず、十分な証拠を求めるものとなった。修正後に議論期間を再開し、7月30日の議事録では追加意見がないことを確認して投票へ進んだ。

これは「何も残さなくてよい」という意味でも、「全パケットを保存せよ」という意味でもない。異なるCAの構成を尊重しながら、検証可能な最小接続を設計する責任を実装者に残したのである。

制御レシートと発行レシート

最初の制御レシートは、ある期間のプライマリ視点がどのリゾルバー制御を持っていたかを示す。

制御ID + プライマリ視点ID + リゾルバー/サービスID + ソフトウェア/ビルド + 構成・ポリシーハッシュ + 信頼アンカー版 + RFC 4035/NSEC3/SHA-2/RFC 6840能力 + ローカル例外状態 + 試験ID + 変更承認 + 有効期間

秘密の設定全体を公開する必要はない。保護された保管場所への参照とハッシュで、監査可能性と最小開示を両立できる。ただし、これは能力の証明であって、一回の要求が実際にその制御を通った証明ではない。

次の発行レシートが実行を結ぶ。

試行ID + 証明書/事前証明書 + 要求・判断時刻 + 対象名と範囲 + 検証方式 + CAA範囲 + 規則/草案版 + プライマリ視点ID + 制御レシートID + 問い合わせ種別 + DNSSEC状態 + エラー処理 + リモート視点ID + 各リモートのDNSSEC実行有無と状態 + RIR地域 + MPIC観測・定足数 + 再試行系列 + 不変ハッシュ

この二枚はDaniel Kadeの分析提案であり、SC100が列挙した必須形式ではない。DigiCert、支持者、投票者、ブラウザー、監査人、RFCの提案として扱ってはならない。目的は「十分」を試験可能にしつつ、完全検索ログの除外を尊重することにある。

公開情報からは実装を断定できない

CP/CPSは実務方針を宣言する。構成試験は特定条件の挙動を示す。DNSSEC状態は一つの観測を分類する。証明書は発行を示す。MPIC記録は定足数を示す。これらが自動的に一つのチェーンになるわけではない。プライマリ視点のID、制御の有効時間、試行、判断、証明書を結んで初めて再現できる。

全会一致投票は各社の本番展開を証明しない。内部構成を公開していないCAを違反と推定することもできない。本稿は誤発行、DNS汚染、ログ隠し、特定企業の失敗を主張しない。9月5日のIPR結果、最終文言、正式版、各実装の証拠はまだ観測対象である。

情報源