idnits 2.17.1 draft-ietf-acme-star-delegation-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 date (August 26, 2019) is 1704 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 (-02) exists of draft-handrews-json-schema-01 ** Downref: Normative reference to an Informational draft: draft-handrews-json-schema (ref. 'I-D.handrews-json-schema') == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-07 ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) == Outdated reference: A later version (-13) exists of draft-ietf-acme-authority-token-tnauthlist-03 == Outdated reference: A later version (-13) exists of draft-ietf-cdni-interfaces-https-delegation-01 == Outdated reference: A later version (-04) exists of draft-ietf-stir-cert-delegation-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACME Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Standards Track D. Lopez 5 Expires: February 27, 2020 A. Pastor Perales 6 Telefonica I+D 7 T. Fossati 8 Nokia 9 August 26, 2019 11 An ACME Profile for Generating Delegated STAR Certificates 12 draft-ietf-acme-star-delegation-01 14 Abstract 16 This memo proposes a profile of the ACME protocol that allows the 17 owner of an identifier (e.g., a domain name) to delegate to a third 18 party access to a certificate associated with said identifier. A 19 primary use case is that of a CDN (the third party) terminating TLS 20 sessions on behalf of a content provider (the owner of a domain 21 name). The presented mechanism allows the owner of the identifier to 22 retain control over the delegation and revoke it at any time by 23 cancelling the associated STAR certificate renewal with the ACME CA. 24 Another key property of this mechanism is it does not require any 25 modification to the deployed TLS ecosystem. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 27, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Conventions used in this document . . . . . . . . . . . . 4 64 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 6 68 2.3.1. Order Object on the NDC-IdO side . . . . . . . . . . 6 69 2.3.2. Order Object on the IdO-CA side . . . . . . . . . . . 9 70 2.3.3. Capability Discovery . . . . . . . . . . . . . . . . 9 71 2.3.4. On Cancelation . . . . . . . . . . . . . . . . . . . 9 72 3. CSR Template . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 11 76 4.1. CDNI . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 12 78 4.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 12 79 4.2. STIR . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 5.1. New fields in the "meta" Object within a Directory Object 13 82 5.2. CSR Template Registry . . . . . . . . . . . . . . . . . . 13 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 6.1. Restricting CDNs to the Delegation Mechanism . . . . . . 13 85 6.2. TBC . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 8.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Appendix A. Document History . . . . . . . . . . . . . . . . . . 16 91 A.1. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 16 92 A.2. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 16 93 A.3. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 16 94 A.4. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 This document is a companion document to [I-D.ietf-acme-star]. To 100 avoid duplication, we give here a bare-bones description of the 101 motivation for this solution. For more details and further use 102 cases, please refer to the introductory sections of 103 [I-D.ietf-acme-star]. 105 An Identifier Owner (IdO), that we can associate in the primary use 106 case to a content provider (also referred to as Domain Name Owner, 107 DNO), has agreements in place with one or more NDC (Name Delegation 108 Consumer) to use and attest its identity. In the primary use case, 109 we consider a CDN provider contracted to serve the IdO content over 110 HTTPS. The CDN terminates the HTTPS connection at one of its edge 111 cache servers and needs to present its clients (browsers, mobile 112 apps, set-top-boxes) a certificate whose name matches the authority 113 of the URL that is requested, i.e., that of the IdO. Understandably, 114 most IdOs balk at sharing their long-term private keys with another 115 organization and, equally, delegates would rather not have to handle 116 other parties' long-term secrets. 118 Other relevant use cases are discussed in Section 4. 120 This document describes a profile of the ACME protocol 121 [I-D.ietf-acme-acme] that allows the NDC to request the IdO, acting 122 as a profiled ACME server, a certificate for a delegated identity - 123 i.e., one belonging to the IdO. The IdO then uses the ACME protocol 124 (with the extensions described in [I-D.ietf-acme-star]) to request 125 issuance of a STAR certificate for the same delegated identity. The 126 generated short-term certificate is automatically renewed by the ACME 127 Certification Authority (CA), periodically fetched by the NDC and 128 used to terminate HTTPS connections in lieu of the IdO. The IdO can 129 end the delegation at any time by simply instructing the CA to stop 130 the automatic renewal and letting the certificate expire shortly 131 thereafter. 133 In case the delegated identity is a domain name, this document also 134 provides a way for the NDC to inform the IdO about the CNAME mappings 135 that need to be installed in the IdO's DNS zone to enable the 136 aliasing of the delegated name, thus allowing the complete name 137 delegation workflow to be handled using a single interface. 139 1.1. Terminology 141 IdO Identifier Owner, the owner of an identifier (e.g., a domain 142 name) that needs to be delegated. 143 DNO Domain Name Owner, a specific kind of IdO whose identifier is a 144 domain name 146 NDC Name Delegation Consumer, the entity to which the domain name is 147 delegated for a limited time. This is a CDN in the primary use 148 case (in fact, readers may note the symmetry of the two acronyms). 149 CDN Content Delivery Network, a widely distributed network that 150 serves the domain's web content to a wide audience at high 151 performance. 152 STAR Short-Term, Automatically Renewed X.509 certificates. 153 ACME The IETF Automated Certificate Management Environment, a 154 certificate management protocol. 155 CA A Certificate Authority that implements the ACME protocol. 157 1.2. Conventions used in this document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in 162 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 163 capitals, as shown here. 165 2. Protocol Flow 167 This section presents the protocol flow. For completeness, we 168 include the ACME profile proposed in this draft as well as the 169 extended ACME protocol described in [I-D.ietf-acme-star]. 171 2.1. Preconditions 173 The protocol assumes the following preconditions are met: 175 o The IdO exposes an ACME server interface to the NDC(s) comprising 176 the account management interface; 177 o The NDC has registered an ACME account with the IdO; 178 o NDC and IdO have agreed on a "CSR template" to use, including at a 179 minimum: subject name (e.g., "somesite.example.com"), requested 180 algorithms and key length, key usage, extensions (e.g., 181 TNAuthList). The NDC is required to use this template for every 182 CSR created under the same delegation; 183 o IdO has registered an ACME account with the Certificate Authority 184 (CA) 186 Note that even if the IdO implements the ACME server role, it is not 187 acting as a CA: in fact, from the point of view of the certificate 188 issuance process, the IdO only works as a "policing" forwarder of the 189 NDC's key-pair and is responsible for completing the identity 190 verification process towards the ACME CA. 192 2.2. Overview 194 The interaction between the NDC and the IdO is governed by the 195 profiled ACME workflow detailed in Section 2.3. The interaction 196 between the IdO and the CA is ruled by ACME STAR [I-D.ietf-acme-star] 197 as well as any other ACME extension that applies (e.g., 198 [I-D.ietf-acme-authority-token-tnauthlist] for STIR). 200 The outline of the combined protocol is as follow (Figure 1): 202 o NDC sends an Order for the delegated identifier to IdO; 203 o IdO creates an Order resource in state "ready" with a "finalize" 204 URL; 205 o NDC immediately sends a finalize request (which includes the CSR) 206 to the IdO; 207 o IdO verifies the CSR according to the agreed CSR template; 208 o If the CSR verification fails, the Order is moved to an "invalid" 209 state and everything stops; 210 o If the CSR verification is successful, IdO moves the Order to 211 state "processing", and sends an Order' (using its own account) 212 for the delegated identifier to the ACME STAR CA; 213 o If the ACME STAR protocol fails, Order' moves to "invalid" and the 214 same state is reflected in the NDC Order; 215 o If the ACME STAR run is successful (i.e., Order' is "valid"), IdO 216 copies the "star-certificate" URL from Order' to Order and moves 217 its state "valid". 219 The NDC can now download, install and use the certificate bearing the 220 name delegated by the IdO. 222 Note that, because the identity validation is suppressed, the NDC 223 sends the finalize request, including the CSR, to the IdO immediately 224 after the Order has been acknowledged. The IdO must buffer a (valid) 225 CSR until the Validation phase completes successfully. 227 NDC IdO CA 228 Client Server Client Server 230 Order 231 Signature -------> 233 [ No identity validation ] 235 CSR 236 Signature -------> 238 Order' 239 Signature -------> 240 <------- Required 241 Authorizations 243 Responses 244 Signature -------> 246 <~~~~~~~~Validation~~~~~~~~> 248 CSR 249 Signature -------> 251 <~~~~~~Await issuance~~~~~~> <~~~~~~Await issuance~~~~~~> 253 <------------------------------------ Certificate 255 Figure 1: End to end flow 257 2.3. Delegated Identity Profile 259 2.3.1. Order Object on the NDC-IdO side 261 The Order object created by the NDC: 263 o MUST contain identifiers with the new "delegated" field set to 264 true; 265 o MUST NOT contain the notBefore and notAfter fields; 266 o MAY contain any of the "recurrent-*" fields listed in 267 Section 3.1.1 of [I-D.ietf-acme-star]; 268 o In case the identifier type is "dns", it MAY contain a "cname" 269 field with the alias of the identifier in the NDC domain. This 270 field is used by the IdO to create the DNS aliasing needed to 271 redirect the resolvers to the delegated entity. 273 POST /acme/new-order HTTP/1.1 274 Host: acme.dno.example 275 Content-Type: application/jose+json 277 { 278 "protected": base64url({ 279 "alg": "ES256", 280 "kid": "https://acme.dno.example/acme/acct/evOfKhNU60wg", 281 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 282 "url": "https://acme.dno.example/acme/new-order" 283 }), 284 "payload": base64url({ 285 "identifiers": [ 286 { 287 "type": "dns", 288 "value": "abc.ndc.dno.example.", 289 "delegated": true, 290 "cname": "abc.ndc.example." 291 } 292 ], 293 }), 294 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 295 } 297 The Order object that is created on the IdO: 299 o MUST start in the "ready" state; 300 o MUST contain an "authorizations" array with zero elements; 301 o MUST NOT contain the "notBefore" and "notAfter" fields. 303 { 304 "status": "ready", 305 "expires": "2016-01-01T00:00:00Z", 307 "identifiers": [ 308 { 309 "type": "dns", 310 "value": "abc.ndc.dno.example.", 311 "delegated": true, 312 "cname": "abc.ndc.example." 313 } 314 ], 316 "authorizations": [], 318 "finalize": "https://acme.dno.example/acme/order/TO8rfgo/finalize" 319 } 321 The IdO SHOULD copy any "recurrent-*" field from the NDC request into 322 the related STAR request to the ACME CA. 324 When the validation of the identifiers has been successfully 325 completed and the certificate has been issued by the CA, the IdO: 327 o MUST move its Order resource status to "valid"; 328 o MUST copy the "star-certificate" field from the STAR Order; 330 The latter indirectly includes (via the NotBefore and NotAfter HTTP 331 headers) the renewal timers needed by the NDC to inform its 332 certificate reload logic. 334 { 335 "status": "valid", 336 "expires": "2016-01-01T00:00:00Z", 338 "identifiers": [ 339 { 340 "type": "dns", 341 "value": "abc.ndc.dno.example.", 342 "delegated": true, 343 "cname": "abc.ndc.example." 344 } 345 ], 347 "authorizations": [], 349 "finalize": "https://acme.dno.example/acme/order/TO8rfgo/finalize", 351 "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" 352 } 354 If an "identifier" object of type "dns" was included, the IdO MUST 355 validate the specified CNAME at this point in the flow. The NDC and 356 IdO may have a pre-established list of valid CNAME values. At the 357 minimum, the IdO MUST verify that both DNS names are syntactically 358 valid. 360 Following this validation, the IdO can add the CNAME records to its 361 zone: 363 abc.ndc.dno.example. CNAME abc.ndc.example. 365 2.3.2. Order Object on the IdO-CA side 367 When sending the Order to the ACME CA, the IdO SHOULD strip the 368 "delegated" and "cname" attributes sent by the NDC (Section 2.3.1). 369 The IdO MUST add the necessary STAR extensions to the Order. In 370 addition, to allow the NDC to download the certificate using 371 unauthenticated GET, the IdO MUST add the recurrent-certificate-get 372 attribute and set it to true. 374 2.3.3. Capability Discovery 376 In order to help a client to discover support for this profile, the 377 directory object of an ACME server MUST contain the following 378 attribute inside the "meta" field: 380 o star-delegation-enabled: boolean flag indicating support for the 381 profile specified in this memo. An ACME server that supports this 382 delegation profile MUST include this key, and MUST set it to true. 384 2.3.4. On Cancelation 386 It is worth noting that cancelation of the ACME STAR certificate is a 387 prerogative of the IdO. The NDC does not own the relevant account 388 key on the ACME CA, therefore it can't issue a cancelation request 389 for the STAR cert. Potentially, since it holds the STAR cert private 390 key, it could request the revocation of a single STAR certificate. 391 However, STAR explicitly disables the revokeCert interface. 393 3. CSR Template 395 The CSR template is used to express and constrain the shape of the 396 CSR that the NDC uses to request the certificate. The CSR is used 397 for every CSR created under the same delegation. Its validation is a 398 critical element in the security of the whole delegation mechanism. 400 The CSR template is defined using JSON Schema 401 [I-D.handrews-json-schema], a mature, widely used format, which is a 402 natural fit for the JSON-centric ACME. 404 Instead of defining every possible CSR attribute, this document takes 405 a minimalist approach by declaring only the minimum attribute set and 406 deferring the registration of further, more specific, attributes to 407 future documents. Critically, this document establishes the 408 necessary IANA registry and registration rules (see Section 5.2). 410 3.1. Rules 412 TODO 414 3.2. Example 416 The CSR template in Figure 2 represents one possible CSR template 417 governing the delegation exchanges provided in the rest of this 418 document. 420 { 421 "type": "object", 422 "properties": { 423 "san": { 424 "type": "string", 425 "pattern": "*.ndc.dno.example." 426 }, 427 "requested-algorithms": { 428 "type": "object", 429 "properties": { 430 "sigAlgo": { 431 "type": "string", 432 "enum": [ 433 "ecdsa-with-sha256" 434 ] 435 }, 436 }, 437 "required": [ 438 "sigAlgo" 439 ] 440 }, 441 "key-usage": { 442 "type": "string", 443 "enum": [ 444 "digitalSignature" 445 ] 446 } 447 }, 448 "required": [ 449 "san", 450 "requested-algorithms", 451 "key-length", 452 "key-usage" 453 ], 454 "title": "csr-template", 455 "description": "Example CSR Template for IETF ACME STAR Delegation" 456 } 458 Figure 2: Example CSR template 460 4. Further Use Cases 462 4.1. CDNI 464 [I-D.ietf-cdni-interfaces-https-delegation] discusses several 465 solutions addressing different delegation requirements for the CDNI 466 (CDN Interconnection) environment. This section discusses two of the 467 stated requirements in the context of the STAR delegation workflow. 469 4.1.1. Multiple Parallel Delegates 471 In some cases the content owner (IdO) would like to delegate 472 authority over a web site to multiple NDCs (CDNs). This could happen 473 if the IdO has agreements in place with different regional CDNs for 474 different geographical regions, or if a "backup" CDN is used to 475 handle overflow traffic by temporarily altering some of the CNAME 476 mappings in place. The STAR delegation flow enables this use case 477 naturally, since each CDN can authenticate separately to the IdO (via 478 its own separate account) specifying its CSR, and the IdO is free to 479 allow or deny each certificate request according to its own policy. 481 4.1.2. Chained Delegation 483 In other cases, a content owner (IdO) delegates some domains to a 484 large CDN (uCDN), which in turn delegates to a smaller regional CDN, 485 dCDN. The DNO has a contractual relationship with uCDN, and uCDN has 486 a similar relationship with dCDN. However IdO may not even know 487 about dCDN. 489 The STAR protocol can be chained to support this use case: uCDN could 490 forward requests from dCDN to DNO, and forward responses back to 491 dCDN. Whether such proxying is allowed is governed by policy and 492 contracts between the parties. 494 A mechanism is necessary at the interface between uCDN and dCDN by 495 which the uCDN can advertise: 497 o The namespace that is made available to the dCDN to mint its 498 delegated names; 499 o The policy for creating the key material (allowed algorithms, 500 minimum key lengths, key usage, etc.) that the dCDN needs to 501 satisfy. 503 Note that such mechanism is provided by the CSR template. 505 4.2. STIR 507 As a second use case, we consider the delegation of credentials in 508 the STIR ecosystem [I-D.ietf-stir-cert-delegation]. 510 In the STIR "delegated" model, a service provider, the NDC, needs to 511 sign PASSPorT's [RFC8225] for telephone numbers (e.g., TN=+123) 512 belonging to another service provider, the IdO. In order to do that, 513 it needs a STIR certificate, and private key, that includes TN=+123 514 in the TNAuthList [RFC8226] cert extension. 516 The STAR delegation profile described in this document applies 517 straightforwardly, the only extra requirement being the ability to 518 instruct the NDC about the allowed TNAuthList values. This can be 519 achieved by a simple extension of the CSR template. 521 5. IANA Considerations 523 [[RFC Editor: please replace XXXX below by the RFC number.]] 525 5.1. New fields in the "meta" Object within a Directory Object 527 This document adds the following entries to the ACME Directory 528 Metadata Fields: 530 +-------------------------+------------+-----------+ 531 | Field Name | Field Type | Reference | 532 +-------------------------+------------+-----------+ 533 | star-delegation-enabled | boolean | RFC XXXX | 534 +-------------------------+------------+-----------+ 536 5.2. CSR Template Registry 538 TODO 540 6. Security Considerations 542 6.1. Restricting CDNs to the Delegation Mechanism 544 When a web site is delegated to a CDN, the CDN can in principle 545 modify the web site at will, create and remove pages. This means 546 that a malicious or breached CDN can pass the ACME (as well as common 547 non-ACME) HTTPS-based validation challenges and generate a 548 certificate for the site. This is true regardless of whether the 549 CNAME mechanisms defined in the current document is used or not. 551 In some cases, this is the desired behavior: the domain owner trusts 552 the CDN to have full control of the cryptographic credentials for the 553 site. The current document however assumes that the domain owner 554 only wants to delegate restricted control, and wishes to retain the 555 capability to cancel the CDN's credentials at a short notice. 557 To restrict certificate delegation only to the protocol defined here: 559 o The domain owner MUST make sure that the CDN cannot modify the DNS 560 records for the domain. The domain owner should ensure it is the 561 only entity authorized to modify the DNS zone. Typically, it 562 establishes a CNAME resource record from a subdomain into a CDN- 563 managed domain. 565 o The domain owner MUST use a CAA record [RFC6844] to restrict 566 certificate issuance for the domain to specific CAs that comply 567 with ACME. 568 o The domain owner MUST use the ACME-specific CAA mechanism 569 [I-D.ietf-acme-caa] to restrict issuance to a specific account key 570 which is controlled by it, and MUST require "dns-01" as the sole 571 validation method. 573 6.2. TBC 575 o CSR validation 576 o CNAME mappings 577 o Composition with ACME STAR 578 o Composition with other ACME extensions 579 o Channel security 581 7. Acknowledgments 583 This work is partially supported by the European Commission under 584 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 585 for a Middleboxed Internet (MAMI). This support does not imply 586 endorsement. 588 8. References 590 8.1. Normative References 592 [I-D.handrews-json-schema] 593 Wright, A. and H. Andrews, "JSON Schema: A Media Type for 594 Describing JSON Documents", draft-handrews-json-schema-01 595 (work in progress), March 2018. 597 [I-D.ietf-acme-acme] 598 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 599 Kasten, "Automatic Certificate Management Environment 600 (ACME)", draft-ietf-acme-acme-18 (work in progress), 601 December 2018. 603 [I-D.ietf-acme-caa] 604 Landau, H., "CAA Record Extensions for Account URI and 605 ACME Method Binding", draft-ietf-acme-caa-10 (work in 606 progress), June 2019. 608 [I-D.ietf-acme-star] 609 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 610 Fossati, "Support for Short-Term, Automatically-Renewed 611 (STAR) Certificates in Automated Certificate Management 612 Environment (ACME)", draft-ietf-acme-star-07 (work in 613 progress), August 2019. 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, 617 DOI 10.17487/RFC2119, March 1997, 618 . 620 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 621 Authority Authorization (CAA) Resource Record", RFC 6844, 622 DOI 10.17487/RFC6844, January 2013, 623 . 625 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 626 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 627 May 2017, . 629 8.2. Informative References 631 [I-D.ietf-acme-authority-token-tnauthlist] 632 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 633 "TNAuthList profile of ACME Authority Token", draft-ietf- 634 acme-authority-token-tnauthlist-03 (work in progress), 635 March 2019. 637 [I-D.ietf-cdni-interfaces-https-delegation] 638 Fieau, F., Emile, S., and S. Mishra, "CDNI extensions for 639 HTTPS delegation", draft-ietf-cdni-interfaces-https- 640 delegation-01 (work in progress), May 2019. 642 [I-D.ietf-stir-cert-delegation] 643 Peterson, J., "STIR Certificate Delegation", draft-ietf- 644 stir-cert-delegation-00 (work in progress), July 2019. 646 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 647 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 648 . 650 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 651 Credentials: Certificates", RFC 8226, 652 DOI 10.17487/RFC8226, February 2018, 653 . 655 Appendix A. Document History 657 [[Note to RFC Editor: please remove before publication.]] 659 A.1. draft-ietf-acme-star-delegation-01 661 o Addition of the STIR use case. 662 o Refinement of the CDNI use case. 663 o Addition of the CSR template (partial, more work required). 664 o Further security considerations (work in progress). 666 A.2. draft-ietf-acme-star-delegation-00 668 o Republished as a working group draft. 670 A.3. draft-sheffer-acme-star-delegation-01 672 o Added security considerations about disallowing CDNs from issuing 673 certificates for a delegated domain. 675 A.4. draft-sheffer-acme-star-delegation-00 677 o Initial version, some text extracted from draft-sheffer-acme-star- 678 requests-02 680 Authors' Addresses 682 Yaron Sheffer 683 Intuit 685 EMail: yaronf.ietf@gmail.com 687 Diego Lopez 688 Telefonica I+D 690 EMail: diego.r.lopez@telefonica.com 692 Antonio Agustin Pastor Perales 693 Telefonica I+D 695 EMail: antonio.pastorperales@telefonica.com 696 Thomas Fossati 697 Nokia 699 EMail: thomas.fossati@nokia.com