2011年に起こったComodo社/DigiNotar社の認証局からの証明書の不正発行事件を契機として、証明書発行時の審査方法やSSLにおける証明書の有効性の検証方法についての議論が盛んに行われるようになりました。
これらの議論から出てきた技術要素の中から、標準化に向けた議論が進んでいるものや、すでに一部のアプリケーションに実装されているものも出てきています。
今回から数回に分け、これらの技術要素の中から、いくつかピックアップして解説していきたいと思います。

DANEが考案された背景

今回ご紹介するのがDNS-based Authentication of Named Entities（DANE)です。ちなみにこれ、どう発音するのか、ぱっと見わかりづらいのですが、"デーン"と発音するのが正しいようです。
この技術が出てきた背景として、現在のSSLの標準的な実装である「信頼された認証局（トラストアンカー）のもとで発行された証明書は、すべてのドメインに対して有効である」という考え方に対する反省があります。

悪意を持った第三者は、証明書発行時の審査の甘さやシステムの脆弱性を持つ認証局を狙い、ドメイン所有者の関知することなく、そのドメインに対して、証明書を不正に発行し、中間者攻撃に利用してしまいます。

DANEの仕様について

DANEは、ドメイン（DNS）とそのドメインに証明書を発行する認証局あるいは発行された証明書そのものの紐づけを行い、上記のような事態を防ぐことを目的としています。

※ドメインと認証局のひも解けを明確にするという点については次回ご紹介するDNS Certification Authority Authorization(CAA)も基本的に同じです。

DANEについては、Use Caseと要求事項がRFC6394として2011年10月に、また仕様についてはRFC6698として2012年8月にRFC化されています。この中でDANEはDNS Security Extensions(DNSSEC)のオプションであると位置づけられており、DNSSECの使用が前提となっています。DNSSECによってDNSの信頼性が上がったので、ここにSSL証明書に関する情報も関連付けておけばいいじゃないか、ということですね。

DANEでは、DNSのリソースレコードの1つとして「TLSAレコード」というものを定義し、この中に証明書の情報を格納します。格納する証明書情報の種類はその用途に応じて以下の4種類が定義されています。

(1) CA証明書の情報　（CA constraint）

そのドメインに発行されたエンドエンティティ証明書（SSL証明書）の発行元CAの証明書情報（ちなみにここでいう「証明書情報」については、証明書そのもの、あるいはその公開鍵（あるいはそれらのハッシュ値）です）。
クライアント（主にWEBブラウザ）は、SSLハンドシェイクで取得したサーバの証明書のパス検証（証明書の階層の検証）を行い、証明書の階層の中にTLSAレコードに設定されたCA証明書が含まれていることを確認しなければなりません。
これによって、当該のドメインで使用されるべき証明書を発行する認証局（CA）を限定することが来出ます。

(2) エンドエンティティ証明書の情報（service certificate constraint）

そのドメインに発行されたエンドエンティティ証明書の情報。
クライアントは、SSLハンドシェイクで取得したサーバの証明書がTLSAレコードに設定された証明書と一致することを確認し、さらに通常の証明書のパス検証を行わなければなりません。
これによって、当該ドメインで使用されるべき証明書を限定することができます。

(3) トラストアンカーの証明書の情報（trust anchor assertion）

そのドメインに発行されたエンドエンティティ証明書のトラストアンカー（証明書階層の最上位に位置するCA）の証明書（SSL証明書）情報。
これによってブラウザ等のクライアントアプリケーションに「信頼されたルート認証局」として登録されていない、いわゆる「プライベートCA」から発行された証明書を使用することができるようになります。 クライアントは、SSLハンドシェイクで取得したサーバの証明書のパス検証を行い、トラストアンカーがTLSAレコードに設定された証明書と一致することを確認しなければなりません。

(4) 自己署名証明書の情報（domain-issued certificate）

そのドメインに発行された自己署名証明書（セルフサイン-いわゆる「オレオレ証明書」）の情報。
SSLハンドシェイクで取得したサーバの証明書がTLSAレコードに設定された証明書と一致することを確認する必要がありますが、証明書のパス検証は必要ありません。
これによって、自己署名証明書を信頼されるSSLサーバ証明書として使用することができるようになります。

このように、自分のドメインで使用できる証明書やその発行者を限定することで、他の認証局からの誤発行による、なりすましを防ぐことが可能になります。

DANE普及の条件

DANEの普及はクライアントアプリケーションであるWEBブラウザの実装に大きく依存します。Chromeが対応しているという噂があったのですが、私が調べた限りでは正式な対応なのかどうか確証を得られませんでした。また、FireFoxをDANEに対応させるアドインがあるということだったのですが、現状ではまだアルファ版レベルのものしかないようです（情報お持ちの方がいらっしゃればぜひ教えてください）。今後の動向に注目したいと思います。

次回はDNS Certification Authority Authorization(CAA)についてお話ししたいと思います。