[Ach] Proposed contribution on CAA records

[Aaron Zauner]

> On 18 Jun 2016, at 11:16, Maarten Van Horenbeeck <maarten.vhb at gmail.com> wrote:
> 
> 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:

Excellent 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

Would you be willing to open a Pull Request on GitHub for that? If not we'll find someone to typeset this for you.

Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20160618/459f7861/attachment.sig>