idnits 2.17.1 draft-sheffer-acme-star-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 27, 2017) is 2527 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) == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-06 == Outdated reference: A later version (-02) exists of draft-fieau-cdni-https-delegation-01 -- Obsolete informational reference (is this intentional?): RFC 6844 (Obsoleted by RFC 8659) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACME Working Group Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Standards Track D. Lopez 5 Expires: November 28, 2017 O. Gonzalez de Dios 6 Telefonica I+D 7 T. Fossati 8 Nokia 9 May 27, 2017 11 Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate 12 Authority over Web Sites 13 draft-sheffer-acme-star-02 15 Abstract 17 This memo proposes two mechanisms that work in concert to allow a 18 third party (e.g., a content delivery network) to terminate TLS 19 sessions on behalf of a domain name owner (e.g., a content provider). 21 The proposed mechanisms are: 23 1. An extension to the ACME protocol to enable the issuance of 24 short-term and automatically renewed certificates, and 25 2. A protocol that allows a domain name owner to delegate to a third 26 party control over a certificate that bears one or more names in 27 that domain. 29 It should be noted that these are in fact independent building blocks 30 that can be used separately to solve completely different problems. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 28, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction: A Solution for the HTTPS CDN Use Case . . . . . 3 67 1.1. Cloud Use Case . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Conventions used in this document . . . . . . . . . . . . 4 70 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5 72 2.2. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 6 73 2.3. Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 2.4. Termination . . . . . . . . . . . . . . . . . . . . . . . 8 75 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 9 76 3.1. STAR API . . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.1.1. Creating a Registration . . . . . . . . . . . . . . . 9 78 3.1.2. Polling the Registration . . . . . . . . . . . . . . 10 79 3.2. ACME Authorization . . . . . . . . . . . . . . . . . . . 11 80 3.3. Transport Security for the STAR Protocol Leg . . . . . . 11 81 3.4. ACME Extensions between Proxy and Server . . . . . . . . 11 82 3.4.1. Extending the Order Resource . . . . . . . . . . . . 11 83 3.4.2. Canceling a Recurrent Order . . . . . . . . . . . . . 12 84 3.4.3. Indicating Support of Recurrent Orders . . . . . . . 12 85 3.5. Fetching the Certificates . . . . . . . . . . . . . . . . 12 86 4. CDNI Use Cases . . . . . . . . . . . . . . . . . . . . . . . 13 87 4.1. Multiple Parallel Delegates . . . . . . . . . . . . . . . 13 88 4.2. Chained Delegation . . . . . . . . . . . . . . . . . . . 13 89 5. Operational Considerations . . . . . . . . . . . . . . . . . 13 90 5.1. Certificate Transparency (CT) Logs . . . . . . . . . . . 13 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 6.1. STAR Protocol Authentication . . . . . . . . . . . . . . 14 93 6.2. Restricting CDNs to the Delegation Mechanism . . . . . . 14 94 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 97 8.2. Informative References . . . . . . . . . . . . . . . . . 15 98 Appendix A. Document History . . . . . . . . . . . . . . . . . . 17 99 A.1. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 17 100 A.2. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 17 101 A.3. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 17 102 A.4. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 17 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 105 1. Introduction: A Solution for the HTTPS CDN Use Case 107 A content provider (referred to in this document as Domain Name 108 Owner, DNO) has agreements in place with one or more Content Delivery 109 Networks (CDNs) that are contracted to serve its content over HTTPS. 110 The CDN terminates the HTTPS connection at one of its edge cache 111 servers and needs to present its clients (browsers, set-top-boxes) a 112 certificate whose name matches the authority of the URL that is 113 requested, i.e. that of the DNO. However, many DNOs balk at sharing 114 their long-term private keys with another organization and, equally, 115 CDN providers would rather not have to handle other parties' long- 116 term secrets. This problem has been discussed at the IETF under the 117 LURK (limited use of remote keys) title. 119 This document proposes a solution to the above problem that involves 120 the use of short-term certificates with a DNO's name on them, and a 121 scheme for handling the naming delegation from the DNO to the CDN. 122 The generated short-term credentials are automatically renewed by an 123 ACME Certification Authority (CA) [I-D.ietf-acme-acme] and routinely 124 rotated by the CDN on its edge cache servers. The DNO can end the 125 delegation at any time by simply instructing the CA to stop the 126 automatic renewal and let the certificate expire shortly thereafter. 128 Using short-term certificates makes revocation cheap and effective 129 [Topalovic] [I-D.iab-web-pki-problems] in case of key compromise or 130 of termination of the delegation; seamless certificate issuance and 131 renewal enable the level of workflow automation that is expected in 132 today's cloud environments. Also, compared to other keyless-TLS 133 solutions [I-D.cairns-tls-session-key-interface] 134 [I-D.erb-lurk-rsalg], the proposed approach doesn't suffer from 135 scalability issues or increase in connection setup latency, while 136 requiring virtually no changes to existing COTS caching software used 137 by the CDN. 139 1.1. Cloud Use Case 141 A similar use case is that of cloud infrastructure components, such 142 as load balancers and Web Application Firewalls (WAF). These 143 components are typically provisioned with the DNO's certificate, and 144 similarly to the CDN use case, many organizations would prefer to 145 manage the private key only on their own cloud-based or on-premise 146 hosts, often on Hardware Security Modules (HSMs). 148 Here again, the STAR solution allows the DNO to delegate authority 149 over the domain to the cloud provider, with the ability to revoke 150 this authority at any time. 152 1.2. Terminology 154 DNO Domain Name Owner, the owner of a domain that needs to be 155 delegated. 156 NDC Name Delegation Consumer, the entity to which the domain name is 157 delegated for a limited time. This is often a CDN (in fact, 158 readers may note the similarity of the two acronyms). 159 CDN Content Delivery Network, a widely distributed network that 160 serves the domain's web content to a wide audience at high 161 performance. 162 STAR Short-Term, Automatically Renewed X.509 certificates. 163 ACME The IETF Automated Certificate Management Environment, a 164 certificate management protocol. 165 CA A Certificate Authority that implements the ACME protocol. 167 1.3. Conventions used in this document 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in 172 [RFC2119]. 174 2. Protocol Flow 176 The protocol flow can be split into two: a STAR interface, used by 177 NDC and DNO to agree on the name delegation, and the extended ACME 178 interface, used by DNO to obtain the short-term and automatically 179 renewed certificate from the CA, which is eventually consumed by the 180 NDC. The latter is also used to terminate the delegation, if so 181 needed. 183 The following subsections describe the preconditions (Section 2.1), 184 and the three main phases of the protocol: 186 o Bootstrap: the NDC requests from the DNO the delegation of a 187 specific name and in turn DNO asks an ACME CA to create the 188 corresponding short-term and auto-renewed (STAR) certificate 189 (Section 2.2); 190 o Auto-renewal: the ACME CA periodically re-issues the short-term 191 certificate and posts it to a public URL (Section 2.3); 193 o Termination: the DNO (indirectly) stops name delegation by 194 explicitly requesting the ACME CA to discontinue the automatic 195 renewal of the certificate (Section 2.4). 197 This diagram presents the entities involved in the protocol and their 198 interactions during the different phases. 200 +-----------------+ 201 | STAR Proxy | 202 | (DNO) | 203 Bootstrap +-----------------+ Bootstrap 204 +---------->+ STAR | ACME +-----------+ 205 | | Server | Client | Terminate | 206 | +--------+--------+ | 207 | v 208 +--------+ +--------+ 209 | STAR | Refresh | ACME | 210 | Client +------------------------------->| Server | 211 | (NDC) | | (CA) | 212 +--------+ +--------+ 214 2.1. Preconditions 216 The protocol assumes the following preconditions are met: 218 o A mutually authenticated channel between NDC and DNO pre-exists. 219 This is called "STAR channel" and all STAR protocol exchanges 220 between NDC and DNO are run over it. It provides the guarantee 221 that requests and responses are authentic. 222 o NDC and DNO have agreed on a "CSR template" to use, including at a 223 minimum: 225 - Subject name (e.g., "somesite.example.com"), 226 - Validity (e.g., 24 to 72 hours), 227 - Requested algorithms, 228 - Key length, 229 - Key usage. 231 The NDC is required to use this template for every CSR created 232 under the same delegation. 233 o DNO has registered through the ACME interface exposed by the 234 Certificate Authority (CA) using the usual ACME registration 235 procedure. In ACME terms, the DNO has an Account on the server 236 and is ready to issue Orders. 238 2.2. Bootstrap 240 The NDC (STAR Client) generates a key-pair, wraps it into a 241 Certificate Signing Request (CSR) according to the agreed upon CSR 242 template, and sends it to the DNO (STAR Proxy) over the pre- 243 established STAR channel. The DNO uses the NDC identity provided on 244 the STAR channel to look up the CSR template that applies to the 245 requesting NDC and decides whether or not to accept the request. 246 Assuming everything is in order, it then "forwards" the NDC request 247 to the ACME CA by means of the usual ACME application procedure. 248 Specifically, the DNO, in its role as an ACME client, requests the CA 249 to issue a STAR certificate, i.e., one that: 251 o Has a short validity (e.g., 24 to 72 hours); 252 o Is automatically renewed by the CA for a certain period of time; 253 o Is downloadable from a (highly available) public link without 254 requiring any special authorization. 256 Other than that, the ACME protocol flows as normal between DNO and 257 CA, in particular DNO is responsible for satisfying the requested 258 ACME challenges until the CA is willing to issue the requested 259 certificate. Per normal ACME processing, the DNO is given back an 260 Order ID for the issued STAR certificate to be used in subsequent 261 interaction with the CA (e.g., if the certificate needs to be 262 terminated.) 264 Concurrently, a response is sent back to the NDC with an endpoint to 265 poll for completion of the certificate generation process. 267 The bootstrap phase ends when the DNO obtains the OK from the ACME CA 268 and posts the certificate's URL to the "completion endpoint" where 269 the NDC can retrieve it. 271 ........................... 272 STAR : STAR Proxy / : ACME/STAR 273 Client : ACME Client : Server 274 | : | | : | 275 | : | | ACME registration | 276 +-------. : | |<--------------------->| 277 | | : | | STAR capabilities | 278 | generate CSR : | | : | 279 | | : | | : | 280 |<------' : | | : | 281 | : | | : | 282 | Request new : | | : | 283 +---------------------->| | : | 284 | cert for CSR : | | : | 285 | : +-------. | : | 286 | : | | | : | 287 | : | Verify CSR | : | 288 | : | | | : | 289 | : +<------' | : | 290 | Accepted, poll at | | : | 291 |<----------------------+ | : | 292 | "completion URL" |- - - - - - - >| Application for | 293 | : | +---------------------->| 294 | : | | STAR certificate | 295 | : | | : | 296 | GET "completion URL" | | : Challenge | 297 |<--------------------->| |<--------------------->| 298 | in progress : | | : Response | 299 | : | | : | 300 | : | | Finalize/Certificate | 301 | : | |<----------------------+ 302 | GET "completion URL" |< - - - - - - -| : + Order Id | 303 +---------------------->| | : | 304 | : | | : | 305 | 200, certificate URL | | : | 306 |<----------------------+ | : | 307 | and other metadata | | : | 308 | : | | : | 309 `.........................' 311 Figure 1: Bootstrap 313 2.3. Refresh 315 The CA automatically re-issues the certificate (using the same CSR) 316 before it expires and publishes it to the URL that the NDC has come 317 to know at the end of the bootstrap phase. The NDC downloads and 318 installs it. This process goes on until either: 320 o DNO terminates the delegation, or 321 o Automatic renewal expires. 323 STAR ACME/STAR 324 Client Server 325 | Retrieve cert | [...] 326 |<--------------------->| | 327 | +------. / 328 | | | / 329 | | Automatic renewal : 330 | | | \ 331 | |<-----' \ 332 | Retrieve cert | | 333 |<--------------------->| 72 hours 334 | | | 335 | +------. / 336 | | | / 337 | | Automatic renewal : 338 | | | \ 339 | |<-----' \ 340 | Retrieve cert | | 341 |<--------------------->| 72 hours 342 | | | 343 | +------. / 344 | | | / 345 | | Automatic renewal : 346 | | | \ 347 | |<-----' \ 348 | | | 349 | [...] | [...] 351 Figure 2: Auto renewal 353 2.4. Termination 355 The DNO may request early termination of the STAR certificate by 356 including the Order ID in a certificate termination request to the 357 ACME interface, defined below. After the CA receives and verifies 358 the request, it shall: 360 o Cancel the automatic renewal process for the STAR certificate; 361 o Change the certificate publication resource to return an error 362 indicating the termination of the delegation to external clients, 363 including the NDC. 365 Note that it is not necessary to explicitly revoke the short-term 366 certificate. 368 STAR STAR ACME/STAR 369 Client Proxy Server 370 | | | 371 | | Terminate Order ID | 372 | +---------------------->| 373 | | +-------. 374 | | | | 375 | | | End auto renewal 376 | | | Remove cert link 377 | | | etc. 378 | | | | 379 | | Done |<------' 380 | |<----------------------+ 381 | | | 382 | | 383 | Retrieve cert | 384 +---------------------------------------------->| 385 | Error: terminated | 386 |<----------------------------------------------+ 387 | | 389 Figure 3: Termination 391 3. Protocol Details 393 This section describes the protocol's details. We start with the 394 STAR API between the STAR Client and the STAR Proxy. Then we 395 describe a few extensions to the ACME protocol running between the 396 STAR Proxy and the ACME Server. 398 3.1. STAR API 400 This API allows the STAR Client to request a STAR certificate via the 401 STAR Proxy, using a previously agreed-upon CSR template. 403 The API consists of a single resource, "registration". A new 404 Registration is created with a POST request, and the Registration 405 instance is polled to obtain its details. 407 3.1.1. Creating a Registration 409 To create a registration, use: 411 POST /star/registration 412 Host: star-proxy.example.net 413 Content-Type: application/json 415 { 416 "csr": "...", // CSR in PEM format 417 "lifetime": 365 // requested registration lifetime in days, 418 // between 1 and 1095 419 } 421 Upon success, the call returns the new Registration resource. 423 HTTP/1.1 201 Created 424 Location: https://star-proxy.example.net/star/registration/567 426 3.1.2. Polling the Registration 428 The returned Registration can be polled until the information is 429 available from the ACME server. 431 GET /star/registration/567 432 Host: star-proxy.example.net 434 In responding to poll requests while the validation is still in 435 progress, the server MUST return a 200 (OK) response and MAY include 436 a Retry-After header field to suggest a polling interval to the 437 client. The Retry-After value MUST be expressed in seconds. If the 438 Retry-After header is present, in order to avoid surprising 439 interactions with heuristic expiration times, a max-age Cache-Control 440 SHOULD also be present and set to a value slightly smaller than the 441 Retry-After value. 443 HTTP/1.1 200 OK 444 Retry-After: 10 445 Cache-Control: max-age=9 447 { 448 "status": "pending" 449 } 451 When the operation is successfully completed, the ACME Proxy returns: 453 HTTP/1.1 200 OK 454 Expires: Sun, 09 Sep 2018 14:09:00 GMT 456 { 457 "status": "valid", // or "failed" 458 "lifetime": 365, // lifetime of the registration in days, 459 // possibly less than requested 460 "certificates": "https://acme-server.example.org/certificates/A51A3" 461 } 463 The Expires header applies to the Registration resource itself, and 464 may be as small as a few minutes. It is unrelated to the Order's 465 lifetime which is measured in days or longer. The "certificates" 466 attribute contains a URL of the certificate pull endpoint, see 467 Section 3.5. 469 If the registration fails for any reason, the server returns a "200 470 OK" response, with the status as "failed" and a "reason" attribute 471 containing a human readable error message. 473 3.2. ACME Authorization 475 The DNO MUST restrict the authorizations it requests from the ACME 476 server to only those that cannot be spoofed by a malicious DNC. In 477 most cases the DNC will have strong control of HTTP content under the 478 delegated domain, and therefore HTTPS-based authorization MUST NOT be 479 used. See also Section 6.2. 481 3.3. Transport Security for the STAR Protocol Leg 483 Traffic between the STAR Client and the STAR Proxy MUST be protected 484 with HTTPS. For interoperability, all implementations MUST support 485 HTTP Basic Authentication [RFC7617]. However some deployments MAY 486 prefer mutually- authenticated HTTPS or two-legged OAUTH. 488 3.4. ACME Extensions between Proxy and Server 490 This protocol extends the ACME protocol, to allow for recurrent 491 orders. 493 3.4.1. Extending the Order Resource 495 The Order resource is extended with the following attributes: 497 { 498 "recurrent": true, 499 "recurrent-total-lifetime": 365, // requested lifetime of the 500 // recurrent registration, in days 501 "recurrent-certificate-validity": 7 502 // requested validity of each certificate, in days 503 } 505 These attributes are included in a POST message when creating the 506 order, as part of the "payload" encoded object. They are returned 507 when the order has been created, and the ACME server MAY adjust them 508 at will, according to its local policy. 510 3.4.2. Canceling a Recurrent Order 512 An important property of the recurrent Order is that it can be 513 cancelled by the domain name owner, with no need for certificate 514 revocation. We use the DELETE message to cancel the Order: 516 DELETE /acme/order/1 HTTP/1.1 517 Host: acme-server.example.org 519 Which returns: 521 HTTP/1.1 202 Deleted 523 The server MUST NOT issue any additional certificates for this Order, 524 beyond the certificate that is available for collection at the time 525 of deletion. 527 3.4.3. Indicating Support of Recurrent Orders 529 ACME supports sending arbitrary extensions when creating an Order, 530 and as a result, there is no need to explicitly indicate support of 531 this extension. The Proxy MUST verify that the "recurrent" attribute 532 was understood, as indicated by the "recurrent" attribute included in 533 the created Order. Since the standard ACME protocol does not allow 534 to explicitly cancel a pending Order (the DELETE operation above is 535 an extension), a Proxy that encounters an non-supporting server will 536 probably let the Order expire instead of following through with the 537 authorization process. 539 3.5. Fetching the Certificates 541 The certificate is fetched from the certificate endpoint, as per 542 [I-D.ietf-acme-acme], Sec. 7.4.2 "Downloading the Certificate". The 543 server MUST include an Expires header that indicates expiry of the 544 specific certificate. When the certificate expires, the client MAY 545 assume that a newer certificate is already in place. 547 A certificate MUST be replaced by its successor at the latest 24 548 hours before its "Not After" time. 550 4. CDNI Use Cases 552 Members of the IETF CDNI (Content Delivery Network Interconnection) 553 working group are interested in delegating authority over web content 554 to CDNs. Their requirements are described in a draft 555 [I-D.fieau-cdni-https-delegation] that compares several solutions. 556 This section discusses two particular requirements in the context of 557 the STAR protocol. 559 4.1. Multiple Parallel Delegates 561 In some cases the DNO would like to delegate authority over a web 562 site to multiple CDNs. This could happen if the DNO has agreements 563 in place with different regional CDNs for different geographical 564 regions. STAR enables this use case naturally, since each CDN can 565 authenticate separately to the DNO specifying its CSR, and the DNO is 566 free to allow or deny each certificate request according to its own 567 policy. 569 4.2. Chained Delegation 571 In other cases, a content owner (DNO) delegates some domains to a 572 large CDN (CDN1), which in turn delegates to a smaller regional CDN, 573 CDN2. The DNO has a contractual relationship with CDN1, and CDN1 has 574 a similar relationship with CDN2. However DNO may not even know 575 about CDN2. 577 The STAR protocol does not prevent this use case, although there is 578 no special support for it. CDN1 can forward requests from CDN2 to 579 DNO, and forward responses back to CDN2. Whether such proxying is 580 allowed is governed by policy and contracts between the parties. 582 5. Operational Considerations 584 5.1. Certificate Transparency (CT) Logs 586 TBD: larger logs and how to deal with them. 588 6. Security Considerations 590 6.1. STAR Protocol Authentication 592 The STAR protocol allows its client to obtain certificates bearing 593 the DNO's identity. Therefore strong client authentication is 594 mandatory. 596 When multiple NDCs may connect to the same DNO, the STAR protocol's 597 authentication must allow the DNO to distinguish between different 598 NDCs. Among other benefits, this allows to DNO to cancel a STAR 599 registration for one of its clients instead of all of them. 601 6.2. Restricting CDNs to the Delegation Mechanism 603 Currently there are no standard methods for the DNO to ensure that 604 the CDN cannot issue a certificate through mechanisms other than the 605 one described here, for the URLs under the CDN's control. For 606 example, regardless of the STAR solution, a rogue CDN employee can 607 use the ACME protocol (or proprietary mechanisms used by various CAs) 608 to create a fake certificate for the DNO's content because ACME 609 authorizes its requests using information that may be under the 610 adversary's control. 612 The best solution currently being worked on would consist of several 613 related configuration steps: 615 o Make sure that the CDN cannot modify the DNS records for the 616 domain. Typically this would mean that the content owner 617 establishes a CNAME resource record from a subdomain into a CDN- 618 managed domain. 619 o Restrict certificate issuance for the domain to specific CAs that 620 comply with ACME. This assumes universal deployment of CAA 621 [RFC6844] by CAs, which is not the case yet. We note that the CA/ 622 Browser Forum has recently decided to require CAA checking 623 [CAB-CAA]. 624 o Deploy ACME-specific methods to restrict issuance to a specific 625 authorization key which is controlled by the content owner 626 [I-D.landau-acme-caa], and/or to specific ACME authorization 627 methods. 629 This solution is recommended in general, even if an alternative to 630 the mechanism described here is used. 632 7. Acknowledgments 634 This work is partially supported by the European Commission under 635 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 636 for a Middleboxed Internet (MAMI). This support does not imply 637 endorsement. 639 8. References 641 8.1. Normative References 643 [I-D.ietf-acme-acme] 644 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 645 Certificate Management Environment (ACME)", draft-ietf- 646 acme-acme-06 (work in progress), March 2017. 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, 650 DOI 10.17487/RFC2119, March 1997, 651 . 653 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 654 RFC 7617, DOI 10.17487/RFC7617, September 2015, 655 . 657 8.2. Informative References 659 [CAB-CAA] CA/Browser Forum, "Ballot 187 - Make CAA Checking 660 Mandatory", March 2017, . 663 [I-D.cairns-tls-session-key-interface] 664 Cairns, K., Mattsson, J., Skog, R., and D. Migault, 665 "Session Key Interface (SKI) for TLS and DTLS", draft- 666 cairns-tls-session-key-interface-01 (work in progress), 667 October 2015. 669 [I-D.erb-lurk-rsalg] 670 Erb, S. and R. Salz, "A PFS-preserving protocol for LURK", 671 draft-erb-lurk-rsalg-01 (work in progress), May 2016. 673 [I-D.fieau-cdni-https-delegation] 674 Fieau, F., Emile, S., and S. Mishra, "HTTPS delegation in 675 CDNI", draft-fieau-cdni-https-delegation-01 (work in 676 progress), March 2017. 678 [I-D.iab-web-pki-problems] 679 Housley, R. and K. O'Donoghue, "Improving the Public Key 680 Infrastructure (PKI) for the World Wide Web", draft-iab- 681 web-pki-problems-05 (work in progress), October 2016. 683 [I-D.landau-acme-caa] 684 Landau, H., "CA Account URI Binding for CAA Records", 685 draft-landau-acme-caa-01 (work in progress), October 2016. 687 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 688 Authority Authorization (CAA) Resource Record", RFC 6844, 689 DOI 10.17487/RFC6844, January 2013, 690 . 692 [Topalovic] 693 Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. 694 Boneh, "Towards Short-Lived Certificates", 2012, 695 . 697 Appendix A. Document History 699 [[Note to RFC Editor: please remove before publication.]] 701 A.1. draft-sheffer-acme-star-02 703 o Using a more generic term for the delegation client, NDC. 704 o Added an additional use case: public cloud services. 705 o More detail on ACME authorization. 707 A.2. draft-sheffer-acme-star-01 709 o A terminology section. 710 o Some cleanup. 712 A.3. draft-sheffer-acme-star-00 714 o Renamed draft to prevent confusion with other work in this space. 715 o Added an initial STAR protocol: a REST API. 716 o Discussion of CDNI use cases. 718 A.4. draft-sheffer-acme-star-lurk-00 720 o Initial version. 722 Authors' Addresses 724 Yaron Sheffer 725 Intuit 727 EMail: yaronf.ietf@gmail.com 729 Diego Lopez 730 Telefonica I+D 732 EMail: diego.r.lopez@telefonica.com 734 Oscar Gonzalez de Dios 735 Telefonica I+D 737 EMail: oscar.gonzalezdedios@telefonica.com 738 Thomas Fossati 739 Nokia 741 EMail: thomas.fossati@nokia.com