私はただ疑問に思っていました。多くのSSL証明書を使用します。最近では、ほとんど専らletsencryptを使用しています（ありがとう！）。これらの証明書の要点は、証明書のドメイン名の所有権の証明は、これらのドメインの下でDNSレコードまたはWebサイトを操作する力に由来するということです。DNS証明は、いくつかのキー（letsencryptで指定）をTXTレコードとしてDNSに追加することから得られます。

したがって、ドメインのDNSレコードを変更できる十分な証拠であれば、DNSのフィンガープリントで自己署名証明書を使用してみませんか？

DNSベースのletsencrypt（およびその他のCA）の手順とまったく同じ信頼性が得られると思います。

1. 自己署名CAを作成します（さまざまな方法の手順に従うだけです）
2. いくつかのドメインの証明書を作成します
3. 手順1のCAを使用して手順2の証明書に署名します。これで、信頼されていないCAによって署名された基本証明書が作成されました。
4. TXT（または専用）レコードを各ドメインのDNSに追加して、このCAでこのドメインの証明書に署名したことを示します。いいね： 'CA = -fingerpint of CA-'
5. ブラウザは証明書をダウンロードし、CAのフィンガープリントとCA証明書を特定のドメインのDNS内のデータと比較することにより、証明書を検証します。

これにより、基本的なSSL証明書と同じ信頼レベルで、第三者の干渉なしに信頼できる自己署名証明書を作成できます。DNSにアクセスできる限り、証明書は有効です。暗号化などのDNSSECを追加して、CAとSOAレコードからハッシュを作成し、DNSレコードの変更で信頼が失われるようにすることもできます。

これは以前に考慮されましたか？

ジェルマー

これを可能にする基本インフラストラクチャが存在し、DNSベースの名前付きエンティティの認証（DANE）と呼ばれ、RFC6698で指定されています。これTLSAは、エンドエンティティの証明書またはその公開キー、またはチェーン内のCAの1つを指定するリソースレコードによって機能します（実際には4つの異なるタイプがあります。詳細についてはRFCを参照してください）。

可決

しかし、DANEはまだ広く採用されていません。VeriSignはDNSSECとDANEの採用を監視し、その成長を追跡します。

比較のために、VeriSignによると、約270万のDNSゾーンが存在するため、すべてのゾーンの1％以上が少なくとも1つのTLSAレコードを持っています。

正式な答えを出すことはできません。なぜDANEなのか、私の推測は次のとおりです。

DANEは、証明書失効リスト（CRL）およびオンライン証明書ステータスプロトコル（OCSP）と同じ問題に悩まされています。提示された証明書の有効性を検証するには、第三者に連絡する必要があります。HannoBöck が、なぜこれが実際に大きな問題であるのか、良い概要を説明します。要するに、あなたが第三者に連絡できないとき、何をすべきかという問題です。この場合、ブラウザベンダーはソフトフェイル（許可）を選択しましたが、全体がかなり無意味になり、Chromeは最終的に2012年にOCSPを無効にすることを決定しました。

DNSSEC

おそらくDNSはCAのCRLおよびOCSPサーバーよりもはるかに優れた可用性を提供しますが、それでもオフライン検証を不可能にします。さらに、DANEは、DNSSECと組み合わせてのみ使用する必要があります。通常のDNSは認証されていないUDP上で動作するため、偽造やMITM攻撃などの傾向があります。DNSSECの採用はDANEの採用よりもはるかに優れていますが、ユビキタスではありません。

そして、DNSSECを使用すると、ソフトフェールの問題に再び遭遇します。私の知る限りでは、主要なサーバー/クライアントオペレーティングシステムはデフォルトで検証DNSSECリゾルバーを提供していません。

次に、失効の問題もあります。DNSSECには失効メカニズムがなく、代わりに短命のキーに依存します。

ソフトウェアサポート

参加するすべてのソフトウェアは、DANEサポートを実装する必要があります。

理論的には、これは暗号ライブラリの仕事であり、アプリケーション開発者は多くのことを行う必要はないと思うかもしれませんが、実際には、暗号ライブラリは通常プリミティブのみを提供し、アプリケーションは多くの構成とセットアップを自分で行う必要があります（そして残念なことに、物事を間違える多くの方法があります）。

たとえば、主要なWebサーバー（Apacheやnginxなど）がDANEを実装しているか、それを行う計画があるかどうかはわかりません。ここでは、Webサーバーが特に重要です。これは、Webテクノロジー上に構築されるものが増えているため、多くの場合、それらが最初に実装される場所であるためです。

CRL、OCSP、およびOCSP Staplingを比較として見ると、DANE導入のストーリーがどのように進むかを推測できる場合があります。OpenSSL、libnss、GnuTLSなどを使用するアプリケーションの一部のみがこれらの機能をサポートしています。Apacheやnginxのような主要なソフトウェアがそれをサポートするのに少し時間がかかり、再びHannoBöckの記事を参照すると、それは間違ってしまい、実装に欠陥がありました。PostfixやDovecotなどの他の主要なソフトウェアプロジェクトはOCSPをサポートしていませんそして、基本的にファイルシステム内のファイルを指す非常に限られたCRL機能を持っています（定期的に再読み込みする必要はないため、手動でサーバーをリロードする必要があります）。これらは頻繁にTLSを使用するプロジェクトであることに注意してください。次に、たとえばPostgreSQL / MySQLなど、TLSがあまり一般的ではなく、せいぜいCRLを提供するようなものを調べ始めることができます。

したがって、私は最新のWebサーバーでさえも実装しておらず、他のほとんどのソフトウェアはOCSPとCRLを実装することすらできていません。5年間のエンタープライズアプリケーションまたはアプライアンスで幸運を祈ります。

潜在的なアプリケーション

では、実際にどこでDANEを使用できますか？現在のところ、一般的なインターネット上ではありません。サーバーとクライアントを制御する場合は、オプションかもしれませんが、この場合、多くの場合、公開キー固定に頼ることができます。

SMTPは最長の期間、認証されたトランスポート暗号化を一切備えていなかったため、メール空間では、DANEが何らかの牽引力を得ています。SMTPサーバーは時々TLSを相互に使用していましたが、証明書の名前が実際に一致したことを確認しませんでした。現在、DANEを介してこれを確認し始めています。

さまざまな種類の証明書検証手順

通常のCA署名付き証明書では、いくつかのレベルの証明書検証があります。

• ドメイン検証（DV）
  ドメイン名の所有権のみが検証され、ドメイン名のみが証明書に「サブジェクト」として表示されます
• 組織の検証（OV）
  ドメイン名と所有者名が検証され、ドメイン名と所有者名が証明書に「サブジェクト」として表示される
• Extended Validation（EV）
  所有者エンティティ、ドメイン名、所有者名のより厳密な検証は、証明書に「Subject」として表示され、所有者名の付いた緑色のバー

記述し、代替を提案するプロセスは、最低レベルのドメイン検証（DV）にのみ適用されます。

DVは、LetsEncryptが行ったことのように、検証が比較的簡単に自動化できるレベルであり、DNSがトラストアンカーの唯一のソースとして使用された場合に提供できるものと同様の信頼レベルを提供します（UIの意味、証明書信頼されているが、検証されていない追加データが含まれている）。

名前付きエンティティのDNSベースの認証（DANE）

DANEは、DNSSECの上に構築され（DNSデータの信頼性が重要であるため）、DNSのTLSクライアントの信頼アンカー情報を公開します。

これは、使用TLSARRタイプを、証明書または公開鍵（どちらか識別するために使用することができるセレクタと、あるいはまた（成功するために定期的に証明書チェーンの検証を必要とせずに、エンドエンティティまたはCAのいずれか）を証明書の使用を）方法とCERT / keyデータはレコードで表されます（一致するタイプ）。

TLSAレコード所有者名、ポート、およびプロトコル（例えばを示す接頭有する_443._tcp）とRDATAを示しcert usage、selectorそしてmatching type一致する証明書/鍵データに加えてモード。これらのパラメーターの詳細については、RFC6698のセクション2.1を参照してください。

TLSAこのような例を見てのために記録することができます：

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

使用モード2または3（TLSAトラストアンカーのみの使用を示す）を使用すると、DANE対応クライアントは、一般的に信頼されているCAによって署名されていないが、TLSAレコードと一致する証明書を受け入れます。
これは、概念的には質問で提案したものと同じです。

キャッチ？現在、DANE対応クライアントは多かれ少なかれ存在しません。1つの問題は、DNSSEC自体が、DANEが離陸するためにおそらく必要とされるほど広く展開されていないことです（特にクライアントマシンでの検証）。DANEは認証されたDNSデータに依存する最初の潜在的に大きな新しいユースケースの1つであることを考えると、おそらく鶏肉と卵の問題のようです。

DNSSECとDANEの検証を追加するブラウザプラグインがありますが、この時点でメインストリームの近くにあるものはあまりありません。そして、ネイティブにサポートされているのではなくプラグインであるため、一般的な使用に関しては、他の何よりも概念実証としての役割を果たします。

できた 検討されています。それでも起こる可能性はありますが、それほど大きな動きはありません。