ルート認証局がドメインの証明書の発行を許可されているのはなぜですか？
証明書のオーソリティが、任意のドメイン名についてブラウザーによって信頼された証明書を発行することを許可されているのはなぜですか？
ハイジャックされた1つのルート認証局が、ブラウザが信頼する信頼できる偽の証明書を発行できるという意味ではありません。これは、エンドユーザーの観点からはあまり安全ではありません。
たとえばDNS SECを介してドメイン名レコードの証明書への署名を許可および信頼するルート認証局を指定する方が安全ではありませんか？同様のDNSの例は、ドメインからのメール送信を許可するメールサーバーを指定するメールSPFレコードでもあります。
すべてのルートCAを信頼してドメイン名の証明書を発行するように設計されているのはなぜですか？
すべてのルートCAを信頼してドメイン名の証明書を発行するように設計されているのはなぜですか？
これには歴史的な理由があり、おそらく競争を促進する理由があります。最初は、非常に高額なルートCAがいくつかありました。すべてのCAが誰に対しても証明書を発行できるため、価格が下がりました。各CAがインターネットの特定の部分の証明書にのみ署名できる場合、この競争は不可能です。
インターネットプロトコルのさまざまな部分にあるこのような安全でない初期設計は、通常、オプションのセキュリティ、つまり証明書の固定、クロスサイトスクリプティングに対するコンテンツセキュリティポリシーなどを追加することで回避されます。もちろん、これらすべてがオプションのセキュリティを追加するだけです。したがって、めったに使用されません。一般的な考えは、それがなぜ気にせずに機能するということです。
たとえばDNS SECを介してドメイン名レコードの証明書への署名を許可および信頼するルート認証局を指定する方が安全ではありませんか？
メールセキュリティの分野でそれを使用するアイデアがあります [〜＃〜] dane [〜＃〜] は徐々にフォロワーを獲得しており、SSHまたは他のキーと証明書（またはフィンガープリント）。主な問題は、これらすべての証明書を配信するためにDNSSecに依存する前に、まずどこでもDNSSecを使用可能にする必要があるということです。しかし、現時点では、インターネットのほんの一部だけがDNSSecによって保護されています。また、多くのDNSリゾルバーはDNSSecをまったくまたは適切に処理せず、アプリケーションレベルでは通常、DNS応答の保護ステータスにもアクセスできません。
同様のDNSの例は、ドメインからのメール送信を許可するメールサーバーを指定するメールSPFレコードでもあります。
SPFまたはDKIMレコードはセキュリティにそれほど関係がないと見なされているため、保護されていないプレーンDNSを使用したこれらのレコードの配信は許容可能と見なされます。これは、完全に信頼できる応答が必要な証明書には当てはまりません。
DNSSECに依存することは、本質的には、CAからレジストラ（例：GoDaddyのような会社）、TLD（例：VeriSign）、およびルート（例：ICANN）への信頼の移転に相当します。 CAを信頼できる以上に、これらのエンティティを信頼できるかどうかはわかりません。この件に関する優れた記事については、Moxie Marlinspikeのブログ投稿を参照してください。 http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity
証明書に関する基本的な問題の1つに遭遇しました。これらは認証の形式ですが、承認には不十分です。私はあなたが誰であるか知っていますが、あなたは何に署名することが許可されていますか？そして、あなたと私はとにかく定義に同意しますか？
時間の経過とともに、さまざまなビットがX.509にハッキングされています。ビットは、コードに署名したり、TLSを介して暗号化したりできるかどうかを表します。しかし、「スコープ」という概念はありません。 「私はCAですが、example.comドメインの証明書にしか署名できません」とは異なります。それでも、実装の違いと解釈の違いがあります。
大きな問題の1つは、X.509が認証と承認を混乱させることです。ユーザーが実行できる一連の操作（データの署名、データの暗号化、証明書の発行、証明書の失効など）は明確に定義されていません。可能な制限（常に、決して、時には、承認があるなど）は定義されていません。操作の範囲（ドメイン、サブドメインなどに限定）が正しく定義されていません。
20〜30年前のシステムであり、その年齢を示しています。しかし、簡単な修正はありません。