> On 18 Jun 2016, at 11:16, Maarten Van Horenbeeck <[email protected]> 
> 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:[email protected]
> 
> 
> 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@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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Ach mailing list
[email protected]
http://lists.cert.at/cgi-bin/mailman/listinfo/ach

Reply via email to