!!! Overview [1] [{$pagename}] ([CAA]), specified in [RFC 6844] in [2013|Year 2013], allows a [DNS] [domain name|DNS Domain] holder to specify one or more [Certification Authorities|Certificate Authority] ([CAs]) authorized to issue [certificates] for that [DNS Domain]. [{$pagename}] [DNS Resource Records] allow a public [Certificate Authority] to implement additional controls to reduce the [risk] of unintended [certificate] mis-issue. [RFC 6844] defines the syntax of the CAA record and rules for processing CAA records by [certificate] issuers. [{$pagename}] is part of the [Identity Proofing] during the [Credential Enrollment] process. [{$pagename}] is a proposal to improve the strength of the [Public Key Infrastructure] ecosystem with a new control to restrict which [CA]s can issue certificates for a particular domain name for during the [Certificate Request Process] !! September [2017|Year 2017] Although CAA had been in the proposed-standard state for more than 4 years, there was little obvious happening until very recently, with only a hundred or two hundred sites adopting it. But that’s going to change, because the [Certification Authority Browser Forum] recently voted to mandate [CAA] support as part of its [certificate] issuance standard Baseline Requirements. The changes will become effective in __September [2017|Year 2017].__ !! [CAA] RR Type A [CAA] [RR] consists of a flags byte and a tag-value pair referred to as a property. Multiple properties MAY be associated with the same domain name by publishing multiple CAA RRs at that domain name. The following flag is defined: * Issuer Critical: If set to '1', indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer. Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set. ! [Examples] for [CAA] RR Type * CAA 0 issue "ca.example.net" * CAA 0 iodef "mailto:security@example.com" * CAA 0 iodef "http://iodef.example.com/" In the following [examples], assume that we want to control certificate issuance for the domain [example.com]. To signify that only the CA Let's Encrypt can issue certificates to the domain, as well as all of its subdomains, one may use the CAA record %%prettify {{{ example.com. IN CAA 0 issue "letsencrypt.org" }}} /% To disallow issuance for a specific subdomain, nocerts.example.com, one would allow issuance only to the empty issuer list, %%prettify {{{ nocerts.example.com. IN CAA 0 issue ";" }}} /% In this case, in a request to issue a certificate to nocerts.example.com, the relevant CA will stop its search for RAA records at the subdomain. To signify that the CA may report certificate issues or policy violations by email to caa@example.com, or through RID messages to caa.example.com, the iodef property may be applied as follows: %%prettify {{{ nocerts.example.com. IN CAA 0 issue ";" nocerts.example.com. IN CAA 0 iodef "mailto:caa@example.com" nocerts.example.com. IN CAA 0 iodef "https://caa.example.com" }}} /% If, in the original example, we would like to allow issuance to specific domains, but disallow issuance of any wildcard certificates, the issuewild property may be applied: %%prettify {{{ example.com. IN CAA 0 issue "letsencrypt.org" example.com. IN CAA 0 issuewild ";" }}} /% The critical flag is intended for usage when future inclusions of new properties may impact issuance. If, for example, a future version of CAA would include the tag "future", then the record set %%prettify {{{ example.com. IN CAA 0 issue "letsencrypt.org" example.com. IN CAA 128 future "Some value" }}} /% would result in __no issuance__, if the [CA] does not know how to parse the record, for instance if it has not yet updated its parsing engine to the new version. !! More Information There might be more information for this subject on one of the following: [{ReferringPagesPlugin before='*' after='\n' }] ---- * [#1] - [DNS_Certification_Authority_Authorization|Wikipedia:DNS_Certification_Authority_Authorization|target='_blank'] - based on information obtained 2017-10-30-