なぜ公開鍵証明書は「トラストアンカー」なのですか？これにより、単一障害点が発生しますか？

Question

ルートCAの現在使用されている概念（主にSSL/TLSコンテキスト）を見ると、単一障害点の脆弱性を確認できます。つまり、秘密鍵が公開されると、自動的にチェーン全体が失われます。

トラストチェーントポロジの現在の状態
CA trust chain

つまり、ルートCA証明書として宣言された1つの自己署名証明書で開始し（ http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x160.html を参照）、署名します。その他の証明書（必ずしも中間ではない）

ルートCA証明書の秘密鍵を開示すると、チェーン全体を無効にする必要があります。

可能なリングトポロジ
Ring CA topology

私は、双方向の署名付き証明書があり、各CAが少なくとも他の2つによって署名されているトポロジについて考えます。これにより、次のような証明書のセキュリティパラメータが強化される可能性があります。

単一のCAの侵害は、チェーン全体の取り消しを意味しません（CA_1の侵害は、CA_2またはCA_3のチェーン全体を削除しません）
偽のCAを作成するには、少なくとも2つを偽造する必要があるため、有効なチェーンを作成できます。

だから質問は：

公開鍵証明書の作成者がSPoFの脆弱なチェーンを使用するようになった原因は何ですか？
何かありますか、リングトポロジーにありませんか？

NRCocker · Accepted Answer

すべてのルートCAは自己署名されています。つまり、CAが責任を持って安全に運用されていることを暗黙のうちに信頼することを余儀なくされています。これは常に当てはまるわけではありません（ Diginotar ）。

認証局の方法に代わるものがあります。これらの1つは web of trust で、主にPGPで使用されます/ [〜＃〜] gpg [〜＃〜] / OpenPGP 実装。

PKIの実装では、1つのPKIが別のPKIを「信頼」する必要がある状況が発生する可能性があります。これは相互署名または相互認証と呼ばれます。

PKIの主要なコンポーネントの1つは LDAPディレクトリサービスです。ここでは、署名済みの証明書と失効情報が公開されて公開されます。ディレクトリはツリー構造の形式をとります。ツリーの各エントリは、エントリの識別名（DName）の一部を形成します。たとえば、CN = NRC、OU = IT、O = MyOrg、C = GBです。このDNameでは、ルート要素は国であるCで、組織の場合はOが続き、OU、組織単位、および共通名のCNが続きます。各DName要素は、特定のスキーマオブジェクトクラスを持つディレクトリツリーのエントリです。オブジェクトクラスは、エントリの必須属性とオプション属性を定義します。 CN要素は通常、inetorgpersonと呼ばれるスキーマオブジェクトクラスによってLDAP用語で表されますが、PKIのために特殊なタイプが開発されています。 PKIオブジェクトの完全なLDAPスキーマが定義されていますここ。

これには、PKI CAオブジェクトクラスの定義が含まれます。これには、crossCertificatePair属性が含まれます。この属性を使用すると、CAの追加の証明書を（図のように）別のCAから発行できます。つまり、コアCA証明書は自己署名されていますが、相互認証の目的では、そのトラストアンカーは別のルートCAです。実際、RootCA1がRootCA2の相互認証証明書に署名する場合、RootCA2もRootCA1の相互認証証明書に署名する可能性があります。実際、あなたが質問で指定したように、相互認証を介して、RootCA1がRootCA2に署名し、RootCA2がRootCA3に署名し、RootCA3がRootCA1に署名するリング状況になる可能性があります。相互認証されたCAの検証では、認証プロセスがCAのLDAPエントリで相互認証された証明書を検索する必要があります。これは、ルートCA証明書（自己署名「コア」証明書）では参照されないためです。 Subject Information Access 拡張子のCAのLDAPエントリへの参照。

相互認証を考慮すると、証明書パスの検証は非常に複雑なプロセスになる可能性があります。ただし、ユーザーが複雑なプロセスを信頼できる検証機関に「外部委託」できるようにする特殊なソフトウェアサービスが開発されています。これらのサービスはオンライン証明書ステータスプロトコルおよびサーバーベースの証明書検証プロトコルサーバーと呼ばれます。 Axway VA は、OCSPとSCVPの両方を1つに含むサーバーであり、相互認証されたCA環境で完全な証明書パス検証を提供するように構成できます。

user2497624 · Answer

いろいろな理由が考えられます。最初のものは、経済的です。効果的には、認定の取得にはコストがかかります。チェーンの上位にいるほど、コストが高くなります。使用すると、理論的には興味深いかもしれませんが、企業の2倍のコストがかかります（CAはサービスを販売する経済的なエンティティであり、無料で提供することはありません）。いくつかの研究はあなたのソリューションをさらに推し進め、P2P認証さえ提案しましたこれについて説明する1つの論文です。ただし、分散型認証（集中型ではなく）の問題は、規範とルールの制御と確立が難しいことです。

最後に、あなたが提案するソリューションを見ると、それに固有の問題がいくつかあります。少なくとも、あなたがそれを提示する方法では、CA-3はCA-1を証明する階層はなく、その逆も同様ですが、明らかに1つはより高い権限である必要があり、1つはより低い権限によって証明することができません。