From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8659.txt | 823 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 823 insertions(+) create mode 100644 doc/rfc/rfc8659.txt (limited to 'doc/rfc/rfc8659.txt') diff --git a/doc/rfc/rfc8659.txt b/doc/rfc/rfc8659.txt new file mode 100644 index 0000000..124e1c7 --- /dev/null +++ b/doc/rfc/rfc8659.txt @@ -0,0 +1,823 @@ + + + + +Internet Engineering Task Force (IETF) P. Hallam-Baker +Request for Comments: 8659 Venture Cryptography +Obsoletes: 6844 R. Stradling +Category: Standards Track Sectigo +ISSN: 2070-1721 J. Hoffman-Andrews + Let's Encrypt + November 2019 + + + DNS Certification Authority Authorization (CAA) Resource Record + +Abstract + + The Certification Authority Authorization (CAA) DNS Resource Record + allows a DNS domain name holder to specify one or more Certification + Authorities (CAs) authorized to issue certificates for that domain + name. CAA Resource Records allow a public CA to implement additional + controls to reduce the risk of unintended certificate mis-issue. + This document defines the syntax of the CAA record and rules for + processing CAA records by CAs. + + This document obsoletes RFC 6844. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8659. + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Definitions + 2.1. Requirements Language + 2.2. Defined Terms + 3. Relevant Resource Record Set + 4. Mechanism + 4.1. Syntax + 4.1.1. Canonical Presentation Format + 4.2. CAA issue Property + 4.3. CAA issuewild Property + 4.4. CAA iodef Property + 4.5. Critical Flag + 5. Security Considerations + 5.1. Use of DNS Security + 5.2. Non-compliance by Certification Authority + 5.3. Mis-Issue by Authorized Certification Authority + 5.4. Suppression or Spoofing of CAA Records + 5.5. Denial of Service + 5.6. Abuse of the Critical Flag + 6. Deployment Considerations + 6.1. Blocked Queries or Responses + 6.2. Rejected Queries and Malformed Responses + 6.3. Delegation to Private Nameservers + 6.4. Bogus DNSSEC Responses + 7. Differences from RFC 6844 + 8. IANA Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + The Certification Authority Authorization (CAA) DNS Resource Record + allows a DNS domain name holder to specify the Certification + Authorities (CAs) authorized to issue certificates for that domain + name. Publication of CAA Resource Records allows a public CA to + implement additional controls to reduce the risk of unintended + certificate mis-issue. + + Like the TLSA record defined in DNS-Based Authentication of Named + Entities (DANE) [RFC6698], CAA records are used as a part of a + mechanism for checking PKIX [RFC6698] certificate data. The + distinction between CAA and TLSA is that CAA records specify an + authorization control to be performed by a CA before issuing a + certificate and TLSA records specify a verification control to be + performed by a Relying Party after the certificate is issued. + + Conformance with a published CAA record is a necessary, but not + sufficient, condition for the issuance of a certificate. + + Criteria for the inclusion of embedded trust anchor certificates in + applications are outside the scope of this document. Typically, such + criteria require the CA to publish a Certification Practices + Statement (CPS) that specifies how the requirements of the + Certificate Policy (CP) are achieved. It is also common for a CA to + engage an independent third-party auditor to prepare an annual audit + statement of its performance against its CPS. + + A set of CAA records describes only current grants of authority to + issue certificates for the corresponding DNS domain name. Since + certificates are valid for a period of time, it is possible that a + certificate that is not conformant with the CAA records currently + published was conformant with the CAA records published at the time + that the certificate was issued. Relying Parties MUST NOT use CAA + records as part of certificate validation. + + CAA records MAY be used by Certificate Evaluators as a possible + indicator of a security policy violation. Such use SHOULD take into + account the possibility that published CAA records changed between + the time a certificate was issued and the time at which the + certificate was observed by the Certificate Evaluator. + +2. Definitions + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2.2. Defined Terms + + The following terms are used in this document: + + Certificate: An X.509 Certificate, as specified in [RFC5280]. + + Certificate Evaluator: A party other than a Relying Party that + evaluates the trustworthiness of certificates issued by + Certification Authorities. + + Certification Authority (CA): An Issuer that issues certificates in + accordance with a specified Certificate Policy. + + Certificate Policy (CP): Specifies the criteria that a CA undertakes + to meet in its issue of certificates. See [RFC3647]. + + Certification Practices Statement (CPS): Specifies the means by + which the criteria of the CP are met. In most cases, this will be + the document against which the operations of the CA are audited. + See [RFC3647]. + + Domain Name: The label assigned to a node in the Domain Name System. + + Domain Name System (DNS): The Internet naming system specified in + [RFC1034] and [RFC1035]. + + DNS Security (DNSSEC): Extensions to the DNS that provide + authentication services as specified in [RFC4033], [RFC4034], + [RFC4035], [RFC5155], and any revisions to these specifications. + + Fully Qualified Domain Name (FQDN): A domain name that includes the + labels of all superior nodes in the DNS. + + Issuer: An entity that issues certificates. See [RFC5280]. + + Property: The tag-value portion of a CAA Resource Record. + + Property Tag: The tag portion of a CAA Resource Record. + + Property Value: The value portion of a CAA Resource Record. + + Relevant Resource Record Set (Relevant RRset): A set of CAA Resource + Records resulting from applying the algorithm in Section 3 to a + specific FQDN or Wildcard Domain Name. + + Relying Party: A party that makes use of an application whose + operation depends on the use of a certificate for making a + security decision. See [RFC5280]. + + Resource Record (RR): A particular entry in the DNS, including the + owner name, class, type, time to live, and data, as defined in + [RFC1034] and [RFC2181]. + + Resource Record Set (RRset): A set of RRs of a particular owner + name, class, and type. The time to live on all RRs within an + RRset is always the same, but the data may be different among RRs + in the RRset. + + Wildcard Domain Name: A domain name consisting of a single asterisk + character followed by a single "full stop" character ("*.") + followed by an FQDN. + +3. Relevant Resource Record Set + + Before issuing a certificate, a compliant CA MUST check for + publication of a Relevant RRset. If such an RRset exists, a CA + MUST NOT issue a certificate unless the CA determines that either + (1) the certificate request is consistent with the applicable CAA + RRset or (2) an exception specified in the relevant CP or CPS + applies. If the Relevant RRset for an FQDN or Wildcard Domain Name + contains no Property Tags that restrict issuance (for instance, if it + contains only iodef Property Tags or only Property Tags unrecognized + by the CA), CAA does not restrict issuance. + + A certificate request MAY specify more than one FQDN and MAY specify + Wildcard Domain Names. Issuers MUST verify authorization for all the + FQDNs and Wildcard Domain Names specified in the request. + + The search for a CAA RRset climbs the DNS name tree from the + specified label up to, but not including, the DNS root "." until a + CAA RRset is found. + + Given a request for a specific FQDN X or a request for a Wildcard + Domain Name *.X, the Relevant RRset RelevantCAASet(X) is determined + as follows (in pseudocode): + + Let CAA(X) be the RRset returned by performing a CAA record query + for the FQDN X, according to the lookup algorithm specified in + Section 4.3.2 of [RFC1034] (in particular, chasing aliases). Let + Parent(X) be the FQDN produced by removing the leftmost label of + X. + + RelevantCAASet(domain): + while domain is not ".": + if CAA(domain) is not Empty: + return CAA(domain) + domain = Parent(domain) + return Empty + + For example, processing CAA for the FQDN "X.Y.Z" where there are + no CAA records at any level in the tree RelevantCAASet would have + the following steps: + + CAA("X.Y.Z.") = Empty; domain = Parent("X.Y.Z.") = "Y.Z." + CAA("Y.Z.") = Empty; domain = Parent("Y.Z.") = "Z." + CAA("Z.") = Empty; domain = Parent("Z.") = "." + return Empty + + Processing CAA for the FQDN "A.B.C" where there is a CAA record + "issue example.com" at "B.C" would terminate early upon finding + the CAA record: + + CAA("A.B.C.") = Empty; domain = Parent("A.B.C.") = "B.C." + CAA("B.C.") = "issue example.com" + return "issue example.com" + +4. Mechanism + +4.1. Syntax + + A CAA RR contains a single Property consisting of a tag-value pair. + An FQDN MAY have multiple CAA RRs associated with it, and a given + Property Tag MAY be specified more than once across those RRs. + + The RDATA section for a CAA RR contains one Property. A Property + consists of the following: + + +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| + | Flags | Tag Length = n | + +----------------|----------------+...+---------------+ + | Tag char 0 | Tag char 1 |...| Tag char n-1 | + +----------------|----------------+...+---------------+ + +----------------|----------------+.....+----------------+ + | Value byte 0 | Value byte 1 |.....| Value byte m-1 | + +----------------|----------------+.....+----------------+ + + Where n is the length specified in the Tag Length field and m is the + number of remaining octets in the Value field. They are related by + (m = d - n - 2) where d is the length of the RDATA section. + + The fields are defined as follows: + + Flags: One octet containing the following field: + + Bit 0, Issuer Critical Flag: If the value is set to "1", the + Property is critical. A CA MUST NOT issue certificates for any + FQDN if the Relevant RRset for that FQDN contains a CAA + critical Property for an unknown or unsupported Property Tag. + + Note that according to the conventions set out in [RFC1035], bit 0 is + the Most Significant Bit and bit 7 is the Least Significant Bit. + Thus, according to those conventions, the Flags value 1 means that + bit 7 is set, while a value of 128 means that bit 0 is set. + + All other bit positions are reserved for future use. + + To ensure compatibility with future extensions to CAA, DNS records + compliant with this version of the CAA specification MUST clear (set + to "0") all reserved flag bits. Applications that interpret CAA + records MUST ignore the value of all reserved flag bits. + + Tag Length: A single octet containing an unsigned integer specifying + the tag length in octets. The tag length MUST be at least 1. + + Tag: The Property identifier -- a sequence of ASCII characters. + + Tags MAY contain ASCII characters "a" through "z", "A" through "Z", + and the numbers 0 through 9. Tags MUST NOT contain any other + characters. Matching of tags is case insensitive. + + Tags submitted for registration by IANA MUST NOT contain any + characters other than the (lowercase) ASCII characters "a" through + "z" and the numbers 0 through 9. + + Value: A sequence of octets representing the Property Value. + Property Values are encoded as binary values and MAY employ + sub-formats. + + The length of the Value field is specified implicitly as the + remaining length of the enclosing RDATA section. + +4.1.1. Canonical Presentation Format + + The canonical presentation format of the CAA record is: + + CAA + + Where: + + Flags: An unsigned integer between 0 and 255. + + Tag: A non-zero-length sequence of ASCII letters and numbers in + lowercase. + + Value: The Value field, expressed as either (1) a contiguous set of + characters without interior spaces or (2) a quoted string. See + the format specified in [RFC1035], Section 5.1, + but note that the Value field contains no length byte and is not + limited to 255 characters. + +4.2. CAA issue Property + + If the issue Property Tag is present in the Relevant RRset for an + FQDN, it is a request that Issuers: + + 1. Perform CAA issue restriction processing for the FQDN, and + + 2. Grant authorization to issue certificates containing that FQDN to + the holder of the issuer-domain-name or a party acting under the + explicit authority of the holder of the issuer-domain-name. + + The CAA issue Property Value has the following sub-syntax (specified + in ABNF as per [RFC5234]). + + issue-value = *WSP [issuer-domain-name *WSP] + [";" *WSP [parameters *WSP]] + + issuer-domain-name = label *("." label) + label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) + + parameters = (parameter *WSP ";" *WSP parameters) / parameter + parameter = tag *WSP "=" *WSP value + tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) + value = *(%x21-3A / %x3C-7E) + + For consistency with other aspects of DNS administration, FQDN values + are specified in letter-digit-hyphen Label (LDH-Label) form. + + The following CAA RRset requests that no certificates be issued for + the FQDN "certs.example.com" by any Issuer other than ca1.example.net + or ca2.example.org. + + certs.example.com CAA 0 issue "ca1.example.net" + certs.example.com CAA 0 issue "ca2.example.org" + + Because the presence of an issue Property Tag in the Relevant RRset + for an FQDN restricts issuance, FQDN owners can use an issue Property + Tag with no issuer-domain-name to request no issuance. + + For example, the following RRset requests that no certificates be + issued for the FQDN "nocerts.example.com" by any Issuer. + + nocerts.example.com CAA 0 issue ";" + + An issue Property Tag where the issue-value does not match the ABNF + grammar MUST be treated the same as one specifying an empty + issuer-domain-name. For example, the following malformed CAA RRset + forbids issuance: + + malformed.example.com CAA 0 issue "%%%%%" + + CAA authorizations are additive; thus, the result of specifying both + an empty issuer-domain-name and a non-empty issuer-domain-name is the + same as specifying just the non-empty issuer-domain-name. + + An Issuer MAY choose to specify parameters that further constrain the + issue of certificates by that Issuer -- for example, specifying that + certificates are to be subject to specific validation policies, + billed to certain accounts, or issued under specific trust anchors. + + For example, if ca1.example.net has requested that its customer + account.example.com specify their account number "230123" in each of + the customer's CAA records using the (CA-defined) "account" + parameter, it would look like this: + + account.example.com CAA 0 issue "ca1.example.net; account=230123" + + The semantics of parameters to the issue Property Tag are determined + by the Issuer alone. + +4.3. CAA issuewild Property + + The issuewild Property Tag has the same syntax and semantics as the + issue Property Tag except that it only grants authorization to issue + certificates that specify a Wildcard Domain Name and each issuewild + Property takes precedence over each issue Property when specified. + Specifically: + + Each issuewild Property MUST be ignored when processing a request for + an FQDN that is not a Wildcard Domain Name. + + If at least one issuewild Property is specified in the Relevant RRset + for a Wildcard Domain Name, each issue Property MUST be ignored when + processing a request for that Wildcard Domain Name. + + For example, the following RRset requests that _only_ ca1.example.net + issue certificates for "wild.example.com" or "sub.wild.example.com", + and that _only_ ca2.example.org issue certificates for + "*.wild.example.com" or "*.sub.wild.example.com". Note that this + presumes that there are no CAA RRs for sub.wild.example.com. + + wild.example.com CAA 0 issue "ca1.example.net" + wild.example.com CAA 0 issuewild "ca2.example.org" + + The following RRset requests that _only_ ca1.example.net issue + certificates for "wild2.example.com", "*.wild2.example.com", or + "*.sub.wild2.example.com". + + wild2.example.com CAA 0 issue "ca1.example.net" + + The following RRset requests that _only_ ca2.example.org issue + certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". + It does not permit any Issuer to issue for "wild3.example.com" or + "sub.wild3.example.com". + + wild3.example.com CAA 0 issuewild "ca2.example.org" + wild3.example.com CAA 0 issue ";" + + The following RRset requests that _only_ ca2.example.org issue + certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". + It permits any Issuer to issue for "wild3.example.com" or + "sub.wild3.example.com". + + wild3.example.com CAA 0 issuewild "ca2.example.org" + +4.4. CAA iodef Property + + The iodef Property specifies a means of reporting certificate issue + requests or cases of certificate issue for domains for which the + Property appears in the Relevant RRset, when those requests or + issuances violate the security policy of the Issuer or the FQDN + holder. + + The Incident Object Description Exchange Format (IODEF) [RFC7970] is + used to present the incident report in machine-readable form. + + The iodef Property Tag takes a URL as its Property Value. The URL + scheme type determines the method used for reporting: + + mailto: The IODEF report is reported as a MIME email attachment to + an SMTP email that is submitted to the mail address specified. + The mail message sent SHOULD contain a brief text message to alert + the recipient to the nature of the attachment. + + http or https: The IODEF report is submitted as a web service + request to the HTTP address specified using the protocol specified + in [RFC6546]. + + These are the only supported URL schemes. + + The following RRset specifies that reports may be made by means of + email with the IODEF data as an attachment, a web service [RFC6546], + or both: + + report.example.com CAA 0 issue "ca1.example.net" + report.example.com CAA 0 iodef "mailto:security@example.com" + report.example.com CAA 0 iodef "https://iodef.example.com/" + +4.5. Critical Flag + + The critical flag is intended to permit future versions of CAA to + introduce new semantics that MUST be understood for correct + processing of the record, preventing conforming CAs that do not + recognize the new semantics from issuing certificates for the + indicated FQDNs. + + In the following example, the Property with a Property Tag of "tbs" + is flagged as critical. Neither the ca1.example.net CA nor any other + Issuer is authorized to issue for "new.example.com" (or any other + domains for which this is the Relevant RRset) unless the Issuer has + implemented the processing rules for the "tbs" Property Tag. + + new.example.com CAA 0 issue "ca1.example.net" + new.example.com CAA 128 tbs "Unknown" + +5. Security Considerations + + CAA records assert a security policy that the holder of an FQDN + wishes to be observed by Issuers. The effectiveness of CAA records + as an access control mechanism is thus dependent on observance of CAA + constraints by Issuers. + + The objective of the CAA record properties described in this document + is to reduce the risk of certificate mis-issue rather than avoid + reliance on a certificate that has been mis-issued. DANE [RFC6698] + describes a mechanism for avoiding reliance on mis-issued + certificates. + +5.1. Use of DNS Security + + The use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but + not required. An Issuer MUST NOT issue certificates if doing so + would conflict with the Relevant RRset, irrespective of whether the + corresponding DNS records are signed. + + DNSSEC provides a proof of non-existence for both DNS FQDNs and + RRsets within FQDNs. DNSSEC verification thus enables an Issuer to + determine whether the answer to a CAA record query (1) is empty + because the RRset is empty or (2) is non-empty but the response has + been suppressed. + + The use of DNSSEC allows an Issuer to acquire and archive a proof + that they were authorized to issue certificates for the FQDN. + Verification of such archives may be an audit requirement to verify + CAA record-processing compliance. Publication of such archives may + be a transparency requirement to verify CAA record-processing + compliance. + +5.2. Non-compliance by Certification Authority + + CAA records offer CAs a cost-effective means of mitigating the risk + of certificate mis-issue: the cost of implementing CAA checks is very + small, and the potential costs of a mis-issue event include the + removal of an embedded trust anchor. + +5.3. Mis-Issue by Authorized Certification Authority + + The use of CAA records does not prevent mis-issue by an authorized + CA, i.e., a CA that is authorized to issue certificates for the FQDN + in question by CAA records. + + FQDN holders SHOULD verify that the CAs they authorize to issue + certificates for their FQDNs employ appropriate controls to ensure + that certificates are issued only to authorized parties within their + organization. + + Such controls are most appropriately determined by the FQDN holder + and the authorized CA(s) directly and are thus outside the scope of + this document. + +5.4. Suppression or Spoofing of CAA Records + + Suppression of a CAA record or insertion of a bogus CAA record could + enable an attacker to obtain a certificate from an Issuer that was + not authorized to issue for an affected FQDN. + + Where possible, Issuers SHOULD perform DNSSEC validation to detect + missing or modified CAA RRsets. + + In cases where DNSSEC is not deployed for a corresponding FQDN, an + Issuer SHOULD attempt to mitigate this risk by employing appropriate + DNS security controls. For example, all portions of the DNS lookup + process SHOULD be performed against the authoritative nameserver. + Data cached by third parties MUST NOT be relied on as the sole source + of DNS CAA information but MAY be used to support additional + anti-spoofing or anti-suppression controls. + +5.5. Denial of Service + + Introduction of a malformed or malicious CAA RR could, in theory, + enable a Denial-of-Service (DoS) attack. This could happen by + modification of authoritative DNS records or by spoofing inflight DNS + responses. + + This specific threat is not considered to add significantly to the + risk of running an insecure DNS service. + + An attacker could, in principle, perform a DoS attack against an + Issuer by requesting a certificate with a maliciously long DNS name. + In practice, the DNS protocol imposes a maximum name length, and CAA + processing does not exacerbate the existing need to mitigate DoS + attacks to any meaningful degree. + +5.6. Abuse of the Critical Flag + + A CA could make use of the critical flag to trick customers into + publishing records that prevent competing CAs from issuing + certificates even though the customer intends to authorize multiple + providers. This could happen if the customers were setting CAA + records based on data provided by the CA rather than generating those + records themselves. + + In practice, such an attack would be of minimal effect, since any + competent competitor that found itself unable to issue certificates + due to lack of support for a Property marked critical should + investigate the cause and report the reason to the customer. The + customer will thus discover that they had been deceived. + +6. Deployment Considerations + + A CA implementing CAA may find that they receive errors looking up + CAA records. The following are some common causes of such errors, so + that CAs may provide guidance to their subscribers on fixing the + underlying problems. + +6.1. Blocked Queries or Responses + + Some middleboxes -- in particular, anti-DDoS appliances -- may be + configured to drop DNS packets of unknown types, or they may start + dropping such packets when they consider themselves under attack. + This generally manifests as a timed-out DNS query or as a SERVFAIL at + a local recursive resolver. + +6.2. Rejected Queries and Malformed Responses + + Some authoritative nameservers respond with REJECTED or NOTIMP when + queried for an RR type they do not recognize. At least one + authoritative resolver produces a malformed response (with the QR + (Query/Response) bit set to "0") when queried for unknown RR types. + Per [RFC1034], the correct response RCODE for unknown RR types is 0 + ("No error condition"). + +6.3. Delegation to Private Nameservers + + Some FQDN administrators make the contents of a subdomain + unresolvable on the public Internet by delegating that subdomain to a + nameserver whose IP address is private. A CA processing CAA records + for such subdomains will receive SERVFAIL from its recursive + resolver. The CA MAY interpret that as preventing issuance. FQDN + administrators wishing to issue certificates for private FQDNs SHOULD + use split-horizon DNS with a publicly available nameserver, so that + CAs can receive a valid, empty CAA response for those FQDNs. + +6.4. Bogus DNSSEC Responses + + Queries for CAA RRs are different from most DNS RR types, because a + signed, empty response to a query for CAA RRs is meaningfully + different from a bogus response. A signed, empty response indicates + that there is definitely no CAA policy set at a given label. A bogus + response may mean either a misconfigured zone or an attacker + tampering with records. DNSSEC implementations may have bugs with + signatures on empty responses that go unnoticed, because for more + common RR types like A and AAAA, the difference to an end user + between empty and bogus is irrelevant; they both mean a site is + unavailable. + + In particular, at least two authoritative resolvers that implement + live signing had bugs when returning empty RRsets for DNSSEC-signed + zones, in combination with mixed-case queries. Mixed-case queries, + also known as DNS 0x20, are used by some recursive resolvers to + increase resilience against DNS poisoning attacks. DNSSEC-signing + authoritative resolvers are expected to copy the same capitalization + from the query into their ANSWER section but also to sign the + response as if they had used all lowercase. In particular, PowerDNS + versions prior to 4.0.4 had this bug. + +7. Differences from RFC 6844 + + This document obsoletes [RFC6844]. The most important change is to + the "Certification Authority Processing" section (now called + "Relevant Resource Record Set" (Section 3), as noted below). + [RFC6844] specified an algorithm that performed DNS tree-climbing not + only on the FQDN being processed but also on all CNAMEs and DNAMEs + encountered along the way. This made the processing algorithm very + inefficient when used on FQDNs that utilize many CNAMEs and would + have made it difficult for hosting providers to set CAA policies on + their own FQDNs without setting potentially unwanted CAA policies on + their customers' FQDNs. This document specifies a simplified + processing algorithm that only performs tree-climbing on the FQDN + being processed, and it leaves the processing of CNAMEs and DNAMEs up + to the CA's recursive resolver. + + This document also includes a "Deployment Considerations" section + (Section 6) detailing experience gained with practical deployment of + CAA enforcement among CAs in the WebPKI. + + This document clarifies the ABNF grammar for the issue and issuewild + tags and resolves some inconsistencies with the document text. In + particular, it specifies that parameters are separated with + semicolons. It also allows hyphens in Property Tags. + + This document also clarifies the processing of a CAA RRset that is + not empty but that does not contain any issue or issuewild tags. + + This document removes the section titled "The CAA RR Type," merging + it with "Mechanism" (Section 4) because the definitions were mainly + duplicates. It moves the "Use of DNS Security" section into Security + Considerations (Section 5). It renames "Certification Authority + Processing" to "Relevant Resource Record Set" (Section 3) and + emphasizes the use of that term to more clearly define which domains + are affected by a given RRset. + +8. IANA Considerations + + IANA has added this document as a reference for the "Certification + Authority Restriction Flags" and "Certification Authority Restriction + Properties" registries and updated references to [RFC6844] within + those registries to refer instead to this document. IANA has also + updated the CAA TYPE in the "Resource Record (RR) TYPEs" subregistry + of the "Domain Name System (DNS) Parameters" registry with a + reference to this document. + +9. References + +9.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + . + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, + . + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + . + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, DOI 10.17487/RFC4034, March 2005, + . + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, + . + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, + . + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [RFC6546] Trammell, B., "Transport of Real-time Inter-network + Defense (RID) Messages over HTTP/TLS", RFC 6546, + DOI 10.17487/RFC6546, April 2012, + . + + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication + of Named Entities (DANE) Transport Layer Security (TLS) + Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August + 2012, . + + [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification + Authority Authorization (CAA) Resource Record", RFC 6844, + DOI 10.17487/RFC6844, January 2013, + . + + [RFC7970] Danyliw, R., "The Incident Object Description Exchange + Format Version 2", RFC 7970, DOI 10.17487/RFC7970, + November 2016, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +9.2. Informative References + + [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. + Wu, "Internet X.509 Public Key Infrastructure Certificate + Policy and Certification Practices Framework", RFC 3647, + DOI 10.17487/RFC3647, November 2003, + . + +Acknowledgements + + The authors would like to thank the following people who contributed + to the design and documentation of this work item: Corey Bonnell, + Chris Evans, Stephen Farrell, Jeff Hodges, Paul Hoffman, Tim + Hollebeek, Stephen Kent, Adam Langley, Ben Laurie, James Manger, + Chris Palmer, Scott Schmit, Sean Turner, and Ben Wilson. + +Authors' Addresses + + Phillip Hallam-Baker + Venture Cryptography + + Email: phill@hallambaker.com + + + Rob Stradling + Sectigo Ltd. + + Email: rob@sectigo.com + + + Jacob Hoffman-Andrews + Let's Encrypt + + Email: jsha@letsencrypt.org -- cgit v1.2.3