View source for DNS Certification Authority Authorization

{{Short description|Internet security policy mechanism}}
{{Infobox technology standard
| status          = [[Internet Standard#Proposed Standard|Proposed Standard]]
| first_published = {{Start date|2010|10|18}}
| version         = {{IETF RFC|8659}}
| version_date    = November 2019
| organization    = [[Organization:Internet Engineering Task Force|IETF]]
| authors         = {{Plainlist|
* Phillip Hallam-Baker
* Rob Stradling
* Jacob Hoffman-Andrews
}}
| abbreviation    = CAA
}}
'''DNS Certification Authority Authorization''' ('''CAA''') is an [[Internet security]] policy mechanism that allows [[Domain name|domain name]] holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular [[Domain name|domain name]]. It does this by means of a "CAA" [[Domain Name System]] (DNS) resource record.

It was drafted by computer scientists Phillip Hallam-Baker and Rob Stradling in response to increasing concerns about the security of publicly trusted certificate authorities. It is an [[Organization:Internet Engineering Task Force|Internet Engineering Task Force]] (IETF) [[Internet Standard#Proposed Standard|proposed standard]].

== Background ==
A [[Certificate authority#CA compromise|series of incorrectly issued certificates]] from 2001 onwards<ref name="feistyduck">{{Cite web|url=https://www.feistyduck.com/ssl-tls-and-pki-history/|title=SSL/TLS and PKI History|last=Ristić|first=Ivan|website=Feisty Duck|language=en|access-date=June 8, 2018}}</ref><ref name="arstechnica2011">{{Cite news|url=https://arstechnica.com/information-technology/2011/08/earlier-this-year-an-iranian/|title=Another fraudulent certificate raises the same old questions about certificate authorities|last=Bright|first=Peter|date=August 30, 2011|work=[[Ars Technica]]|access-date=February 10, 2018|language=en-us}}</ref> damaged trust in publicly trusted certificate authorities,<ref name="ruohonen2018">{{Cite journal|last=Ruohonen|first=Jukka|arxiv=1804.07604|title=An Empirical Survey on the Early Adoption of DNS Certification Authority Authorization|journal=Journal of Cyber Security Technology|year=2019|volume=3|issue=4|pages=205–218|doi=10.1080/23742917.2019.1632249|s2cid=5027899}}</ref> and accelerated work on various security mechanisms, including [[Certificate Transparency]] to track mis-issuance, [[HTTP Public Key Pinning]] and [[DNS-based Authentication of Named Entities|DANE]] to block mis-issued certificates on the [[Client-side|client-side]], and CAA to block mis-issuance on the certificate authority side.<ref name="sigcomm2017" />

The first draft of CAA was written by Phillip Hallam-Baker and Rob Stradling, and submitted as an IETF Internet Draft in October 2010.<ref name="draft-hallambaker-donotissue-00">{{Cite IETF|title=DNS Certification Authority Authorization (CAA) Resource Record|draft=draft-hallambaker-donotissue-00|last1=Hallam-Baker|first1=Phillip|last2=Stradling|first2=Rob|date=October 18, 2010|publisher=[[Organization:Internet Engineering Task Force|IETF]]}}</ref> This was progressively improved by the [[X.509#PKIX Working Group|PKIX Working Group]],<ref name="draft-ietf-pkix-caa-00">{{Cite IETF|title=DNS Certification Authority Authorization (CAA) Resource Record|draft=draft-ietf-pkix-caa-00|last1=Hallam-Baker|first1=Phillip|author-link1=Phillip Hallam-Baker|last2=Stradling|first2=Rob|last3=Ben|first3=Laurie|author-link3=Ben Laurie|date=June 2, 2011|publisher=[[Organization:Internet Engineering Task Force|IETF]]}}</ref> and approved by the IESG as {{IETF RFC|6844}}, a [[Internet Standard#Proposed Standard|Proposed Standard]], in January 2013.<ref name="rfc6844">{{Cite IETF|title=DNS Certification Authority Authorization (CAA) Resource Record|rfc=6844|last1=Hallam-Baker|first1=Phillip|author-link1=Phillip Hallam-Baker|last2=Stradling|first2=Rob|date=January 2013|publisher=[[Organization:Internet Engineering Task Force|IETF]]|doi=10.17487/RFC6844|issn=2070-1721}}</ref> CA/Browser Forum discussion began shortly afterward,<ref name="sigcomm2017" /> and in March 2017 they voted in favor of making CAA implementation mandatory for all certificate authorities by September 2017.<ref name="cab2017">{{Cite web|url=https://cabforum.org/pipermail/public/2017-March/009988.html|title=Results on Ballot 187 - Make CAA Checking Mandatory|last=Hall|first=Kirk|date=March 8, 2017|publisher=CA/Browser Forum|access-date=January 7, 2018}}</ref><ref name="globalsign2017">{{Cite web|url=https://www.globalsign.com/en/blog/what-is-certificate-authority-authorization-checking/|title=What is CAA (Certificate Authority Authorization)?|last=Beattie|first=Doug|date=August 22, 2017|website=[[Company:GlobalSign|GlobalSign]]|language=en|access-date=February 2, 2018}}</ref> At least one certificate authority, [[Company:Comodo Group|Comodo]], failed to implement CAA before the deadline.<ref name="bleepingcomputer2017">{{Cite news|url=https://www.bleepingcomputer.com/news/security/comodo-caught-breaking-new-caa-standard-one-day-after-it-went-into-effect/|title=Comodo Caught Breaking New CAA Standard One Day After It Went Into Effect|last=Cimpanu|first=Catalin|date=September 11, 2017|work=[[Bleeping Computer]]|access-date=January 8, 2018|language=en}}</ref> A 2017 study by the Technical University of Munich found many instances where certificate authorities failed to correctly implement some part of the standard.<ref name="sigcomm2017">{{Cite journal|last1=Scheitle|first1=Quirin|last2=Chung|first2=Taejoong|last3=Hiller|first3=Jens|last4=Gasser|first4=Oliver|last5=Naab|first5=Johannes|last6=van Rijswijk-Deij|first6=Roland|last7=Hohlfeld|first7=Oliver|last8=Holz|first8=Ralph|last9=Choffnes|first9=Dave|last10=Alan|first10=Mislove|last11=Carle|first11=Georg|display-authors=2|date=April 2018|title=A First Look at Certification Authority Authorization (CAA)|url=https://ccronline.sigcomm.org/wp-content/uploads/2018/05/sigcomm-ccr-final163.pdf|journal=ACM SIGCOMM Computer Communication Review|volume=48|issue=2|pages=10–23|doi=10.1145/3213232.3213235|s2cid=13988123|issn=0146-4833}}</ref>

In September 2017, Jacob Hoffman-Andrews submitted an Internet Draft intended to simplify the CAA standard. This was improved by the LAMPS Working Group, and approved as {{IETF RFC|8659}}, a Proposed Standard, in November 2019.<ref name="rfc8659">{{Cite IETF|title=DNS Certification Authority Authorization (CAA) Resource Record|rfc=8659|date=November 2019|publisher=[[Organization:Internet Engineering Task Force|IETF]]|doi=10.17487/RFC8659|issn=2070-1721}}</ref>

{{As of|2020|January}}, [[Company:Qualys|Qualys]] reports that still, only 6.8% of the 150,000 most popular [[Transport Layer Security|TLS]]-supporting websites use CAA records.<ref name="ssllabs">{{Cite web|url=https://www.ssllabs.com/ssl-pulse/|title=SSL Pulse|date=January 3, 2020|website=SSL Labs|publisher=[[Company:Qualys|Qualys]]|access-date=January 31, 2020}}</ref>

== Record ==
Certificate authorities implementing CAA perform a [[Domain Name System|DNS]] lookup for CAA resource records, and if any are found, ensure that they are listed as an authorized party before issuing a digital certificate. Each CAA resource record consists of the following components:<ref name="rfc8659" />
; flag : A flags byte which implements an extensible signaling system for future use. {{As of|2018}}, only the ''issuer critical'' flag has been defined, which instructs certificate authorities that they must understand the corresponding property tag before issuing a certificate.<ref name="rfc8659" /> This flag allows the protocol to be extended in the future with mandatory extensions,<ref name="sigcomm2017" /> similar to [[X.509#Structure of a certificate|critical extensions in X.509 certificates]].
; tag :One of the following property:
:; issue: This property authorizes the holder of the domain specified in associated property value to issue certificates for the domain for which the property is published.
:; issuewild :This property acts like ''issue'' but only authorizes the issuance of [[Wildcard certificate|wildcard certificate]]s, and takes precedence over the ''issue'' property for wildcard certificate requests.
:; iodef : This property specifies a method for certificate authorities to report invalid certificate requests to the domain name holder using the [[Incident Object Description Exchange Format]]. {{As of|2018}}, not all certificate authorities support this tag, so there is no guarantee that all certificate issuances will be reported.
:; contactemail : Increasingly, contact information is not available in WHOIS due to concerns about potential GDPR violations. This property allows domain holders to publish contact information in DNS.<ref>{{Cite web|title=Public Key Infrastructure using X.509 (PKIX) Parameters|url=https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa-properties|access-date=2020-08-22|website=www.iana.org}}</ref><ref>https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf {{Bare URL PDF|date=March 2022}}</ref>
:; contactphone : As above, for phone numbers.<ref>{{Cite mailing list|url=https://archive.cabforum.org/pipermail/public/2019-January/014498.html|title=Ballot SC14: CAA Contact Property and Associated Phone Validation Methods|date=January 7, 2019|access-date=October 19, 2020|mailing-list=CA/Browser Forum|last=Beattie|first=Doug}}</ref>

; value: The value associated with the chosen property tag.

The lack of any CAA records authorizes normal unrestricted issuance, and the presence of a single blank ''issue'' tag disallows all issuance.<ref name="rfc8659" /><ref name="globalsign2017" /><ref name="symantec">{{Cite web|url=https://www.websecurity.symantec.com/security-topics/what-is-certificate-authority-authorization|title=What is Certificate Authority Authorization (CAA)?|website=[[Company:NortonLifeLock|Symantec]]|access-date=January 8, 2018}}</ref>

Third parties monitoring certificate authority behavior might check newly issued certificates against the domain's CAA records. {{IETF RFC|8659}} states; CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation. Such use SHOULD take into account the possibility that published CAA records changed between the time a certificate was issued and the time at which the certificate was observed by the Certificate Evaluator.<ref name="rfc8659" />

== Extensions ==
{{IETF RFC|8657}} specifies <code>"accounturi"</code> and <code>"validationmethods"</code> parameters which allow users to specify desired methods of domain control validation as defined in [[Automated Certificate Management Environment|ACME protocol]]. For example, website administrator can bind a domain they control to particular account registered with their desired Certification Authority.

=== History ===
A draft of the first extension to the CAA standard was published on October 26, 2016, proposing a new ''account-uri'' token to the end of the ''issue'' property, which ties a domain to a specific [[Automated Certificate Management Environment]] account.<ref name="draft-ietf-acme-caa-00">{{Cite IETF|title=CAA Record Extensions for Account URI and ACME Method Binding|draft=draft-ietf-acme-caa-00|last1=Landau|first1=Hugo|date=October 26, 2016|publisher=[[Organization:Internet Engineering Task Force|IETF]]}}</ref> This was amended on August 30, 2017, to also include a new ''validation-methods'' token, which ties a domain to a specific validation method,<ref name="draft-ietf-acme-caa-04">{{Cite IETF|title=CAA Record Extensions for Account URI and ACME Method Binding|draft=draft-ietf-acme-caa-04|last1=Landau|first1=Hugo|date=August 30, 2017|publisher=[[Organization:Internet Engineering Task Force|IETF]]}}</ref> and then further amended on June 21, 2018, to remove the hyphen in ''account-uri'' and ''validation-methods'' making them instead ''accounturi'' and ''validationmethods''.<ref name="draft-ietf-acme-caa-05">{{Cite IETF|title=CAA Record Extensions for Account URI and ACME Method Binding|draft=draft-ietf-acme-caa-05|last1=Landau|first1=Hugo|date=June 21, 2018|publisher=[[Organization:Internet Engineering Task Force|IETF]]}}</ref>

== Examples ==
To indicate that only the certificate authority identified by ''ca.example.net'' is authorized to issue certificates for [[Example.com|example.com]] and all subdomains, one may use this CAA record:<ref name="rfc8659" />
{{sxhl|2=zone|
example.com.  IN  CAA 0 issue "ca.example.net"
}}
To disallow any certificate issuance, one may allow issuance only to an empty issuer list:
{{sxhl|2=zone|
example.com.  IN  CAA  0 issue ";"
}}
To indicate that certificate authorities should report invalid certificate requests to an [[Email address|email address]] and a Real-time Inter-network Defense endpoint:

{{sxhl|2=zone|
example.com.  IN  CAA 0 iodef "mailto:security@example.com"
example.com.  IN  CAA 0 iodef "http://iodef.example.com/"
}}

To use a future extension of the protocol, for example, one which defines a new ''future'' property, which needs to be understood by the certificate authority before they can safely proceed, one may set the ''issuer critical'' flag:
{{sxhl|2=zone|
example.com.  IN  CAA  0 issue "ca.example.net"
example.com.  IN  CAA  128 future "value"
}}

== Incidents ==
In 2017, Camerfirma was found to improperly validate CAA records. Camerfirma claimed to have misunderstood the CA/Browser Forum Baseline Requirements describing CAA validation.<ref>{{Cite web|title=CA:Camerfirma Issues - MozillaWiki|url=https://wiki.mozilla.org/CA:Camerfirma_Issues#Issue_F:_Ignoring_CAA_based_on_another_CA.27s_Certificate_Transparency_disclosure_.28Nov._2017.29|access-date=2021-04-27|website=wiki.mozilla.org}}</ref><ref name="sigcomm2017" />

In early 2020, [[Organization:Let's Encrypt|Let's Encrypt]] disclosed that their software improperly queried and validated CAA records potentially affecting over 3 million certificates.<ref>{{Cite web|last=Claburn|first=Thomas|date=3 March 2020|title=Let's Encrypt? Let's revoke 3 million HTTPS certificates on Wednesday, more like: Check code loop blunder strikes|url=https://www.theregister.com/2020/03/03/lets_encrypt_cert_revocation/|url-status=live|access-date=2021-04-27|website=www.theregister.com|language=en|archive-url=https://web.archive.org/web/20200531124914/https://www.theregister.com/2020/03/03/lets_encrypt_cert_revocation/ |archive-date=May 31, 2020 }}</ref> Let's Encrypt worked with customers and site operators to replace over 1.7 million certificates, but decided not to revoke the rest to avoid client downtime and since the affected certificates would all expire in less than 90 days.<ref>{{Cite magazine|last=Barrett|first=Brian|date=3 March 2020|title=The Internet Avoided a Minor Disaster Last Week|language=en-US|magazine=Wired|url=https://www.wired.com/story/lets-encrypt-internet-calamity-that-wasnt/|access-date=2021-04-27|issn=1059-1028}}</ref>

== See also ==
* [[Certificate authority#CA compromise|Certificate authority compromise]]
* [[Certificate Transparency]]
* [[DNS-based Authentication of Named Entities]]
* [[HTTP Public Key Pinning]]
* [[List of DNS record types]]

== References ==
{{Reflist}}

== External links ==
* {{IETF RFC|8659}}
* [https://ccadb-public.secure.force.com/ccadb/AllCAAIdentifiersReport List of CA identifiers for use in CAA records] at Common CA Database

{{SSL/TLS}}

[[Category:Transport Layer Security]]
[[Category:Domain Name System]]

{{Sourceattribution|DNS Certification Authority Authorization}}