Cannabis Ruderalis

thcscience_admin
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
61.69.15.66 (talk)
No edit summary
rm duplication between lede and immediately following
Tag: 2017 wikitext editor
Line 1: Line 1:
{{Use American English|date=January 2018}}
{{Use American English|date=January 2018}}
{{Use mdy dates|date=January 2018}}
{{Use mdy dates|date=January 2018}}
'''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 certificates for a particular [[domain name]] using a [[Domain Name System]] (DNS) [[resource record]]. It was written by [[Phillip Hallam-Baker]] and Rob Stradling in 2010 and is currently an [[Internet Engineering Task Force]] (IETF) [[Internet Standard#Proposed Standard|proposed standard]]. It is mandatory as of {{date|Sep 2017}} for publicly trusted certificate authorities to support CAA.
'''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 certificates for a particular [[domain name]] using a [[Domain Name System]] (DNS) [[resource record]]. It is currently an [[Internet Engineering Task Force]] (IETF) [[Internet Standard#Proposed Standard|proposed standard]].


== Background ==
== Background ==

Revision as of 16:40, 5 June 2018

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 certificates for a particular domain name using a Domain Name System (DNS) resource record. It is currently an Internet Engineering Task Force (IETF) proposed standard.

Background

The first draft of CAA was written by Phillip Hallam-Baker and Rob Stradling, and submitted as an IETF Internet Draft in October 2010.[1] In 2011, the certificate authorities Comodo and DigiNotar were compromised,[2] accelerating work on various mechanisms to prevent or monitor unauthorized certificate issuance, including Certificate Transparency as a mechanism to track mis-issuance, DANE as a mechanism to block mis-issued certificates on the client-side, and CAA as an additional verification layer on the certificate authority side. CAA was progressively improved by the PKIX Working Group,[3] and submitted to the IESG as RFC 6844, a Proposed Standard, in January 2013.[4] Initially the implementation of CAA was voluntary, however in March 2017 the CA/Browser Forum voted in favor of making CAA checking mandatory for all certificate authorities by September 2017.[5][6] At least one certificate authority, Comodo, failed to implement CAA before the deadline.[7] A 2017 study by the Technical University of Munich found many instances where certificate authorities failed to correctly implement some part of the standard.[8] As of April 2018, Qualys reports that 3.1% of the 150,000 most popular TLS-supporting websites use CAA records.[9]

Protocol

CAA implements a new type of DNS resource record which specifies which certificate authorities are authorized to issue certificates for a particular domain name, whether they are authorized to issue wildcard certificates, and how certificate authorities can report attempts to issue possibly fraudulent certificates. Certificate authorities implementing CAA are expected to perform a DNS lookup for CAA records, and ensure that a proposed certificate complies with those records prior to issuing it.

Each resource record consists of a flags byte, a property tag and a property value. As of 2018, the following properties are defined:[4]

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 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 to the domain name holder when a certificate is issued, or when a certificate is requested that violates the domain's CAA record. As of 2018, not all certificate authorities support this tag, so there is no guarantee that all certificate issuances will be reported.

The flags byte implements an extensible signalling 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.[4] This flag allows the protocol to be extended in the future with mandatory extensions,[8] similar to critical extensions in X.509 certificates.

Certificates authorities interpret the lack of a CAA record to authorize unrestricted issuance, and the presence of a single blank issue tag to disallow all issuance.[4][10] Third parties monitoring certificate authority behaviour 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.

Support

DNS server software that supports CAA
Software Supported Since version
BIND Yes 9.10.1B[11]
Knot DNS Yes 2.2.0[12][13]
ldns Yes 1.6.17[12]
NSD Yes 4.0.1[12][14]
OpenDNSSEC Yes [12]
PowerDNS Yes 4.0.0[12]
Simple DNS Plus Yes 6.0[12]
tinydns Yes [12]
Windows Server 2016 Yes [12]

Many hosted DNS providers also support CAA records, including Amazon Route 53,[15] Cloudflare, DNS Made Easy and Google Cloud DNS.[12]

Examples

To authorise the Let's Encrypt certificate authority to issue certificates for the domain example.com and all its subdomains, while restricting issuance by other certificate authorities, one may use this CAA record: 

example.com.  IN  CAA  0 issue "letsencrypt.org"

To disallow any certificate issuance, one would allow issuance only to an empty issuer list: 

example.com.  IN  CAA  0  issue ";"

When using a subdomain, certificate authorities climb the DNS name tree looking for a CAA record until they find one or reach the second-level domain: 

; Let's Encrypt will be permitted to issue certificates for example.com and certs.nocerts.example.com, but not nocerts.example.com
example.com.  IN  CAA  0 issue "letsencrypt.org"
nocerts.example.com.  IN  CAA  0 issue ";"
certs.nocerts.example.com.  IN  CAA  0 issue "letsencrypt.org"

If a record is empty, any CNAME or DNAME aliases are checked for a CAA record before moving up to a higher subdomain: 

; Let's Encrypt will be allowed to issue certificates for certs.example.com 
example.net.  IN  CAA  0  issue "letsencrypt.org"
example.com.  IN  CAA  0  issue ";"
certs.example.com  IN  CNAME  example.net

To authorise issuance for normal certificates, while restricting the issuance of wildcard certificates: 

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild ";"

To authorise issuance for example.com but not nocerts.example.com: 

example.com.  IN  CAA  0 issue "letsencrypt.org"
nocerts.example.com.  IN  CAA  0 issue ";"

To request that the certificate authority report policy violations by email or through RID messages: 

nocerts.example.com.  IN  CAA  0 iodef "mailto:caa@example.com"
nocerts.example.com.  IN  CAA  0 iodef "https://caa.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 "letsencrypt.org"
example.com.  IN  CAA  128 future "value"

See also

References

  1. ^ Hallam-Baker, Phillip; Stradling, Rob (October 18, 2010). DNS Certification Authority Authorization (CAA) Resource Record. IETF. I-D draft-hallambaker-donotissue-00.
  2. ^ Bright, Peter (August 30, 2011). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica. Retrieved February 10, 2018. {{cite news}}: Cite has empty unknown parameter: |dead-url= (help)
  3. ^ 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.
  4. ^ a b c d Hallam-Baker, Phillip; Stradling, Rob (January 2013). DNS Certification Authority Authorization (CAA) Resource Record. IETF. doi:10.17487/RFC6844. ISSN 2070-1721. RFC 6844.
  5. ^ Hall, Kirk (March 8, 2017). "Results on Ballot 187 - Make CAA Checking Mandatory". CA/Browser Forum. Retrieved January 7, 2018.
  6. ^ Beattie, Doug (August 22, 2017). "What is CAA (Certificate Authority Authorization)?". GlobalSign. Retrieved February 2, 2018.
  7. ^ Cimpanu, Catalin (September 11, 2017). "Comodo Caught Breaking New CAA Standard One Day After It Went Into Effect". Bleeping Computer. Retrieved January 8, 2018.
  8. ^ a b Scheitle, Quirin; Chung, Taejoong; et al. (2017). A First Look at Certification Authority Authorization (CAA) (PDF) (Technical report). Technical University of Munich.
  9. ^ "SSL Pulse". SSL Labs. Qualys. April 3, 2018. Retrieved April 15, 2018. {{cite web}}: Cite has empty unknown parameter: |dead-url= (help)
  10. ^ "What is Certificate Authority Authorization (CAA)?". Symantec. Retrieved January 8, 2018.
  11. ^ Risk, Vicky (August 29, 2014). "Certificate Authority Authorization Records". Internet Systems Consortium. Retrieved January 7, 2018.
  12. ^ a b c d e f g h i "Who Supports CAA Records?". SSLMate. Retrieved January 7, 2018.
  13. ^ Včelak, Jan (April 26, 2016). "Knot DNS 2.2.0 release". Retrieved January 7, 2018.
  14. ^ "Name Server Daemon (NSD) Releases". NLnet Labs. January 27, 2014. Retrieved January 7, 2018.
  15. ^ "Amazon Route 53 now supports CAA records". Amazon Web Services. August 21, 2017. Retrieved January 7, 2018.

External links

source: https://en.wikipedia.org/wiki/Special%3ADiff%2F844547694

Leave a Reply