idnits 2.17.1 draft-friel-acme-subdomains-05.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 date (June 23, 2021) is 1028 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Friel 3 Internet-Draft R. Barnes 4 Intended status: Standards Track Cisco 5 Expires: December 25, 2021 T. Hollebeek 6 DigiCert 7 M. Richardson 8 Sandelman Software Works 9 June 23, 2021 11 ACME for Subdomains 12 draft-friel-acme-subdomains-05 14 Abstract 16 This document outlines how ACME can be used by a client to obtain a 17 certificate for a subdomain identifier from a certification 18 authority. The client has fulfilled a challenge against a parent 19 domain but does not need to fulfill a challenge against the explicit 20 subdomain as certificate policy allows issuance of the subdomain 21 certificate without explicit subdomain ownership proof. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 25, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. ACME Workflow and Identifier Requirements . . . . . . . . . . 3 60 4. ACME Issuance of Subdomain Certificates . . . . . . . . . . . 5 61 4.1. ACME Challenge Type . . . . . . . . . . . . . . . . . . . 5 62 4.2. Authorization Object . . . . . . . . . . . . . . . . . . 5 63 4.3. Pre-Authorization . . . . . . . . . . . . . . . . . . . . 6 64 4.4. New Orders . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.5. Directory Object Metadata . . . . . . . . . . . . . . . . 9 66 5. Illustrative Call Flow . . . . . . . . . . . . . . . . . . . 9 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 6.1. Authorization Object Fields Registry . . . . . . . . . . 15 69 6.2. Directory Object Metadata Fields Registry . . . . . . . . 15 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 7.1. ACME Server Policy Considerations . . . . . . . . . . . . 17 72 8. Informative References . . . . . . . . . . . . . . . . . . . 17 73 Appendix A. CA Browser Forum Baseline Requirements Extracts . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 76 1. Introduction 78 ACME [RFC8555] defines a protocol that a certification authority (CA) 79 and an applicant can use to automate the process of domain name 80 ownership validation and X.509v3 (PKIX) [RFC5280] certificate 81 issuance. This document outlines how ACME can be used to issue 82 subdomain certificates, without requiring the ACME client to 83 explicitly fulfill an ownership challenge against the subdomain 84 identifiers - the ACME client need only fulfill an ownership 85 challenge against a parent domain identifier. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 The following terms are defined in the CA/Browser Forum Baseline 96 Requirements [CAB] and are reproduced here 97 o Authorization Domain Name (ADN): The Domain Name used to obtain 98 authorization for certificate issuance for a given FQDN. The CA 99 may use the FQDN returned from a DNS CNAME lookup as the FQDN for 100 the purposes of domain validation. If the FQDN contains a 101 wildcard character, then the CA MUST remove all wildcard labels 102 from the left most portion of requested FQDN. The CA may prune 103 zero or more labels from left to right until encountering a Base 104 Domain Name and may use any one of the intermediate values for the 105 purpose of domain validation 107 o Base Domain Name: The portion of an applied-for FQDN that is the 108 first domain name node left of a registry-controlled or public 109 suffix plus the registry-controlled or public suffix (e.g. 110 "example.co.uk" or "example.com"). For FQDNs where the right-most 111 domain name node is a gTLD having ICANN Specification 13 in its 112 registry agreement, the gTLD itself may be used as the Base Domain 113 Name. 115 o Certification Authority (CA): An organization that is responsible 116 for the creation, issuance, revocation, and management of 117 Certificates. The term applies equally to both Roots CAs and 118 Subordinate CAs 120 o Domain Name: The label assigned to a node in the Domain Name 121 System 123 o Domain Namespace: The set of all possible Domain Names that are 124 subordinate to a single node in the Domain Name System 126 o Fully-Qualified Domain Name (FQDN): A Domain Name that includes 127 the labels of all superior nodes in the Internet Domain Name 128 System. 130 The following terms are used in this document: 132 o CSR: Certificate Signing Request 134 o Parent Domain: a node in the Domain Name System that has a Domain 135 Name and a subordinate Domain Namespace 137 o Subdomain: a Domain Name that is in the Domain Namespace of a 138 given Parent Domain 140 3. ACME Workflow and Identifier Requirements 142 A typical ACME workflow for issuance of certificates is as follows: 144 1. client POSTs a newOrder request that contains a set of 145 "identifiers" 147 2. server replies with a set of "authorizations" and a "finalize" 148 URI 150 3. client sends POST-as-GET requests to retrieve the 151 "authorizations", with the downloaded "authorization" object(s) 152 containing the "identifier" that the client must prove that they 153 control 155 4. client proves control over the "identifier" in the 156 "authorization" object by completing the specified challenge, for 157 example, by publishing a DNS TXT record 159 5. client POSTs a CSR to the "finalize" API 161 6. server replies with an updated order object that includes a 162 "certificate" URI 164 7. client sends POST-as-GET request to the "certificate" URI to 165 download the certificate 167 ACME places the following restrictions on "identifiers": 169 o section 7.1.3: The authorizations required are dictated by server 170 policy; there may not be a 1:1 relationship between the order 171 identifiers and the authorizations required. 173 o section 7.1.4: the only type of "identifier" defined by the ACME 174 specification is a fully qualified domain name: "The only type of 175 identifier defined by this specification is a fully qualified 176 domain name (type: "dns"). The domain name MUST be encoded in the 177 form in which it would appear in a certificate." 179 o Section 7.4: the "identifier" in the CSR request must match the 180 "identifier" in the newOrder request: "The CSR MUST indicate the 181 exact same set of requested identifiers as the initial newOrder 182 request." 184 o Sections 8.3: the "identifier", or FQDN, in the "authorization" 185 object must be used when fulfilling challenges via HTTP: 186 "Construct a URL by populating the URL template ... where the 187 domain field is set to the domain name being verified" 189 o Section 8.4: the "identifier", or FQDN, in the "authorization" 190 object must be used when fulfilling challenges via DNS: "The 191 client constructs the validation domain name by prepending the 192 label "_acme-challenge" to the domain name being validated." 194 ACME does not mandate that the "identifier" in a newOrder request 195 matches the "identifier" in "authorization" objects. 197 4. ACME Issuance of Subdomain Certificates 199 As noted in the previous section, ACME does not mandate that the 200 "identifier" in a newOrder request matches the "identifier" in 201 "authorization" objects. This means that the ACME specification does 202 not preclude an ACME server processing newOrder requests and issuing 203 certificates for a subdomain without requiring a challenge to be 204 fulfilled against that explicit subdomain. 206 ACME server policy could allow issuance of certificates for a 207 subdomain to a client where the client only has to fulfill an 208 authorization challenge for a parent domain of that subdomain. This 209 allows a flow where a client proves ownership of, for example, 210 "example.org" and then successfully obtains a certificate for 211 "sub.example.org". 213 ACME server policy is out of scope of this document, however some 214 commentary is provided in Section 7.1. 216 Clients need a mechanism to instruct the ACME server that they are 217 requesting authorization for a Domain Namespace subordinate to a 218 given ADN, as opposed to just requesting authorization for an 219 explicit ADN identifier. Clients need a mechanism to do this in both 220 newAuthz and newOrder requests. ACME servers need a mechanism to 221 indicate to clients that authorization objects are valid for an 222 entire Domain Namespace. These are described in this section. 224 4.1. ACME Challenge Type 226 ACME for subdomains is restricted for use with "dns-01" challenges. 227 If a server policy allows a client to fulfill a challenge against a 228 parent ADN of a requested certificate FQDN identifier, then the 229 server MUST issue a "dns-01" challenge against that parent ADN. 231 4.2. Authorization Object 233 ACME [RFC8555] section 7.1.4 defines the authorization object. When 234 ACME server policy allows authorization for Domain Namespaces 235 subordinate to an ADN, the server indicates this by including the 236 "domainNamespace" flag in the authorization object for that ADN 237 identifier: 239 domainNamespace (optional, boolean): This field MUST be present 240 and true for authorizations where ACME server policy allows 241 certificates to be issued for any Domain Name in the Domain 242 Namespace subordinate to the ADN specified in the 'identifier' 243 field of the authorization object. 245 The following example shows an authorization object for the ADN 246 "example.org" where the authorization covers the Domain Namespace 247 subordinate to "example.org". 249 { 250 "status": "valid", 251 "expires": "2015-03-01T14:09:07.99Z", 253 "identifier": { 254 "type": "dns", 255 "value": "example.org" 256 }, 258 "challenges": [ 259 { 260 "url": "https://example.com/acme/chall/prV_B7yEyA4", 261 "type": "http-01", 262 "status": "valid", 263 "token": "DGyRejmCefe7v4NfDGDKfA", 264 "validated": "2014-12-01T12:05:58.16Z" 265 } 266 ], 268 "domainNamespace": true 269 } 271 If the "domainNamespace" field is not included, then the assumed 272 default value is false. 274 4.3. Pre-Authorization 276 The standard ACME workflow has authorization objects created 277 reactively in response to a certificate order. ACME also allows for 278 pre-authorization, where clients obtain authorization for an 279 identifier proactively, outside of the context of a specific 280 issuance. With the ACME pre-authorization flow, a client can pre- 281 authorize for a parent ADN once, and then issue multiple newOrder 282 requests for certificates with identifiers in the Domain Namespace 283 subordinate to that ADN. 285 ACME [RFC8555] section 7.4.1 defines the "identifier" object for 286 newAuthz requests. One additional field for the "identifier" object 287 is defined: 289 domainNamespace (optional, boolean): An ACME client sets this flag 290 to indicate to the server that it is requesting an authorization 291 for the Domain Namespace subordinate to the specified ADN 292 identifier value 294 Clients include the flag in the "identifier" object of newAuthz 295 requests to indicate that they are requesting a Domain Namespace 296 authorization. In the following example newAuthz payload, the client 297 is requesting pre-authorization for the Domain Namespace subordinate 298 to "example.org". 300 "payload": base64url({ 301 "identifier": { 302 "type": "dns", 303 "value": "example.org", 304 "domainNamespace": true 305 } 306 }) 308 If the server is willing to allow a single authorization for the 309 Domain Namespace, and there is not an existing authorization object 310 for the identifier, then it will create an authorization object and 311 include the "domainNamespace" flag with value of true. If the server 312 policy does not allow creation of Domain Namespace authorizations 313 subordinate to that ADN, the server can create an authorization 314 object for the indicated identifier, and include the 315 "domainNamespace" flag with value of false. In both scenarios, 316 handling of the pre-authorization follows the process documented in 317 ACME section 7.4.1. 319 4.4. New Orders 321 Clients need a mechanism to optionally indicate to servers whether or 322 not they are authorized to fulfill challenges against parent ADNs for 323 a given identifier FQDN. For example, if a client places an order 324 for an identifier "foo.bar.example.org", and is authorized to update 325 DNS TXT records against the parent ADNs "bar.example.org" or 326 "example.org", then the client needs a mechanism to indicate control 327 over the parent ADNs to the ACME server. 329 This can be achieved by adding an optional field "domainNamespace" to 330 the "identifiers" field in the order object: 332 domainNamespace (optional, string): This is the parent ADN of a 333 Domain Namespace that the requested identifier belongs to. The 334 client MUST have DNS control over the parent ADN. 336 This field specifies the ADN of the Domain Namespace that the client 337 has DNS control over, and is capable of fulfilling challenges 338 against. Based on server policy, the server can choose to issue a 339 challenge against any parent domain of the identifier in the Domain 340 Namespace up to and including the specified "domainNamespace", and 341 create a corresponding authorization object against the chosen 342 identifier. 344 In the following example newOrder payload, the client requests a 345 certificate for identifier "foo.bar.example.org" and indicates that 346 it can fulfill a challenge against the parent ADN and the Domain 347 Namespace subordinate to "bar.example.org". The server can then 348 choose to issue a challenge against either "foo.bar.example.org" or 349 "bar.example.org" identifiers. 351 "payload": base64url({ 352 "identifiers": [ 353 { "type": "dns", 354 "value": "foo.bar.example.org", 355 "domainNamespace": "bar.example.org" } 356 ], 357 "notBefore": "2016-01-01T00:04:00+04:00", 358 "notAfter": "2016-01-08T00:04:00+04:00" 359 }) 361 In the following example newOrder payload, the client requests a 362 certificate for identifier "foo.bar.example.org" and indicates that 363 it can fulfill a challenge against the parent ADN and the Domain 364 Namespace subordinate to "example.org". The server can then choose 365 to issue a challenge against any one of "foo.bar.example.org", 366 "bar.example.org" or "example.org" identifiers. 368 "payload": base64url({ 369 "identifiers": [ 370 { "type": "dns", 371 "value": "foo.bar.example.org", 372 "domainNamespace": "example.org" } 373 ], 374 "notBefore": "2016-01-01T00:04:00+04:00", 375 "notAfter": "2016-01-08T00:04:00+04:00" 376 }) 378 If the client is unable to fulfill authorizations against parent 379 ADNs, the client should not include the "domainNamespace" field. 381 Server newOrder handling generally follows the process documented 382 ACME section 7.4. If the server is willing to allow Domain Namespace 383 authorizations for the ADN specified in "domainNamespace", then it 384 creates an authorization object against that ADN and includes the 385 "domainNamespace" flag with a value of true. If the server policy 386 does not allow creation of Domain Namespace authorizations against 387 that ADN, then it can create an authorization object for the 388 indicated identifier value, and include the "domainNamespace" flag 389 with value of false. 391 4.5. Directory Object Metadata 393 An ACME server can advertise support for authorization of Domain 394 Namespaces by including the following boolean flag in its "ACME 395 Directory Metadata Fields" registry: 397 domainNamespace (optional, bool): Indicates if an ACME server 398 supports authorization of Domain Namespaces. 400 If not specified, then no default value is assumed. If an ACME 401 server supports authorization of Domain Namespaces, it can indicate 402 this by including this field with a value of "true". 404 5. Illustrative Call Flow 406 The call flow illustrated here uses the ACME pre-authorization flow 407 using DNS-based proof of ownership. 409 +--------+ +------+ +-----+ 410 | Client | | ACME | | DNS | 411 +--------+ +------+ +-----+ 412 | | | 413 STEP 1: Pre-Authorization of parent domain 414 | | | 415 | POST /newAuthz | | 416 | "example.org" | | 417 |--------------------------->| | 418 | | | 419 | 201 authorizations | | 420 |<---------------------------| | 421 | | | 422 | Publish DNS TXT | | 423 | "example.org" | | 424 |--------------------------------------->| 425 | | | 426 | POST /challenge | | 427 |--------------------------->| | 428 | | Verify | 429 | |---------->| 430 | 200 status=valid | | 431 |<---------------------------| | 432 | | | 433 | Delete DNS TXT | | 434 | "example.org" | | 435 |--------------------------------------->| 436 | | | 437 STEP 2: Place order for sub1.example.org 438 | | | 439 | POST /newOrder | | 440 | "sub1.example.org" | | 441 |--------------------------->| | 442 | | | 443 | 201 status=ready | | 444 |<---------------------------| | 445 | | | 446 | POST /finalize | | 447 | CSR SAN "sub1.example.org" | | 448 |--------------------------->| | 449 | | | 450 | 200 OK status=valid | | 451 |<---------------------------| | 452 | | | 453 | POST /certificate | | 454 |--------------------------->| | 455 | | | 456 | 200 OK | | 457 | PEM SAN "sub1.example.org" | | 458 |<---------------------------| | 459 | | | 460 STEP 3: Place order for sub2.example.org 461 | | | 462 | POST /newOrder | | 463 | "sub2.example.org" | | 464 |--------------------------->| | 465 | | | 466 | 201 status=ready | | 467 |<---------------------------| | 468 | | | 469 | POST /finalize | | 470 | CSR SAN "sub2.example.org" | | 471 |--------------------------->| | 472 | | | 473 | 200 OK status=valid | | 474 |<---------------------------| | 475 | | | 476 | POST /certificate | | 477 |--------------------------->| | 478 | | | 479 | 200 OK | | 480 | PEM SAN "sub2.example.org" | | 481 |<---------------------------| | 483 o STEP 1: Pre-authorization of Domain Namespace 485 The client sends a newAuthz request for the parent ADN of the 486 Domain Namespace including the "domainNamespace" flag in the 487 identifier object. 489 POST /acme/new-authz HTTP/1.1 490 Host: example.com 491 Content-Type: application/jose+json 493 { 494 "protected": base64url({ 495 "alg": "ES256", 496 "kid": "https://example.com/acme/acct/evOfKhNU60wg", 497 "nonce": "uQpSjlRb4vQVCjVYAyyUWg", 498 "url": "https://example.com/acme/new-authz" 499 }), 500 "payload": base64url({ 501 "identifier": { 502 "type": "dns", 503 "value": "example.org", 504 "domainNamespace": true 505 } 506 }), 507 "signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps" 508 } 510 The server creates and returns an authorization object for the 511 identifier including the "domainNamespace" flag. The object is 512 initially in "pending" state. Once the client completes the 513 challenge, the server will transition the authorization object and 514 associated challenge object status to "valid". 516 { 517 "status": "pending", 518 "expires": "2015-03-01T14:09:07.99Z", 520 "identifier": { 521 "type": "dns", 522 "value": "example.org" 523 }, 525 "challenges": [ 526 { 527 "url": "https://example.com/acme/chall/prV_B7yEyA4", 528 "type": "http-01", 529 "status": "pending", 530 "token": "DGyRejmCefe7v4NfDGDKfA", 531 "validated": "2014-12-01T12:05:58.16Z" 532 } 533 ], 535 "domainNamespace": true 536 } 538 o STEP 2: The client places a newOrder for "sub1.example.org" 540 The client sends a newOrder request to the server and includes the 541 subdomain identifier. Note that the identifier is in the Domain 542 Namespace that has been pre-authorised in step 1. The client does 543 not need to include the "domainNamespace" field in the 544 "identifier" object as it has already pre-authorized the Domain 545 Namespace. 547 POST /acme/new-order HTTP/1.1 548 Host: example.com 549 Content-Type: application/jose+json 551 { 552 "protected": base64url({ 553 "alg": "ES256", 554 "kid": "https://example.com/acme/acct/evOfKhNU60wg", 555 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 556 "url": "https://example.com/acme/new-order" 557 }), 558 "payload": base64url({ 559 "identifiers": [ 560 { "type": "dns", "value": "sub1.example.org" } 561 ], 562 "notBefore": "2016-01-01T00:04:00+04:00", 563 "notAfter": "2016-01-08T00:04:00+04:00" 564 }), 565 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 566 } 568 As an authorization object already exists for the parent ADN of the 569 Domain Namespace, the server replies with an order object with a 570 status of "valid" that includes a link to the existing "valid" 571 authorization object. 573 HTTP/1.1 201 Created 574 Replay-Nonce: MYAuvOpaoIiywTezizk5vw 575 Link: ;rel="index" 576 Location: https://example.com/acme/order/TOlocE8rfgo 578 { 579 "status": "valid", 580 "expires": "2016-01-05T14:09:07.99Z", 582 "notBefore": "2016-01-01T00:00:00Z", 583 "notAfter": "2016-01-08T00:00:00Z", 585 "identifiers": [ 586 { "type": "dns", "value": "sub1.example.org" } 587 ], 589 "authorizations": [ 590 "https://example.com/acme/authz/PAniVnsZcis" 591 ], 593 "finalize": "https://example.com/acme/order/TOlocrfgo/finalize" 594 } 596 The client can proceed to finalize the order and download the 597 certificate for "sub1.example.org". 599 o STEP 3: The client places a newOrder for "sub2.example.org" 601 The client sends a newOrder request to the server and includes the 602 subdomain identifier. Note that the identifier is in the Domain 603 Namespace that has been pre-authorised in step 1. The client does 604 not need to include the "domainNamespace" field in the 605 "identifier" object as it has already pre-authorized the Domain 606 Namespace. 608 POST /acme/new-order HTTP/1.1 609 Host: example.com 610 Content-Type: application/jose+json 612 { 613 "protected": base64url({ 614 "alg": "ES256", 615 "kid": "https://example.com/acme/acct/evOfKhNU60wg", 616 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 617 "url": "https://example.com/acme/new-order" 618 }), 619 "payload": base64url({ 620 "identifiers": [ 621 { "type": "dns", "value": "sub2.example.org" } 622 ], 623 "notBefore": "2016-01-01T00:04:00+04:00", 624 "notAfter": "2016-01-08T00:04:00+04:00" 625 }), 626 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 627 } 629 As an authorization object already exists for the parent ADN of the 630 Domain Namespace, the server replies with an order object with a 631 status of "valid" that includes a link to the existing "valid" 632 authorization object. 634 HTTP/1.1 201 Created 635 Replay-Nonce: MYAuvOpaoIiywTezizk5vw 636 Link: ;rel="index" 637 Location: https://example.com/acme/order/TOlocE8rfgo 639 { 640 "status": "valid", 641 "expires": "2016-01-05T14:09:07.99Z", 643 "notBefore": "2016-01-01T00:00:00Z", 644 "notAfter": "2016-01-08T00:00:00Z", 646 "identifiers": [ 647 { "type": "dns", "value": "sub1.example.org" } 648 ], 650 "authorizations": [ 651 "https://example.com/acme/authz/PAniVnsZcis" 652 ], 654 "finalize": "https://example.com/acme/order/ROni7rdde/finalize" 655 } 657 The client can proceed to finalize the order and download the 658 certificate for "sub2.example.org". 660 6. IANA Considerations 662 6.1. Authorization Object Fields Registry 664 The following field is added to the "ACME Authorization Object 665 Fields" registry defined in ACME [RFC8555]. 667 +-----------------+------------+--------------+-----------+ 668 | Field Name | Field Type | Configurable | Reference | 669 +-----------------+------------+--------------+-----------+ 670 | domainNamespace | boolean | false | RFC XXXX | 671 +-----------------+------------+--------------+-----------+ 673 6.2. Directory Object Metadata Fields Registry 675 The following field is added to the "ACME Directory Metadata Fields" 676 registry defined in ACME [RFC8555]. 678 +-----------------+------------+-----------+ 679 | Field Name | Field Type | Reference | 680 +-----------------+------------+-----------+ 681 | domainNamespace | boolean | RFC XXXX | 682 +-----------------+------------+-----------+ 684 7. Security Considerations 686 This document documents enhancements to ACME [RFC8555] that optimize 687 the protocol flows for issuance of certificates for subdomains. The 688 underlying goal of ACME for Subdomains remains the same as that of 689 ACME: managing certificates that attest to identifier/key bindings 690 for these subdomains. Thus, ACME for Subdomains has the same two 691 security goals as ACME: 693 1. Only an entity that controls an identifier can get an 694 authorization for that identifier 696 2. Once authorized, an account key's authorizations cannot be 697 improperly used by another account 699 ACME for Subdomains makes no changes to: 701 o account or account key management 703 o ACME channel establishment, security mechanisms or threat model 705 o Validation channel establishment, security mechanisms or threat 706 model 708 Therefore, all Security Considerations in ACME in the following areas 709 are equally applicable to ACME for Subdomains: 711 o Threat Model 713 o Integrity of Authorizations 715 o Denial-of-Service Considerations 717 o Server-Side Request Forgery 719 o CA Policy Considerations 721 Some additional comments on ACME server policy are given in the 722 following section. 724 7.1. ACME Server Policy Considerations 726 The ACME for Subdomains and the ACME specifications do not mandate 727 any specific ACME server or CA policies, or any specific use cases 728 for issuance of certificates. For example, an ACME server could be 729 used: 731 o to issue Web PKI certificates where the ACME server must comply 732 with CA/Browser Forum [CAB] Baseline Requirements. 734 o as a Private CA for issuance of certificates within an 735 organisation. The organisation could enforce whatever policies 736 they desire on the ACME server. 738 o for issuance of IoT device certificates. There are currently no 739 IoT device certificate policies that are generally enforced across 740 the industry. Organizations issuing IoT device certificates can 741 enforce whatever policies they desire on the ACME server. 743 ACME server policy could specify whether: 745 o issuance of subdomain certificates is allowed based on proof of 746 ownership of a parent domain 748 o issuance of subdomain certificates is allowed, but only for a 749 specific set of parent domains 751 o whether DNS based proof of ownership, or HTTP based proof of 752 ownership, or both, are allowed 754 ACME server policy specification is explicitly out of scope of this 755 document. For reference, extracts from CA/Browser Forum Baseline 756 Requirements are given in the appendices. 758 8. Informative References 760 [CAB] CA/Browser Forum, "Baseline Requirements for the Issuance 761 and Management of Publicly-Trusted Certificates", n.d., 762 . 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, 767 DOI 10.17487/RFC2119, March 1997, 768 . 770 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 771 Housley, R., and W. Polk, "Internet X.509 Public Key 772 Infrastructure Certificate and Certificate Revocation List 773 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 774 . 776 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 777 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 778 May 2017, . 780 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 781 Kasten, "Automatic Certificate Management Environment 782 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 783 . 785 Appendix A. CA Browser Forum Baseline Requirements Extracts 787 The CA/Browser Forum Baseline Requirements [CAB] allow issuance of 788 subdomain certificates where authorization is only required for a 789 parent domain. Baseline Requirements version 1.7.1 states: 791 o Section: "1.6.1 Definitions": Authorization Domain Name: The 792 Domain Name used to obtain authorization for certificate issuance 793 for a given FQDN. The CA may use the FQDN returned from a DNS 794 CNAME lookup as the FQDN for the purposes of domain validation. 795 If the FQDN contains a wildcard character, then the CA MUST remove 796 all wildcard labels from the left most portion of requested FQDN. 797 The CA may prune zero or more labels from left to right until 798 encountering a Base Domain Name and may use any one of the 799 intermediate values for the purpose of domain validation. 801 o Section: "3.2.2.4.6 Agreed-Upon Change to Website": Once the FQDN 802 has been validated using this method, the CA MAY also issue 803 Certificates for other FQDNs that end with all the labels of the 804 validated FQDN. This method is suitable for validating Wildcard 805 Domain Names. 807 o Section: "3.2.2.4.7 DNS Change": Once the FQDN has been validated 808 using this method, the CA MAY also issue Certificates for other 809 FQDNs that end with all the labels of the validated FQDN. This 810 method is suitable for validating Wildcard Domain Names. 812 Authors' Addresses 814 Owen Friel 815 Cisco 817 Email: ofriel@cisco.com 818 Richard Barnes 819 Cisco 821 Email: rlb@ipv.sx 823 Tim Hollebeek 824 DigiCert 826 Email: tim.hollebeek@digicert.com 828 Michael Richardson 829 Sandelman Software Works 831 Email: mcr+ietf@sandelman.ca