DNS Certification Authority Authorization (CAA)

ウェブサイトセキュリティ業界動向

2013年08月23日 2023年07月26日

前回に引き続き、SSLに関連する新しい技術についてご紹介したいと思います。
今回ご紹介するのは「DNS Certification Authority Authorization (CAA)」です。

DANEとCAAの違い
CAAの仕様について
CAA普及の条件

DANEとCAAの違い

CAAの基本的な考え方は、DNSレコードの中にそのドメインに対して証明書を発行できる認証局の情報を記述し、意図しない認証局からの証明書の誤発行を防ごうというものです。この考え方は前回ご紹介したDANEに非常によく似ています。では、DANEとCAAの間にはどのような違いがあるのでしょうか。

CAAは今年(2013年)の1月にRFC6844としてRFC化されていますが、この中にDANEとCAAの違いを説明する記述がありますので、ちょっと長くなりますが引用しましょう。ご紹介するDNS Certification Authority Authorization(CAA)も基本的に同じです。

Like the TLSA record defined in DNS-Based Authentication of Named Entities (DANE) [RFC6698], CAA records are used as a part of a mechanism for checking PKIX certificate data. The distinction between the two specifications is that CAA records specify an authorization control to be performed by a certificate issuer before issue of a certificate and TLSA records specify a verification control to be performed by a relying party after the certificate is issued.

(訳)
RFC6698のDANEで定義されているTLSAレコードと同様に、CAAレコードも証明書データの検証メカニズムの一部として使用されます。両者の違いは、CAAレコードは証明書発行前に証明書発行者によって行われる審査コントロールとして定義されているのに対し、TLSAレコードは証明書発行後に信頼者によって行われる検証コントロールとして定義されていることです。

少しわかりにくいですが、一言で言ってしまえば「CAAは認証局が利用するもの、DANEは信頼者が利用するもの」という違いがあるということです。
「信頼者」とは、たとえばWEBサイトの閲覧者であり、そのサイトに設定された証明書に基づいてそのサイトを信頼するかどうか判断する人（またはアプリケーション）のことです。DANEは、この信頼者が閲覧しているサイトに設定された証明書の信頼性を検証するための手段として提供されます。
これに対しCAAは、認証局があるドメインに対する証明書の発行依頼を受けた際、自分がそのドメインに対する正当な証明書発行者として登録されているかどうかを確認することによって、その申請が正当なドメイン所有者からのものであるかどうかを判断するための手段として提供されます。DANEでは証明書の誤発行そのものを止めることはできないが、CAAではそれができる、ということですね。

さらに、このRFCには明確に以下のような記述があります。

Relying Applications MUST NOT use CAA records as part of certificate validation.

(訳)
信頼者側のアプリケーションは、CAAレコードを証明書検証の一部として使用してはなりません。

この理由について、RFCでは「ある一時点において、これからそのドメインに対して証明書を発行すべき認証局と、その時点で使用されている証明書を発行した認証局が一致しない場合があるから」と言っています。
証明書には通常有効期間が設定されています。たとえばあるドメインで1年有効期間を持つ証明書を利用している場合、管理者は有効期限の1か月くらい前には新しい証明書を発行したいと考えるでしょう。この時に管理者が、新しい証明書は前回と異なる認証局から発行したいと考えたらどうなるでしょうか。管理者は、DNSのCAAレコードを新しい認証局の情報に書き換えたうえで、その認証局に対して証明書の発行を要求する必要があります。この時点で、CAAレコードの認証局の情報は、現時点で使用している証明書を発行した認証局とは一致しなくなります。もし信頼者がこの情報に基づいて現在の証明書を検証しようとすると、正当な証明書であるにもかかわらず検証に失敗するという結果になってしまいます。
このような矛盾を防ぐため、信頼者が証明書の検証にCAAレコードを使用することを禁じているのです。

CAAの仕様について

CAAレコードは、「フラグ」「タグ」「値」の3つの要素によって構成されます。

フラグ（Issuer Critical)

当該CAAレコードがクリティカルか否かを表します。もしこのフラグの値が'1'(Critical)であった場合、認証局は後続のタグを正しく解釈し、もし解釈できないタグであった場合には証明書を発行してはなりません。

issue	当該ドメインに対して証明書を発行すべき認証局が所有しているドメインを「値」として定義します。
issuewild	当該ドメインに対してワイルドカード証明書を発行すべき認証局が所有しているドメインを「値」として定義します。
iodef	認証局がCAAレコードの定義と矛盾する証明書発行要求を受けた際に、その旨を連絡する連絡先のURLを「値」として定義します。

ワイルドカード証明書とは、発行先として"*.example.com"のような指定がされている証明書です。この場合、この証明書はexample.comのすべてのサブドメイン（例えば、www.example.com, ssl.example.com, mail.example.com....等)に対して有効な証明書としてみなされます。便利な反面、誤発行による被害は甚大です。ですから、issuewildタグを定義することによってワイルドカード証明書の発行の可否をドメインの管理者がコントロールできるようにしているのです。

以下は、example.comのすべてのサブドメインについて、ca.example.netというドメインを所有している認証局のみに証明書の発行を許し、もしほかの認証局が当該ドメインについての証明書発行要求を受けた場合の通知先のEmailアドレスおよびWEBのURLについて定義しているDNSゾーンファイルの例です。

$ORIGIN example.com
　　　CAA 0 issue "ca.example.net"
　　　CAA 0 iodef "mailto:security@example.com"
　　　CAA 0 iodef "http://iodef.example.com/"

CAA普及の条件

前回、DANEの普及の条件が、クライアントアプリケーションであるWEBブラウザへの実装であることをご説明しました。これに対しCAAを使用するのは認証局だけですので、認証局のソフトウェアがCAAレコードのチェックロジックを実装すればよく、クライアント側のアプリケーションには何も影響を及ぼしません。
このことから、一般的にCAAの普及は比較的早期に実現可能であると考えられており、以前当ブログでもご紹介したCA/Browser Forumにおいても、その実装方法について活発に議論されています。

また機会があれば実装の進捗状況などについてもお話ししたいと思います。