要約

  • SC-104が指定するTLS Baseline Requirementsの基点では、Subscriber Certificateに非クリティカルなAuthority Information Access拡張がMUSTである。ただし内部のid-ad-caIssuersはSHOULD、id-ad-ocspはMAYである。
  • 提案の固定diffは、外側の存在要件をMUSTからSHOULDへ変え、少なくとも一つのAccessDescriptionを要求する文に「存在する場合」を加える。メソッドごとの規則は変えない。
  • caIssuersは発行者証明書の取得と認証パス選択を助け、OCSPはオンラインの証明書状態サービスを示す。同じ拡張に入るが、役割は別である。
  • 公開通知による投票期限は2026年9月3日00:00 UTCである。調査締切の9月2日時点で、可決、IPRレビュー完了、最終Guidelineへの収録を先取りしてはならない。
  • 手続、プロファイル、メソッド、発行済み証明書、relying partyの挙動を別々に記録し、バージョンとフィンガープリントで結ぶ必要がある。「AIA準拠」という一項目では足りない。

住所録があっても、どの窓口が載るかは別問題

AIAは、発行者に関する情報やサービスへの到達先を記す拡張である。比喩的にいえば住所録に近い。しかし、住所録の存在を義務付ける規則と、そこにどの窓口を載せるかという規則は別に書かれている。

投票の基点commit ad77bf…では、Subscriber Certificate Extensions表のauthorityInformationAccessはMUSTで、クリティカルではない。続く節はAuthorityInfoAccessSyntaxに一つ以上のAccessDescriptionを要求する。そして許されるメソッドを二つに限定する。OCSPはMAY、caIssuersはSHOULD、その他はMUST NOTである。

したがって現行の基点は、空でない外箱を必須にする一方、特定の一つのサービスを必ず提供するとは約束していない。caIssuersのSHOULDには例外を慎重に判断する規範的な重みがある。OCSPのMAYとは同じではない。

SC-104は、この外箱と内側の水準差を二行で処理する。表のMUSTをSHOULDへ変える。構文規則を「拡張が存在する場合」に限定する。OID、URL型、順序、個数、caIssuersとOCSPの水準は変更しない。CA CertificateやOCSP Responder Certificateの全プロファイルを書き換える提案でもない。

この限定性を守るなら、「AIAが不要になる」という見出しは成立しない。

SHOULDを単なる任意にすると記録が壊れる

RFC 2119におけるSHOULDは、正当な理由がある場合の逸脱を認めるが、その含意を理解し、慎重に比較した上で選ぶことを求める。RFC 8174は、大文字の規範語がその意味を持つ条件を明確にする。

仮にSC-104が最終的に有効なGuidelineへ入った場合、AIAを省略したSubscriber Certificateは、外側のMUST違反ではなくなる。それでもSHOULDから外れる判断には、理由、対象製品、発行プロファイルの版、適用期間、互換性試験を残す余地がある。

監査システムが「存在／不存在」しか保存しなければ、検証済みの例外と設定ミスを区別できない。SHOULDをMAYのように扱うことになる。逆に、あらゆる省略を直ちに不適合とすれば、MUSTから変える意味を消してしまう。

必要なのは中間状態である。通常の包含、理由を持つ例外、説明されていない逸脱を区別し、どの規則版で誰が判断したかを記録する。共通規則が柔軟になるほど、ローカルな決定の証拠は細かくできる。

パス構築と状態確認を一つにしない

RFC 5280では、id-ad-caIssuersは発行者証明書の取得先を示し、認証パスの選択に役立つ。id-ad-ocspはオンラインで証明書状態を問い合わせるサービスを示す。両方がHTTP URIを持ち得ることや、一つのAIA拡張に並ぶことは、機能の同一性を意味しない。

Baseline Requirementsの別の箇所もこの違いを読む。Subscriber CertificateにAIAのOCSPポインタがあるかどうかは、CRLの更新やCRL Distribution Pointsに関する条件と関係する。したがって、外箱の有無だけを記録すると、どの条件が成立していたかを後から復元できない。

caIssuersがないことだけで、パス構築の失敗も証明できない。TLSサーバーが適切な中間証明書を送る場合がある。クライアントがローカルストアやキャッシュに持つ場合もある。ベンダーが別経路で配布することもある。

逆も同じである。caIssuers URLが証明書にあっても、クライアントが取得を実装または許可しているとは限らない。URLが到達可能とも、取得物から有効なパスを作れるとも限らない。証明書は候補経路を符号化する。実行ログではない。

同じ証明書でもクライアント条件が違う

Microsoftは、WindowsがAIAを用いて欠けた発行者証明書を取得できること、管理者がその取得を無効化できることを説明している。ここで必要な観測項目は、Windowsという名称ではない。製品版、ポリシー、証明書ストア、キャッシュ、ネットワーク、URL、サーバーが送ったチェーンである。

Mozillaは2020年、FirefoxがRemote Settingsを通じて開示済みの中間CA証明書を事前配布する仕組みを説明した。サイトが正しい中間証明書を送らない場合のunknown issuerエラーを減らす狙いもあった。これは、ライブのcaIssuers取得以外の供給経路を示す例である。

ただし、この例から全Firefox版で全中間証明書が常に揃うとは言えない。サーバーのチェーン設定が不要とも言えない。Windowsの例から、全クライアントがAIA取得に依存するとも言えない。どちらも実装の境界を示すだけで、市場全体の測定ではない。

観測では、中間証明書を実際にどこから得たかを書くべきである。サーバー、ローカルストア、キャッシュ、事前配布、caIssuers取得を区別しない成功ログは、依存関係を隠す。後にキャッシュが消えた時、原因不明の回帰として現れる。

投票結果より前に規則を成立させない

公開されたSC-104通知は、Google Trust ServicesのEthan Davisを提案者、SwissSignのRoman FischerとDigiCertのStephen Davidsonをendorserとして示す。基点はBaseline Requirements 2.2.9で、基点と提案commitの固定比較が提示された。

議論期間は2026年8月20日から27日UTC、投票期間は8月27日から9月3日00:00 UTCとされた。この記事の調査締切は9月2日である。よって確認できる状態は「投票中」であり、「可決済み」ではない。

CA/Browser Forumの手続では、投票成功、IPRレビュー、Final Maintenance Guidelineの公開も別状態である。pull requestがopenであること、投票メールがあること、将来mergeされることのどれも、特定日に有効だった規則版の代わりにはならない。

手続レシートには、ballot ID、提案者、endorser、基点commit、提案commit、議論と投票の期間、投票資格の分母、票数、結果、IPRの開始と終了、除外通知、最終版、発効日を持たせる。最新ラベルで履歴を上書きしてはいけない。

もし後日可決されても、9月2日の状態が遡って変わるわけではない。否決や修正の場合も、固定diffは検討された案の証拠として残る。手続の時間は技術文そのものと同じく監査対象である。

五層の状態表

手続層は、SC-104が提案、投票、IPR、公開のどこにいるかを示す。権威の状態であり、発行実態ではない。

プロファイル層は、証明書種別、Guideline版、AIAの外側の規範語、クリティカル性、発効日を示す。適用ルールであり、証明書のバイト列ではない。

メソッド層は、caIssuersとOCSPを別行にし、OID、目的、SHOULDまたはMAY、位置型、個数、順序を示す。外箱に内側の差を吸収させない。

発行層は、発行CA、製品、テンプレートまたは設定版、証明書フィンガープリント、実際のAIAと各AccessDescriptionを示す。観測されたバイト列である。

利用層は、relying partyの製品、版、OS、ポリシー、ストア、キャッシュまたは事前配布、サーバーチェーン、ネットワーク、取得試行、状態確認、結果を示す。一つの再現可能な実行である。

Guideline版が手続とプロファイルを結び、発行設定がプロファイルと証明書を結び、フィンガープリントが証明書と利用結果を結ぶ。しかし、結合は同一化ではない。あるクライアントの失敗はballotを無効にしない。あるクライアントの成功は省略の普遍的安全性を証明しない。

Lu Hengの「最小の初期仕様」「将来の決定をローカルに検証する」「公開と採用を区別する」という考え方は、この境界の編集原則として使える。Lu HengがSC-104を評価したという意味ではない。共通規則が証明できる範囲と、実装が証明すべき範囲を混ぜないためである。

公開資料がまだ示していないこと

今回の資料には、現在のSubscriber CertificateのうちAIA、caIssuers、OCSPを含む割合の測定がない。SC-104が成立した時にどのCAがテンプレートを変えるかも分からない。サイズ、プライバシー、遅延、可用性、障害率、安全性の効果も定量化されていない。

提案の規範的理由は、その欠落があっても検討できる。特定メソッドを保証しない内部規則に、外側のMUSTを合わせ直すという議論である。ただし論理的一貫性は、運用上の便益を実証したことにはならない。

支持側は、Firefoxの事前配布を普遍的な無害性の証拠にできない。反対側は、Windowsの取得機能を普遍的な依存の証拠にできない。必要なのは、発行者、証明書、サーバー、クライアント、設定を分けた測定である。

二行を二行のまま評価する

SC-104はWeb PKI全体を設計し直す提案ではない。外側の存在要件をMUSTからSHOULDへ移し、内側の二つの水準を維持する提案である。

Working Groupは共通規則を決められる。CAは有効な規則の下で発行設定を決める。クライアントはパス構築と状態確認を決める。サーバーは提示チェーンを決める。これらは連関するが、一つの主体が行う一つの決定ではない。

五層の記録があれば、「AIAは不要になった」という大きすぎる結論を避けられる。代わりに、どの版がどの言葉を採用し、どの証明書にどのメソッドがあり、どのクライアントがどの条件で何をしたかを述べられる。

二行の変更に必要なのは、二行以上の予言ではない。五つの小さな証拠である。

出典

  1. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  2. CA/Browser Forum servercert pull request 665 — SC-104
  3. SC-104の固定比較
  4. CA/Browser Forum servercert issue 673
  5. SC-104投票通知の公開アーカイブ
  6. 投票基点commitのTLS Baseline Requirements
  7. CA/Browser Forum Bylaws
  8. RFC 5280 4.2.2.1節
  9. RFC 2119
  10. RFC 8174
  11. Microsoft, Authority Information Access retrieval
  12. Mozilla Security Blog, Firefoxへの中間CA証明書の事前配布