要約

  • Mozillaの現行方針は、ルートストアの維持、期間を対象とする監査、そして個別証明書に加入者情報を入れる前の検証実務を別のものとして扱う。
  • 方針文書や期間監査は、特定の申請、検証観測、発行、後日の失効状態、あるいは一つのクライアント結果を遡及的に証明しない。

2026年7月1日に有効となったMozilla Root Store Policy 3.1は、いくつもの正しい命題を並べながら、同義語にはしていない。Mozillaは用途別の信頼ビットを伴うCA証明書を配布する。適用範囲のルートと、実際にサーバーまたはメール証明書を発行できる中間CAについて、組込み前とその後少なくとも年一回の特定監査を求める。同時に、加入者が提出した情報は証明書に含める前に独立した情報源又は別の通信経路で確認されなければならず、TLS用証明書については、CAが文書化された方法でドメイン名の使用権限とIPアドレスの管理を確認しなければならない。

どの文も重要である。しかし、一つが次の文の証拠へ自動的に変わるわけではない。

監査が扱うのは保証の境界である。対象システム、基準、期間、方法、試験した証拠、所見、制約がある。方針は期間監査情報を少なくとも毎年更新することを求める。2027年7月1日以降に始まる年次監査期間には、ウェブサイト信頼ビットを持つ所定のCAにDetailed Controls Reportも求める。この報告の目的はシステム境界、統制、実装、試験、運用有効性を監督に役立てることだ。これは有用な統治証拠であるが、全ての申請の台帳でも、一件の発行時点を復元する資料でもない。

証明書そのものを見ると違いは明らかになる。シリアル番号、発行者、有効期間、SANはオブジェクトを記述する。どの申請が届いたか、その時どの手順版が適用されたか、誰又はどの自動統制が権限を持ったか、独立した情報源で何を観測したか、その観測が許容時間内だったか、なぜ鍵と名前を結び付けたかは示さない。監査人の意見は、存在するというだけでこれらの欠けた結合を作らない。

逆方向の置換も危険である。発行記録はオブジェクトが作られたことを示せても、統制環境全体が監査期間を通じて機能したこと、全運用場所が範囲にあったこと、後の事象がなかったこと、派生配布物が同じルート扱いを保ったことは証明しない。Mozilla方針は、Mozilla由来のソフトウェアを配布する者が証明書や信頼ビットを追加、削除、変更できることを明記する。方針が統治するのはMozillaの既定配布であり、全ての配布物ではない。

発行は後の受理でもない。NSSの文書は証明書ブロックと信頼ブロックを分け、ルートを証明書と信頼設定の組として説明する。クライアントは自らのソフトウェア状態とローカル条件で経路を構築し評価する必要がある。ホスト名、時刻、拡張、経路構築、失効情報、アプリケーション用途、接続時に観測した対象サービスは別の問いである。これは特定クライアントの失敗を述べるものではなく、クライアント側の証拠なしに監査又は発行記録が言える範囲を限定するものだ。

実務上必要なのは、境界を持つ発行証拠レシートである。保護された申請識別子、申請名と鍵指紋、手順・方針版、権限ある担当者又は自動統制、独立情報源又は代替経路の観測と時間窓、そしてシリアル、発行者、有効期間、関連拡張、発行時刻を保存する。後日の失効は照会時刻と応答文脈を伴う別記録にする。クライアント結果も、ビルド又は方針境界、ホスト名、経路、時刻とともに別に保存し、不必要な利用者データは集めない。

これはドメイン管理証拠、顧客ファイル、防御上の詳細を公開せよという提案ではない。一つの主張を別の主張の代理にしないという提案である。機微な証拠は適切な権限の下で検証できる。残すべきなのは結合の地図、すなわちどの決定がどのオブジェクトをどの規則の下で支え、後で実際にどの観測が引用されたかである。

証拠の限界

確認した資料は、特定のCA、加入者、証明書、監査意見、DCR、事故、依拠当事者の出来事を示していない。不適合も立証していない。ここでのレシートは編集上の分析であり、Mozilla、CA/Browser Forum、NSS、RFCの要件ではない。

出典

  1. Mozilla Root Store Policy 3.1
  2. Mozilla NSS: Updating NSS’s Root Store
  3. RFC 5280