idnits 2.17.1 draft-friel-acme-subdomains-04.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 20 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2021) is 1144 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) == Missing Reference: 'TODO' is mentioned on line 267, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: September 10, 2021 T. Hollebeek 6 DigiCert 7 M. Richardson 8 Sandelman Software Works 9 March 09, 2021 11 ACME for Subdomains 12 draft-friel-acme-subdomains-04 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 September 10, 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. Parent Domain Control Indication . . . . . . . . . . . . 5 63 4.3. Pre-Authorization . . . . . . . . . . . . . . . . . . . . 7 64 4.4. Illustrative Call Flow . . . . . . . . . . . . . . . . . 7 65 4.5. newOrder and newAuthz Handling . . . . . . . . . . . . . 8 66 4.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. Resource Enhancements . . . . . . . . . . . . . . . . . . . . 10 68 5.1. Authorization Object . . . . . . . . . . . . . . . . . . 10 69 5.2. Identifier Object . . . . . . . . . . . . . . . . . . . . 10 70 5.3. Directory Object Metadata . . . . . . . . . . . . . . . . 11 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. Authorization Object Fields Registry . . . . . . . . . . 11 73 6.2. Directory Object Metadata Fields Registry . . . . . . . . 11 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 7.1. ACME Server Policy Considerations . . . . . . . . . . . . 12 76 8. Informative References . . . . . . . . . . . . . . . . . . . 13 77 Appendix A. CA Browser Forum Baseline Requirements Extracts . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 ACME [RFC8555] defines a protocol that a certification authority (CA) 83 and an applicant can use to automate the process of domain name 84 ownership validation and X.509v3 (PKIX) [RFC5280] certificate 85 issuance. This document outlines how ACME can be used to issue 86 subdomain certificates, without requiring the ACME client to 87 explicitly fulfill an ownership challenge against the subdomain 88 identifiers - the ACME client need only fulfill an ownership 89 challenge against a parent domain identifier. 91 2. Terminology 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 BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 The following terms are defined in the CA/Browser Forum Baseline 100 Requirements [CAB] and are reproduced here: 102 o Base Domain Name: The portion of an applied-for FQDN that is the 103 first domain name node left of a registry-controlled or public 104 suffix plus the registry-controlled or public suffix (e.g. 105 "example.co.uk" or "example.com"). For FQDNs where the right-most 106 domain name node is a gTLD having ICANN Specification 13 in its 107 registry agreement, the gTLD itself may be used as the Base Domain 108 Name. 110 o ADN: Authorization Domain Name. The Domain Name used to obtain 111 authorization for certificate issuance for a given FQDN. 113 o Domain Name: The label assigned to a node in the Domain Name 114 System 116 o Domain Namespace: The set of all possible Domain Names that are 117 subordinate to a single node in the Domain Name System 119 The following terms are used in this document: 121 o CA: Certification Authority 123 o CSR: Certificate Signing Request 125 o FQDN: Fully Qualified Domain Name 127 o Parent Domain: a node in the Domain Name System that has a Domain 128 Name 130 o Subdomain: a Domain Name that is in the Domain Namespace of a 131 given Parent Domain 133 3. ACME Workflow and Identifier Requirements 135 A typical ACME workflow for issuance of certificates is as follows: 137 1. client POSTs a newOrder request that contains a set of 138 "identifiers" 140 2. server replies with a set of "authorizations" and a "finalize" 141 URI 143 3. client sends POST-as-GET requests to retrieve the 144 "authorizations", with the downloaded "authorization" object(s) 145 containing the "identifier" that the client must prove that they 146 control 148 4. client proves control over the "identifier" in the 149 "authorization" object by completing the specified challenge, for 150 example, by publishing a DNS TXT record 152 5. client POSTs a CSR to the "finalize" API 154 6. server replies with an updated order object that includes a 155 "certificate" URI 157 7. client sends POST-as-GET request to the "certificate" URI to 158 download the certificate 160 ACME places the following restrictions on "identifiers": 162 o section 7.1.3: The authorizations required are dictated by server 163 policy; there may not be a 1:1 relationship between the order 164 identifiers and the authorizations required. 166 o section 7.1.4: the only type of "identifier" defined by the ACME 167 specification is a fully qualified domain name: "The only type of 168 identifier defined by this specification is a fully qualified 169 domain name (type: "dns"). The domain name MUST be encoded in the 170 form in which it would appear in a certificate." 172 o Section 7.4: the "identifier" in the CSR request must match the 173 "identifier" in the newOrder request: "The CSR MUST indicate the 174 exact same set of requested identifiers as the initial newOrder 175 request." 177 o Sections 8.3: the "identifier", or FQDN, in the "authorization" 178 object must be used when fulfilling challenges via HTTP: 179 "Construct a URL by populating the URL template ... where the 180 domain field is set to the domain name being verified" 182 o Section 8.4: the "identifier", or FQDN, in the "authorization" 183 object must be used when fulfilling challenges via DNS: "The 184 client constructs the validation domain name by prepending the 185 label "_acme-challenge" to the domain name being validated." 187 ACME does not mandate that the "identifier" in a newOrder request 188 matches the "identifier" in "authorization" objects. 190 4. ACME Issuance of Subdomain Certificates 192 As noted in the previous section, ACME does not mandate that the 193 "identifier" in a newOrder request matches the "identifier" in 194 "authorization" objects. This means that the ACME specification does 195 not preclude an ACME server processing newOrder requests and issuing 196 certificates for a subdomain without requiring a challenge to be 197 fulfilled against that explicit subdomain. 199 ACME server policy could allow issuance of certificates for a 200 subdomain to a client where the client only has to fulfill an 201 authorization challenge for a parent domain of that subdomain. This 202 allows a flow where a client proves ownership of, for example, 203 "example.org" and then successfully obtains a certificate for 204 "sub.example.org". 206 ACME server policy is out of scope of this document, however some 207 commentary is provided in Section 7.1. 209 4.1. ACME Challenge Type 211 ACME for subdomains is restricted for use with "dns-01" challenges. 212 If a server policy allows a client to fulfill a challenge against a 213 parent ADN of a requested certificate FQDN identifier, then the 214 server MUST issue a "dns-01" challenge against that parent ADN. 216 4.2. Parent Domain Control Indication 218 Clients need a mechanism to optionally indicate to servers whether or 219 not they are authorized to fulfill challenges against parent ADNs for 220 a given identifier FQDN. For example, if a client places an order 221 for an identifier "foo.bar.example.org", but the client is not 222 authorized to update DNS TXT records against the parent ADNs 223 "bar.example.org" or "example.org", then we want to avoid the server 224 sending a challenge against those ADNs. 226 This can be achieved by adding an optional boolean 227 "parentDomainAuthorization" flag to the "identifiers" field in the 228 order object. This boolean flag indicates whether the client has 229 control of all parent ADNs and can fulfill challenges against all 230 parent domains. 232 In the following example, the client requests a certificate for 233 identifier "foo.bar.example.org" and indicates that it can fulfill a 234 challenge against the FQDN or any of the parent ADNs 235 "bar.example.org" or "example.org". The server can then choose which 236 of the ADNs to issue a challenge against. 238 { 239 "identifiers": [ 240 { "type": "dns", "value": "foo.bar.example.org", "parentDomainAuthorization": true } 241 ], 242 "notBefore": "2016-01-01T00:04:00+04:00", 243 "notAfter": "2016-01-08T00:04:00+04:00" 244 } 246 If the client is unable to fulfill, authorizations against parent 247 ADNs, the client should include this flag set to "false". When a 248 server receives an order with this flag set against an identifier, it 249 MUST NOT issue an authorization challenge against any of the 250 identifier's parent ADNs. 252 For example, if a client places an order for "foo.bar.example.org" 253 but does not have control over parent domains "bar.example.org" or 254 "example.org", the client should send the following order object: 256 { 257 "identifiers": [ 258 { "type": "dns", "value": "foo.bar.example.org", "parentDomainAuthorization": false }, 259 ], 260 "notBefore": "2016-01-01T00:04:00+04:00", 261 "notAfter": "2016-01-08T00:04:00+04:00" 262 } 264 If a client does not explicitly specify a value for 265 "parentDomainAuthorization", then no default value is assumed. 267 [TODO] Is this granular enough? Is there any need for a client to be 268 able to specify a subset of parent ADNs it has control over? e.g. if 269 a client wants a cert for "foo.bar.example.org" and has control over 270 "bar.example.org" but not "example.org". 272 { 273 "identifiers": [ 274 { "type": "dns", 275 "value": "foo.bar.example.org" 276 "adns": [ 277 "foo.bar.example.org", 278 "bar.example.org" 279 ] 280 } 281 ], 282 "notBefore": "2016-01-01T00:04:00+04:00", 283 "notAfter": "2016-01-08T00:04:00+04:00" 284 } 286 4.3. Pre-Authorization 288 The standard ACME workflow has authorization objects created 289 reactively in response to a certificate order. ACME also allows for 290 pre-authorization, where clients obtain authorization for an 291 identifier proactively, outside of the context of a specific 292 issuance. This document allows for both workflows, and Section 4.5 293 outlines how the ACME server handles newOrder and newAuthz requests 294 for both workflows. 296 It may make sense to use the ACME pre-authorization flow for the 297 subdomain use case, however, that is an operator implementation and 298 deployment decision. With the ACME pre-authorization flow, the 299 client could pre-authorize for the parent domain once, and then issue 300 multiple newOrder requests for certificates for multiple subdomains. 302 4.4. Illustrative Call Flow 304 The call flow illustrated here uses the ACME pre-authorization flow. 305 The call flow also illustrates the DNS-based proof of ownership 306 mechanism, but the subdomain workflow is equally valid for HTTP based 307 proof of ownership. 309 +--------+ +------+ +-----+ 310 | Client | | ACME | | DNS | 311 +--------+ +------+ +-----+ 312 | | | 313 STEP 1: Pre-Authorization of parent domain 314 | | | 315 | POST /newAuthz | | 316 | "example.org" | | 317 |--------------------->| | 318 | | | 319 | 201 authorizations | | 320 |<---------------------| | 321 | | | 322 | Publish DNS TXT | | 323 | "example.org" | | 324 |--------------------------------->| 325 | | | 326 | POST /challenge | | 327 |--------------------->| | 328 | | Verify | 329 | |---------->| 330 | 200 status=valid | | 331 |<---------------------| | 332 | | | 333 | Delete DNS TXT | | 334 | "example.org" | | 335 |--------------------------------->| 336 | | | 337 STEP 2: Place order for subdomain 338 | | | 339 | POST /newOrder | | 340 | "sub.example.org" | | 341 |--------------------->| | 342 | | | 343 | 201 status=ready | | 344 |<---------------------| | 345 | | | 346 | POST /finalize | | 347 | CSR "sub.example.org"| | 348 |--------------------->| | 349 | | | 350 | 200 OK status=valid | | 351 |<---------------------| | 352 | | | 353 | POST /certificate | | 354 |--------------------->| | 355 | | | 356 | 200 OK | | 357 | PKI "sub.example.org"| | 358 |<---------------------| | 360 4.5. newOrder and newAuthz Handling 362 Servers may consider validation of a parent domain sufficient 363 authorization for a subdomain. If a server has such a policy and a 364 client has already fulfilled an authorization challenge for the 365 parent domain then: 367 o If the client submits a newAuthz request for a subdomain: The 368 server MUST return status 200 (OK) response. The response body is 369 the existing authorization object for the parent domain with 370 status set to "valid". 372 o If the client submits a newOrder request for a subdomain: The 373 server MUST return a 201 (Created) response. The response body is 374 an order object with status set to "ready" and links to the 375 unexpired authorizations against the parent domain. 377 If a server has such a policy and a client has not fulfilled an 378 authorization challenge for the parent domain then: 380 o If the client submits a newAuthz request for a subdomain: The 381 server MUST return a status 201 (Created) response. If the client 382 indicates that it has control over the parent domains by including 383 the "parentDomainAuthorization" value of "true", then the response 384 body is a newly created authorization object, and server policy 385 dictates whether the authorization object is for the subdomain 386 identifier, or one of the parent domains. If the client indicates 387 that it does not have control over the parent domain by including 388 the "parentDomainAuthorization" value of "false", then server MUST 389 return an authorization object for the specified identifier, and 390 not for a parent domain. 392 o If the client submits a newOrder request for a subdomain: The 393 server MUST return a status 201 (Created) response. If the client 394 indicates that it has control over the parent domains by including 395 the "parentDomainAuthorization" value of "true", then the response 396 body is an order object with status set to "pending" and links to 397 newly created authorizations object, and server policy dictates 398 whether the authorization object is for the subdomain identifier, 399 or one of the parent domains. If the client indicates that it 400 does not have control over the parent domain by including the 401 "parentDomainAuthorization" value of "false", then server MUST 402 return an authorization object for the specified identifier, and 403 not for a parent domain. 405 4.6. Examples 407 In order to illustrate subdomain behaviour, let us assume that a 408 client wishes to get certificates for subdomain identifiers 409 "sub0.example.org", "sub1.example.org" and "sub2.example.org" under 410 parent domain "example.org", and CA policy allows certificate 411 issuance of these subdomain identifiers while only requiring the 412 client to fulfill an ownership challenge for parent domain 413 "example.org". Let us also assume that the client has not yet proven 414 ownership of parent domain "example.org". 416 1. The client POSTs a newOrder request for identifier 417 "sub0.example.org" and includes a "parentDomainAuthorization" 418 value of "true" 420 The server creates an authorization object for identifier 421 "example.org". The server replies with a 201 (Created) response. 422 The response body is an order object with status set to "pending" 423 and a link to newly created authorization object against the 424 parent domain "example.org". Therefore, the server is 425 instructing the client to fulfill a challenge against domain 426 identifier "example.org" in order to obtain a certificate 427 including identifier "sub0.example.org". 429 The client completes the challenge for "example.org", POSTs a CSR 430 to the order finalize URI, and downloads the certificate. 432 2. The client POSTs a newOrder request for identifier 433 "sub1.example.org" 435 The server replies with a 201 (Created) response. The response 436 body is an order object with status set to "ready" and a link to 437 the unexpired authorization against the parent domain 438 "example.org". 440 The client POSTs a CSR to the order finalize URI, and downloads 441 the certificate. 443 3. The client POSTs a newAuthz request for identifier 444 "sub2.example.org" 446 The server replies with a 200 (OK) response. The response body 447 is the previously created authorization object for "example.org" 448 with status set to "valid". 450 5. Resource Enhancements 452 This document defines enhancements to the authorization and directory 453 objects. 455 5.1. Authorization Object 457 If an ACME server allows issuance of certificates for subdomains of a 458 parent domain, then the authorization object for the parent domain 459 MUST include the optional "includeSubDomains" field, with a value of 460 true. 462 The structure of an ACME authorization resource is enhanced to 463 include the following optional field: 465 includeSubDomains (optional, boolean): This field MUST be present and 466 true for authorizations where ACME server policy allows certificates 467 to be issued for subdomains of the identifier in the authorization 468 object without explicit authorization of the subdomain 470 5.2. Identifier Object 472 The "Identifier" object which can be included in requests to newAuthz 473 resource, and in order objects, is enhanced to include the following 474 optional field: 476 parentDomainAuthorization (optional, boolean): Clients include this 477 field to indicate if they have control over parent domains for the 478 specified identifier and are able to fulfill challenges against 479 parent domains of the identifier. If not specified, then no default 480 value is assumed 482 5.3. Directory Object Metadata 484 An ACME server can advertise support of issuance of subdomain 485 certificates by including the boolean field 486 "includeSubDomainsAuthorization" in its "ACME Directory Metadata 487 Fields" registry. If not specified, then no default value is 488 assumed. If an ACME server supports issuance of subdomain 489 certificates, it can indicate this by including this field with a 490 value of "true". 492 6. IANA Considerations 494 6.1. Authorization Object Fields Registry 496 The following field is added to the "ACME Authorization Object 497 Fields" registry defined in ACME [RFC8555]. 499 +-------------------+------------+--------------+-----------+ 500 | Field Name | Field Type | Configurable | Reference | 501 +-------------------+------------+--------------+-----------+ 502 | includeSubDomains | boolean | false | RFC XXXX | 503 +-------------------+------------+--------------+-----------+ 505 6.2. Directory Object Metadata Fields Registry 507 The following field is added to the "ACME Directory Metadata Fields" 508 registry defined in ACME [RFC8555]. 510 +--------------------------------+------------+-----------+ 511 | Field Name | Field Type | Reference | 512 +--------------------------------+------------+-----------+ 513 | includeSubDomainsAuthorization | boolean | RFC XXXX | 514 +--------------------------------+------------+-----------+ 516 7. Security Considerations 518 This document documents enhancements to ACME [RFC8555] that optimize 519 the protocol flows for issuance of certificates for subdomains. The 520 underlying goal of ACME for Subdomains remains the same as that of 521 ACME: managing certificates that attest to identifier/key bindings 522 for these subdomains. Thus, ACME for Subdomains has the same two 523 security goals as ACME: 525 1. Only an entity that controls an identifier can get an 526 authorization for that identifier 528 2. Once authorized, an account key's authorizations cannot be 529 improperly used by another account 531 ACME for Subdomains makes no changes to: 533 o account or account key management 535 o ACME channel establishment, security mechanisms or threat model 537 o Validation channel establishment, security mechanisms or threat 538 model 540 Therefore, all Security Considerations in ACME in the following areas 541 are equally applicable to ACME for Subdomains: 543 o Threat Model 545 o Integrity of Authorizations 547 o Denial-of-Service Considerations 549 o Server-Side Request Forgery 551 o CA Policy Considerations 553 Some additional comments on ACME server policy are given in the 554 following section. 556 7.1. ACME Server Policy Considerations 558 The ACME for Subdomains and the ACME specifications do not mandate 559 any specific ACME server or CA policies, or any specific use cases 560 for issuance of certificates. For example, an ACME server could be 561 used: 563 o to issue Web PKI certificates where the ACME server must comply 564 with CA/Browser Forum [CAB] Baseline Requirements. 566 o as a Private CA for issuance of certificates within an 567 organisation. The organisation could enforce whatever policies 568 they desire on the ACME server. 570 o for issuance of IoT device certificates. There are currently no 571 IoT device certificate policies that are generally enforced across 572 the industry. Organizations issuing IoT device certificates can 573 enforce whatever policies they desire on the ACME server. 575 ACME server policy could specify whether: 577 o issuance of subdomain certificates is allowed based on proof of 578 ownership of a parent domain 580 o issuance of subdomain certificates is allowed, but only for a 581 specific set of parent domains 583 o whether DNS based proof of ownership, or HTTP based proof of 584 ownership, or both, are allowed 586 ACME server policy specification is explicitly out of scope of this 587 document. For reference, extracts from CA/Browser Forum Baseline 588 Requirements are given in the appendices. 590 8. Informative References 592 [CAB] CA/Browser Forum, "Baseline Requirements for the Issuance 593 and Management of Publicly-Trusted Certificates", n.d., 594 . 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, 599 DOI 10.17487/RFC2119, March 1997, 600 . 602 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 603 Housley, R., and W. Polk, "Internet X.509 Public Key 604 Infrastructure Certificate and Certificate Revocation List 605 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 606 . 608 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 609 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 610 May 2017, . 612 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 613 Kasten, "Automatic Certificate Management Environment 614 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 615 . 617 Appendix A. CA Browser Forum Baseline Requirements Extracts 619 The CA/Browser Forum Baseline Requirements [CAB] allow issuance of 620 subdomain certificates where authorization is only required for a 621 parent domain. Baseline Requirements version 1.7.1 states: 623 o Section: "1.6.1 Definitions": Authorization Domain Name: The 624 Domain Name used to obtain authorization for certificate issuance 625 for a given FQDN. The CA may use the FQDN returned from a DNS 626 CNAME lookup as the FQDN for the purposes of domain validation. 627 If the FQDN contains a wildcard character, then the CA MUST remove 628 all wildcard labels from the left most portion of requested FQDN. 629 The CA may prune zero or more labels from left to right until 630 encountering a Base Domain Name and may use any one of the 631 intermediate values for the purpose of domain validation. 633 o Section: "3.2.2.4.6 Agreed-Upon Change to Website": Once the FQDN 634 has been validated using this method, the CA MAY also issue 635 Certificates for other FQDNs that end with all the labels of the 636 validated FQDN. This method is suitable for validating Wildcard 637 Domain Names. 639 o Section: "3.2.2.4.7 DNS Change": Once the FQDN has been validated 640 using this method, the CA MAY also issue Certificates for other 641 FQDNs that end with all the labels of the validated FQDN. This 642 method is suitable for validating Wildcard Domain Names. 644 Authors' Addresses 646 Owen Friel 647 Cisco 649 Email: ofriel@cisco.com 651 Richard Barnes 652 Cisco 654 Email: rlb@ipv.sx 656 Tim Hollebeek 657 DigiCert 659 Email: tim.hollebeek@digicert.com 660 Michael Richardson 661 Sandelman Software Works 663 Email: mcr+ietf@sandelman.ca