要約

  • Symantec の認証局事業を DigiCert が取得したことで、新しい発行基盤への移行路はできた。しかし Google、Mozilla、Apple は、旧PKIをいつ、どの範囲で受け入れなくするかを、それぞれの製品と例外規則の中で決め続けた。
  • 証明書が期限内で署名も正しく、買収契約が完了していても、利用者のクライアントがそのチェーンを認める保証にはならない。継続性は、依拠当事者の実行中の判断を把握し、拒否が始まる前に代替チェーンへ移ることでしか得られない。

買収契約の外にあったもの

企業買収は、従業員、顧客契約、設備、鍵の管理手順、収益を移せる。2017年の取引も、Symantec のウェブサイトセキュリティ事業を DigiCert へ移し、独立運用される新しい発行基盤を用意する現実的な道を作った。だが、公開ルートの効力は、そのルートを信頼アンカーとして扱う第三者ソフトウェアに依存する。売り手は、その次のソフトウェア更新まで引き渡せない。

Mozilla はこの境界を明文化した。ルートストアの信頼は組織間で自動的に移転しない。DigiCert による取得後も、旧 Symantec ルートの段階的な不信頼化は続く。そうでなければ、制裁対象となった認証局は、事業売却や組織再編で措置を回避し、ほぼ同じ運用を別の名前で継続できてしまう。

Google の記録は、なぜそこまでの判断に至ったかを説明する。2017年1月の公開投稿を契機に、疑わしいウェブ認証証明書が調査された。発行能力を与えられた複数組織に十分な監督がなく、過去から続く問題の一部だと判断されたことで、Chrome チームは旧基盤への信頼を失った。

これは全証明書が不正だったという認定ではない。一枚の証明書ではなく、階層全体に与えていた包括的な推定を見直したという意味だ。そのため対策も、特定証明書の失効だけではなく、新旧発行基盤の分離、サイトの再発行、そしてクライアント受容規則の段階変更になった。

一つのチェーンを刻んだ四つの時計

第一は発行日の時計である。Chrome は2016年6月1日を Chrome 66 で先に不信頼化する古い証明書の境界とした。2017年12月1日は DigiCert 管理の新基盤への切替点であり、それ以降に旧基盤から発行された証明書は Chrome に受け入れられない。Chrome 70 では、限定的な例外を除き旧基盤全体への信頼を外す計画だった。

第二はリリースの時計だ。方針発表の日に全端末が変わるわけではない。Canary、Beta、Stable と段階的にコードへ入る。Google は Chrome 66 と70の各日程を示し、企業向けには旧PKIの不信頼化を一時的に止めるポリシーも用意したが、2019年1月1日に終了させた。例外は局所的な猶予であり、公開信頼の回復ではなかった。

Mozilla にも独自の順序があった。Firefox 58 はコンソール警告、Firefox 60 は2016年6月1日以前の対象証明書を接続エラーとし、その後に旧ルート全般を外す。未移行サイトがなお多かったため、最終段階は Firefox 63 から64へ延期された。危険とみなした階層を長く許容するか、多数の未移行サイトを壊すかという現実の比較だった。

第三はサイト運営者の時計である。証明書の notAfter が先でも、ブラウザー側の締切が先に来る。Mozilla は2018年3月初めに、上位100万サイトのおよそ1%が Firefox 60 の影響を受けると推計し、同版の公開直前には0.15%未満まで低下したと報告した。次段階を測った別時点では3.5%が残っていた。母集団条件の異なるスナップショットだが、信頼方針が大量の棚卸しと交換作業へ変わる過程を示す。

第四はインストール済み端末の時計だ。Apple は2018年8月1日に部分的不信頼化を始め、一定の発行期間については信頼済みCTログへの登録を条件に受け入れを継続した。列挙された Symantec CA の全面的不信頼化は2020年2月25日とされる。Chrome、Firefox、Apple の利用者に同時刻の世界的切替は存在しなかった。

同じサーバーと証明書でも、一人は接続でき、別の一人は拒否される。変わったのは証明書のバイト列ではなく、依拠側で動く受容状態だった。

CTは可視化であり、正当化ではない

RFC 6962 は Certificate Transparency を追記専用ログ、署名付きタイムスタンプ、一貫性証明として設計した。ドメイン所有者は知らない発行を発見でき、監査者はログが異なる履歴を提示していないか検証できる。

同じRFCは、署名付きタイムスタンプが誤発行でないことを保証しないとも述べる。CTが証明するのは、発行という主張が観測可能になったことだ。申請者の権利、検証の妥当性、ブラウザーが発行者を受け入れ続ける義務までは証明しない。

Apple の移行規則では、限定された期間の証明書についてCT掲載が受容条件の一つになった。それは旧ルートへの永久承認ではない。予期しないCT記録を見つけた企業は、申請者、検証方法、実配備、影響クライアント、失効を調べる必要がある。ログ記載は調査開始点であって判決ではない。

実効的な権限はクライアントに宿った

ルート証明書は中央権威に見えるが、実際には各クライアントが信頼アンカーとして実行することで力を持つ。Google は Chrome、Mozilla は Firefox、Apple は自社プラットフォームを変え、企業は管理端末の例外を一時維持し、サイトは別チェーンへ移れる。それぞれに強い権限がある一方、他者の選択を消すことはできない。

Heng Lu の running-code primacy は、ここでは明示した分析枠組みであり、事件の事実資料ではない。制度上の主張は参加者が規則を実行して初めて現実の効果を得る。技術的依存の大きさだけで無制限の主権が生まれるわけでもない。Symantec の売却はクライアントの信頼ストアを書き換えなかった。新運営者とサイトは、依拠側が選んで受け入れるチェーンを提供する必要があった。

ただしブラウザーベンダーの力は巨大である。少数企業の判断が世界中の交換費用を生む以上、公開要件、証拠、段階的実装、期限付き例外、案件間の一貫性が必要だ。コードで実行できることは有効性を示すだけで、公正さの証明にはならない。

期限表では足りない

有効期限だけの証明書台帳では、この移行を予告できない。必要なのは、完全な提供チェーン、到達可能なルート群、重要な利用者が使うルートプログラム、リリースチャネル、発行日境界、CT要件、下位CA例外、実クライアントでの代替確認である。

鍵侵害、誤発行、監査不備、リーフ失効、ルート不信頼化、ブラウザー展開も分けるべきだ。相互に関連しても、止められる主体と影響経路は異なる。

認証局の買収評価でも、顧客契約、現行発行機能、旧ルート、新ルート、下位関係、監査義務、CT参加、既発行証明書の交換費用を別に見る。終了予定のチェーンに依存する売上は、新基盤へ移行済みの売上と同価値ではない。

証拠の限界

公式資料は日程と「信頼は自動移転しない」という立場を裏付けるが、旧証明書すべての不正を証明しない。Mozilla の比率は時点限定の測定である。Apple の日程を Chrome や Firefox に当てはめてもならない。ルートプログラムは自社クライアントに実効権限を持つが、ウェブ全体の主権者ではない。

情報源