m Disambiguating links to Dane (link changed to DNS-based Authentication of Named Entities) using DisamAssist. |
BrownHairedGirl (talk | contribs) remove links to deleted portals Tag: AWB |
||
Line 15: | Line 15: | ||
}} |
}} |
||
{{Internet security protocols}} |
{{Internet security protocols}} |
||
'''DNS Certification Authority Authorization''' ('''CAA''') is an [[Internet security]] policy mechanism which allows [[domain name]] holders to indicate to [[certificate authorities]] whether they are authorized to issue [[digital certificates]] for a particular [[domain name]]. It does this by means of a new "CAA" [[Domain Name System]] (DNS) [[resource record]]. |
'''DNS Certification Authority Authorization''' ('''CAA''') is an [[Internet security]] policy mechanism which allows [[domain name]] holders to indicate to [[certificate authorities]] whether they are authorized to issue [[digital certificates]] for a particular [[domain name]]. It does this by means of a new "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 [[Internet Engineering Task Force]] (IETF) [[Internet Standard#Proposed Standard|proposed standard]]. |
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 [[Internet Engineering Task Force]] (IETF) [[Internet Standard#Proposed Standard|proposed standard]]. |
||
== Background == |
== 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 arXiv|last=Ruohonen|first=Jukka|eprint=1804.07604|title=An Empirical Survey on the Early Adoption of DNS Certification Authority Authorization|class=cs.CR|date=April 20, 2018}}</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]], and CAA to block mis-issuance on the certificate authority side.<ref name="sigcomm2017" /> |
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 arXiv|last=Ruohonen|first=Jukka|eprint=1804.07604|title=An Empirical Survey on the Early Adoption of DNS Certification Authority Authorization|class=cs.CR|date=April 20, 2018}}</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]], 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|authorlink1=Phillip Hallam-Baker|last2=Stradling|first2=Rob|date=October 18, 2010|publisher=[[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|authorlink1=Phillip Hallam-Baker|last2=Stradling|first2=Rob|last3=Ben|first3=Laurie|authorlink3=Ben Laurie|date=June 2, 2011|publisher=[[Internet Engineering Task Force|IETF]]}}</ref> and submitted to 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|authorlink1=Phillip Hallam-Baker|last2=Stradling|first2=Rob|date=January 2013|publisher=[[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=[[GlobalSign]]|language=en|access-date=February 2, 2018}}</ref> At least one certificate authority, [[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|last=Scheitle|first=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|issn=0146-4833}}</ref> |
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|authorlink1=Phillip Hallam-Baker|last2=Stradling|first2=Rob|date=October 18, 2010|publisher=[[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|authorlink1=Phillip Hallam-Baker|last2=Stradling|first2=Rob|last3=Ben|first3=Laurie|authorlink3=Ben Laurie|date=June 2, 2011|publisher=[[Internet Engineering Task Force|IETF]]}}</ref> and submitted to 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|authorlink1=Phillip Hallam-Baker|last2=Stradling|first2=Rob|date=January 2013|publisher=[[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=[[GlobalSign]]|language=en|access-date=February 2, 2018}}</ref> At least one certificate authority, [[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|last=Scheitle|first=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|issn=0146-4833}}</ref> |
||
{{As of|2018|June}}, [[Qualys]] reports that still, only 3.4% 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=June 3, 2018|website=SSL Labs|publisher=[[Qualys]]|access-date=June 9, 2018}}</ref> |
{{As of|2018|June}}, [[Qualys]] reports that still, only 3.4% 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=June 3, 2018|website=SSL Labs|publisher=[[Qualys]]|access-date=June 9, 2018}}</ref> |
||
Line 64: | Line 64: | ||
== See also == |
== See also == |
||
{{Portal|Computer security}} |
|||
* [[Certificate authority#CA compromise|Certificate authority compromise]] |
* [[Certificate authority#CA compromise|Certificate authority compromise]] |
||
* [[Certificate Transparency]] |
* [[Certificate Transparency]] |
Revision as of 23:35, 9 July 2019
Abbreviation | CAA |
---|---|
Status | Proposed Standard |
First published | October 18, 2010 |
Latest version | RFC 6844 January 2013 |
Organization | IETF |
Authors |
|
Internet security protocols |
---|
Key management |
Application layer |
Domain Name System |
Internet Layer |
DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism which allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a new "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 Internet Engineering Task Force (IETF) proposed standard.
Background
A series of incorrectly issued certificates from 2001 onwards[1][2] damaged trust in publicly trusted certificate authorities,[3] and accelerated work on various security mechanisms, including Certificate Transparency to track mis-issuance, HTTP Public Key Pinning and DANE to block mis-issued certificates on the client-side, and CAA to block mis-issuance on the certificate authority side.[4]
The first draft of CAA was written by Phillip Hallam-Baker and Rob Stradling, and submitted as an IETF Internet Draft in October 2010.[5] This was progressively improved by the PKIX Working Group,[6] and submitted to the IESG as RFC 6844, a Proposed Standard, in January 2013.[7] CA/Browser Forum discussion began shortly afterward,[4] and in March 2017 they voted in favor of making CAA implementation mandatory for all certificate authorities by September 2017.[8][9] At least one certificate authority, Comodo, failed to implement CAA before the deadline.[10] A 2017 study by the Technical University of Munich found many instances where certificate authorities failed to correctly implement some part of the standard.[4]
As of June 2018[update], Qualys reports that still, only 3.4% of the 150,000 most popular TLS-supporting websites use CAA records.[11]
Record
Certificate authorities implementing CAA perform a 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.[7] Each CAA resource record consists of the following components, separated by whitespace:[7]
- flag
- A flags byte which implements an extensible signaling system for future use. As of 2018[update], only the issuer critical flag has been defined, which instructs certificate authorities that they must understand the corresponding property tag before issuing a certificate.[7] This flag allows the protocol to be extended in the future with mandatory extensions,[4] similar to 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 certificates, 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[update], not all certificate authorities support this tag, so there is no guarantee that all certificate issuances will be reported.
- 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.[7][9][12]
Third parties monitoring certificate authority behavior might check newly issued certificates against the domain's CAA records, but must be aware that a domain's CAA records may have changed between the time the certificate was issued and the time the third-party checks them. Clients must not use CAA as part of their certificate validation process.[7]
Extensions
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.[13] This was amended on August 30, 2017, to also include a new validation-methods token, which ties a domain to a specific validation method,[14] and then further amended on June 21, 2018 to remove the hyphen in account-uri and validation-methods making them instead accounturi and validationmethods.[15]
Examples
To indicate that only the certificate authority identified by ca.example.net is authorized to issue certificates for example.com and all subdomains, one may use this CAA record:[7]
example.com. IN CAA 0 issue "ca.example.net"
To disallow any certificate issuance, one may allow issuance only to an empty issuer list:
example.com. IN CAA 0 issue ";"
To indicate that certificate authorities should report invalid certificate requests to an email address and a Real-time Inter-network Defense endpoint:
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:
example.com. IN CAA 0 issue "ca.example.net" example.com. IN CAA 128 future "value"
See also
- Certificate authority compromise
- Certificate Transparency
- DNS-based Authentication of Named Entities
- HTTP Public Key Pinning
- List of DNS record types
References
- ^ Ristić, Ivan. "SSL/TLS and PKI History". Feisty Duck. Retrieved June 8, 2018.
- ^ Bright, Peter (August 30, 2011). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica. Retrieved February 10, 2018.
- ^ Ruohonen, Jukka (April 20, 2018). "An Empirical Survey on the Early Adoption of DNS Certification Authority Authorization". arXiv:1804.07604 [cs.CR].
- ^ a b c d Scheitle, Quirin; Chung, Taejoong; et al. (April 2018). "A First Look at Certification Authority Authorization (CAA)" (PDF). ACM SIGCOMM Computer Communication Review. 48 (2): 10–23. doi:10.1145/3213232.3213235. ISSN 0146-4833.
- ^ Hallam-Baker, Phillip; Stradling, Rob (October 18, 2010). DNS Certification Authority Authorization (CAA) Resource Record. IETF. I-D draft-hallambaker-donotissue-00.
- ^ Hallam-Baker, Phillip; Stradling, Rob; Ben, Laurie (June 2, 2011). DNS Certification Authority Authorization (CAA) Resource Record. IETF. I-D draft-ietf-pkix-caa-00.
- ^ a b c d e f g Hallam-Baker, Phillip; Stradling, Rob (January 2013). DNS Certification Authority Authorization (CAA) Resource Record. IETF. doi:10.17487/RFC6844. ISSN 2070-1721. RFC 6844.
- ^ Hall, Kirk (March 8, 2017). "Results on Ballot 187 - Make CAA Checking Mandatory". CA/Browser Forum. Retrieved January 7, 2018.
- ^ a b Beattie, Doug (August 22, 2017). "What is CAA (Certificate Authority Authorization)?". GlobalSign. Retrieved February 2, 2018.
- ^ Cimpanu, Catalin (September 11, 2017). "Comodo Caught Breaking New CAA Standard One Day After It Went Into Effect". Bleeping Computer. Retrieved January 8, 2018.
- ^ "SSL Pulse". SSL Labs. Qualys. June 3, 2018. Retrieved June 9, 2018.
- ^ "What is Certificate Authority Authorization (CAA)?". Symantec. Retrieved January 8, 2018.
- ^ Landau, Hugo (October 26, 2016). CAA Record Extensions for Account URI and ACME Method Binding. IETF. I-D draft-ietf-acme-caa-00.
- ^ Landau, Hugo (August 30, 2017). CAA Record Extensions for Account URI and ACME Method Binding. IETF. I-D draft-ietf-acme-caa-04.
- ^ Landau, Hugo (June 21, 2018). CAA Record Extensions for Account URI and ACME Method Binding. IETF. I-D draft-ietf-acme-caa-05.