idnits 2.17.1 draft-landau-acme-caa-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 19, 2016) is 2745 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4648' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC7517' is defined on line 304, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-03 ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACME Working Group H. Landau 3 Internet-Draft October 19, 2016 4 Intended status: Informational 5 Expires: April 22, 2017 7 CA Account URI Binding for CAA Records 8 draft-landau-acme-caa-01 10 Abstract 12 The CAA DNS record allows a domain to communicate issuance policy to 13 CAs, but only allows a domain to define policy with CA-level 14 granularity. However, the CAA specification also provides facilities 15 for extension to admit more granular, CA-specific policy. This 16 specification defines two such parameters, one allowing specific 17 accounts of a CA to be identified by URI and one allowing specific 18 methods of domain control validation as defined by the ACME protocol 19 to be required. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 22, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Extensions to the CAA Record: account-uri Parameter . . . . . 2 58 3.1. Use with ACME . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Use without ACME . . . . . . . . . . . . . . . . . . . . 3 60 4. Extensions to the CAA Record: acme-methods Parameter . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 5.1. URI Ambiguity . . . . . . . . . . . . . . . . . . . . . . 4 63 5.2. Authorization Freshness . . . . . . . . . . . . . . . . . 5 64 5.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.4. Use without DNSSEC . . . . . . . . . . . . . . . . . . . 6 66 5.5. Restrictions Supercedeable by DNS Delegation . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 69 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 This specification defines two parameters for the 'issue' and 75 'issuewild' properties of the Certification Authority Authorization 76 (CAA) DNS resource record [RFC6844]. The first, 'account-uri', 77 allows authorization conferred by a CAA policy to be restricted to 78 specific accounts of a CA, which are identified by URIs. The second, 79 'acme-methods', allows the set of validation [I-D.ietf-acme-acme] 80 methods supported by an ACME-based CA to validate domain control to 81 be limited to a subset of the full set of methods which it supports. 83 2. Terminology 85 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 86 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 87 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 88 [RFC2119] and indicate requirement levels for compliant CAA-URI 89 implementations. 91 3. Extensions to the CAA Record: account-uri Parameter 93 A CAA parameter "account-uri" is defined for the 'issue' and 94 'issuewild' properties defined by [RFC6844]. The value of this 95 parameter, if specified, MUST be a URI [RFC3986] identifying a 96 specific CA account. 98 "CA account" means an object maintained by a specific CA representing 99 a specific entity, or group of related entities, which may request 100 the issuance of certificates. 102 The presence of this parameter constrains the property to which it is 103 attached. A CA MUST only consider a property with an "account-uri" 104 parameter to authorize issuance where the URI specified is an URI 105 that the CA recognises as identifying the account making a 106 certificate issuance request. 108 If a certificate issuance request is made to a CA such that no 109 account URI is available, because the request is made in the absence 110 of any account or the account has no URI assigned to it, a CA MUST 111 NOT consider any property having an "account-uri" parameter as 112 authorizing issuance. 114 If an CA finds multiple CAA records pertaining to it (i.e., having 115 property 'issue' or 'issuewild' as applicable and a domain that the 116 CA recognises as its own) with different "account-uri" parameters, 117 the CA MUST NOT consider the CAA record set to authorize issuance 118 unless at least one of the specified account URIs identifies the 119 account of the CA by which issuance is requested. A property without 120 an "account-uri" parameter matches any account. A property with an 121 invalid or unrecognised "account-uri" parameter is unsatisfiable. 123 The presence of an "account-uri" parameter does not replace or 124 supercede the need to validate the domain name specified in an 125 "issue" or "issuewild" record in the manner described in the CAA 126 specification. CAs MUST still perform such verification. For 127 example, a CAA property which specifies a domain name belonging to CA 128 A and an account URI identifying an account at CA B is unsatisfiable. 130 3.1. Use with ACME 132 An ACME [I-D.ietf-acme-acme] registration object MAY be identified by 133 setting the "account-uri" parameter to the URI of the ACME 134 registration object. 136 Implementations of this specification which also implement ACME MUST 137 recognise such URIs. 139 3.2. Use without ACME 141 The "account-uri" specification provides a general mechanism to 142 identify entities which may request certificate issuance via URIs. 143 The use of specific kinds of URI may be specified in future RFCs, and 144 CAs not implementing ACME MAY assign and recognise their own URIs 145 arbitrarily. 147 4. Extensions to the CAA Record: acme-methods Parameter 149 A CAA parameter "acme-methods" is also defined for the 'issue' and 150 'issuewild' properties. The value of this parameter, if specified, 151 MUST be a comma-separated string of ACME challenge method names. The 152 use of this parameter is specific to ACME and CAs implementing it. 154 The presence of this parameter constrains the property to which it is 155 attached. A CA MUST only consider a property with the "acme-methods" 156 parameter to authorize issuance where the name of the challenge 157 method being used is one of the names listed in the comma separated 158 list. 160 The special method value 'non-acme' is defined. Where a CA supports 161 ACME, but also allows the issuance of certificates by other means, it 162 MUST ensure that all of its other issuance channels recognise the 163 'acme-methods' parameter. For the purposes of validation, such non- 164 ACME transactions shall be considered to have a method name of 'non- 165 acme'. Thus, domains implementing CAA which wish to nominate a CA 166 which supports issuance via both ACME and non-ACME means can choose 167 whether to allow one or both. 169 5. Security Considerations 171 This specification describes an extension to the CAA record 172 specification increasing the granularity at which CAA policy can be 173 expressed. This allows the set of entities capable of successfully 174 requesting issuance of certificates for a given domain to be 175 restricted beyond that which would otherwise be possible, while still 176 allowing issuance for specific accounts of a CA. This improves the 177 security of issuance for domains which choose to employ it, when 178 combined with a CA which implements this specification. 180 5.1. URI Ambiguity 182 Suppose that CA A recognises "a.example.com" as identifying itself, 183 CA B is a subsidiary of CA A which recognises both "a.example.com" 184 and "b.example.com" as identifying itself. 186 Suppose that both CA A and CA B issue account URIs of the form 188 "account-id:1234" 190 If the CA domain name in a CAA record is specified as "a.example.com" 191 then this could be construed as identifying account number 1234 at CA 192 A or at CA B. These may be different accounts, creating ambiguity. 194 Thus, CAs MUST ensure that the URIs they recognise as pertaining to a 195 specific account of that CA are unique within the scope of all domain 196 names which they recognise as identifying that CA for the purpose of 197 CAA record validation. 199 It is RECOMMENDED that CAs satisfy this requirement by using URIs 200 which include an authority: 202 "https://a.example.com/account/1234" 204 5.2. Authorization Freshness 206 The CAA specification governs the act of issuance by a CA. In some 207 cases, a CA may establish authorization for an account to request 208 certificate issuance for a specific domain separately to the act of 209 issuance itself. Such authorization may occur substantially prior to 210 a certificate issuance request. The CAA policy expressed by a domain 211 may have changed in the meantime, creating the risk that a CA will 212 issue certificates in a manner inconsistent with the presently 213 published CAA policy. 215 CAs SHOULD consider adopting practices to reduce the risk of such 216 circumstances. Possible countermeasures include issuing 217 authorizations with very limited validity periods, such as an hour, 218 or revalidating the CAA policy for a domain at certificate issuance 219 time. 221 5.3. DNSSEC 223 Where a domain chooses to secure its nameservers using DNSSEC, the 224 authenticity of its DNS data can be assured, providing that a CA 225 makes all DNS resolutions via an appropriate, trusted DNSSEC- 226 validating resolver. A domain can use this property to protect 227 itself from the threat posed by a global adversary capable of 228 performing man-in-the-middle attacks, which is not ordinarily 229 mitigated by the "domain validation" model. 231 In order to facilitate this, a CA validation process must either rely 232 solely on information obtained via DNSSEC, or meaningfully bind the 233 other parts of the validation transaction using material obtained via 234 DNSSEC. 236 The CAA parameters described in this specification can be used to 237 ensure that only validation methods meeting these criteria are used. 238 In particular, a domain secured via DNSSEC SHOULD either: 240 1. Use the "account-uri" parameter to ensure that only accounts 241 which it controls are authorized to obtain certificates, or 243 2. Exclusively use validation methods which rely solely on 244 information obtained via DNSSEC, and use the "acme-methods" 245 parameter to ensure that only such methods are used. 247 5.4. Use without DNSSEC 249 Where a domain does not secure its nameservers using DNSSEC, or one 250 or more of the CAs it authorizes do not perform CAA validation 251 lookups using a trusted DNSSEC-validating resolver, use of the 252 "account-uri" parameter does not confer additional security against 253 an attacker capable of performing a man-in-the-middle attack against 254 all validation attempts made by a CA, as such an attacker could 255 simply fabricate the responses to DNS lookups for CAA records. 257 In this case, the "account-uri" mechanism still provides an effective 258 means of administrative control over issuance, except where control 259 over DNS is subdelegated (see below). 261 5.5. Restrictions Supercedeable by DNS Delegation 263 Because CAA records are located during validation by walking up the 264 DNS hierarchy until one or more records are found, the use of the 265 "account-uri" parameter, or any CAA policy, is not an effective way 266 to restrict or control issuance for subdomains of a domain, where 267 control over those subdomains is delegated to another party (such as 268 via DNS delegation or providing limited access to manage subdomain 269 DNS records). 271 6. IANA Considerations 273 None. As per the CAA specification, the parameter namespace for the 274 CAA 'issue' and 'issuewild' properties has CA-defined semantics. 275 This document merely specifies a RECOMMENDED semantic for a parameter 276 of the name "account-uri". 278 7. Normative References 280 [I-D.ietf-acme-acme] 281 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 282 Certificate Management Environment (ACME)", draft-ietf- 283 acme-acme-03 (work in progress), July 2016. 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 287 RFC2119, March 1997, 288 . 290 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 291 Resource Identifier (URI): Generic Syntax", STD 66, RFC 292 3986, DOI 10.17487/RFC3986, January 2005, 293 . 295 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 296 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 297 . 299 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 300 Authority Authorization (CAA) Resource Record", RFC 6844, 301 DOI 10.17487/RFC6844, January 2013, 302 . 304 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/ 305 RFC7517, May 2015, 306 . 308 Appendix A. Examples 310 The following shows an example DNS zone file fragment which nominates 311 two account URIs as authorized to issue certificates for the domain 312 "example.com". Issuance is restricted to the CA "example.net". 314 example.com. IN CAA 0 issue "example.net; \ 315 account-uri=https://example.net/registration/1234" 316 example.com. IN CAA 0 issue "example.net; \ 317 account-uri=https://example.net/registration/2345" 319 The following shows a zone file fragment which restricts the ACME 320 methods which can be used; only ACME methods "dns-01" and "xyz-01" 321 can be used. 323 example.com. IN CAA 0 issue "example.net; \ 324 acme-methods=dns-01,xyz-01" 326 The following shows a zone file fragment in which one account can be 327 used to issue with the "dns-01" method and one account can be used to 328 issue with the "http-01" method. 330 example.com. IN CAA 0 issue "example.net; \ 331 account-uri=https://example.net/registration/1234; \ 332 acme-methods=dns-01" 333 example.com. IN CAA 0 issue "example.net; \ 334 account-uri=https://example.net/registration/2345; \ 335 acme-methods=http-01" 337 The following shows a zone file fragment in which only ACME method 338 "dns-01" can be used, but non-ACME methods of issuance are also 339 allowed. 341 example.com. IN CAA 0 issue "example.net; \ 342 acme-methods=dns-01,non-acme" 344 Author's Address 346 Hugo Landau 348 Email: hlandau@devever.net