要約

  • CA/Browser Forumのpull request 622は、現時点でも公開中のDraft Ballot SC-XXである。正式な投票番号、投票、IPRレビュー、採択、発効のいずれも確認されていない。
  • 現行TLS Baseline Requirements 2.2.9は、Certificate Problem Reportなどを受領してから公表された失効までを測る。草案ではCAが24時間以内に報告をactionableと判断し、その判断から理由別の失効期限を走らせる。
  • Actionableは調査可能という入口条件であり、違反の立証ではない。凍結した草案は、有効期間内で未失効の証明書を少なくとも一件特定し、規則違反または失効理由を説明することを求める。
  • 同じ判断時刻から120時間以内に、CAは自ら発行した他の有効・未失効証明書も調べる。追加で影響が判明した証明書には、最初に特定された時点から個別の期限が生じる。
  • 草案のRevokedは外部から試せる。証明書が示す該当CRLにはシリアル番号が掲載され、該当OCSPはcertStatus=revokedを返さなければならない。ただし全キャッシュの同時更新を意味しない。
  • 正式窓口での受領、actionability、実体判断、母集団調査、理由別期限、公開状態をつなぐ、プライバシーを限定したレシートが必要だ。時刻・件数・状態コードを示しつつ、秘密鍵や報告本文、加入者情報は保護できる。

公開できる終点と、見えない起点

失効した証明書を一枚渡されれば、調査者はその証明書が指すCRLやOCSPを照会できる。応答を保存し、ある時点で外部の利用者にも失効状態が届いたことを立証できる。ところが、そこに至る時計の最初の一目盛りは照会できない。問題報告を受け取ったCAが、材料は調査に足りると判断する瞬間だからだ。

PR 622は、この内部判断に制度上の重みを与える。CAはCertificate Problem Reportの受領後24時間以内にactionabilityを判断する。肯定すれば、連絡可能な報告者への調査結果の連絡、理由に応じた失効作業、発行済み証明書群の横断調査が始まる。後二者の時計は同じではない。

4.9.1.1の失効期限には複数の型がある。秘密鍵漏えいや、ドメイン検証が信頼できないことを示す証拠などは24時間以内の失効を要求する。別の列挙理由には24時間のSHOULDと5日以内のMUSTがある。したがって監査には、開始時刻だけでなく、どの理由クラスを適用したかが要る。

現行2.2.9では、問題報告または失効関連通知の受領から「published revocation」までの期間をこの上限に結び付ける。提案は第三者報告について、その外側の開始点をactionability判断へ移す。提案理由は、必要な情報が揃ったかをCAが確認するための一定時間だと説明する。

識別できる証明書も論拠もないメッセージが、直ちにサービス停止を伴う期限を動かさない設計には合理性がある。しかし、分類が期限を左右した瞬間、分類は単なるメール整理ではなくなる。後から検証できる統治上の出来事になる。

調査できることと、正しいことは別である

草案の入口は、少なくとも一件の有効な識別子を要求する。対象はそのCAが発行し、報告時点で有効期間内、かつ未失効の証明書である。シリアル番号は受け付けなければならず、証明書またはprecertificateのSHA-256フィンガープリントは受け付けることが望ましい。さらに、Baseline RequirementsやCAポリシーにどう反するのか、または秘密鍵漏えいなどの失効理由を記す。

この条件を満たしても、報告者の主張が正しいとは限らない。実在の証明書と実在の条文を示しながら、事実関係を誤解することはある。CAは案件を受け付けた後、違反なしと結論できる。pull requestのコメントも、actionableであること、不遵守が認定されたこと、是正が完了したことを分けている。

この区別はCA側にも制約をかける。actionableを「CAが主張に同意した」と解釈すれば、調査が終わるまで期限を始めずに済む。入口判定が最終判決を兼ね、時計は都合よく後ろへ動く。草案の“is considered actionable if it includes”という構造は、結論ではなく入力テストとして読むべきだ。

どこに送れば受領となるかも重要である。提案はCertification Practice Statementの1.5.2節に明確な手順を置き、見つけやすいウェブページ、FAQ、ナレッジベースを勧める。処理不能な送信をフォームで防いでもよいが、処理可能な報告を受け取れなければならない。

議論では、秘密鍵、ドメイン名、シリアル、フィンガープリントのどれをフォームが受けるべきか、メールを必須にするか、任意の従業員へ届いた連絡をどう扱うかが争われた。一般社員へ送られた鍵が直ちに技術部門の24時間時計を始めるのは不合理だ。他方、公開窓口が利用可能な証拠を案件化する前に捨てれば、その窓口は名目だけになる。レシートには窓口と受領時刻、当時の公開手順の版を含める必要がある。

「失効済み」をデータベースの外へ出す

提案の中で最も測定しやすい部分は、Revokedの新しい定義である。証明書にCRL Distribution Point URIがあれば、その場所で得られるCRLにシリアル番号が含まれること。Authority Information AccessのOCSP URIがあれば、その場所への当該シリアルの照会にcertStatus=revokedが返ること。この二つを証明書が示すなら、双方が該当条件になると読むのが自然だ。

servercert issue 252は2021年以来、失効という語の実行点を問い続けている。内部データベースのフラグを変えた時か。新しいCRLまたはOCSP応答に署名した時か。オリジンサーバーへ配置した時か。それとも証明書自身が指す配布経路から利用者が取得できる時か。

内部フラグは、利用者の信頼判断を変えない。署名済みオブジェクトが配布されない場合も同じだ。草案は完了を利用者が触れるインターフェースに置く。これは、CAの内部作業完了という自己申告より強い。

ただし、ネットワーク全体が同じミリ秒に切り替わるという意味ではない。issue 252にはCDN上のコンテンツを一斉に消去・更新する難しさが記録されている。キャッシュごとに短時間の差があり得るし、オンデマンドOCSP応答は問い合わせ時に生成される場合もある。これは観測可能な完了条件であって、宇宙規模の同時性保証ではない。

終点の定義が強くなるほど、起点の証拠不足が目立つ。外から到達できる応答に対し、actionability判断はまずCAの案件管理システム内にしかない。

120時間の仕事は、母集団をCAへ返す

報告者が見つける一枚と、CAが把握できる全体は大きく違う。提案はactionabilityから120時間以内に、同じ不遵守が他の有効・未失効証明書にもないか、当該CAの発行群を評価するよう求める。報告者は一枚を特定すれば入口条件を満たし得る。発行ログ、検証方式、顧客関係、ソフトウェア展開履歴を持つCAが兄弟証明書を探す。

DigiCertのCNAME検証インシデントは、この分担が必要な理由を示す一例であり、草案が事故を防げたという証明ではない。Bugzilla 1910322によれば、第三者は当初、把握していたシリアル番号を渡さなかった。DigiCertの後の報告は、シリアルのないCPRを真剣に扱わなかったことを根本原因の一つに挙げ、完全報告時点でその方式により発行された有効証明書を83,267件とした。外部の最初の兆候と、内部で見える影響群には桁違いの差があった。

完全な列挙を報告者に要求すれば、情報を持たない側へ探索責任を移すことになる。一枚の入口とCA全体の調査を組み合わせる案は、能力に責任を合わせる。しかし新しい証拠点も作る。120時間はactionabilityから始まり、追加証明書の理由別期限はCAがそれを最初に特定した時から始まる。

「全体調査完了」という一行では、検索をいつ始めたか、システムがいつ一致を出したか、人がいつ案件へ転記したかを区別できない。必要なのは、開始時の母集団定義、クエリまたは手法の版、開始・完了時刻、検査数、新規該当数、例外、後日の訂正である。検索式や顧客一覧を公開する必要はない。後で見つかった一群が、当初の検索対象に存在しなかったかのように扱われない証拠は要る。

不完全な報告にも履歴がある

報告品質を上げる狙いは正当だが、欠けた入力を消す権限と混同してはならない。DigiCert事例では既知のシリアルが当初共有されなかった。SSL.comをめぐるBugzilla 1942270では、メールからフォームへ誘導され、“thumbprint”欄の意味が不明だったという訴えがあり、最終的にINVALIDで解決された。GoDaddyのBugzilla 1942241では、侵害鍵を含むアーカイブ添付を公式アドレスが拒んだという訴えがあり、最終状態はFIXEDだった。

これらは万能な窓口設計を示さない。メール添付をセキュリティ上の理由で遮断することも、フォームが迷惑送信を除くこともあり得る。平文の秘密鍵には特別な扱いが必要で、報告者が誤っている場合もある。すべてのメッセージを失効命令にしない草案の慎重さは妥当だ。

問題は、入力品質のしきい値が古い履歴を消すときである。凍結テキストでは、連絡先がある不処理案件について、CAは通常、判定後24時間以内に不足項目を求める。後日その材料を受領した時刻が後続期限の基礎になる。期限の開始が後日になることと、最初の接触が消えることは同義ではない。

受領、不処理、不足照会、追完、actionableまで同じ案件識別子を使うべきだ。月曜の詳しい指摘に金曜シリアルが加わり、公開履歴が金曜から始まるなら、個別手続は守れても全行程は失われる。期限が金曜から正当に始まる場合でも、月曜からの経路は保存できる。

最小レシートは何を結ぶべきか

公開すべきなのはインシデント資料一式ではない。草案が作る状態遷移を、後から分離できない形で結ぶ証跡である。

状態 最小限のレシート
正式受領 窓口、公開手順の版、受領時刻、プライバシー保護された報告ID
初期分類 actionability判断時刻、揃った／欠けた入力、限定された理由コード
実体判断 違反または失効理由の種類。actionabilityとは明示的に分離
初期証明書群 件数、保護された識別子、24時間または5日の期限クラス
母集団評価 範囲、手法の版、開始・完了、検査数、新規該当数、例外
追加発見 保護された各項目または集約群の初回特定時刻と期限クラス
公開 該当する各CRL/OCSP場所と、失効を最初に正常観測した時刻
残存状態 配布例外、加入者調整、訂正、次の行動責任者

公開層は時刻、件数、状態コードだけでもよい。識別子は加入者や調査を害する局面ではハッシュ化または遅延できる。平文の秘密鍵、報告本文、アカウント情報、内部検出クエリ、安全上のフォーム制御は非公開にすべきだ。必要ならルートプログラムや監査人が保護層を確認する。

Lu Hengの「現実層」という区別は、ここでは限定的な編集上の試験として使える。Web PKIの教義でも、Forumの意思決定を代行する原理でもない。ある状態名が、その状態に実際の効果を与える出来事へ接続されているかを見るための問いである。Actionableは時計を変え、Revokedは利用者が受け入れてよい対象を変える。どちらも名前だけでなく時刻と観測を要する。

2026年9月15日は、まだ規則の日付ではない

凍結時のpull requestはDraft Ballot SC-XXのままで、headはef1dda7b7652d439c3b4b8db2328c4afd4a31ec0、baseは6aba16d239d793d547c9397c50a3013257107bb6である。比較対象の現行mainは5c13e270b4e0b6aaef258acf0a642d1c5a36cf97、文書版は2.2.9だった。

一方、PR headの文書は自らを2.2.2と記し、2026年9月15日という提案上の発効日を含む。この組み合わせは、日付が採択済み規則ではなく、古い版表示を残した作業枝のフィールドだという警告になる。8月13日のSCWG議事録は作業が論じられたことを示すが、憲章・細則に沿う正式番号、議論期間、投票、IPR、公開が完了した証拠ではない。

運用者は今からレシートや調査ログを試せる。しかし9月15日を現行義務として扱ってはならない。監視すべきなのは最終投票番号、正式な議論と投票、IPR状態、マージされた規範文書、明示された発効条項である。

出典

  1. Heng Lu「On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile」
  2. CA/Browser Forum servercert pull request 622
  3. 凍結head ef1dda7b…の提案版Baseline Requirements
  4. 凍結main commit 5c13e270…の現行Baseline Requirements
  5. servercert issue 252：失効の技術的意味の明確化
  6. Mozilla Bugzilla 1910322：DigiCert CNAME検証インシデント
  7. Mozilla Bugzilla 1942270：SSL.comの報告手段に関する苦情
  8. Mozilla Bugzilla 1942241：GoDaddyの添付ファイルに関する苦情
  9. 2026年8月13日SCWG議事録
  10. Server Certificate Working Group Charter
  11. CA/Browser Forum Bylaws