5Internet Engineering Task Force (IETF) H. Landau
6Request for Comments: 8657 November 2019
7Category: Standards Track
11 Certification Authority Authorization (CAA) Record Extensions for
12 Account URI and Automatic Certificate Management Environment (ACME)
17 The Certification Authority Authorization (CAA) DNS record allows a
18 domain to communicate an issuance policy to Certification Authorities
19 (CAs) but only allows a domain to define a policy with CA-level
20 granularity. However, the CAA specification (RFC 8659) also provides
21 facilities for an extension to admit a more granular, CA-specific
22 policy. This specification defines two such parameters: one allowing
23 specific accounts of a CA to be identified by URIs and one allowing
24 specific methods of domain control validation as defined by the
25 Automatic Certificate Management Environment (ACME) protocol to be
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/rfc8657.
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 3. Extensions to the CAA Record: The "accounturi" Parameter
64 4. Extensions to the CAA Record: The "validationmethods" Parameter
65 5. Security Considerations
66 5.1. Limited to CAs Processing CAA Records
67 5.2. Restrictions Ineffective without CA Recognition
68 5.3. Mandatory Consistency in CA Recognition
70 5.5. Authorization Freshness
71 5.6. Use with and without DNSSEC
72 5.7. Restrictions Supersedable by DNS Delegation
73 5.8. Misconfiguration Hazards
74 5.9. Revelation of Account URIs
75 6. IANA Considerations
76 7. Normative References
82 This specification defines two parameters for the "issue" and
83 "issuewild" Properties of the Certification Authority Authorization
84 (CAA) DNS resource record [RFC8659]. The first, "accounturi", allows
85 authorization conferred by a CAA policy to be restricted to specific
86 accounts of a Certification Authority (CA), which are identified by
87 URIs. The second, "validationmethods", allows the set of validation
88 methods supported by a CA to validate domain control to be limited to
89 a subset of the full set of methods that it supports.
93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
95 "OPTIONAL" in this document are to be interpreted as described in
96 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
97 capitals, as shown here.
101 This document defines the "accounturi" CAA parameter for the "issue"
102 and "issuewild" Properties defined by [RFC8659]. The value of this
103 parameter, if specified, MUST be a URI [RFC3986] identifying a
106 "CA account" means an object that is maintained by a specific CA,
107 that may request the issuance of certificates, and that represents a
108 specific entity or group of related entities.
110 The presence of this parameter constrains the Property to which it is
111 attached. Where a CAA Property has an "accounturi" parameter, a CA
112 MUST only consider that Property to authorize issuance in the context
113 of a given certificate issuance request if the CA recognizes the URI
114 specified in the value portion of that parameter as identifying the
115 account making that request.
117 A Property without an "accounturi" parameter matches any account. A
118 Property with an invalid or unrecognized "accounturi" parameter is
119 unsatisfiable. A Property with multiple "accounturi" parameters is
122 The presence of an "accounturi" parameter does not replace or
123 supersede the need to validate the domain name specified in an
124 "issue" or "issuewild" record in the manner described in the CAA
125 specification [RFC8659]. CAs MUST still perform such validation.
126 For example, a CAA "issue" Property that specifies a domain name
127 belonging to CA A and an "accounturi" parameter identifying an
128 account at CA B is unsatisfiable.
132 An Automatic Certificate Management Environment (ACME) [RFC8555]
133 account object MAY be identified by setting the "accounturi"
134 parameter to the URI of the ACME account object.
136 Implementations of this specification that also implement ACME MUST
141 The "accounturi" specification provides a general mechanism to
142 identify entities that may request certificate issuance via URIs.
143 The use of specific kinds of URIs may be specified in future RFCs,
144 and CAs not implementing ACME MAY assign and recognize their own URIs
149 This document also defines the "validationmethods" CAA parameter for
150 the "issue" and "issuewild" Properties. The value of this parameter,
151 if specified, MUST be a comma-separated string of zero or more
152 validation method labels.
154 A validation method label identifies a validation method. A
155 validation method is a particular way in which a CA can validate
156 control over a domain.
158 The presence of this parameter constrains the Property to which it is
159 attached. A CA MUST only consider a Property with the
160 "validationmethods" parameter to authorize issuance where the
161 validation method being used is identified by one of the validation
162 method labels listed in the comma-separated list.
164 Each validation method label MUST be either the label of a method
165 defined in the "ACME Validation Methods" IANA registry [RFC8555] or a
166 CA-specific non-ACME validation method label as defined below.
168 Where a CA supports both the "validationmethods" parameter and one or
169 more non-ACME validation methods, it MUST assign labels to those
170 methods. If appropriate non-ACME labels are not present in the "ACME
171 Validation Methods" IANA registry, the CA MUST use labels beginning
172 with the string "ca-", which are defined to have CA-specific meaning.
174 The value of the "validationmethods" parameter MUST comply with the
175 following ABNF [RFC5234]:
177 value = [*(label ",") label]
178 label = 1*(ALPHA / DIGIT / "-")
1805. Security Considerations
182 This specification describes an extension to the CAA record
183 specification, increasing the granularity at which a CAA policy can
184 be expressed. This allows the set of entities capable of
185 successfully requesting issuance of certificates for a given domain
186 to be restricted beyond the set of entities would otherwise be
187 possible, while still allowing issuance for specific accounts of a
188 CA. This improves the security of issuance for domains that choose
189 to employ it, when combined with a CA that implements this
1925.1. Limited to CAs Processing CAA Records
194 All of the security considerations listed in [RFC8659] are inherited
195 by this document. This specification merely enables a domain with an
196 existing relationship with a CA to further constrain that CA in its
197 issuance practices, where that CA implements this specification. In
198 particular, it provides no additional security above that provided by
199 using the unextended CAA specification alone as concerns matters
200 relating to any other CA. The capacity of any other CA to issue
201 certificates for the given domain is completely unchanged.
203 As such, a domain that, via CAA records, authorizes only CAs adopting
204 this specification and that constrains its policy by means of this
205 specification, remains vulnerable to unauthorized issuance by CAs
206 that do not honor CAA records or that honor them only on an advisory
207 basis. Where a domain uses DNSSEC, it also remains vulnerable to CAs
208 that honor CAA records but that do not validate CAA records by means
209 of a trusted DNSSEC-validating resolver.
2115.2. Restrictions Ineffective without CA Recognition
213 Because the parameters of "issue" or "issuewild" CAA Properties
214 constitute a CA-specific namespace, the CA identified by an "issue"
215 or "issuewild" Property decides what parameters to recognize and
216 their semantics. Accordingly, the CAA parameters defined in this
217 specification rely on their being recognized by the CA named by an
218 "issue" or "issuewild" CAA Property and are not an effective means of
219 control over issuance unless a CA's support for the parameters is
220 established beforehand.
222 CAs that implement this specification SHOULD make available
223 documentation indicating as such, including explicit statements as to
224 which parameters are supported. Domains configuring CAA records for
225 a CA MUST NOT assume that the restrictions implied by the
226 "accounturi" and "validationmethods" parameters are effective in the
227 absence of explicit indication as such from that CA.
229 CAs SHOULD also document whether they implement DNSSEC validation for
230 DNS lookups done for validation purposes, as this affects the
231 security of the "accounturi" and "validationmethods" parameters.
2335.3. Mandatory Consistency in CA Recognition
235 A CA MUST ensure that its support for the "accounturi" and
236 "validationmethods" parameters is fully consistent for a given domain
237 name that a CA recognizes as identifying itself in a CAA "issue" or
238 "issuewild" Property. If a CA has multiple issuance systems (for
239 example, an ACME-based issuance system and a non-ACME-based issuance
240 system, or two different issuance systems resulting from a corporate
241 merger), it MUST ensure that all issuance systems recognize the same
244 A CA that is unable to do this MAY still implement the parameters by
245 splitting the CA into two domain names for the purposes of CAA
246 processing. For example, a CA "example.com" with an ACME-based
247 issuance system and a non-ACME-based issuance system could recognize
248 only "acme.example.com" for the former and "example.com" for the
249 latter, and then implement support for the "accounturi" and
250 "validationmethods" parameters for "acme.example.com" only.
252 A CA that is unable to ensure consistent processing of the
253 "accounturi" parameter or the "validationmethods" parameter for a
254 given CA domain name as specifiable in CAA "issue" or "issuewild"
255 Properties MUST NOT implement support for these parameters. Failure
256 to do so would result in an implementation of these parameters that
257 does not provide effective security.
261 Suppose that CA A recognizes "a.example.com" as identifying itself
262 and CA B is a subsidiary of CA A that recognizes both "a.example.com"
263 and "b.example.com" as identifying itself.
265 Suppose that both CA A and CA B issue account URIs of the form:
267 "urn:example:account-id:1234"
269 If the CA domain name in a CAA record is specified as
270 "a.example.com", then this could be construed as identifying account
271 number 1234 at CA A or at CA B. These may be different accounts,
274 Thus, CAs MUST ensure that the URIs they recognize as pertaining to a
275 specific account of that CA are unique within the scope of all domain
276 names that they recognize as identifying that CA for the purpose of
277 CAA record validation.
279 CAs SHOULD satisfy this requirement by using URIs that include an
280 authority (see Section 3.2 of [RFC3986]):
282 "https://a.example.com/account/1234"
2845.5. Authorization Freshness
286 The CAA specification [RFC8659] governs the act of issuance by a CA.
287 In some cases, a CA may establish authorization for an account to
288 request certificate issuance for a specific domain separately from
289 the act of issuance itself. Such authorization may occur
290 substantially prior to a certificate issuance request. The CAA
291 policy expressed by a domain may have changed in the meantime,
292 creating the risk that a CA will issue certificates in a manner
293 inconsistent with the presently published CAA policy.
295 CAs SHOULD adopt practices to reduce the risk of such circumstances.
296 Possible countermeasures include issuing authorizations with very
297 limited validity periods, such as an hour, or revalidating the CAA
298 policy for a domain at certificate issuance time.
3005.6. Use with and without DNSSEC
302 The "domain validation" model of validation commonly used for
303 certificate issuance cannot ordinarily protect against adversaries
304 who can conduct global man-in-the-middle attacks against a particular
305 domain. A global man-in-the-middle attack is an attack that can
306 intercept traffic to or from a given domain, regardless of the origin
307 or destination of that traffic. Such an adversary can intercept all
308 validation traffic initiated by a CA and thus appear to have control
311 Where a domain is signed using DNSSEC, the authenticity of its DNS
312 data can be assured, providing that a given CA makes all DNS
313 resolutions via a trusted DNSSEC-validating resolver. A domain can
314 use this Property to protect itself from the threat posed by an
315 adversary capable of performing a global man-in-the-middle attack
318 In order to facilitate this, a CA validation process must either rely
319 solely on information obtained via DNSSEC or meaningfully bind the
320 other parts of the validation transaction using material obtained via
323 The CAA parameters described in this specification can be used to
324 ensure that only validation methods meeting these criteria are used.
325 In particular, a domain secured via DNSSEC SHOULD either:
327 1. Use the "accounturi" parameter to ensure that only accounts that
328 it controls are authorized to obtain certificates, or
330 2. Exclusively use validation methods that rely solely on
331 information obtained via DNSSEC and use the "validationmethods"
332 parameter to ensure that only such methods are used.
334 A CA supporting the "accounturi" parameter or the "validationmethods"
335 parameter MUST perform CAA validation using a trusted
336 DNSSEC-validating resolver.
338 "Trusted" in this context means that the CA both trusts the resolver
339 itself and ensures that the communications path between the resolver
340 and the system performing CAA validation is secure. It is
341 RECOMMENDED that a CA ensure this by using a DNSSEC-validating
342 resolver running on the same machine as the system performing CAA
345 The use of the "accounturi" parameter or the "validationmethods"
346 parameter does not confer additional security against an attacker
347 capable of performing a man-in-the-middle attack against all
348 validation attempts made by a given CA that is authorized by CAA
351 1. A domain does not secure its nameservers using DNSSEC, or
353 2. That CA does not perform CAA validation using a trusted
354 DNSSEC-validating resolver.
356 Moreover, the use of the "accounturi" parameter or the
357 "validationmethods" parameter does not mitigate man-in-the-middle
358 attacks against CAs that do not validate CAA records or that do not
359 do so using a trusted DNSSEC-validating resolver, regardless of
360 whether or not those CAs are authorized by CAA; see Section 5.1.
362 In these cases, the "accounturi" and "validationmethods" parameters
363 still provide an effective means of administrative control over
364 issuance, except where control over DNS is subdelegated (see below).
3665.7. Restrictions Supersedable by DNS Delegation
368 CAA records are located during validation by walking up the DNS
369 hierarchy until one or more records are found. CAA records are
370 therefore not an effective way of restricting or controlling issuance
371 for subdomains of a domain, where control over those subdomains is
372 delegated to another party (such as via DNS delegation or by
373 providing limited access to manage subdomain DNS records).
3755.8. Misconfiguration Hazards
377 Because the "accounturi" and "validationmethods" parameters express
378 restrictive security policies, misconfiguration of said parameters
379 may result in legitimate issuance requests being refused.
3815.9. Revelation of Account URIs
383 Because CAA records are publicly accessible, the use of the
384 "accounturi" parameter enables third parties to observe the
385 authorized account URIs for a domain. This may allow third parties
386 to identify a correlation between domains if those domains use the
389 CAs are encouraged to select and process account URIs under the
390 assumption that untrusted third parties may learn of them.
3926. IANA Considerations
394 This document has no IANA actions. As per [RFC8659], the parameter
395 namespace for the CAA "issue" and "issuewild" Properties has CA-
396 defined semantics, and the identifiers within that namespace may be
397 freely and arbitrarily assigned by a CA. This document merely
398 specifies recommended semantics for parameters of the names
399 "accounturi" and "validationmethods", which CAs may choose to adopt.
4017. Normative References
403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
404 Requirement Levels", BCP 14, RFC 2119,
405 DOI 10.17487/RFC2119, March 1997,
406 <https://www.rfc-editor.org/info/rfc2119>.
408 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
409 Resource Identifier (URI): Generic Syntax", STD 66,
410 RFC 3986, DOI 10.17487/RFC3986, January 2005,
411 <https://www.rfc-editor.org/info/rfc3986>.
413 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
414 Specifications: ABNF", STD 68, RFC 5234,
415 DOI 10.17487/RFC5234, January 2008,
416 <https://www.rfc-editor.org/info/rfc5234>.
418 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
419 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
420 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
422 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
423 Kasten, "Automatic Certificate Management Environment
424 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
425 <https://www.rfc-editor.org/info/rfc8555>.
427 [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
428 "DNS Certification Authority Authorization (CAA) Resource
429 Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
430 <https://www.rfc-editor.org/info/rfc8659>.
434 The following shows an example DNS zone file fragment that nominates
435 two account URIs as authorized to issue certificates for the domain
436 "example.com". Issuance is restricted to the CA "example.net".
438 example.com. IN CAA 0 issue "example.net; \
439 accounturi=https://example.net/account/1234"
440 example.com. IN CAA 0 issue "example.net; \
441 accounturi=https://example.net/account/2345"
443 The following shows a zone file fragment that restricts the ACME
444 methods that can be used; only ACME methods "dns-01" and "xyz-01" can
447 example.com. IN CAA 0 issue "example.net; \
448 validationmethods=dns-01,xyz-01"
450 The following shows an equivalent way of expressing the same
453 example.com. IN CAA 0 issue "example.net; validationmethods=dns-01"
454 example.com. IN CAA 0 issue "example.net; validationmethods=xyz-01"
456 The following shows a zone file fragment in which one account can be
457 used to issue with the "dns-01" method and one account can be used to
458 issue with the "http-01" method.
460 example.com. IN CAA 0 issue "example.net; \
461 accounturi=https://example.net/account/1234; \
462 validationmethods=dns-01"
463 example.com. IN CAA 0 issue "example.net; \
464 accounturi=https://example.net/account/2345; \
465 validationmethods=http-01"
467 The following shows a zone file fragment in which only ACME method
468 "dns-01" or a CA-specific method "ca-foo" can be used.
470 example.com. IN CAA 0 issue "example.net; \
471 validationmethods=dns-01,ca-foo"
477 Email: hlandau@devever.net