Cannabis Ruderalis

Content deleted Content added
2001:559:c027:2:484e:75c8:b11a:91de (talk)
Pippin Bear (talk | contribs)
Corrections re how CAA records are intended (and specified) to be used
Line 1: Line 1:
'''DNS Certification Authority Authorization''' ('''CAA''') uses the [[Internet]]'s [[Domain Name System]] to specify which [[certificate authority|certificate authorities]] may be regarded as authoritative for a domain. This is intended to support additional cross-checking at the client end of [[Transport Layer Security|TLS]] connections{{dubious|date=November 2016}} to attempt to prevent certificates issued by CAs other than the specified CAs from being used to spoof the identity of websites or perform [[man-in-the-middle attack]]s on them.
'''DNS Certification Authority Authorization''' ('''CAA''') uses the [[Internet]]'s [[Domain Name System]] to allow the holder of a domain to specify which [[certificate authority|certificate authorities]] are allowed to issue certificates for that domain. This is not intended to support additional cross-checking at the client end of [[Transport Layer Security|TLS]] connections (rather, [[DANE]] is intended to be used for that purpose), but as a check for certificate authorities to carry out as part of their issuance procedures. CAA records are intended to allow CAs to avoid mis-issuing certificates in some circumstances, while DANE records are intended to allow relying applications (TLS clients) to avoid relying on mis-issued certificates in some circumstances.<ref>{{cite web|url=https://tools.ietf.org/html/rfc6844|title=RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record|publisher=Internet Engineering Task Force|author=P. Hallam-Baker and R. Stradling|date=January 2013}}</ref>


DNS Certification Authority Authorization is specified by RFC 6844. It defines a new "CAA" DNS Resource Record type for name-value pairs that can carry a wide range of information to be used as part of the CA authorization process. Use of CAA, where available, to validate certificates is recommended, but not mandatory. Furthermore the certificate evaluator should consider, that the CAA records may have changed in the time between the certificate was issued and the certificate is observed by the evaluator.<ref>{{cite web|url=https://tools.ietf.org/html/rfc6844|title=RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record|publisher=Internet Engineering Task Force|author=P. Hallam-Baker and R. Stradling|date=January 2013}}</ref>
DNS Certification Authority Authorization is specified by RFC 6844. It defines a new "CAA" DNS Resource Record type for name-value pairs that can carry a wide range of information to be used as part of the CA authorization process. It may also be possible for certificate evaluators to use CAA records to detect possible mis-issued certificates. However, the certificate evaluator should consider that the CAA records may have changed between the time the certificate was issued and the time the certificate is observed by the evaluator.<ref>{{cite web|url=https://tools.ietf.org/html/rfc6844|title=RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record|publisher=Internet Engineering Task Force|author=P. Hallam-Baker and R. Stradling|date=January 2013}}</ref>


== Structure of CAA resource record ==
== Structure of CAA resource record ==

Revision as of 16:48, 19 January 2017

DNS Certification Authority Authorization (CAA) uses the Internet's Domain Name System to allow the holder of a domain to specify which certificate authorities are allowed to issue certificates for that domain. This is not intended to support additional cross-checking at the client end of TLS connections (rather, DANE is intended to be used for that purpose), but as a check for certificate authorities to carry out as part of their issuance procedures. CAA records are intended to allow CAs to avoid mis-issuing certificates in some circumstances, while DANE records are intended to allow relying applications (TLS clients) to avoid relying on mis-issued certificates in some circumstances.[1]

DNS Certification Authority Authorization is specified by RFC 6844. It defines a new "CAA" DNS Resource Record type for name-value pairs that can carry a wide range of information to be used as part of the CA authorization process. It may also be possible for certificate evaluators to use CAA records to detect possible mis-issued certificates. However, the certificate evaluator should consider that the CAA records may have changed between the time the certificate was issued and the time the certificate is observed by the evaluator.[2]

Structure of CAA resource record

Each CAA resource record contains a flags byte and tag-value pair, hereafter referred to as property.[clarification needed]

Currently one flag is defined: Issuer Critical represented by the byte value '1'. If set, the "corresponding property tag must be understood if the semantics of the CAA record are to be correctly interpreted by an issuer."[3]

Besides the flag, three property tags are defined:

issue: This property authorizes the holder of the domain to issue certificates for the domain in which the property is published.

issuewild: This property acts like issue but allows wildcard certificates.

iodef: This property specifies a URL for reporting certificate issues. This is not mandatory for the client.

Supported Server

As of 2016, CAA records are supported in the BIND DNS server,[4] the NSD authoritative DNS server (as of version 4.0.1),[5] the Knot DNS server (since version 2.2.0).[6] and PowerDNS (since version 4.0.0).[7]

References

  1. ^ P. Hallam-Baker and R. Stradling (January 2013). "RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record". Internet Engineering Task Force.
  2. ^ P. Hallam-Baker and R. Stradling (January 2013). "RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record". Internet Engineering Task Force.
  3. ^ P. Hallam-Baker and R. Stradling (January 2013). "RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record". Internet Engineering Task Force.
  4. ^ Vicky Risk (August 29, 2014). "Certificate Authority Authorization Records". Internet Systems Consortium.
  5. ^ NLNet Labs (January 27, 2014). "NSD: Name Server Daemon Releases". NLNet Labs.
  6. ^ Včelak, Jan. "[knot-dns-users] Knot DNS 2.2.0 release". Retrieved 2016-04-26.
  7. ^ "Supported Record Types". PowerDNS.com.

See also


Leave a Reply