Cannabis Ruderalis

thcscience_admin
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Renamed user Y7tw0Ef0XR (talk | contribs)
407 edits
Tag: 2017 wikitext editor
Copyedit (major)
Line 1: Line 1:
'''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 name=rfc6844>{{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''' ('''CAA''') uses the [[Internet]]'s [[Domain Name System]] to allow the holder of a domain to specify which [[certificate authorities]] (CAs) 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, [[DNS-based Authentication of Named Entities]] – DANE – is intended to be used for that purpose), but as a check for CAs 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 name=rfc6844>{{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 name=rfc6844 />
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 name=rfc6844 />


== Structure of CAA resource record ==
== Structure of CAA resource record ==
Line 7: Line 7:
Each CAA resource record contains a flags byte and a property. The flags byte contains flags which can influence the interpretation of the record. The property consists of a "tag" which allows selection between several kinds of CAA record, and a "value" string whose meaning depends on the choice of tag.
Each CAA resource record contains a flags byte and a property. The flags byte contains flags which can influence the interpretation of the record. The property consists of a "tag" which allows selection between several kinds of CAA record, and a "value" string whose meaning depends on the choice of tag.


Currently one flag is defined: the ''Issuer Critical'' flag is represented by the most significant bit of the flags byte. If the Issuer Critical flag's value is 1 (that is, a flags byte equal to 128), this indicates that a CA which does not understand or does not implement the property tag in this record should refuse to issue a certificate for the domain.<ref name=rfc6844 /> This is similar to the way [[X.509#Structure_of_a_certificate|critical extensions in X509 certificates]] work.
Currently one flag is defined: the ''issuer critical'' flag is represented by the most significant bit of the flag's byte. If the issuer-critical flag's value is 1 (that is, a flags byte equal to 128), this indicates that a CA which does not understand or does not implement the property tag in this record should refuse to issue a certificate for the domain.<ref name=rfc6844 /> This is similar to the way [[X.509#Structure_of_a_certificate|critical extensions in X509 certificates]] work.


Besides the flag, three property tags are defined:
Besides the flag, three property tags are defined:


'''issue''': This property authorizes the holder of the domain specified in the "value" field to issue certificates for the domain for which the property is published.
; issue : This property authorizes the holder of the domain specified in the "value" field to issue certificates for the domain for which the property is published.
⚫
; issuewild : This property acts like ''issue'' but allows wildcard certificates.
⚫
; iodef : This property specifies a method for CAs to report to the domain holder when a certificate is issued. Not all CAs support this tag, so there is no guarantee that all certificate issuances will be reported.


== Supporting servers ==
⚫
'''issuewild''': This property acts like ''issue'' but allows wildcard certificates.

⚫
'''iodef''': This property specifies a method for CAs to report to the domain holder when a certificate is issued. Not all CAs support this tag, so there is no guarantee that all certificate issuances will be reported.

== Supported Server ==


{{As of|2016}}, CAA records are supported in the [[BIND]] DNS server,<ref>{{cite web|url=https://www.isc.org/blogs/certificate-authority-authorization-records/|title=Certificate Authority Authorization Records|publisher=Internet Systems Consortium|date=August 29, 2014|author=Vicky Risk}}</ref> the [[NSD]] authoritative DNS server (as of version 4.0.1),<ref>{{cite web|url=http://www.nlnetlabs.nl/projects/nsd/index.html#releases|title=NSD: Name Server Daemon Releases|publisher=NLNet Labs|date=January 27, 2014|author=NLNet Labs}}</ref> the [[Knot DNS]] server (since version 2.2.0).<ref>{{Cite web|url=https://lists.nic.cz/pipermail/knot-dns-users/2016-April/000853.html|title=[knot-dns-users] Knot DNS 2.2.0 release|last=Včelak|first=Jan|access-date=2016-04-26}}</ref> and [[PowerDNS]] (since version 4.0.0).<ref>{{cite web|url=https://doc.powerdns.com/md/types/|title=Supported Record Types|publisher=PowerDNS.com}}</ref>
{{As of|2016}}, CAA records are supported in the [[BIND]] DNS server,<ref>{{cite web|url=https://www.isc.org/blogs/certificate-authority-authorization-records/|title=Certificate Authority Authorization Records|publisher=Internet Systems Consortium|date=August 29, 2014|author=Vicky Risk}}</ref> the [[NSD]] authoritative DNS server (as of version 4.0.1),<ref>{{cite web|url=http://www.nlnetlabs.nl/projects/nsd/index.html#releases|title=NSD: Name Server Daemon Releases|publisher=NLNet Labs|date=January 27, 2014|author=NLNet Labs}}</ref> the [[Knot DNS]] server (since version 2.2.0).<ref>{{Cite web|url=https://lists.nic.cz/pipermail/knot-dns-users/2016-April/000853.html|title=[knot-dns-users] Knot DNS 2.2.0 release|last=Včelak|first=Jan|access-date=2016-04-26}}</ref> and [[PowerDNS]] (since version 4.0.0).<ref>{{cite web|url=https://doc.powerdns.com/md/types/|title=Supported Record Types|publisher=PowerDNS.com}}</ref>

Revision as of 21:41, 15 February 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 (CAs) 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, DNS-based Authentication of Named Entities – DANE – is intended to be used for that purpose), but as a check for CAs 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.[1]

Structure of CAA resource record

Each CAA resource record contains a flags byte and a property. The flags byte contains flags which can influence the interpretation of the record. The property consists of a "tag" which allows selection between several kinds of CAA record, and a "value" string whose meaning depends on the choice of tag.

Currently one flag is defined: the issuer critical flag is represented by the most significant bit of the flag's byte. If the issuer-critical flag's value is 1 (that is, a flags byte equal to 128), this indicates that a CA which does not understand or does not implement the property tag in this record should refuse to issue a certificate for the domain.[1] This is similar to the way critical extensions in X509 certificates work.

Besides the flag, three property tags are defined:

issue
This property authorizes the holder of the domain specified in the "value" field to issue certificates for the domain for which the property is published.
issuewild
This property acts like issue but allows wildcard certificates.
iodef
This property specifies a method for CAs to report to the domain holder when a certificate is issued. Not all CAs support this tag, so there is no guarantee that all certificate issuances will be reported.

Supporting servers

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

References

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

See also

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

Leave a Reply