単一の証明書/ CSRに署名する複数のCA？
スラッシュドット で提案されたこれを見た
だから私はかなり多くの人々が自己署名証明書への切り替えを望んでいる人たちを見てきました（IMOはほとんどの場合、それを安全にするために実際に必要なことを理解していません）、異なるネットワークパスからの証明書をチェックするという考え（これはうまくいかない場合）あなたの唯一の道は危険にさらされています、そしてあなたはあなたのためにチェックをするサービスへの通信をどのように安全にしますか？）.
したがって、代替案は次のとおりです。複数のCAが必要です。
同じプロバイダーからのより多くのサービスではなくより多くのお金である "拡張された検証"方法を行う代わりに、単一の証明書に複数のCA署名を付ける方がはるかに良いでしょう。
同じ期間内に複数のCAを危険にさらして証明書を作成することは、証明書を作成するよりもかなり困難です。さらに重要なことは、大規模なCAの取り消しがはるかに簡単になるということです。
新しい標準では、サイトの証明書に5つの異なるCAが署名することを想定しており、最小許容量は3つの署名です。
次に、Verisignが危険にさらされた場合、証明書をプルしても問題はありません。証明書の有効な署名は4つまで減少しますが、それでも問題ありません。これにより、CAのパフォーマンスが大幅に向上するはずです。
最大のCAでさえエンドユーザーが多くのことを気にする必要なく完全に使い捨てになるため、Verisignでさえ、セキュリティの問題が人気のために手放されるとは信じられません。サイトは、別の5番目のCAを使用して、完全な強度に戻ります。
これはうまくいくように思えます（ただし、バイナリ証明書の検証とは対照的に、セキュリティの評価は得られますが、検証されません）。実行可能性についてはどうですか？既存の標準の範囲内でそれを行うことができますか？複数のCAに同じCSRを発行し、一連の証明書全体をブラウザーに提供するかどうかを理解できません。複数のCAによって1つの証明書が順番に署名されているだけの場合。
SSL/TLSへの変更時：SSL/TLS プロトコルは、証明書を匿名のBLOBとして送信します。約16 MB（ばかげています）。新しい証明書形式を使用する場合は、プロトコル自体を変更する必要はありません。
SSL/TLS実装では、blobがエンコードされていることを想定しています X.509証明書 。このような証明書には、単一の発行者（CA名が記述されている）と単一の署名の余地があります。そのため、既存のX.509標準の範囲内で「マルチ署名証明書」を持つことはできません。あなたはcouldそれぞれに同じ公開鍵を使用して複数の証明書を取得し、SSLクライアントソフトウェアがサーバーに対して複数の証明書を受信することを気にしないように、ある種の規則のみが必要になります。それらすべてをチェックします。
証明書の発行について：a 証明書リクエストは、リクエスタの公開鍵とその意図された名前、および発行された証明書でCAが自由に複製できる、または複製できない種類の情報。個別のCAからの証明書であっても、名前と公開鍵がすべて含まれている場合は、理論上の問題はありません。実際、any CAは、ユーザーとの対話を必要とせずに、このような証明書を発行できます。それらはすべて同じ証明書要求を使用できます。 実際、既存のCAがWebベースのシナリオの一部として証明書を発行するため、いくつかの変更が必要になります。この場合、購入者のブラウザーは新しいキーペアを生成し、公開部分をCAに送信するように指示されます。人間のバイヤーとの相互作用なし。各サーバーに少なくとも3つの証明書を所有させるという考えは、基本的にサーバー証明書の市場を3倍にするので、商用CAはプラットフォームに関連する微調整を進んで実装するだろうと確信しています。
アイデアの健全性について：複数の検証を要求することは健全なアイデアです（ OpenPGP 形式はすでに対応しており、ほとんどの場合Web-of-trust CAの本質的な信頼性の欠如）が、逆効果の可能性があります。単一の不正または侵害されたCAが一般的なセキュリティに影響を与えない場合、次のComodoのようなイベントはあまり宣伝されない可能性があります。 。複数の検証は、一般的な寛大さと責任の喪失を助長する傾向があります。
収束について：スラッシュドットの引用について述べているのは 収束 です。これは足がかりを得ようとする新しいシステムです。プロトコルの詳細とポインタについては this answer を参照してください。
これは本当に良いアイデアだと思います。ただし、サポートするには新しいバージョンのSSLおよびTLSが必要です。現在のところ、トラストアンカーは1つだけであるという前提ですべてが設計されています。つまり、それはおそらく決して起こりません。私はWindows 98をサポートする必要があると主張する人々との議論をまだ持っています。
このアイデアがうまくいくかどうか疑わしい。 CAは、証明書の署名を自動化するために相互にAPIを必要とします。彼らは何をチェックしますか？彼らがお互いのリクエストをチェックしなければ、（ComodoやDigiNotarの場合のように）1つのCA APIへのアクセス権を取得したハッカーが勝つでしょう。 do CA間署名リクエストをチェックする場合、何をチェックすればよいですか？
マルチCAのアプローチで防止できるのは、2番目の署名CAが最初のCAが失敗したドメインにフラグを立てた場合に、攻撃者が* .google.comなどの注目度の高いドメインの証明書を取得することです。
ただし、個人的には、moxieのネットワークパースペクティブアプローチが好きです。特に、技術者のみのソリューションにすることなく、信頼の決定をユーザーの手に戻すためです。
より良い方法は、DNSSECとDANEの形ですでに作業に組み込まれています。現在のサイト証明書システムの主な脆弱性は、任意のCAが任意のドメイン名の証明書を発行できることです。したがって、ドメインを侵害するのに必要なCAは1つだけです。代わりに、特定のドメインのサイト証明書に署名するキーを指定できます。
https://tools.ietf.org/html/rfc6698 （DANE仕様）から：
「TLSが依存しているパブリックCAモデルは、これらのCAのいずれかが任意のドメイン名の証明書を発行することを可能にするため、根本的に脆弱です。その秘密と機能は、TLSで使用される証明書によって提供されるセキュリティを損なう可能性があります。この問題は、侵害されたCAが偽のキーを含む代替証明書を発行できるために発生します。複数の国の政府が何百万ものユーザーから信頼されている主要なTLSで保護されたWebサイトを盗聴または破壊しようとしているなど、セキュリティの問題。」
私はおそらく数年遅れていますが、とにかく...
頭に浮かぶ1つの問題は、mitmがクライアントが複数の証明書をネゴシエートできないようにし、ハッキングされたものだけをCAから取得できることです。
簡単なソリューションIMOは、別のポートを使用するか、または別のプロトコル名を作成して、クライアントが複数の証明書を取得する必要があることをクライアントに知らせることです。