> On 18.06.2016, at 12:57, Aaron Zauner <[email protected]> wrote:
>
>
>> 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.
>
+1
Thank you very much Maarten.
>
>>
>>
>> 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
>
> _______________________________________________
> Ach mailing list
> [email protected]
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
_______________________________________________
Ach mailing list
[email protected]
http://lists.cert.at/cgi-bin/mailman/listinfo/ach
