5Internet Engineering Task Force (IETF) P. Hallam-Baker
6Request for Comments: 8659 Venture Cryptography
7Obsoletes: 6844 R. Stradling
8Category: Standards Track Sectigo
9ISSN: 2070-1721 J. Hoffman-Andrews
14 DNS Certification Authority Authorization (CAA) Resource Record
19 allows a DNS domain name holder to specify one or more Certification
20 Authorities (CAs) authorized to issue certificates for that domain
21 name. CAA Resource Records allow a public CA to implement additional
22 controls to reduce the risk of unintended certificate mis-issue.
23 This document defines the syntax of the CAA record and rules for
24 processing CAA records by CAs.
26 This document obsoletes RFC 6844.
30 This is an Internet Standards Track document.
32 This document is a product of the Internet Engineering Task Force
33 (IETF). It represents the consensus of the IETF community. It has
34 received public review and has been approved for publication by the
35 Internet Engineering Steering Group (IESG). Further information on
36 Internet Standards is available in Section 2 of RFC 7841.
38 Information about the current status of this document, any errata,
39 and how to provide feedback on it may be obtained at
40 https://www.rfc-editor.org/info/rfc8659.
44 Copyright (c) 2019 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (https://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
61 2.1. Requirements Language
63 3. Relevant Resource Record Set
66 4.1.1. Canonical Presentation Format
67 4.2. CAA issue Property
68 4.3. CAA issuewild Property
69 4.4. CAA iodef Property
71 5. Security Considerations
72 5.1. Use of DNS Security
73 5.2. Non-compliance by Certification Authority
74 5.3. Mis-Issue by Authorized Certification Authority
75 5.4. Suppression or Spoofing of CAA Records
76 5.5. Denial of Service
77 5.6. Abuse of the Critical Flag
78 6. Deployment Considerations
79 6.1. Blocked Queries or Responses
80 6.2. Rejected Queries and Malformed Responses
81 6.3. Delegation to Private Nameservers
82 6.4. Bogus DNSSEC Responses
83 7. Differences from RFC 6844
84 8. IANA Considerations
86 9.1. Normative References
87 9.2. Informative References
93 The Certification Authority Authorization (CAA) DNS Resource Record
94 allows a DNS domain name holder to specify the Certification
95 Authorities (CAs) authorized to issue certificates for that domain
96 name. Publication of CAA Resource Records allows a public CA to
97 implement additional controls to reduce the risk of unintended
98 certificate mis-issue.
100 Like the TLSA record defined in DNS-Based Authentication of Named
101 Entities (DANE) [RFC6698], CAA records are used as a part of a
102 mechanism for checking PKIX [RFC6698] certificate data. The
103 distinction between CAA and TLSA is that CAA records specify an
104 authorization control to be performed by a CA before issuing a
105 certificate and TLSA records specify a verification control to be
106 performed by a Relying Party after the certificate is issued.
108 Conformance with a published CAA record is a necessary, but not
109 sufficient, condition for the issuance of a certificate.
111 Criteria for the inclusion of embedded trust anchor certificates in
112 applications are outside the scope of this document. Typically, such
113 criteria require the CA to publish a Certification Practices
114 Statement (CPS) that specifies how the requirements of the
115 Certificate Policy (CP) are achieved. It is also common for a CA to
116 engage an independent third-party auditor to prepare an annual audit
117 statement of its performance against its CPS.
119 A set of CAA records describes only current grants of authority to
120 issue certificates for the corresponding DNS domain name. Since
121 certificates are valid for a period of time, it is possible that a
122 certificate that is not conformant with the CAA records currently
123 published was conformant with the CAA records published at the time
124 that the certificate was issued. Relying Parties MUST NOT use CAA
125 records as part of certificate validation.
127 CAA records MAY be used by Certificate Evaluators as a possible
128 indicator of a security policy violation. Such use SHOULD take into
129 account the possibility that published CAA records changed between
130 the time a certificate was issued and the time at which the
131 certificate was observed by the Certificate Evaluator.
1352.1. Requirements Language
137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
139 "OPTIONAL" in this document are to be interpreted as described in
140 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
141 capitals, as shown here.
145 The following terms are used in this document:
147 Certificate: An X.509 Certificate, as specified in [RFC5280].
149 Certificate Evaluator: A party other than a Relying Party that
150 evaluates the trustworthiness of certificates issued by
151 Certification Authorities.
153 Certification Authority (CA): An Issuer that issues certificates in
154 accordance with a specified Certificate Policy.
156 Certificate Policy (CP): Specifies the criteria that a CA undertakes
157 to meet in its issue of certificates. See [RFC3647].
159 Certification Practices Statement (CPS): Specifies the means by
160 which the criteria of the CP are met. In most cases, this will be
161 the document against which the operations of the CA are audited.
164 Domain Name: The label assigned to a node in the Domain Name System.
166 Domain Name System (DNS): The Internet naming system specified in
167 [RFC1034] and [RFC1035].
169 DNS Security (DNSSEC): Extensions to the DNS that provide
170 authentication services as specified in [RFC4033], [RFC4034],
171 [RFC4035], [RFC5155], and any revisions to these specifications.
173 Fully Qualified Domain Name (FQDN): A domain name that includes the
174 labels of all superior nodes in the DNS.
176 Issuer: An entity that issues certificates. See [RFC5280].
178 Property: The tag-value portion of a CAA Resource Record.
180 Property Tag: The tag portion of a CAA Resource Record.
182 Property Value: The value portion of a CAA Resource Record.
184 Relevant Resource Record Set (Relevant RRset): A set of CAA Resource
185 Records resulting from applying the algorithm in Section 3 to a
186 specific FQDN or Wildcard Domain Name.
188 Relying Party: A party that makes use of an application whose
189 operation depends on the use of a certificate for making a
190 security decision. See [RFC5280].
192 Resource Record (RR): A particular entry in the DNS, including the
193 owner name, class, type, time to live, and data, as defined in
194 [RFC1034] and [RFC2181].
196 Resource Record Set (RRset): A set of RRs of a particular owner
197 name, class, and type. The time to live on all RRs within an
198 RRset is always the same, but the data may be different among RRs
201 Wildcard Domain Name: A domain name consisting of a single asterisk
202 character followed by a single "full stop" character ("*.")
2053. Relevant Resource Record Set
207 Before issuing a certificate, a compliant CA MUST check for
208 publication of a Relevant RRset. If such an RRset exists, a CA
209 MUST NOT issue a certificate unless the CA determines that either
210 (1) the certificate request is consistent with the applicable CAA
211 RRset or (2) an exception specified in the relevant CP or CPS
212 applies. If the Relevant RRset for an FQDN or Wildcard Domain Name
213 contains no Property Tags that restrict issuance (for instance, if it
214 contains only iodef Property Tags or only Property Tags unrecognized
215 by the CA), CAA does not restrict issuance.
217 A certificate request MAY specify more than one FQDN and MAY specify
218 Wildcard Domain Names. Issuers MUST verify authorization for all the
219 FQDNs and Wildcard Domain Names specified in the request.
221 The search for a CAA RRset climbs the DNS name tree from the
222 specified label up to, but not including, the DNS root "." until a
225 Given a request for a specific FQDN X or a request for a Wildcard
226 Domain Name *.X, the Relevant RRset RelevantCAASet(X) is determined
227 as follows (in pseudocode):
229 Let CAA(X) be the RRset returned by performing a CAA record query
230 for the FQDN X, according to the lookup algorithm specified in
231 Section 4.3.2 of [RFC1034] (in particular, chasing aliases). Let
232 Parent(X) be the FQDN produced by removing the leftmost label of
235 RelevantCAASet(domain):
236 while domain is not ".":
237 if CAA(domain) is not Empty:
239 domain = Parent(domain)
242 For example, processing CAA for the FQDN "X.Y.Z" where there are
243 no CAA records at any level in the tree RelevantCAASet would have
246 CAA("X.Y.Z.") = Empty; domain = Parent("X.Y.Z.") = "Y.Z."
247 CAA("Y.Z.") = Empty; domain = Parent("Y.Z.") = "Z."
248 CAA("Z.") = Empty; domain = Parent("Z.") = "."
251 Processing CAA for the FQDN "A.B.C" where there is a CAA record
252 "issue example.com" at "B.C" would terminate early upon finding
255 CAA("A.B.C.") = Empty; domain = Parent("A.B.C.") = "B.C."
256 CAA("B.C.") = "issue example.com"
257 return "issue example.com"
263 A CAA RR contains a single Property consisting of a tag-value pair.
264 An FQDN MAY have multiple CAA RRs associated with it, and a given
265 Property Tag MAY be specified more than once across those RRs.
267 The RDATA section for a CAA RR contains one Property. A Property
268 consists of the following:
270 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
271 | Flags | Tag Length = n |
272 +----------------|----------------+...+---------------+
273 | Tag char 0 | Tag char 1 |...| Tag char n-1 |
274 +----------------|----------------+...+---------------+
275 +----------------|----------------+.....+----------------+
276 | Value byte 0 | Value byte 1 |.....| Value byte m-1 |
277 +----------------|----------------+.....+----------------+
279 Where n is the length specified in the Tag Length field and m is the
280 number of remaining octets in the Value field. They are related by
281 (m = d - n - 2) where d is the length of the RDATA section.
283 The fields are defined as follows:
285 Flags: One octet containing the following field:
287 Bit 0, Issuer Critical Flag: If the value is set to "1", the
288 Property is critical. A CA MUST NOT issue certificates for any
289 FQDN if the Relevant RRset for that FQDN contains a CAA
290 critical Property for an unknown or unsupported Property Tag.
292 Note that according to the conventions set out in [RFC1035], bit 0 is
293 the Most Significant Bit and bit 7 is the Least Significant Bit.
294 Thus, according to those conventions, the Flags value 1 means that
295 bit 7 is set, while a value of 128 means that bit 0 is set.
297 All other bit positions are reserved for future use.
299 To ensure compatibility with future extensions to CAA, DNS records
300 compliant with this version of the CAA specification MUST clear (set
301 to "0") all reserved flag bits. Applications that interpret CAA
302 records MUST ignore the value of all reserved flag bits.
304 Tag Length: A single octet containing an unsigned integer specifying
305 the tag length in octets. The tag length MUST be at least 1.
307 Tag: The Property identifier -- a sequence of ASCII characters.
309 Tags MAY contain ASCII characters "a" through "z", "A" through "Z",
310 and the numbers 0 through 9. Tags MUST NOT contain any other
311 characters. Matching of tags is case insensitive.
313 Tags submitted for registration by IANA MUST NOT contain any
314 characters other than the (lowercase) ASCII characters "a" through
315 "z" and the numbers 0 through 9.
317 Value: A sequence of octets representing the Property Value.
318 Property Values are encoded as binary values and MAY employ
321 The length of the Value field is specified implicitly as the
322 remaining length of the enclosing RDATA section.
3244.1.1. Canonical Presentation Format
326 The canonical presentation format of the CAA record is:
328 CAA <flags> <tag> <value>
332 Flags: An unsigned integer between 0 and 255.
334 Tag: A non-zero-length sequence of ASCII letters and numbers in
337 Value: The Value field, expressed as either (1) a contiguous set of
338 characters without interior spaces or (2) a quoted string. See
339 the <character-string> format specified in [RFC1035], Section 5.1,
340 but note that the Value field contains no length byte and is not
341 limited to 255 characters.
3434.2. CAA issue Property
345 If the issue Property Tag is present in the Relevant RRset for an
346 FQDN, it is a request that Issuers:
348 1. Perform CAA issue restriction processing for the FQDN, and
350 2. Grant authorization to issue certificates containing that FQDN to
351 the holder of the issuer-domain-name or a party acting under the
352 explicit authority of the holder of the issuer-domain-name.
354 The CAA issue Property Value has the following sub-syntax (specified
355 in ABNF as per [RFC5234]).
357 issue-value = *WSP [issuer-domain-name *WSP]
358 [";" *WSP [parameters *WSP]]
360 issuer-domain-name = label *("." label)
361 label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
363 parameters = (parameter *WSP ";" *WSP parameters) / parameter
364 parameter = tag *WSP "=" *WSP value
365 tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
366 value = *(%x21-3A / %x3C-7E)
368 For consistency with other aspects of DNS administration, FQDN values
369 are specified in letter-digit-hyphen Label (LDH-Label) form.
371 The following CAA RRset requests that no certificates be issued for
372 the FQDN "certs.example.com" by any Issuer other than ca1.example.net
375 certs.example.com CAA 0 issue "ca1.example.net"
376 certs.example.com CAA 0 issue "ca2.example.org"
378 Because the presence of an issue Property Tag in the Relevant RRset
379 for an FQDN restricts issuance, FQDN owners can use an issue Property
380 Tag with no issuer-domain-name to request no issuance.
382 For example, the following RRset requests that no certificates be
383 issued for the FQDN "nocerts.example.com" by any Issuer.
385 nocerts.example.com CAA 0 issue ";"
387 An issue Property Tag where the issue-value does not match the ABNF
388 grammar MUST be treated the same as one specifying an empty
389 issuer-domain-name. For example, the following malformed CAA RRset
392 malformed.example.com CAA 0 issue "%%%%%"
394 CAA authorizations are additive; thus, the result of specifying both
395 an empty issuer-domain-name and a non-empty issuer-domain-name is the
396 same as specifying just the non-empty issuer-domain-name.
398 An Issuer MAY choose to specify parameters that further constrain the
399 issue of certificates by that Issuer -- for example, specifying that
400 certificates are to be subject to specific validation policies,
401 billed to certain accounts, or issued under specific trust anchors.
403 For example, if ca1.example.net has requested that its customer
404 account.example.com specify their account number "230123" in each of
405 the customer's CAA records using the (CA-defined) "account"
406 parameter, it would look like this:
408 account.example.com CAA 0 issue "ca1.example.net; account=230123"
410 The semantics of parameters to the issue Property Tag are determined
4134.3. CAA issuewild Property
415 The issuewild Property Tag has the same syntax and semantics as the
416 issue Property Tag except that it only grants authorization to issue
417 certificates that specify a Wildcard Domain Name and each issuewild
418 Property takes precedence over each issue Property when specified.
421 Each issuewild Property MUST be ignored when processing a request for
422 an FQDN that is not a Wildcard Domain Name.
424 If at least one issuewild Property is specified in the Relevant RRset
425 for a Wildcard Domain Name, each issue Property MUST be ignored when
426 processing a request for that Wildcard Domain Name.
428 For example, the following RRset requests that _only_ ca1.example.net
429 issue certificates for "wild.example.com" or "sub.wild.example.com",
430 and that _only_ ca2.example.org issue certificates for
431 "*.wild.example.com" or "*.sub.wild.example.com". Note that this
432 presumes that there are no CAA RRs for sub.wild.example.com.
434 wild.example.com CAA 0 issue "ca1.example.net"
435 wild.example.com CAA 0 issuewild "ca2.example.org"
437 The following RRset requests that _only_ ca1.example.net issue
438 certificates for "wild2.example.com", "*.wild2.example.com", or
439 "*.sub.wild2.example.com".
441 wild2.example.com CAA 0 issue "ca1.example.net"
443 The following RRset requests that _only_ ca2.example.org issue
444 certificates for "*.wild3.example.com" or "*.sub.wild3.example.com".
445 It does not permit any Issuer to issue for "wild3.example.com" or
446 "sub.wild3.example.com".
448 wild3.example.com CAA 0 issuewild "ca2.example.org"
449 wild3.example.com CAA 0 issue ";"
451 The following RRset requests that _only_ ca2.example.org issue
452 certificates for "*.wild3.example.com" or "*.sub.wild3.example.com".
453 It permits any Issuer to issue for "wild3.example.com" or
454 "sub.wild3.example.com".
456 wild3.example.com CAA 0 issuewild "ca2.example.org"
4584.4. CAA iodef Property
460 The iodef Property specifies a means of reporting certificate issue
461 requests or cases of certificate issue for domains for which the
462 Property appears in the Relevant RRset, when those requests or
463 issuances violate the security policy of the Issuer or the FQDN
466 The Incident Object Description Exchange Format (IODEF) [RFC7970] is
467 used to present the incident report in machine-readable form.
469 The iodef Property Tag takes a URL as its Property Value. The URL
470 scheme type determines the method used for reporting:
472 mailto: The IODEF report is reported as a MIME email attachment to
473 an SMTP email that is submitted to the mail address specified.
474 The mail message sent SHOULD contain a brief text message to alert
475 the recipient to the nature of the attachment.
477 http or https: The IODEF report is submitted as a web service
478 request to the HTTP address specified using the protocol specified
481 These are the only supported URL schemes.
483 The following RRset specifies that reports may be made by means of
484 email with the IODEF data as an attachment, a web service [RFC6546],
487 report.example.com CAA 0 issue "ca1.example.net"
488 report.example.com CAA 0 iodef "mailto:security@example.com"
489 report.example.com CAA 0 iodef "https://iodef.example.com/"
493 The critical flag is intended to permit future versions of CAA to
494 introduce new semantics that MUST be understood for correct
495 processing of the record, preventing conforming CAs that do not
496 recognize the new semantics from issuing certificates for the
499 In the following example, the Property with a Property Tag of "tbs"
500 is flagged as critical. Neither the ca1.example.net CA nor any other
501 Issuer is authorized to issue for "new.example.com" (or any other
502 domains for which this is the Relevant RRset) unless the Issuer has
503 implemented the processing rules for the "tbs" Property Tag.
505 new.example.com CAA 0 issue "ca1.example.net"
506 new.example.com CAA 128 tbs "Unknown"
5085. Security Considerations
510 CAA records assert a security policy that the holder of an FQDN
511 wishes to be observed by Issuers. The effectiveness of CAA records
512 as an access control mechanism is thus dependent on observance of CAA
513 constraints by Issuers.
515 The objective of the CAA record properties described in this document
516 is to reduce the risk of certificate mis-issue rather than avoid
517 reliance on a certificate that has been mis-issued. DANE [RFC6698]
518 describes a mechanism for avoiding reliance on mis-issued
5215.1. Use of DNS Security
523 The use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but
524 not required. An Issuer MUST NOT issue certificates if doing so
525 would conflict with the Relevant RRset, irrespective of whether the
526 corresponding DNS records are signed.
528 DNSSEC provides a proof of non-existence for both DNS FQDNs and
529 RRsets within FQDNs. DNSSEC verification thus enables an Issuer to
530 determine whether the answer to a CAA record query (1) is empty
531 because the RRset is empty or (2) is non-empty but the response has
534 The use of DNSSEC allows an Issuer to acquire and archive a proof
535 that they were authorized to issue certificates for the FQDN.
536 Verification of such archives may be an audit requirement to verify
537 CAA record-processing compliance. Publication of such archives may
538 be a transparency requirement to verify CAA record-processing
5415.2. Non-compliance by Certification Authority
543 CAA records offer CAs a cost-effective means of mitigating the risk
544 of certificate mis-issue: the cost of implementing CAA checks is very
545 small, and the potential costs of a mis-issue event include the
546 removal of an embedded trust anchor.
5485.3. Mis-Issue by Authorized Certification Authority
550 The use of CAA records does not prevent mis-issue by an authorized
551 CA, i.e., a CA that is authorized to issue certificates for the FQDN
552 in question by CAA records.
554 FQDN holders SHOULD verify that the CAs they authorize to issue
555 certificates for their FQDNs employ appropriate controls to ensure
556 that certificates are issued only to authorized parties within their
559 Such controls are most appropriately determined by the FQDN holder
560 and the authorized CA(s) directly and are thus outside the scope of
5635.4. Suppression or Spoofing of CAA Records
565 Suppression of a CAA record or insertion of a bogus CAA record could
566 enable an attacker to obtain a certificate from an Issuer that was
567 not authorized to issue for an affected FQDN.
569 Where possible, Issuers SHOULD perform DNSSEC validation to detect
570 missing or modified CAA RRsets.
572 In cases where DNSSEC is not deployed for a corresponding FQDN, an
573 Issuer SHOULD attempt to mitigate this risk by employing appropriate
574 DNS security controls. For example, all portions of the DNS lookup
575 process SHOULD be performed against the authoritative nameserver.
576 Data cached by third parties MUST NOT be relied on as the sole source
577 of DNS CAA information but MAY be used to support additional
578 anti-spoofing or anti-suppression controls.
5805.5. Denial of Service
582 Introduction of a malformed or malicious CAA RR could, in theory,
583 enable a Denial-of-Service (DoS) attack. This could happen by
584 modification of authoritative DNS records or by spoofing inflight DNS
587 This specific threat is not considered to add significantly to the
588 risk of running an insecure DNS service.
590 An attacker could, in principle, perform a DoS attack against an
591 Issuer by requesting a certificate with a maliciously long DNS name.
592 In practice, the DNS protocol imposes a maximum name length, and CAA
593 processing does not exacerbate the existing need to mitigate DoS
594 attacks to any meaningful degree.
5965.6. Abuse of the Critical Flag
598 A CA could make use of the critical flag to trick customers into
599 publishing records that prevent competing CAs from issuing
600 certificates even though the customer intends to authorize multiple
601 providers. This could happen if the customers were setting CAA
602 records based on data provided by the CA rather than generating those
605 In practice, such an attack would be of minimal effect, since any
606 competent competitor that found itself unable to issue certificates
607 due to lack of support for a Property marked critical should
608 investigate the cause and report the reason to the customer. The
609 customer will thus discover that they had been deceived.
6116. Deployment Considerations
613 A CA implementing CAA may find that they receive errors looking up
614 CAA records. The following are some common causes of such errors, so
615 that CAs may provide guidance to their subscribers on fixing the
6186.1. Blocked Queries or Responses
620 Some middleboxes -- in particular, anti-DDoS appliances -- may be
621 configured to drop DNS packets of unknown types, or they may start
622 dropping such packets when they consider themselves under attack.
623 This generally manifests as a timed-out DNS query or as a SERVFAIL at
624 a local recursive resolver.
6266.2. Rejected Queries and Malformed Responses
628 Some authoritative nameservers respond with REJECTED or NOTIMP when
629 queried for an RR type they do not recognize. At least one
630 authoritative resolver produces a malformed response (with the QR
631 (Query/Response) bit set to "0") when queried for unknown RR types.
632 Per [RFC1034], the correct response RCODE for unknown RR types is 0
633 ("No error condition").
6356.3. Delegation to Private Nameservers
637 Some FQDN administrators make the contents of a subdomain
638 unresolvable on the public Internet by delegating that subdomain to a
639 nameserver whose IP address is private. A CA processing CAA records
640 for such subdomains will receive SERVFAIL from its recursive
641 resolver. The CA MAY interpret that as preventing issuance. FQDN
642 administrators wishing to issue certificates for private FQDNs SHOULD
643 use split-horizon DNS with a publicly available nameserver, so that
644 CAs can receive a valid, empty CAA response for those FQDNs.
6466.4. Bogus DNSSEC Responses
648 Queries for CAA RRs are different from most DNS RR types, because a
649 signed, empty response to a query for CAA RRs is meaningfully
650 different from a bogus response. A signed, empty response indicates
651 that there is definitely no CAA policy set at a given label. A bogus
652 response may mean either a misconfigured zone or an attacker
653 tampering with records. DNSSEC implementations may have bugs with
654 signatures on empty responses that go unnoticed, because for more
655 common RR types like A and AAAA, the difference to an end user
656 between empty and bogus is irrelevant; they both mean a site is
659 In particular, at least two authoritative resolvers that implement
660 live signing had bugs when returning empty RRsets for DNSSEC-signed
661 zones, in combination with mixed-case queries. Mixed-case queries,
662 also known as DNS 0x20, are used by some recursive resolvers to
663 increase resilience against DNS poisoning attacks. DNSSEC-signing
664 authoritative resolvers are expected to copy the same capitalization
665 from the query into their ANSWER section but also to sign the
666 response as if they had used all lowercase. In particular, PowerDNS
667 versions prior to 4.0.4 had this bug.
6697. Differences from RFC 6844
671 This document obsoletes [RFC6844]. The most important change is to
672 the "Certification Authority Processing" section (now called
673 "Relevant Resource Record Set" (Section 3), as noted below).
674 [RFC6844] specified an algorithm that performed DNS tree-climbing not
675 only on the FQDN being processed but also on all CNAMEs and DNAMEs
676 encountered along the way. This made the processing algorithm very
677 inefficient when used on FQDNs that utilize many CNAMEs and would
678 have made it difficult for hosting providers to set CAA policies on
679 their own FQDNs without setting potentially unwanted CAA policies on
680 their customers' FQDNs. This document specifies a simplified
681 processing algorithm that only performs tree-climbing on the FQDN
682 being processed, and it leaves the processing of CNAMEs and DNAMEs up
683 to the CA's recursive resolver.
685 This document also includes a "Deployment Considerations" section
686 (Section 6) detailing experience gained with practical deployment of
687 CAA enforcement among CAs in the WebPKI.
689 This document clarifies the ABNF grammar for the issue and issuewild
690 tags and resolves some inconsistencies with the document text. In
691 particular, it specifies that parameters are separated with
692 semicolons. It also allows hyphens in Property Tags.
694 This document also clarifies the processing of a CAA RRset that is
695 not empty but that does not contain any issue or issuewild tags.
697 This document removes the section titled "The CAA RR Type," merging
698 it with "Mechanism" (Section 4) because the definitions were mainly
699 duplicates. It moves the "Use of DNS Security" section into Security
700 Considerations (Section 5). It renames "Certification Authority
701 Processing" to "Relevant Resource Record Set" (Section 3) and
702 emphasizes the use of that term to more clearly define which domains
703 are affected by a given RRset.
7058. IANA Considerations
707 IANA has added this document as a reference for the "Certification
708 Authority Restriction Flags" and "Certification Authority Restriction
709 Properties" registries and updated references to [RFC6844] within
710 those registries to refer instead to this document. IANA has also
711 updated the CAA TYPE in the "Resource Record (RR) TYPEs" subregistry
712 of the "Domain Name System (DNS) Parameters" registry with a
713 reference to this document.
7179.1. Normative References
719 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
720 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
721 <https://www.rfc-editor.org/info/rfc1034>.
723 [RFC1035] Mockapetris, P., "Domain names - implementation and
724 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
725 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
728 Requirement Levels", BCP 14, RFC 2119,
729 DOI 10.17487/RFC2119, March 1997,
730 <https://www.rfc-editor.org/info/rfc2119>.
732 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
733 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
734 <https://www.rfc-editor.org/info/rfc2181>.
736 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
737 Rose, "DNS Security Introduction and Requirements",
738 RFC 4033, DOI 10.17487/RFC4033, March 2005,
739 <https://www.rfc-editor.org/info/rfc4033>.
741 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
742 Rose, "Resource Records for the DNS Security Extensions",
743 RFC 4034, DOI 10.17487/RFC4034, March 2005,
744 <https://www.rfc-editor.org/info/rfc4034>.
746 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
747 Rose, "Protocol Modifications for the DNS Security
748 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
749 <https://www.rfc-editor.org/info/rfc4035>.
751 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
752 Security (DNSSEC) Hashed Authenticated Denial of
753 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
754 <https://www.rfc-editor.org/info/rfc5155>.
756 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
757 Specifications: ABNF", STD 68, RFC 5234,
758 DOI 10.17487/RFC5234, January 2008,
759 <https://www.rfc-editor.org/info/rfc5234>.
761 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
762 Housley, R., and W. Polk, "Internet X.509 Public Key
763 Infrastructure Certificate and Certificate Revocation List
764 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
765 <https://www.rfc-editor.org/info/rfc5280>.
767 [RFC6546] Trammell, B., "Transport of Real-time Inter-network
768 Defense (RID) Messages over HTTP/TLS", RFC 6546,
769 DOI 10.17487/RFC6546, April 2012,
770 <https://www.rfc-editor.org/info/rfc6546>.
772 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
773 of Named Entities (DANE) Transport Layer Security (TLS)
774 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
775 2012, <https://www.rfc-editor.org/info/rfc6698>.
777 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
778 Authority Authorization (CAA) Resource Record", RFC 6844,
779 DOI 10.17487/RFC6844, January 2013,
780 <https://www.rfc-editor.org/info/rfc6844>.
782 [RFC7970] Danyliw, R., "The Incident Object Description Exchange
783 Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
784 November 2016, <https://www.rfc-editor.org/info/rfc7970>.
786 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
787 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
788 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7909.2. Informative References
792 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
793 Wu, "Internet X.509 Public Key Infrastructure Certificate
794 Policy and Certification Practices Framework", RFC 3647,
795 DOI 10.17487/RFC3647, November 2003,
796 <https://www.rfc-editor.org/info/rfc3647>.
800 The authors would like to thank the following people who contributed
801 to the design and documentation of this work item: Corey Bonnell,
802 Chris Evans, Stephen Farrell, Jeff Hodges, Paul Hoffman, Tim
803 Hollebeek, Stephen Kent, Adam Langley, Ben Laurie, James Manger,
804 Chris Palmer, Scott Schmit, Sean Turner, and Ben Wilson.
811 Email: phill@hallambaker.com
817 Email: rob@sectigo.com
820 Jacob Hoffman-Andrews
823 Email: jsha@letsencrypt.org