Sectigo の Comodo 遺産が示す、証明書信頼の委任発行による失敗の仕組み

概要

• 確認された公開記録：Comodo のインシデント報告によれば、2011年3月15日に登録局アカウントが侵害され、7つのドメインにわたる9件の不正な証明書が発行された。同報告はまた、発見後直ちにすべてが失効され、OCSP レスポンダートラフィックの監視において失効後の使用試行は検出されなかったと述べている。（Comodo インシデント報告）
• ブラウザとプラットフォームの対応：Mozilla、Microsoft、その他のブラウザやプラットフォーム事業者は、この事件を単なる発行者内の管理問題として扱わなかった。Mozilla は証明書ブラックリスト更新を配信し、Microsoft はセキュリティアドバイザリ2524375と、当該9件の証明書を Windows の信頼されない証明書ストアに追加する更新を公開した。Mozilla の追跡報告は、侵害された登録局経路について説明している。（Mozilla アドバイザリ、Microsoft アドバイザリ、Mozilla 追跡報告）
• 説明責任の境界：公開証拠は、Comodo のルート鍵やハードウェア・セキュリティ・モジュール（HSM）が侵害されたという公開認定ではなく、委任発行の失敗を支持している。Comodo は自社の CA 基盤と HSM 鍵は侵害されなかったと述べた。この区別は技術的な主張を狭めるが、説明責任の問題を狭めるものではない。侵害された委任アカウントが依然として高価値ドメイン向けのブラウザに信頼される証明書を生成したのである。
• 評価：攻撃者は侵入および悪用未遂の責任を負う。Comodo は委任発行モデル、リセラー認証、インシデント後の統制を掌握していた。ブラウザおよび OS ベンダーは緊急時の不信化を、ルートプログラムは継続的信頼をそれぞれ掌握していた。依拠当事者サービスとユーザーは、自身では直接観察できない結果を被った。

認証局はルート鍵から遠く離れた場所で機能不全に陥りうる

認証局のインシデントは、しばしば単一の劇的な侵害として想像される。すなわち、攻撃者がルート秘密鍵を盗み、ウェブ全体を偽造し、信頼システム全体が崩壊するというものだ。Comodo の事例は、より日常的でありながら、より示唆に富んでいた。Comodo は、自社の CA 基盤は侵害されておらず、ハードウェア・セキュリティ・モジュール内の鍵も侵害されなかったと述べた。不正証明書は、証明書発注プラットフォームへの委任された玄関口である登録局アカウントを通じて発行されたのである。（Comodo インシデント報告）

この違いは重要である。ルート鍵侵害は、基盤となる暗号アンカーが依然として利用可能かどうかを問う。委任発行の侵害は、より困難な運用上の問いを提起する。すなわち、パートナーアカウント、リセラーのワークフロー、検証担当者、自動化システム、緊急失効チャネルにどれほどの実質的な CA 権限が委ねられているのか、という問いである。もし委任アカウントが mail.google.com、www.google.com、login.yahoo.com、login.skype.com、addons.mozilla.org、login.live.com の証明書を発行させることができるのであれば、信頼システムは数学的な根源において失敗したのではなく、管理上の境界において失敗したのである。

管理上の境界こそが、公共のインターネットが存在する場所である。ユーザーは、どの登録局が証明書要求を検証したかを決定しない。ユーザーが見るのは、鍵アイコン、ドメイン名、そしてブラウザによるチェーンの受け入れのみである。ブラウザベンダーやルートプログラムは、単一の企業本社を信頼しているだけではない。秘密鍵を取り巻く運用システムを信頼しているのである。そのシステムには、検証手順、アカウントセキュリティ、リセラー監視、監査証跡、失効サービスの能力、インシデント報告、そして障害が再発した場合に信頼を除去または制限する意思が含まれる。

したがって、Comodo の記録は、不正証明書の数が少なかったがゆえに、有用な説明責任の事例となっている。9件の証明書は、何千ものエッジケースに教訓を埋もれさせることなく、失敗モードを示すのに十分である。この事件は、既知の大規模な傍受キャンペーンを引き起こす必要はなかった。ガバナンスの問題を露呈するには十分だったのである。この事件は、委任アカウントが、認証局のブラウザルートとしての地位を、インターネット上で最も機密性の高いアイデンティティ宛先の証明書へと変換し得ることを示した。

その宛先の名称自体が問題を内包している。ログインエンドポイントの証明書は、装飾的な産物ではない。それは、ブラウザに対して暗号的なアイデンティティを提示するための資格情報である。攻撃者がそのような証明書を、トラフィック迂回、DNS 操作、ローカルネットワーク制御、ルーティング妨害、マルウェア、あるいは国家レベルのネットワークアクセスと組み合わせることができれば、ユーザーは、その接続が意図したサービスとのものではないことを見分ける通常の手段を持たない可能性がある。Microsoft は、これらの証明書が、コンテンツのなりすまし、フィッシング攻撃、ブラウザユーザーに対する中間者攻撃に使用される可能性があると警告した。（Microsoft アドバイザリ2524375）

正しい結論は限定されたものである。公開記録は、9件の証明書すべてが成功裏の大規模傍受に使用されたことを示してはいない。Comodo は、1件のみがインターネット上で生きた状態で確認され、OCSP レスポンダートラフィックの監視では失効後の使用試行は検出されなかったと述べた。それでも Microsoft と Mozilla は、証明書の信頼性は予防的に設計されているため、この事件を緊急と扱った。主要なログインドメインになりすますことができる証明書は、事後の証拠が大規模な悪用を証明する前に危険なのである。

公開された時系列は異例なほど具体的である

Comodo のインシデント報告は、最初の骨格を提供している。それによれば、2011年3月15日、ある登録局が攻撃を受け、その RA のユーザーアカウント1件が侵害された。そのアカウントはその後不正に使用され、7つのドメインにわたる9件の証明書が発行された。Comodo は発見後直ちに全証明書を失効させたと述べた。同報告書はドメイン名とシリアル番号を列挙し、目撃された証明書と目撃されなかった証明書とを区別した。（Comodo インシデント報告）

Mozilla の追跡報告は、そのアカウントレベルの障害をブラウザの信頼に結びつけた。Mozilla は、Comodo の RA パートナーが内部セキュリティ侵害に見舞われ、攻撃者がその RA アカウントを Comodo に対して使用し、9件の不正証明書を発行させたと述べた。また Mozilla は、証明書が失効されたこと、Firefox がそれらをブラックリストに登録する更新を配信したこと、そして Mozilla が Comodo や他の CA と更なる措置について議論していることにも言及した。（Mozilla 追跡報告）

Mozilla Foundation Security Advisory 2011-11は簡潔だが重要である。これは2011年3月22日に HTTPS 証明書ブラックリストの更新を発表し、影響度は高、Firefox と SeaMonkey が影響を受け、複数の無効な HTTPS 証明書が悪用防止のためブラックリストに登録されたと説明した。プロッキング作業のための Bugzilla 記録は、ブラウザ側の対応を示す公開証跡である。（MFSA 2011-11、Mozilla Bugzilla 642395）

Microsoft のセキュリティアドバイザリ2524375はプラットフォーム層を追加した。Microsoft は、Comodo から2011年3月16日に、第三者のために9件の証明書が本人確認を十分に検証せずに署名されたと報告を受けたと述べた。Microsoft は影響を受けるプロパティを列挙し、なりすまし、フィッシング、中間者攻撃のリスクを説明し、Comodo が証明書を失効させ証明書失効リストに掲載したと言及した。それでも Microsoft は、失効確認だけではあらゆるネットワーク状況で保護を保証できるほど堅牢ではないため、当該9件の証明書をローカルの信頼されない証明書ストアに追加する更新をリリースした。（Microsoft アドバイザリ2524375）

この最後の点が要諦である。失効だけで十分に信頼性があれば、OS の更新はこれほど緊急ではない。Microsoft のアドバイザリは問題を簡潔に説明した。CRL や OCSP エンドポイントに到達できない場合、ブラウザやアプリケーションはユーザーを露出させたまま動作し続ける可能性がある。証明書は発行者によって失効されていたが、依拠当事者ソフトウェアは依然として不確実性を除去するためにローカルの不信ロジックを必要とした。これこそが、CA インシデントがブラウザ、OS、エコシステム全体のインシデントに転化する瞬間である。

Comodo の報告書にある後の3月26日の詳細も明らかである。Comodo は、3月26日にリセラーユーザーアカウントへの侵入を検知し阻止したと述べ、3月15日の事件後に実装された新しい統制により不正証明書発行のリスクは除去されたと述べた。また、攻撃は同一の実行者によるものとみられるとした。この更新は単なる補足ではない。最初の侵害後の委任発行に対する再試行を示唆し、インシデント後の統制を精査の対象とするものである。（Comodo インシデント報告）

公開説明責任記録としては、この時系列は強力だが不完全である。公開に際しては日付、委任アカウント経路、証明書数、ドメイン、失効主張、ブラウザと OS の対応、そして後日の阻止された試みの存在が示された。しかし、完全な独立したフォレンジック報告、正確な初期侵入経路、リセラーの完全な統制環境、監査結果、ルートプログラムとの非公開通信、ブラウザベンダーが使用した正確な判断基準は公開されていない。

委任は責任の抜け穴ではない

委任発行における最も誘惑的な防御は、同時に最も弱い説明責任防御でもある。すなわち、ルート CA は侵害されていないのだから、失敗はどこか別の場所にある、という主張である。技術的には、それは真実かもしれない。ガバナンス上は、それでは不十分である。認証局は、検証や発注機能を委任するかどうか、パートナーをどのように認証するか、どのドメインに追加チェックが必要か、発行異常をどのように検知するか、どの委任アクターがブラウザに信頼される発行への実際的なアクセスを得るかを自ら選択する。

このことは、委任モデルがすべて無謀であることを意味しない。大規模な証明書発行は常に分散に依存してきた。企業、ホスティングプロバイダー、リセラー、マネージドサービスチャネルは、組織が迅速に証明書を取得するのを支援できる。自動化と委任はコストを削減し普及を改善しうる。説明責任の問いは、委任モデルが、委任アカウントが行えることに対して見合った統制を備えているかどうかである。

Comodo の証明書は、悪用価値の低い無名のドメイン向けではなかった。それらはウェブメール、検索、ソフトウェア配布、ブラウザ拡張、ログインに関連するドメイン向けであった。有用な委任発行システムは、高価値ドメイン向けの証明書が、小規模ビジネスドメインの定期更新とは異なるリスクプロファイルを呈することを認識すべきである。その認識は、より強力なドメイン管理検証、帯域外承認、高リスク名監視、異常検知、レート制限、パートナーアカウント制限、顧客の事前承認、あるいはリセラーアカウントが世界的に機微な名前に対する発行を試みる際の即時エスカレーションとして現れうる。

現代のベースライン要件とルートストアポリシーは、2011年のエコシステムよりもこれらの問題をより明示的に語っている。CA/Browser Forum Baseline Requirements は現在、サーバー証明書発行、検証、失効、CA 運用に関する公開要件を提供している。Mozilla のルートストアポリシーと執行資料は、Mozilla 製品によって信頼される認証局を含めたり懲戒したりするための条件を定義している。（CA/Browser Forum Baseline Requirements、Mozilla Root Store Policy、Mozilla CA enforcement policy）

これらの現行文書は、特定の2011年の統制が現在の規則に違反していたことの証明として遡及的に読むべきではない。それらが関連するのは、エコシステムがどのように信頼を公開された運用要件へと翻訳することを学んだかを示しているからである。委任は、CA が結果に対して説明責任を負い続ける場合にのみ許容される。CA は、ブラウザに信頼される証明書の社会的意味を外部委託することはできない。検証の一部を外部委託することはできるが、ブラウザルートプログラムとユーザーは依然としてその証明書を CA の信頼として経験する。

ここで、不正利用連絡先の経済学が物語に加わる。不正証明書発行は、委任決定を行っていない当事者にコストを課す。ブラウザベンダーは緊急更新を配信しなければならない。OS ベンダーは不信ストアを維持しなければならない。サイト運営者はなりすましを監視しなければならない。セキュリティチームはユーザーが傍受されたかどうかを調査しなければならない。エンドユーザーは目に見えない改善に依存しなければならない。発行者とその委任パートナーは調査と風評コストを負うかもしれないが、緊急作業はエコシステム全体に分散される。

したがって、このインシデントはスピードの代償を誰が払うのかを問うている。迅速で摩擦の少ない発行は、すべてが機能しているときには証明書販売者と顧客に利益をもたらす。委任アカウントが失敗すると、同じスピードが攻撃者の資産となり、他の当事者が結果を遅らせるか元に戻すために支払う。成熟した説明責任モデルは、より強力なパートナー統制、より高リスクな発行ゲート、義務的な報告、ルートプログラムが利用可能な証拠を通じて、CA がそうしたリスクの多くを内部化することを要求する。

失効は機能したが、問題を終わらせるには不十分だった

Comodo は、9件の証明書すべてが発見後直ちに失効されたと述べた。これは意味のある事実である。失効は、証明書が誤発行された場合の最初の緊急ブレーキである。しかし、このインシデントは、失効が信頼できるユーザー保護と同じではないことを示した。証明書は CA で失効され、CRL に掲載され、OCSP によって不良とマークされ得るが、現実の失効確認は一様でないため、依然としてクライアント側の更新が必要となる。

Microsoft のアドバイザリは、依拠当事者の問題を異例の明瞭さで説明した。CRL および OCSP チェックは到達可能であれば有用だが、ネットワーク障害やクライアントの挙動がギャップを残し得る。したがって Microsoft は、不正証明書を Windows の信頼されない証明書ストアに追加する更新を発行した。この決定により、通常の失効取得が保護を提供できない場合でも、プラットフォームがそれらの証明書を信頼されないものとして扱うようになった。（Microsoft アドバイザリ2524375）

基礎となる標準は構造の説明に役立つ。RFC 5280はインターネット X.509 公開鍵基盤証明書および CRL プロファイルを定義し、RFC 6960はクライアントが証明書ステータス情報を取得する方法として OCSP を定義している。これらのツールは発行と失効のための公開語彙を作り出すが、すべてのユーザー、ブラウザ、デバイス、ネットワーク、アプリケーションが同一の瞬間に同一の失敗挙動を強制することを保証しない。（RFC 5280、RFC 6960）

この強制ギャップこそが、ブラウザブラックリストが重要であった理由である。Mozilla の更新は、悪用を防ぐために無効な HTTPS 証明書をブラックリストに登録した。ブラウザブラックリストは鈍器だが、決定的である。攻撃者がブロック、傍受、あるいは失敗させるかもしれないネットワーク呼び出しへの依存を取り除く。その代償は、ベンダーが更新を配信し、ユーザーが十分に迅速にそれを受け取らなければならないことである。（MFSA 2011-11）

したがって、Comodo インシデントは階層的な緊急モデルを示した。CA が失効する。ブラウザベンダーがローカルで不信化する。OS ベンダーがローカルで不信化する。サイト運営者が監視する。ルートプログラムが CA の統制を問う。ユーザーは不可視の機構が機能するのを待つ。複数の階層の存在は強みだが、いずれか単一の層で十分ではなかった証拠でもある。

この点は賞賛と批判の両方を和らげるべきである。公開記録が失効後の広範な使用を示さなかった程度に迅速に、Comodo が証明書を検知、開示、失効させたことを評価するのは公平である。また、即時失効では不十分だったと言うのも公平である。依拠当事者保護を全面的に生きた失効に委ねることができなかったため、このインシデントは Mozilla と Microsoft に製品更新を要求した。これは矛盾ではない。間違った証明書が既に流出してしまったときの証明書インシデント対応の通常の姿なのである。

後の Certificate Transparency の発展は教訓に別の枠組みを与える。RFC 6962は証明書の実験的な公開ロギング設計を記述し、RFC 9162は後に Certificate Transparency バージョン2を規定した。Google の Chrome 向け Certificate Transparency ポリシーは、公にログされた証明書は検知と監査が容易であるという考えを反映している。（RFC 6962、RFC 9162、Chrome Certificate Transparency policy）

Certificate Transparency は2011年の Comodo インシデントを遡及的に不可能にしたわけではない。それは隠れた発行を隠しにくくし、ドメイン所有者やモニター、ブラウザが観察しやすくすることで、後のインシデントに対する説明責任環境を変えた。Comodo 事例はその可視性がなぜ重要かを説明する助けとなる。もし委任アカウントが高価値ドメインのために発行できるなら、ドメイン所有者とブラウザエコシステムは単独の非公開発見だけを待つべきではない。

ルートストア信頼は民間プログラムによって運営される公共ユーティリティである

Comodo インシデントはルートストアガバナンスの事例でもある。認証局が強力になるのは、ブラウザや OS が、数十億人が使用するソフトウェアにそのルートを含めたり、ルートに連鎖する中間証明書を信頼したりするからである。ユーザーの信頼決定はプリロードされている。これにより、ルートプログラムは、たとえ民間企業によって運営されている場合でも、事実上の公共セキュリティ資源のスチュワードとなる。

Mozilla のルートプログラム資料は、Mozilla 製品での信頼を求める CA に対する公的な期待を述べている。Chromium と Apple も独自のルートプログラム要件とポリシーを公開している。Microsoft も信頼されたルートプログラムを維持している。これらのプログラムは同一ではないが、ブラウザとプラットフォームの信頼が条件付きであるという中心的前提を共有している。（Mozilla Root Store Policy、Chromium Root Program policy、Apple Root Certificate Program、Microsoft Trusted Root Program）

条件付き信頼は記述するよりも強制する方が難しい。主要な CA を削除または制限すると、ウェブサイト、企業、政府サービス、ローカルポータル、組み込みシステム、古いデバイスに障害が発生しうる。不十分な統制の CA をトラストストアに残せば、ユーザーを傍受に晒す可能性がある。したがってルートプログラムは困難な説明責任負担を負っている。ユーザーを保護するのに十分強力に CA を懲戒しなければならないが、ウェブが不必要な可用性障害に見舞われない程度に予測可能でなければならない。

2011年、Mozilla の公開文書はこの緊張を示した。当面の作業は悪質な証明書をブラックリストに登録することであった。より広範な作業は、何が起こったのかを議論し、追加措置が必要かどうかを問い、CA の統制と対応が継続的信頼を正当化するかどうかを決定することであった。これは一行の判断ではない。侵害経路、封じ込め、パートナー統制、監視、監査、再発確率に関する証拠を必要とする。

Comodo インシデントは、ウェブ全体での Comodo 信頼の単純な公的消去にはつながらなかった。その結果自体が示唆に富む。ルートプログラムは、CA が効果的に対応し、障害を封じ込め、統制を改善し、十分な証拠を提供したと信じるならば、インシデントを許容するかもしれない。しかし寛容は免罪と混同されるべきではない。継続的信頼は将来を見据えたリスク決定であり、インシデントが無害だったとの宣言ではない。

また一般市民は、ルートストアプログラムが CA 報告の受動的な消費者ではなく、対応チェーンの一部であることも学んだ。Mozilla はセキュリティアドバイザリを公開した。Microsoft はセキュリティアドバイザリと更新を公開した。ブラウザベンダーはコードを配信した。ルートプログラムとベンダーは、RA アカウントや Comodo リセラーと無関係なユーザーにとってインシデントを理解可能なものにした。信頼システムの公の顔は、証明書ベンダーではなく、ブラウザと OS だったのである。

これは有用な説明責任の分割を生む。Comodo は発行と失効を統制した。ブラウザとプラットフォームベンダーは緊急時の不信化とユーザー保護を統制した。ルートプログラムは将来の信頼を統制した。サイト運営者は自ドメインの監視を統制した。いかなるアクターもシステム全体を統制しなかったが、複数のアクターが本質的なゲートを統制した。CA が自社基盤は侵害されていないと言うとき、それは一つのゲートに答えるかもしれない。すべてのゲートに答えるわけではない。

Sectigo はブランド名以上のものを継承した

本記事の主題が Sectigo であるのは、現在の事業体が Comodo の認証局事業の後継ブランドだからである。Sectigo の公開資料は、Comodo CA のリブランドとその証明書ライフサイクルおよびデジタルトラスト事業について説明している。（Comodo CA is now Sectigo、Sectigo about page）

これは、現在の Sectigo が2011年のあらゆる運用詳細について、2011年の Comodo 経営陣と同じように責任を負うことを意味しない。企業史には正確さが必要である。2011年のインシデントは Comodo 認証局の記録に属する。Sectigo の説明責任は、信頼の継承、市場での地位、監査期待、ルートプログラムとの関係、そして過去の CA インシデントからの教訓が現在の統制に吸収されていることを示す義務である。

認証局市場において信頼の履歴が重要であるのは、証明書が通常の製品ではないからである。CA は、ブラウザと依拠当事者が受け入れるという主張を販売する。その主張の価値は累積された信頼から生じる。すなわち、監査、ルート収録、コンプライアンス、稼働時間、失効サービス、ブランド認知、そして誤発行が真剣に扱われるという反復された証拠である。リブランドは所有権と戦略を明確にできるが、トラストアンカーの公開インシデント履歴を消去することはできない。

顧客にとって実践的な問いは、2011年の RA アカウントが2026年の直接的な技術リスクとして依然として関連するかどうかではない。おそらく、文字通りの意味ではそうではない。実践的な問いは、現代の CA が、委任発行、アカウントセキュリティ、高リスクドメイン、インシデント開示、証明書透明性ログ、失効サービス品質、ルートプログラムとのコミュニケーションに対して強力な統制を示せるかどうかである。歴史的な委任発行の失敗は、それらの統制がなぜ重要かの証拠である。

ルートプログラムにとって、歴史的な問いはさらに鋭い。大規模な発行フットプリントと多くの委任または自動化チャネルを持つ CA は、異常を迅速に検知し、問題が発生した際に公開インシデント報告を提供できることを証明しなければならない。Common CA Database は、部分的に CA とルートプログラムのコンプライアンスに関する公開情報を調整するために存在する。（CCADB）公開説明責任は、研究者、顧客、依拠当事者が孤立した声明ではなくパターンを評価するのに十分なほどインシデント報告と改善証拠が可視化されることで改善する。

継承問題は Sectigo に固有ではない。CA エコシステムは、誤発行、不十分な検証、侵害された中間認証局、監査の失敗、開示紛争を含む複数のインシデントを経験してきた。各インシデントは同じ不快な教訓を教える。ブラウザの信頼は粘着性が高く、CA を不信化するコストは高くなり得る。この粘着性が CA に経済的価値を与えるが、同時に信頼が損なわれた場合の証拠基準を引き上げる。

高価値ドメインは悪用の政治経済学を露呈する

影響を受けた名称は無作為ではなかった。Comodo と Microsoft の記録は、主要な通信・ID 宛先の証明書を特定している。Google、Yahoo、Skype、Mozilla アドオン、Microsoft Live、そして「Global Trustee」名である。これらの標的は、ユーザーが認証したり、信頼できるコードをダウンロードしたり、機密通信を受け取ったりする可能性のある場所であるがゆえに意味がある。

技術的リスクは中間者傍受である。経済的・政治的リスクは、他者が CA システムを悪用して被害者サービスの正統性を借用できることである。被害ドメイン所有者は自身のサーバーを保護し、HTTPS を強制し、秘密鍵を注意深く管理し、鍵アイコンを信頼するようユーザーを訓練していたかもしれない。信頼された CA によって発行された不正証明書は、トラフィックがネットワーク層で迂回または傍受された場合、そうした作業の多くを回避できる。

このため、DNS 委任権力が明示的に現れる。DNS と証明書は別個のシステムだが、ユーザーの「自分はどこにいるのか？」という感覚において収束する。DNS はユーザーをアドレスへルーティングできる。TLS 証明書は、エンドポイントがそのドメインに対して受け入れられたアイデンティティを提示できるかどうかをブラウザに伝える。どちらかのシステムが破壊されれば、ユーザーは危険にさらされる。両方が攻撃者または強制的なネットワーク環境によって影響を受け得るならば、リスクははるかに悪化する。

悪用連絡先の経済学は醜悪である。ドメイン所有者は、侵害された CA やリセラーから何も購入していないかもしれない。それでも自身の名称に対する不正証明書に対応しなければならない。ブラウザベンダーは発行を引き起こしていないかもしれない。それでも更新をプッシュしなければならない。ユーザーはすべて正しく行っていたかもしれない。それでも失効、ブラックリスト、プラットフォーム更新に依存する。低摩擦の発行市場から利益を得る当事者が、発行が失敗したときに緊急コストを負う当事者と常に同じとは限らない。

現代の CT 監視は、ドメイン所有者が無許可の証明書をより迅速に見るのを助けるが、可視性は経済学の一部にすぎない。誰かが依然としてログを監視し、アラートをトリアージし、CA に連絡し、失効を要求し、必要なら顧客に通知し、トラフィックが傍受され得たかどうかを評価しなければならない。大規模プラットフォームにとってはその作業は実現可能だが、小規模組織にとっては別の隠れたセキュリティ税である。小規模ドメインを含む CA インシデントは、その組織にとって、主要ドメインのインシデントがエコシステムにとって気まずいのと同じくらい存亡に関わりうる。

したがって、Comodo の事例は単に有名なインターネットブランドに関するだけではない。有名ブランドが事件を可視化した。同じ委任発行モデルが、はるかに少ない公開精査のもとで、反体制的なニュースサイト、小規模銀行、地方政府サービス、医療ポータル、ベンダーログインページを害することもあり得た。信頼システムは、標的が世界的に有名なときにどれだけ迅速に調整するかだけでなく、最も可視性の低い依拠当事者をいかに保護するかによって判断されなければならない。

優れたインシデント対応でも未回答の疑問は残った

Comodo の公開対応は有用な事実を含んでいた。日付、RA アカウント侵害、9件の証明書、ドメイン名とシリアル番号、即時失効、OCSP 監視文言、CA 基盤および HSM 非侵害の否定、そして後日の阻止された試みである。ブラウザとプラットフォームベンダーは公開アドバイザリを追加した。2011年当時としては、これは多くのインシデントよりも優れた記録である。

それでも公開記録は、説明責任にとって重要な未回答の問いを残している。RA アカウントの使用を許した正確な統制失敗は何か？3月15日の前後で、どのような認証と承認が要求されていたか？高リスクドメインチェックは存在したか、存在しなかったならなぜか？不正発行に気づいた監視は何か？証明書は失効前にどのくらいの期間存在していたか？どの当事者にどの順序で通知されたか？どのような独立監査証拠が統制をレビューしたか？委任パートナー関係はどうなったか？

これらの回答の一部は、ブラウザルートプログラムや監査人と非公開で共有されたかもしれない。機微な詳細を含む場合は非公開証拠が適切であり得る。しかし公共の信頼は完全に非公開で構築されるわけではない。意味のある改善の詳細がすべて機密であるならば、ユーザーと依拠当事者は CA の信頼性を評価できない。技芸は、攻撃者に操作マニュアルを渡すことなく、統制改善を示すのに十分な証拠を公開することである。

3月26日の阻止された試みは、このことを特に重要にする。Comodo は、後の試みの際に新しい統制が不正発行を防止したと述べた。これは強力で有用な主張である。しかし、一般市民はそれらの統制の簡潔な説明しか受け取らなかった。より堅牢な公開インシデント後の記録は、機微な詳細なしに統制のカテゴリを説明しただろう。すなわち、より強力なリセラー認証、発行異常検知、高リスクドメイン承認、パートナー資格情報ローテーション、監査レビュー、追加監視、ルートプログラム報告である。

教訓は、Comodo の公開対応が特異的に不十分だったということではない。CA インシデントは、通常のソフトウェア脆弱性とは異なる事後分析スタイルを要求するということである。ブラウザに信頼される CA は共有された ID 基盤の一部である。誤発行が生じた場合、その回復証拠は、自社の顧客だけでなく、契約を結んだことのないドメイン所有者、存在を聞いたこともないブラウザユーザー、そして下流の信頼結果を負うルートプログラムをも満足させなければならない。

このインシデントが信頼に関する対話をどのように変えたか

Comodo の出来事は、ウェブ PKI が CA の信頼を不可視のバックグラウンド配管として扱うことに対して、より消極的になりつつあったより広範な時期に位置づけられる。2011年はまた、DigiNotar の侵害ももたらした。これははるかに深刻な CA 障害であり、幅広い不信化につながった。こうした出来事が相まって、エコシステムをより強力な公開インシデント処理、CT、より優れたルートプログラム執行、より詳細なベースライン要件へと押し進めた。

Comodo だけがこれらの改革を引き起こしたと言うのは単純すぎるだろう。また、Comodo を除外するのも単純すぎる。この出来事は、委任された権限を通じた不正発行の明確な例を提供し、高価値ドメインを標的とし、緊急のブラウザおよび OS の対応を必要とした。それはまさに、隠れた信頼関係を可視化する種類のインシデントである。

今日の標準とポリシーの状況は、その変化を反映している。CA/Browser Forum ベースライン要件は、ドメイン検証と失効に対してより正式な公開ベースラインを提供している。Mozilla、Chromium、Apple、Microsoft はルートプログラムの期待を公開している。CT ログはドメイン所有者とブラウザに発行された証明書の公開データソースを提供している。CCADB はルートプログラムの調整と CA の公開情報を提供している。これらのメカニズムはどれも完璧ではないが、相まって CA がインシデントを単なるプライベートな顧客サービスの問題として扱うことをより困難にする。（CA/Browser Forum Baseline Requirements、CCADB、Chrome Certificate Transparency policy）

残された弱点は疲弊による説明責任である。エコシステムはポリシー、監査、バグスレッド、メーリングリストの投稿、インシデント報告、ルートプログラムの課題の洪水を生み出しうる。それらを注意深く読むのはごく小さなコミュニティだけである。これは透明性のパラドックスを生む。情報は公開されているかもしれないが、実践的な説明責任は依然としてそれを監視する時間のある専門家に依存する。CA は開示フォームを遵守しながら、より広範な公衆は何が間違っていたのかを理解できないままである。

Daniel Kade のリスクフレームは、誰が結果変数を掌握していたかを問うことによって、その書類作業を切り裂く。Comodo の事例では、その答えは神秘的ではない。Comodo は委任発行、リセラー認証、失効、公開対応を掌握していた。ブラウザとプラットフォームベンダーはローカルの不信化と更新を掌握していた。ルートプログラムは継続的収録を掌握していた。ドメイン所有者は監視と顧客コミュニケーションを掌握していた。攻撃者は悪意ある行為を掌握していた。ユーザーはほとんど何も掌握していなかった。

この最後の事実こそが、CA の説明責任が厳格でなければならない理由である。ユーザーは HTTPS を探し、警告を回避し、ブラウザを信頼するよう言われている。CA システムが上流で失敗したとき、ユーザーはリセラーアカウント、RA 侵害、OCSP レスポンダー、CRL、ブラックリスト、ルートプログラムの議論を検査できない。彼らは制度的統制に依拠している。制度的統制は制度的説明責任に値する。

委任発行のためのより良い説明責任テスト

次の委任発行インシデントのための真剣な説明責任テストは、証明書数よりも前に開始されるべきである。第一に、CA は、どの委任アカウントがどの証明書を、どのような認証の下で、どのような高リスク名制限と独立した承認をもって要求できるかを示せなければならない。第二に、CA は、主要プラットフォーム、機密ログイン名、公共部門ドメイン、金融サービス、ソフトウェア配布、医療システム、その他の高価値標的を含む要求に対する異常検知を示せなければならない。

第三に、CA は失効の速度と失効の信頼性を証明できなければならない。これは、単に証明書が失効されたと言うだけでなく、失効チェックが失敗またはブロックされた場合に依拠当事者がどのように保護されたかを説明することを意味する。ブラウザとプラットフォームベンダーは依然としてローカルの不信更新を必要とするかもしれないが、CA はそれらのベンダーに緊急連絡経路と証拠パッケージを準備しておくべきである。第四に、CA は、何が起こり、何が起こらず、何が不明のままであり、どの統制が変更されたかを述べる境界付きのインシデント報告を公開できなければならない。

第五に、ルートプログラムは、インシデント後に継続的信頼が適切である理由を説明できなければならない。その説明は非公開の監査記録を晒す必要はないが、レビューされた証拠のカテゴリ、すなわち封じ込め、パートナー統制、検証変更、監査フォローアップ、監視、失効サービス性能、インシデント透明性を述べるべきである。第六に、ドメイン所有者は、無許可の発行を監視し、アラートが現れたときに迅速に CA に連絡する実践的な手段を持つべきである。

Comodo インシデントは各ピースがなぜ重要かを示している。攻撃者は Comodo のルート鍵を必要としなかった。委任アカウントで十分だった。失効はブラウザと OS の対応の必要性を取り除かなかった。公開アドバイザリはパートナー統制に関するすべての疑問を取り除かなかった。少ない証明書数はインシデントを小さくしなかった。標的が ID 上重要なドメインであり、影響を受けた信頼がグローバルだったからである。

Sectigo にとって、継承された教訓は率直である。現代の認証局は、単に大規模に証明書を発行することだけでなく、いかなるパートナー、リセラー、自動化経路、サポートアカウントも、その規模を静かに公衆に対して向けられないことを証明することによって信頼を獲得する。歴史的なインシデントは永続的な罪ではない。それらは、設計によって対処され、監査され、監視され、説明されなければならない失敗モードの永続的な証拠である。

2011年の記録の最も防御可能な読み方は、パニックでも矮小化でもない。Comodo は不正証明書を検知し失効させ、自社のルート基盤は侵害されていないと述べた。それでも Mozilla と Microsoft は保護更新を配信しなければならなかった。攻撃者は、委任発行が主要ドメインに対してブラウザに信頼されるアイデンティティを創出できることを示した。エコシステムは、失効、ルート信頼、リセラー統制が別個のトピックではないことを学んだ。それらは一つの説明責任表面であった。

だからこそ、このインシデントは15年後もなおリスクと説明責任のシリーズに属している。可視的な産物は証明書だった。真の資産は、ブラウザがあるドメインを別のドメインから区別できるという公衆の信頼だった。一度その信頼が侵害された委任アカウントを通じて借用され得ると、問いはルート鍵が HSM 内で安全に保たれたかどうかではない。問いは、委任された信頼に対して実践的統制を持っていたすべての者が、グローバルな依存が要求する規律をもってそれを使用したかどうかである。