[Ach] Proposed contribution on CAA records

Maarten Van Horenbeeck maarten.vhb at gmail.com
Sat Jun 18 05:16:52 CEST 2016


Hi everyone,

I'd like to contribute some text around the use of CAA records, as this is
a helpful technology to improve an organization's use of X.509 PKI. Before
I do a pull request, I though I'd share my proposed text on the list for
discussion. Let me know if you have any edits or change requests, or if you
feel this is out of scope of the document.

Thanks!
Maarten


Proposed contribution:


*Certificate Authority Authorization Records (CAA)*



RFC 6844 describes Certification Authorization Records, a mechanism for
domain name owners to signal which Certificate Authorities are authorized
to issue certificates for their domain.



When a CAA record is defined for a particular domain, it specifies that the
domain owner requests Certificate Authorities to validate any request
against the CAA record. If the certificate issuer is not listed in the CAA
record, it should not issue the certificate.



The RFC also permits Certificate Evaluators to test an issued certificate
against the CAA record, but should exercise caution, as the CAA record may
change during the lifetime of a certificate, without affecting its
validity.



CAA also supports an iodef property type which can be requested by a
Certificate Authority to report certificate issue requests which are
inconsistent with the issuer’s Certificate Policy.



*Configuration*



*BIND supports CAA records as of version 9.9.6. *



A CAA record can be configured by adding it to the zone file:



$ORIGIN example.com

       CAA 0 issue "ca1.org"
       CAA 0 iodef “mailto:security at example.com”



If your organization uses multiple CA’s, you can configure multiple records:



      CAA 0 issue "ca1.org"

      CAA 0 issue "ca2.org"



“ca1.org” and “ca2.org” are unique identifiers for the CA you plan on
using. These strings can be obtained from your Certificate Authority, and
typically are its top level domain. An example is “letsencryptorg” for the
Let’s Encrypt CA operated by the Internet Security Research Group.



*Knot-DNS supports CAA records as of version 2.2.0.*



*Validation*



Once a CAA record is deployed, it can be validated using the following dig
query:



user at system:~$ dig CAA google.com



; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com



;; ANSWER SECTION:

google.com.          3600 IN   CAA  0 issue "symantec.com"




On older versions of Dig, which do not support CAA records, you can query
the record type manually:



dig +short -t TYPE257 google.com

\# 19 0005697373756573796D616E7465632E636F6D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20160618/6b980b1a/attachment.html>


More information about the Ach mailing list