CAA レコードの役割
A 社は，自社のドメイン名で証明書が不正に発行されるリスクを減らすため，example.com の DNS ゾーンに次の CAA レコードを登録した。www.example.com には CAA レコードを登録していない。RFC 8659 に基づく CAA の扱いに関する記述として，適切なものはどれか。
example.com. 3600 IN CAA 0 issue "ca1.example.net"
example.com. 3600 IN CAA 0 iodef "mailto:pki@example.com"- アca2.example.org は，www.example.com の証明書の発行申請を受けた場合，親の example.com の CAA レコードが適用されるので，証明書を発行できない。
- イca1.example.net は，CAA で発行を許可されているので，申請者が www.example.com を管理していることを確認せずに証明書を発行してよい。
- ウca2.example.org が規定に反して www.example.com の証明書を発行した場合でも，Web ブラウザが TLS 接続時に CAA レコードを確認するので，その証明書は検証で拒否される。
- エca1.example.net が www.example.com の証明書を申請者の確認を経て正当に発行すると，iodef で指定した pki@example.com に発行の事実が通知される。
正解と解説を見る
正解 ア
この問題の基礎知識
- CAA レコードは，そのドメイン名の証明書を発行してよい CA をドメイン名の保有者が DNS で指定するもので，issue タグで発行を許可する CA を，iodef タグでポリシーに違反する申請や発行の報告先を指定する。
- CA は，証明書に記載する名前から親のドメインの方向へ順にたどり，最初に見つかった CAA レコードの集合を適用する。
- サーバ証明書を発行する CA は，発行前に申請者がそのドメイン名を管理していることを確認する。CAA の確認は，この確認に加えて CA が行う追加の管理策である。
- CAA は CA が発行前に行う認可の確認，DANE の TLSA レコードは利用者が接続時に行う証明書の検証，CT は発行された証明書を公開ログで監視する仕組みであり，確認する主体と時点が異なる。
アca2.example.org は，www.example.com の証明書の発行申請を受けた場合，親の example.com の CAA レコードが適用されるので，証明書を発行できない。正解
CA は発行前に，対象の名前から親の方向へたどって最初に見つかった CAA レコードの集合を適用する。www.example.com には無いので example.com の CAA レコードが適用され，issue で許可されていない ca2.example.org は発行できない。
イca1.example.net は，CAA で発行を許可されているので，申請者が www.example.com を管理していることを確認せずに証明書を発行してよい。
RFC 8659 は，CAA レコードへの適合は発行に必要な条件だが十分な条件ではないとしている。許可された CA であっても，証明書ポリシーに従って申請者のドメイン名の管理権限を確認する必要があり，CAA はその確認を代替しない。
ウca2.example.org が規定に反して www.example.com の証明書を発行した場合でも，Web ブラウザが TLS 接続時に CAA レコードを確認するので，その証明書は検証で拒否される。
CAA は CA が発行前に確認する仕組みであり，RFC 8659 は証明書の検証に CAA レコードを使ってはならないとしている。接続時に証明書を DNS の情報で検証する仕組みには，DANE の TLSA レコードがある。
エca1.example.net が www.example.com の証明書を申請者の確認を経て正当に発行すると，iodef で指定した pki@example.com に発行の事実が通知される。
iodef は，CA や名前の保有者のセキュリティポリシーに違反する発行の申請や発行を報告する手段を指定するものであり，正当な発行を通知する仕組みではない。発行の事実を把握するには Certificate Transparency（CT）のログを監視する方法がある。
検証用の出典出典照合済み
RFC 8659 DNS Certification Authority Authorization (CAA) Resource Record ／ RFC 6962 Certificate Transparency照合の根拠（7 件）
- ア（正解）: www.example.com に CAA が無ければ親の example.com の CAA RRset が適用される
The search for a CAA RRset climbs the DNS name tree from the specified label up to, but not including, the DNS root "." until a CAA RRset is found.
RFC 8659 · Section 3（新しいタブで開きます） - ア（正解）: issue で許可されていない ca2.example.org は発行してはならない
If such an RRset exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies.
RFC 8659 · Section 3（新しいタブで開きます） - イ（誤り）: CAA で許可されていても，それだけで発行してよいことにはならない
Conformance with a published CAA record is a necessary, but not sufficient, condition for the issuance of a certificate.
RFC 8659 · Section 1（新しいタブで開きます） - ウ（誤り）: Web ブラウザなどの Relying Party は証明書の検証に CAA を使ってはならない
Relying Parties MUST NOT use CAA records as part of certificate validation.
RFC 8659 · Section 1（新しいタブで開きます） - ウ（誤り）の解説: 発行後の検証の仕組みは DANE の TLSA レコード
The distinction between CAA and TLSA is that CAA records specify an authorization control to be performed by a CA before issuing a certificate and TLSA records specify a verification control to be performed by a Relying Party after the certificate is issued.
RFC 8659 · Section 1（新しいタブで開きます） - エ（誤り）: iodef はポリシー違反の申請・発行の報告手段であり，正当な発行の通知ではない
The iodef Property specifies a means of reporting certificate issue requests or cases of certificate issue for domains for which the Property appears in the Relevant RRset, when those requests or issuances violate the security policy of the Issuer or the FQDN holder.
RFC 8659 · Section 4.4（新しいタブで開きます） - エ（誤り）の解説: 発行の事実は CT ログの監視で把握できる
Those who are concerned about misissue can monitor the logs, asking them regularly for all new entries, and can thus check whether domains they are responsible for have had certificates issued that they did not expect.
RFC 6962 · Section 1（新しいタブで開きます）
イの解説の「ドメイン名の管理権限の確認」は RFC 8659 に直接の記述はないが，イは「必要条件だが十分条件ではない」（1 章）で誤りと判断できる。CT は RFC 9162（v2.0，RFC 6962 を廃止）にも同旨の記述があるが，運用されている CT ログの方式である RFC 6962 を出典にした。