idnits 2.17.1 draft-ietf-acme-star-delegation-05.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 February 2021) is 1159 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) -- Looks like a reference, but probably isn't: '1' on line 1191 == Outdated reference: A later version (-13) exists of draft-ietf-acme-authority-token-tnauthlist-06 == Outdated reference: A later version (-13) exists of draft-ietf-cdni-interfaces-https-delegation-04 == Outdated reference: A later version (-04) exists of draft-ietf-stir-cert-delegation-03 == Outdated reference: A later version (-15) exists of draft-ietf-tls-subcerts-10 == Outdated reference: A later version (-06) exists of draft-mglt-lurk-tls13-04 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). 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. López 5 Expires: 25 August 2021 A. Pastor Perales 6 Telefonica I+D 7 T. Fossati 8 ARM 9 21 February 2021 11 An ACME Profile for Generating Delegated STAR Certificates 12 draft-ietf-acme-star-delegation-05 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 25 August 2021. 44 Copyright Notice 46 Copyright (c) 2021 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Conventions used in this document . . . . . . . . . . . . 4 63 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 7 67 2.3.1. Delegation Configuration . . . . . . . . . . . . . . 7 68 2.3.2. Order Object Transmitted from NDC to IdO and to ACME 69 Server . . . . . . . . . . . . . . . . . . . . . . . 10 70 2.3.3. Capability Discovery . . . . . . . . . . . . . . . . 13 71 2.3.4. On Cancellation . . . . . . . . . . . . . . . . . . . 14 72 2.4. Delegation of Non-STAR Certificates . . . . . . . . . . . 14 73 2.5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 15 74 3. CSR Template . . . . . . . . . . . . . . . . . . . . . . . . 16 75 3.1. Template Syntax . . . . . . . . . . . . . . . . . . . . . 16 76 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 4. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 17 78 4.1. CDNI . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 4.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 18 80 4.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 18 81 4.2. STIR . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 83 5.1. New ACME Identifier Object Fields . . . . . . . . . . . . 23 84 5.2. New Fields in the "meta" Object within a Directory 85 Object . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 5.3. New Fields in the Order Object . . . . . . . . . . . . . 24 87 5.4. New Fields in the Account Object . . . . . . . . . . . . 24 88 5.5. New Error Types . . . . . . . . . . . . . . . . . . . . . 24 89 5.6. CSR Template Extensions . . . . . . . . . . . . . . . . . 25 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 91 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 26 92 6.2. Delegation Security Goal . . . . . . . . . . . . . . . . 26 93 6.3. New ACME Channels . . . . . . . . . . . . . . . . . . . . 27 94 6.4. Restricting CDNs to the Delegation Mechanism . . . . . . 28 95 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 98 8.2. Informative References . . . . . . . . . . . . . . . . . 30 99 Appendix A. Document History . . . . . . . . . . . . . . . . . . 31 100 A.1. draft-ietf-acme-star-delegation-05 . . . . . . . . . . . 31 101 A.2. draft-ietf-acme-star-delegation-04 . . . . . . . . . . . 31 102 A.3. draft-ietf-acme-star-delegation-03 . . . . . . . . . . . 31 103 A.4. draft-ietf-acme-star-delegation-02 . . . . . . . . . . . 32 104 A.5. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 32 105 A.6. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 32 106 A.7. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 32 107 A.8. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 32 108 Appendix B. CSR Template Schema . . . . . . . . . . . . . . . . 32 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 111 1. Introduction 113 This document is a companion document to [RFC8739]. To avoid 114 duplication, we give here a bare-bones description of the motivation 115 for this solution. For more details and further use cases, please 116 refer to the introductory sections of [RFC8739]. 118 An Identifier Owner (IdO) has agreements in place with one or more 119 NDC (Name Delegation Consumer) to use and attest its identity. 121 In the primary use case the IdO is a content provider, and we 122 consider a Content Delivery Network (CDN) provider contracted to 123 serve the content over HTTPS. The CDN terminates the HTTPS 124 connection at one of its edge cache servers and needs to present its 125 clients (browsers, mobile apps, set-top-boxes) a certificate whose 126 name matches the authority of the URL that is requested, i.e., that 127 of the IdO. Understandably, some IdOs may balk at sharing their 128 long-term private keys with another organization and, equally, 129 delegates would rather not have to handle other parties' long-term 130 secrets. Other relevant use cases are discussed in Section 4. 132 This document describes a profile of the ACME protocol [RFC8555] that 133 allows the NDC to request from the IdO, acting as a profiled ACME 134 server, a certificate for a delegated identity - i.e., one belonging 135 to the IdO. The IdO then uses the ACME protocol (with the extensions 136 described in [RFC8739]) to request issuance of a STAR certificate for 137 the same delegated identity. The generated short-term certificate is 138 automatically renewed by the ACME Certification Authority (CA), 139 periodically fetched by the NDC and used to terminate HTTPS 140 connections in lieu of the IdO. The IdO can end the delegation at 141 any time by simply instructing the CA to stop the automatic renewal 142 and letting the certificate expire shortly thereafter. 144 In case the delegated identity is a domain name, this document also 145 provides a way for the NDC to inform the IdO about the CNAME mappings 146 that need to be installed in the IdO's DNS zone to enable the 147 aliasing of the delegated name, thus allowing the complete name 148 delegation workflow to be handled using a single interface. 150 While the primary use case we address is delegation of STAR 151 certificates, the mechanism proposed here accommodates any 152 certificate managed with the ACME protocol. See Section 2.4 for 153 details. 155 We note that other ongoing efforts address the problem of certificate 156 delegation for TLS connections, specifically [I-D.ietf-tls-subcerts] 157 and [I-D.mglt-lurk-tls13]. Compared to these other solutions, the 158 current draft does not introduce additional latency to the TLS 159 connection, nor does it require changes to the TLS network stack of 160 either the client or the server. 162 1.1. Terminology 164 IdO Identifier Owner, the owner of an identifier (e.g., a domain 165 name) that needs to be delegated. 166 NDC Name Delegation Consumer, the entity to which the domain name is 167 delegated for a limited time. This is a CDN in the primary use 168 case (in fact, readers may note the symmetry of the two acronyms). 169 CDN Content Delivery Network, a widely distributed network that 170 serves the domain's web content to a wide audience at high 171 performance. 172 STAR Short-Term, Automatically Renewed X.509 certificates. 173 ACME The IETF Automated Certificate Management Environment, a 174 certificate management protocol. 175 CA A Certificate Authority that implements the ACME protocol. 176 Synonymous with "ACME server". 178 1.2. Conventions used in this document 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 182 "OPTIONAL" in this document are to be interpreted as described in 183 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 184 capitals, as shown here. 186 2. Protocol Flow 188 This section presents the protocol flow. For completeness, we 189 include the ACME profile proposed in this draft as well as the 190 extended ACME protocol described in [RFC8739]. 192 2.1. Preconditions 194 The protocol assumes the following preconditions are met: 196 * The IdO exposes an ACME server interface to the NDC(s) comprising 197 the account management interface; 198 * The NDC has registered an ACME account with the IdO; 199 * NDC and IdO have agreed on a "CSR template" to use, including at a 200 minimum: subject name (e.g., "somesite.example.com"), requested 201 algorithms and key length, key usage, extensions (e.g., 202 TNAuthList). The NDC is required to use this template for every 203 CSR created under the same delegation; 204 * IdO has registered an ACME account with the Certificate Authority 205 (CA) 207 Note that even if the IdO implements the ACME server role, it is not 208 acting as a CA: in fact, from the point of view of the certificate 209 issuance process, the IdO only works as a "policing" forwarder of the 210 NDC's key-pair and is responsible for completing the identity 211 verification process towards the ACME server. 213 2.2. Overview 215 The interaction between the NDC and the IdO is governed by the 216 profiled ACME workflow detailed in Section 2.3. The interaction 217 between the IdO and the CA is ruled by ACME STAR [RFC8739] as well as 218 any other ACME extension that applies (e.g., 219 [I-D.ietf-acme-authority-token-tnauthlist] for STIR). 221 The outline of the combined protocol is as follow (Figure 1): 223 * NDC sends an order Order1 for the delegated identifier to IdO; 224 * IdO creates an Order1 resource in state "ready" with a "finalize" 225 URL; 226 * NDC immediately sends a finalize request (which includes the CSR) 227 to the IdO; 228 * IdO verifies the CSR according to the agreed upon CSR template; 229 * If the CSR verification fails, Order1 is moved to an "invalid" 230 state and everything stops; 231 * If the CSR verification is successful, IdO moves Order1 to state 232 "processing", and sends a new Order2 (using its own account) for 233 the delegated identifier to the CA; 234 * If the ACME STAR protocol fails, Order2 moves to "invalid" and the 235 same state is reflected in Order1 (i.e., the NDC Order); 236 * If the ACME STAR run is successful (i.e., Order2 is "valid"), IdO 237 copies the "star-certificate" URL from Order2 to Order1 and 238 updates the Order1 state to "valid". 240 The NDC can now download, install and use the short-term certificate 241 bearing the name delegated by the IdO. This can continue until the 242 STAR certificate expires or the IdO decides to cancel the automatic 243 renewal process with the CA. 245 Note that the interactive identifier authorization phase described in 246 Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because 247 the delegated identity contained in the CSR presented to the IdO is 248 validated against the configured CSR template (Section 2.3.1). 249 Therefore, the NDC sends the finalize request, including the CSR, to 250 the IdO immediately after Order1 has been acknowledged. The IdO 251 SHALL buffer a (valid) CSR until the Validation phase completes 252 successfully. 254 .------. .---------------. .------. 255 | NDC | | IdO | | ACME | 256 +--------+ +--------+--------+ +--------+ 257 | Client | | Server | Client | | Server | 258 '---+----' '----+---+---+----' '----+---' 259 | | | | 260 | Order1 | | | 261 | Signature | | | 262 o------------------->| | | 263 | | | | 264 | [ No identity ] | | | 265 | [ validation via ] | | | 266 | [ authorizations ] | | | 267 | | | | 268 | CSR | | | 269 | Signature | | | 270 o------------------->| | | 271 | Acknowledgement | | Order2 | 272 |<-------------------o | Signature | 273 | | o------------------->| 274 | | | Required | 275 | | | Authorizations | 276 | | |<-------------------o 277 | | | Responses | 278 | | | Signature | 279 | | o------------------->| 280 | | | | 281 | | |<~~~~Validation~~~~>| 282 | | | | 283 | | | CSR | 284 | | | Signature | 285 | | o------------------->| 286 | | | Acknowledgement | 287 | | |<-------------------o 288 | | | | 289 |<~~Await issuance~->| |<~~Await issuance~~>| 290 | | 291 | (unauthenticated) GET STAR certificate | 292 o------------------------------------------------>| 293 | Certificate #1 | 294 |<------------------------------------------------o 295 | (unauthenticated) GET STAR certificate | 296 o------------------------------------------------>| 297 | Certificate #2 | 298 |<------------------------------------------------o 299 | [...] | 300 | (unauthenticated) GET STAR certificate | 301 o------------------------------------------------>| 302 | Certificate #n | 303 |<------------------------------------------------o 305 Figure 1: End to end STAR delegation flow 307 2.3. Delegated Identity Profile 309 This section defines a profile of the ACME protocol, to be used 310 between the NDC and IdO. 312 2.3.1. Delegation Configuration 314 2.3.1.1. Account Object Extensions 316 An NDC identifies itself to the IdO as an ACME account. The IdO can 317 delegate multiple names to a NDC, and these configurations are 318 described through "delegation" objects associated with the NDC's 319 Account object on the IdO. 321 As shown in Figure 2, the ACME account resource on the IdO is 322 extended with a new "delegations" attribute: 324 * delegations (required, string): A URL from which a list of 325 delegations configured for this account can be fetched via a POST- 326 as-GET request. 328 { 329 "status": "valid", 330 "contact": [ 331 "mailto:delegation-admin@ido.example" 332 ], 333 "termsOfServiceAgreed": true, 334 "orders": "https://example.com/acme/orders/rzGoeA", 335 "delegations": "https://acme.ido.example/acme/delegations/adFqoz" 336 } 338 Figure 2: Example Account object with delegations 340 2.3.1.2. Delegation Objects 342 This profile extends the ACME resource model with a new read-only 343 delegation object that represents a delegation configuration that 344 applies to a given NDC. 346 A delegation object contains the CSR template (see Section 3) that 347 applies to that delegation, and optionally any related CNAME mapping 348 for the delegated identifiers. Its structure is as follows: 350 * csr-template (required, object): CSR template as defined in 351 Section 3. 352 * cname-map (optional, object): a map of FQDN pairs. In each pair, 353 the name is the delegated identifier, the value is the 354 corresponding IdO name that is aliased in the IdO's zone file to 355 redirect the resolvers to the delegated entity. Both names and 356 values MUST be FQDNs with a terminating '.'. This field is only 357 meaningful for identifiers of type "dns". 359 An example delegation object is shown in Figure 3. 361 { 362 "csr-template": { 363 "keyTypes": [ 364 { 365 "PublicKeyType": "ecPublicKey", 366 "Curve": "secp521r1", 367 "SignatureType": "ecdsa-with-SHA256" 368 } 369 ], 370 "subject": { 371 "country": "CA", 372 "stateOrProvince": "**", 373 "locality": "**", 374 "commonName": "**" 375 }, 376 "extensions": { 377 "subjectAltName": { 378 "DNS": [ 379 "abc.ndc.ido.example" 380 ] 381 }, 382 "keyUsage": [ 383 "digitalSignature" 384 ], 385 "extendedKeyUsage": [ 386 "serverAuth" 387 ] 388 } 389 }, 390 "cname-map": { 391 "abc.ndc.ido.example.": "abc.ndc.example." 392 } 393 } 395 Figure 3: Example Delegation Configuration object 397 In order to indicate which specific delegation applies to the 398 requested certificate a new "delegation" attribute is added to the 399 identifier in the Order object on the NDC-IdO side (see 400 Section 2.3.2). The value of this attribute is the URL pointing to 401 the delegation configuration object that is to be used for this 402 certificate request. If the "delegation" attribute in the Order 403 object contains a URL that does not correspond to a configuration 404 available to the requesting NDC, the IdO MUST return an error 405 response with status code 403 (Forbidden) and type 406 "urn:ietf:params:acme:error:unknownDelegation". 408 2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server 410 The Order object created by the NDC: 412 * MUST have the delegated name as the identifier value with a 413 "delegation" attribute indicating the configuration used for the 414 identifier. 416 Besides, when delegation is for a STAR certificate, the Order: 418 * MUST NOT contain the "notBefore" and "notAfter" fields; 419 * MUST contain an "auto-renewal" object and inside it, the fields 420 listed in Section 3.1.1 of [RFC8739]. 422 POST /acme/new-order HTTP/1.1 423 Host: acme.ido.example 424 Content-Type: application/jose+json 426 { 427 "protected": base64url({ 428 "alg": "ES256", 429 "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg", 430 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 431 "url": "https://acme.ido.example/acme/new-order" 432 }), 433 "payload": base64url({ 434 "identifiers": [ 435 { 436 "type": "dns", 437 "value": "abc.ndc.ido.example.", 438 "delegation": 439 "https://acme.ido.example/acme/delegations/adFqoz/2" 440 } 441 ], 442 "auto-renewal": { 443 "end-date": "2020-04-20T00:00:00Z", 444 "lifetime": 345600, // 4 days 445 "allow-certificate-get": true 446 } 447 }), 448 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 449 } 451 The Order object that is created on the IdO: 453 * MUST start in the "ready" state; 454 * MUST contain an "authorizations" array with zero elements; 455 * MUST contain the indicated "delegation" configurations. 457 Besides, when delegation is for a STAR certificate, the Order: 459 * MUST NOT contain the "notBefore" and "notAfter" fields. 461 { 462 "status": "ready", 463 "expires": "2019-05-01T00:00:00Z", 465 "identifiers": [ 466 { 467 "type": "dns", 468 "value": "abc.ndc.ido.example.", 469 "delegation": 470 "https://acme.ido.example/acme/delegations/adFqoz/2" 471 } 472 ], 474 "auto-renewal": { 475 "end-date": "2020-04-20T00:00:00Z", 476 "lifetime": 345600, 477 "allow-certificate-get": true 478 }, 480 "authorizations": [], 482 "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize" 483 } 485 The Order is then finalized by the NDC supplying the CSR containing 486 the delegated identifiers. The IdO checks the provided CSR against 487 the template that applies to each delegated identifier, as described 488 in Section 3.1. If the CSR fails validation for any of the 489 identifiers, the IdO MUST return an error response with status code 490 403 (Forbidden) and an appropriate type, e.g., "rejectedIdentifier" 491 or "badCSR". The error response SHOULD contain subproblems 492 (Section 6.7.1 of [RFC8555]) for each failed identifier. If the CSR 493 is successfully validated, the Order object status moves to 494 "processing" and the twin ACME protocol instance is initiated on the 495 IdO-CA side. 497 The Order object created by the IdO: 499 * MUST copy the identifiers sent by the NDC and strip the 500 "delegation" attribute; 502 Besides, when delegation is for a STAR certificate, the Order: 504 * MUST carry a copy of the "auto-renewal" object sent by the NDC and 505 augment it with an "allow-certificate-get" attribute set to true. 507 Instead, when the delegation is for a non-STAR certificate, the 508 Order: 510 * MUST include the "allow-certificate-get" attribute set to true. 512 When the validation of the identifiers has been successfully 513 completed and the certificate has been issued by the CA, the IdO: 515 * MUST move its Order resource status to "valid". 517 Besides, when delegation is for a STAR certificate, the IdO: 519 * MUST copy the "star-certificate" field from the STAR Order. The 520 latter indirectly includes (via the NotBefore and NotAfter HTTP 521 headers) the renewal timers needed by the NDC to inform its 522 certificate reload logic. 524 Instead, when the delegation is for a non-STAR certificate, the IdO: 526 * MUST copy the "certificate" field from the Order, as well as 527 "notBefore" and "notAfter" if these fields exist. 529 { 530 "status": "valid", 531 "expires": "2019-05-01T00:00:00Z", 533 "identifiers": [ 534 { 535 "type": "dns", 536 "value": "abc.ndc.ido.example.", 537 "delegation": 538 "https://acme.ido.example/acme/delegations/adFqoz/2" 539 } 540 ], 542 "auto-renewal": { 543 "end-date": "2020-04-20T00:00:00Z", 544 "lifetime": 345600, 545 "allow-certificate-get": true 546 }, 548 "authorizations": [], 550 "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize", 552 "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" 553 } 555 If an identifier object of type "dns" was included, the IdO can add 556 the corresponding CNAME records to its zone, e.g.: 558 abc.ndc.ido.example. CNAME abc.ndc.example. 560 2.3.3. Capability Discovery 562 In order to help a client to discover support for this profile, the 563 directory object of an ACME server MUST contain the following 564 attribute in the "meta" field: 566 * delegation-enabled: boolean flag indicating support for the 567 profile specified in this memo. An ACME server that supports this 568 delegation profile MUST include this key, and MUST set it to true. 570 The "delegation-enabled" flag may be specified regardless of the 571 existence or setting of the "auto-renewal" flag. 573 2.3.4. On Cancellation 575 It is worth noting that cancellation of the ACME STAR certificate is 576 a prerogative of the IdO. The NDC does not own the relevant account 577 key on the ACME server, therefore it can't issue a cancellation 578 request for the STAR cert. Potentially, since it holds the STAR 579 certificate's private key, it could request the revocation of a 580 single STAR certificate. However, STAR explicitly disables the 581 revokeCert interface. 583 2.4. Delegation of Non-STAR Certificates 585 The mechanism defined here can be used to delegate regular ACME 586 certificates whose expiry is not "short term". 588 To allow delegation of non-STAR certificates, this document allows 589 use of "allow-certificate-get" directly in the Order object and 590 independently of the "auto-renewal" object, so that the NDC can fetch 591 the certificate without having to authenticate into the ACME server. 593 The following differences exist between STAR and non-STAR certificate 594 delegation: 596 * With STAR certificates, the "star-certificate" field is copied by 597 the IdO; with non-STAR certificates, the "certificate" field is 598 copied. 599 * The "auto-renewal" object is not used (either in the request or 600 response) for non-STAR certificates. The field "allow- 601 certificate-get" MUST be included in the order object, and its 602 value MUST be "true". 603 * The "notBefore" and "notAfter" order fields are omitted only in 604 STAR certificates. 606 When delegating a non-STAR certificate, standard certificate 607 revocation still applies. The ACME certificate revocation endpoint 608 is explicitly unavailable for STAR certificates but it is available 609 for all other certificates. We note that according to Sec. 7.6 of 610 [RFC8555], the revocation endpoint can be used with either the 611 account keypair, or the certificate keypair. In other words, the NDC 612 would be able to revoke the certificate. However, given the trust 613 relationship between NDC and IdO expected by the delegation trust 614 model (Section 6.1) as well as the lack of incentives for the NDC - 615 which, doing so, would create a self-inflicted DoS - this does not 616 represent a security risk. 618 2.5. Proxy Behavior 620 There are cases where the ACME Delegation flow should be proxied, 621 such as the use case described in Section 4.1.2. This section 622 describes the behavior of such proxies. 624 An entity implementing the IdO server role - an "ACME Delegation 625 server" - can decide, on a per-identity case, whether to act as a 626 proxy into another ACME Delegation server, or to behave as an IdO and 627 obtain a certificate directly. The determining factor is whether it 628 can successfully be authorized by the ACME server for the identity 629 associated with the certificate request. 631 The identities supported by each server and the disposition for each 632 of them are preconfigured. 634 Following is the proxy's behavior for each of the messages exchanged 635 in the ACME Delegation process: 637 * New-order request: 638 - The complete "identifiers" object MUST be copied as-is. 639 - Similarly, the "auto-renewal" object MUST be copied as-is. 640 * New-order response: 641 - The "status", "expires", "authorizations", "identifiers" and 642 "auto-renewal" attributes/objects MUST be copied as-is. 643 - The "finalize" URL is rewritten, so that the "finalize" request 644 will be made to the proxy. 645 - Similarly, the "Location" header MUST be rewritten to point to 646 an Order object on the proxy. 647 - And similarly, any "Link" relations. 648 * Get Order response: 649 - The "status", "expires", "authorizations", "identifiers" and 650 "auto-renewal" attributes/objects MUST be copied as-is. 651 - Similarly, the "star-certificate" URL MUST be copied as-is. 652 - The "finalize" URL is rewritten, so that the "finalize" request 653 will be made to the proxy. 654 - The "Location" header MUST be rewritten to point to an Order 655 object on the proxy. 656 - Any "Link" relations MUST be rewritten to point to the proxy. 657 * Finalize request: 658 - The CSR MUST be copied as-is. 659 * Finalize response: 660 - The "Location" header, "Link" relations and the "finalize" URLs 661 are rewritten as for Get Order. 663 We note that all the above messages are authenticated, and therefore 664 each proxy must be able to authenticate any subordinate server. 666 3. CSR Template 668 The CSR template is used to express and constrain the shape of the 669 CSR that the NDC uses to request the certificate. The CSR is used 670 for every certificate created under the same delegation. Its 671 validation by the IdO is a critical element in the security of the 672 whole delegation mechanism. 674 Instead of defining every possible CSR attribute, this document takes 675 a minimalist approach by declaring only the minimum attribute set and 676 deferring the registration of further, more specific, attributes to 677 future documents. 679 3.1. Template Syntax 681 The template is a JSON document. Each field denotes one of: 683 * A mandatory field, where the template specifies the literal value 684 of that field. This is denoted by a literal string, such as 685 "client1.ndc.ido.example.com". 686 * A mandatory field, where the content of the field is defined by 687 the client. This is denoted by "**". 688 * An optional field, where the client decides whether the field is 689 included in the CSR and if so, what its value is. This is denoted 690 by "*". 692 The NDC MUST NOT include in the CSR any fields, including any 693 extensions, unless they are specified in the template. 695 The "subject" field and its subfields are mapped into the "subject" 696 field of the CSR, as per [RFC5280], Sec. 4.1.2.6. Other extension 697 fields of the CSR template are mapped into the CSR according to the 698 table in Section 5.6. 700 When the CSR is received by the IdO, it MUST verify that the CSR is 701 consistent with the template that the IdO sent earlier. The IdO MAY 702 enforce additional constraints, e.g. by restricting field lengths. 704 3.2. Example 706 The CSR template in Figure 4 represents one possible CSR template 707 governing the delegation exchanges provided in the rest of this 708 document. 710 { 711 "keyTypes": [ 712 { 713 "PublicKeyType": "RSA", 714 "PublicKeyLength": 4096, 715 "SignatureType": "sha256WithRSAEncryption" 716 } 717 ], 718 "subject": { 719 "country": "CA", 720 "stateOrProvince": "**", 721 "locality": "**", 722 "commonName": "**" 723 }, 724 "extensions": { 725 "subjectAltName": { 726 "DNS": [ 727 "client1.ndc.ido.example" 728 ], 729 "IP": [ 730 "192.0.2.1", 731 "2001:db8::1" 732 ] 733 }, 734 "keyUsage": [ 735 "digitalSignature" 736 ], 737 "extendedKeyUsage": [ 738 "serverAuth", 739 "timeStamping" 740 ] 741 } 742 } 744 Figure 4: Example CSR template 746 The template syntax is defined in Appendix B. 748 4. Further Use Cases 750 This non-normative section describes additional use cases that use 751 STAR certificate delegation in non-trivial ways. 753 4.1. CDNI 755 [I-D.ietf-cdni-interfaces-https-delegation] discusses several 756 solutions addressing different delegation requirements for the CDNI 757 (CDN Interconnection) environment. This section discusses two of the 758 stated requirements in the context of the STAR delegation workflow. 760 This section uses specifically CDNI terminology, e.g. "uCDN" and 761 "dCDN", as defined in [RFC7336]. 763 4.1.1. Multiple Parallel Delegates 765 In some cases the content owner (IdO) would like to delegate 766 authority over a web site to multiple NDCs (CDNs). This could happen 767 if the IdO has agreements in place with different regional CDNs for 768 different geographical regions, or if a "backup" CDN is used to 769 handle overflow traffic by temporarily altering some of the CNAME 770 mappings in place. The STAR delegation flow enables this use case 771 naturally, since each CDN can authenticate separately to the IdO (via 772 its own separate account) specifying its CSR, and the IdO is free to 773 allow or deny each certificate request according to its own policy. 775 4.1.2. Chained Delegation 777 In other cases, a content owner (IdO) delegates some domains to a 778 large CDN (uCDN), which in turn delegates to a smaller regional CDN, 779 dCDN. The IdO has a contractual relationship with uCDN, and uCDN has 780 a similar relationship with dCDN. However IdO may not even know 781 about dCDN. 783 If needed, the STAR protocol can be chained to support this use case: 784 uCDN could forward requests from dCDN to IdO, and forward responses 785 back to dCDN. Whether such proxying is allowed is governed by policy 786 and contracts between the parties. 788 A mechanism is necessary at the interface between uCDN and dCDN by 789 which the uCDN can advertise: 791 * The namespace that is made available to the dCDN to mint its 792 delegated names; 793 * The policy for creating the key material (allowed algorithms, 794 minimum key lengths, key usage, etc.) that the dCDN needs to 795 satisfy. 797 Note that such mechanism is provided by the CSR template. 799 4.1.2.1. Two-Level Delegation in CDNI 801 A User Agent (UA), browser or set-top-box, wants to fetch the video 802 resource at the following URI: "https://video.cp.example/movie". 803 Redirection between Content Provider (CP), upstream, and downstream 804 CDNs is arranged as a CNAME-based aliasing chain as illustrated in 805 Figure 5. 807 .------------. 808 video.cp.example ? | .-----. | 809 .---------------------------------->| | | 810 | (a) | | DNS | CP | 811 | .-------------------------------+ | | 812 | | CNAME video.ucdn.example | '-----' | 813 | | '------------' 814 | | 815 | | 816 .-----------|---v--. .------------. 817 | .-----.-+-----. | video.ucdn.example ? | .-----. | 818 | | | +----------------------------->| | | 819 | UA | TLS | DNS | | (b) | | DNS | uCDN | 820 | | | |<-----------------------------+ | | 821 | '--+--'-----+-' | CNAME video.dcdn.example | '-----' | 822 '------|----^---|--' '------------' 823 | | | 824 | | | 825 | | | .------------. 826 | | | video.dcdn.example ? | .-----. | 827 | | '------------------------------>| | | 828 | | (c) | | DNS | | 829 | '-----------------------------------+ | | 830 | A 192.0.2.1 | +-----+ dCDN | 831 | | | | | 832 '--------------------------------------->| TLS | | 833 SNI: video.cp.example | | | | 834 | '-----' | 835 '------------' 837 Figure 5: DNS Redirection 839 Unlike HTTP based redirection, where the original URL is supplanted 840 by the one found in the Location header of the 302 response, DNS 841 redirection is completely transparent to the User Agent. As a 842 result, the TLS connection to the dCDN edge is done with an SNI equal 843 to the "host" in the original URI - in the example, 844 "video.cp.example". So, in order to successfully complete the 845 handshake, the landing dCDN node has to be configured with a 846 certificate whose subjectAltName matches "video.cp.example", i.e., a 847 Content Provider's name. 849 Figure 6 illustrates the cascaded delegation flow that allows dCDN to 850 obtain a STAR certificate that bears a name belonging to the Content 851 Provider with a private key that is only known to the dCDN. 853 .--------------------. 854 | .------.------. | 855 | | STAR | ACME |<-------------. 856 .------->| CP | dele | STAR | | | 857 | | | srv | cli +-----. | 858 | | '---+--'------' | | 6 859 | '---------|------^---' 5 | 860 | | | | .--|-------. 861 | | | | | .-+----. | 862 | 7 | '---->| ACME | | 863 | | | | | STAR | C | 864 0 | 4 | +------| A | 865 | | | | | HTTP | | 866 | | | | '----+-' | 867 | | .-' '--^--|----' 868 | .--------------v--|--. | | 869 | | .------.----+-. | | 10 870 | | | | STAR | | | | 871 '-->| uCDN | CDNI | dele | | | | 872 | | | fwd | | | | 873 | '----+-'-+----' | | | 874 '-------^--|---|--^--' | | 875 | | | | | | 876 | 2 8 | | | 877 1 | | 3 | | 878 | | | | 9 | 879 .-------|--v---v--|---------. | | 880 | .-+----.----+-.------. | | | 881 | | | STAR | +------------' | 882 | dCDN | CDNI | dele | HTTP | | | 883 | | | cli | |<--------------' 884 | '------'------'------' | 885 '---------------------------' 886 Figure 6: Two levels delegation in CDNI 888 uCDN is configured to delegate to dCDN, and CP is configured to 889 delegate to uCDN, both as defined in Section 2.3.1. 891 1. dCDN requests CDNI path metadata to uCDN; 892 2. uCDN replies with, among other CDNI metadata, the STAR 893 delegation configuration, which includes the delegated Content 894 Provider's name; 895 3. dCDN creates a key-pair and the CSR with the delegated name. It 896 then places an order for the delegated name to uCDN; 897 4. uCDN forwards the received order to the Content Provider (CP); 898 5. CP creates an order for a STAR certificate and sends it to the 899 CA. The order also requests unauthenticated access to the 900 certificate resource; 901 6. After all authorizations complete successfully, the STAR 902 certificate is issued; 903 7. CP notifies uCDN that the STAR certificate is available at the 904 order's star-certificate URL; 905 8. uCDN forwards the information to dCDN. At this point the ACME 906 signalling is complete; 907 9. dCDN requests the STAR certificate using unauthenticated GET 908 from the ACME server; 909 10. the CA returns the certificate. Now dCDN is fully configured to 910 handle HTTPS traffic in-lieu of the Content Provider. 912 Note that 9. and 10. repeat until the delegation expires or is 913 terminated. 915 4.2. STIR 917 As a second use case, we consider the delegation of credentials in 918 the STIR ecosystem [I-D.ietf-stir-cert-delegation]. 920 In the STIR "delegated" mode, a service provider SP2 - the NDC - 921 needs to sign PASSPorT's [RFC8225] for telephone numbers (e.g., 922 TN=+123) belonging to another service provider, SP1 - the IdO. In 923 order to do that, SP2 needs a STIR certificate, and private key, that 924 includes TN=+123 in the TNAuthList [RFC8226] certificate extension. 926 In details (Figure 7): 928 1. SP1 and SP2 agree on the configuration of the delegation - in 929 particular, the CSR template that applies; 931 2. SP2 generates a private/public key-pair and sends a CSR to SP1 932 requesting creation of a certificate with: SP1 name, SP2 public 933 key, and a TNAuthList extension with the list of TNs that SP1 934 delegates to SP2. (Note that the CSR sent by SP2 to SP1 needs to 935 be validated against the CSR template agreed upon in step 1.); 936 3. SP1 sends an Order for the CSR to the CA; 937 4. Subsequently, after the required TNAuthList authorizations are 938 successfully completed, the CA moves the Order to a "valid" 939 state; at the same time the star-certificate endpoint is 940 populated. 941 5. The Order contents are forwarded from SP1 to SP2 by means of the 942 paired "delegation" Order. 943 6. SP2 dereferences the star-certificate URL in the Order to fetch 944 the rolling STAR certificate bearing the delegated identifiers. 946 .-------------------. 947 | .------.------. | 948 | | STAR | STAR |<--------------. 949 .-->| SP1 | dele | dele | | | 950 | | | srv | cli +-----. | 951 | | '----+-'------' | | 4 952 | '------^--|---------' 3 | 953 | | | | .----|-----. 954 | | 5 | | .---+--. | 955 | | | '--->| ACME | | 956 | | | | | STAR | C | 957 1 | | | +------| A | 958 | | | .--->| HTTP | | 959 | 2 | | | '---+--' | 960 | | | | '----|-----' 961 | .------|--v---------. 6 | 962 | | .-+----.------. | | 7 963 | | | STAR | +-----' | 964 '-->| SP2 | dele | HTTP | | | 965 | | cli | |<--------------' 966 | '----+-'-+----' | 967 '-------------------' 969 Figure 7: Delegation in STIR 971 As shown, the STAR delegation profile described in this document 972 applies straightforwardly, the only extra requirement being the 973 ability to instruct the NDC about the allowed TNAuthList values. 974 This can be achieved by a simple extension to the CSR template. 976 5. IANA Considerations 978 [[RFC Editor: please replace XXXX below by the RFC number.]] 980 5.1. New ACME Identifier Object Fields 982 This document requests that IANA create the following new registry 983 under the Automated Certificate Management Environment (ACME) 984 Protocol: 986 * ACME Identifier Object Fields 988 This registry is administered under a Specification Required policy 989 [RFC8126]. 991 The "ACME Identifier Object Fields" registry lists field names that 992 are defined for use in the ACME identifier object. 994 Template: 996 * Field name: The string to be used as a field name in the JSON 997 object 998 * Field type: The type of value to be provided, e.g., string, 999 boolean, array of string 1000 * Reference: Where this field is defined 1002 +============+============+===========================+ 1003 | Field Name | Field Type | Reference | 1004 +============+============+===========================+ 1005 | type | string | Section 7.1.3 of RFC 8555 | 1006 +------------+------------+---------------------------+ 1007 | value | string | Section 7.1.3 of RFC 8555 | 1008 +------------+------------+---------------------------+ 1009 | delegation | string | RFC XXXX | 1010 +------------+------------+---------------------------+ 1012 Table 1 1014 Note: this registry was not created at the time [RFC8555] was 1015 standardized likely because it was not anticipated that the 1016 identifier object would be extended. It is retrospectively 1017 introduced to record the status quo and allow controlled 1018 extensibility of the identifier object. 1020 5.2. New Fields in the "meta" Object within a Directory Object 1022 This document adds the following entries to the ACME Directory 1023 Metadata Fields registry: 1025 +====================+============+===========+ 1026 | Field Name | Field Type | Reference | 1027 +====================+============+===========+ 1028 | delegation-enabled | boolean | RFC XXXX | 1029 +--------------------+------------+-----------+ 1031 Table 2 1033 5.3. New Fields in the Order Object 1035 This document adds the following entries to the ACME Order Object 1036 Fields registry: 1038 +=======================+============+==============+===========+ 1039 | Field Name | Field Type | Configurable | Reference | 1040 +=======================+============+==============+===========+ 1041 | allow-certificate-get | boolean | true | RFC XXXX | 1042 +-----------------------+------------+--------------+-----------+ 1044 Table 3 1046 5.4. New Fields in the Account Object 1048 This document adds the following entries to the ACME Account Object 1049 Fields registry: 1051 +=============+============+==========+===========+ 1052 | Field Name | Field Type | Requests | Reference | 1053 +=============+============+==========+===========+ 1054 | delegations | string | none | RFC XXXX | 1055 +-------------+------------+----------+-----------+ 1057 Table 4 1059 Note that the "delegations" field is only reported by ACME servers 1060 that have "delegation-enabled" set to true in their meta Object. 1062 5.5. New Error Types 1064 This document adds the following entries to the ACME Error Type 1065 registry: 1067 +===================+================================+===========+ 1068 | Type | Description | Reference | 1069 +===================+================================+===========+ 1070 | unknownDelegation | An unknown configuration is | RFC XXXX | 1071 | | listed in the "delegations" | | 1072 | | attribute of the request Order | | 1073 +-------------------+--------------------------------+-----------+ 1075 Table 5 1077 5.6. CSR Template Extensions 1079 IANA is requested to establish a registry "STAR Delegation CSR 1080 Template Extensions", with "Expert Review" as its registration 1081 procedure. 1083 Each extension registered must specify: 1085 * An extension name. 1086 * An extension syntax, as a reference to a JSON Schema document that 1087 defines this extension. 1088 * The extension's mapping into an X.509 certificate extension. 1090 The initial contents of this registry are the extensions defined by 1091 the JSON Schema document in Appendix B. 1093 +==================+===========+===================================+ 1094 | Extension Name | Extension | Mapping to X.509 Certificate | 1095 | | Syntax | Extension | 1096 +==================+===========+===================================+ 1097 | keyUsage | See | [RFC5280], Sec. 4.2.1.3 | 1098 | | Appendix | | 1099 | | B | | 1100 +------------------+-----------+-----------------------------------+ 1101 | extendedKeyUsage | See | [RFC5280], Sec. 4.2.1.12 | 1102 | | Appendix | | 1103 | | B | | 1104 +------------------+-----------+-----------------------------------+ 1105 | subjectAltName | See | [RFC5280], Sec. 4.2.1.6 (note | 1106 | | Appendix | that only specific name formats | 1107 | | B | are allowed: IPv4 address, IPv6 | 1108 | | | address, DNS name, email address) | 1109 +------------------+-----------+-----------------------------------+ 1111 Table 6 1113 6. Security Considerations 1114 6.1. Trust Model 1116 The ACME trust model needs to be extended to include the trust 1117 relationship between NDC and IdO. Note that once this trust link is 1118 established, it potentially becomes recursive. Therefore, there has 1119 to be a trust relationship between each of the nodes in the 1120 delegation chain; for example, in case of cascading CDNs this is 1121 contractually defined. Note that using standard [RFC6125] identity 1122 verification there are no mechanisms available to the IdO to restrict 1123 the use of the delegated name once the name has been handed over to 1124 the first NDC. 1126 6.2. Delegation Security Goal 1128 Delegation introduces a new security goal: only an NDC that has been 1129 authorised by the IdO, either directly or transitively, can obtain a 1130 certificate with an IdO identity. 1132 From a security point of view, the delegation process has five 1133 separate parts: 1135 1. Enabling a specific third party (the intended NDC) to submit 1136 requests for delegated certificates; 1137 2. Making sure that any request for a delegated certificate matches 1138 the intended "shape" in terms of delegated identities as well as 1139 any other certificate metadata, e.g., key length, x.509 1140 extensions, etc.; 1141 3. Serving the certificate back to the NDC; 1142 4. A process for handling revocation of the delegation; 1143 5. A process for handling revocation of the certificate itself. 1145 The first part is covered by the NDC's ACME account that is 1146 administered by the IdO, whose security relies on the correct 1147 handling of the associated key pair. When a compromise of the 1148 private key is detected, the delegate MUST use the account 1149 deactivation procedures defined in Section 7.3.6 of [RFC8555]. 1151 The second part is covered by the act of checking an NDC's 1152 certificate request against the intended CSR template. The steps of 1153 shaping the CSR template correctly, selecting the right CSR template 1154 to check against the presented CSR, and making sure that the 1155 presented CSR matches the selected CSR template are all security 1156 relevant. 1158 The third part builds on the trust relationship between NDC and IdO 1159 that is responsible for correctly forwarding the certificate URL from 1160 the Order returned by the ACME server. 1162 The fourth part is associated with the ability of the IdO to 1163 unilaterally remove the delegation object associated with the revoked 1164 identity, therefore disabling any further NDC requests for such 1165 identity. Note that, in more extreme circumstances, the IdO might 1166 decide to disable the NDC account thus entirely blocking any further 1167 interaction. 1169 The fifth is covered by two different mechanisms, depending on the 1170 nature of the certificate. For STAR, the IdO shall use the 1171 cancellation interface defined in Section 2.3 of [RFC8739]. For non- 1172 STAR, the certificate revocation interface defined in Section 7.6 of 1173 [RFC8555]). 1175 6.3. New ACME Channels 1177 Using the model established in Section 10.1 of [RFC8555], we can 1178 decompose the interactions of the basic delegation workflow as shown 1179 in Figure 8. 1181 ACME Channel 1182 .------------>------------. 1183 .-----. ACME Channel .--+--. .--+----------. 1184 | NDC +------------->| IdO | | ACME server | 1185 '--+--' '--+--' '--+-+--------' 1186 | '-----------<-------------' | 1187 | Validation Channel | 1188 '-------------------->---------------------------' 1189 (subset of) ACME Channel [1] 1191 [1] Unauthenticated certificate fetch and non-STAR certificate 1192 revocation. 1194 Figure 8: Delegation Channels Topology 1196 The considerations regarding the security of the ACME Channel and 1197 Validation Channel discussed in [RFC8555] apply verbatim to the IdO/ 1198 ACME server leg. The same can be said for the ACME channel on the 1199 NDC/IdO leg. A slightly different set of considerations apply to the 1200 ACME Channel between NDC and ACME server, which consists of a subset 1201 of the ACME interface comprising two API endpoints: the 1202 unauthenticated certificate retrieval and, potentially, non-STAR 1203 revocation via certificate private key. No specific security 1204 considerations apply to the former, but the privacy considerations in 1205 Section 6.3 of [RFC8739] do. With regards to the latter, it should 1206 be noted that there is currently no means for an IdO to disable 1207 authorising revocation based on certificate private keys. So, in 1208 theory, an NDC could use the revocation API directly with the ACME 1209 server, therefore bypassing the IdO. The NDC SHOULD NOT directly use 1210 the revocation interface exposed by the ACME server unless failing to 1211 do so would compromise the overall security, for example if the 1212 certificate private key is compromised and the IdO is not currently 1213 reachable. 1215 All other security considerations from [RFC8555] and [RFC8739] apply 1216 as-is to the delegation topology. 1218 6.4. Restricting CDNs to the Delegation Mechanism 1220 When a web site is delegated to a CDN, the CDN can in principle 1221 modify the web site at will, create and remove pages. This means 1222 that a malicious or breached CDN can pass the ACME (as well as common 1223 non-ACME) HTTPS-based validation challenges and generate a 1224 certificate for the site. This is true regardless of whether the 1225 CNAME mechanisms defined in the current document is used or not. 1227 In some cases, this is the desired behavior: the domain owner trusts 1228 the CDN to have full control of the cryptographic credentials for the 1229 site. The current document however assumes that the domain owner 1230 only wants to delegate restricted control, and wishes to retain the 1231 capability to cancel the CDN's credentials at a short notice. 1233 The following is a possible mitigation when the IdO wishes to ensure 1234 that a rogue CDN cannot issue unauthorized certificates: 1236 * The domain owner makes sure that the CDN cannot modify the DNS 1237 records for the domain. The domain owner should ensure it is the 1238 only entity authorized to modify the DNS zone. Typically, it 1239 establishes a CNAME resource record from a subdomain into a CDN- 1240 managed domain. 1241 * The domain owner uses a CAA record [RFC8659] to restrict 1242 certificate issuance for the domain to specific CAs that comply 1243 with ACME and are known to implement [RFC8657]. 1244 * The domain owner uses the ACME-specific CAA mechanism [RFC8657] to 1245 restrict issuance to a specific account key which is controlled by 1246 it, and MUST require "dns-01" as the sole validation method. 1248 We note that the above solution may need to be tweaked depending on 1249 the exact capabilities and authorisation flows supported by the 1250 selected CAs. 1252 7. Acknowledgments 1254 We would like to thank the following people who contributed 1255 significantly to this document with their review comments and design 1256 proposals: Roman Danyliw, Frédéric Fieau, Sanjay Mishra, Jon 1257 Peterson, Ryan Sleevi, Emile Stephan. 1259 This work is partially supported by the European Commission under 1260 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 1261 for a Middleboxed Internet (MAMI). This support does not imply 1262 endorsement. 1264 8. References 1266 8.1. Normative References 1268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1269 Requirement Levels", BCP 14, RFC 2119, 1270 DOI 10.17487/RFC2119, March 1997, 1271 . 1273 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1274 Housley, R., and W. Polk, "Internet X.509 Public Key 1275 Infrastructure Certificate and Certificate Revocation List 1276 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1277 . 1279 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1280 Writing an IANA Considerations Section in RFCs", BCP 26, 1281 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1282 . 1284 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1285 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1286 May 2017, . 1288 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1289 Kasten, "Automatic Certificate Management Environment 1290 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1291 . 1293 [RFC8657] Landau, H., "Certification Authority Authorization (CAA) 1294 Record Extensions for Account URI and Automatic 1295 Certificate Management Environment (ACME) Method Binding", 1296 RFC 8657, DOI 10.17487/RFC8657, November 2019, 1297 . 1299 [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, 1300 "DNS Certification Authority Authorization (CAA) Resource 1301 Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, 1302 . 1304 [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor 1305 Perales, A., and T. Fossati, "Support for Short-Term, 1306 Automatically Renewed (STAR) Certificates in the Automated 1307 Certificate Management Environment (ACME)", RFC 8739, 1308 DOI 10.17487/RFC8739, March 2020, 1309 . 1311 8.2. Informative References 1313 [I-D.ietf-acme-authority-token-tnauthlist] 1314 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 1315 "TNAuthList profile of ACME Authority Token", Work in 1316 Progress, Internet-Draft, draft-ietf-acme-authority-token- 1317 tnauthlist-06, 9 March 2020, . 1321 [I-D.ietf-cdni-interfaces-https-delegation] 1322 Fieau, F., Emile, S., and S. Mishra, "CDNI extensions for 1323 HTTPS delegation", Work in Progress, Internet-Draft, 1324 draft-ietf-cdni-interfaces-https-delegation-04, 9 1325 September 2020, . 1328 [I-D.ietf-stir-cert-delegation] 1329 Peterson, J., "STIR Certificate Delegation", Work in 1330 Progress, Internet-Draft, draft-ietf-stir-cert-delegation- 1331 03, 13 July 2020, . 1334 [I-D.ietf-tls-subcerts] 1335 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 1336 "Delegated Credentials for TLS", Work in Progress, 1337 Internet-Draft, draft-ietf-tls-subcerts-10, 24 January 1338 2021, . 1341 [I-D.mglt-lurk-tls13] 1342 Migault, D., "LURK Extension version 1 for (D)TLS 1.3 1343 Authentication", Work in Progress, Internet-Draft, draft- 1344 mglt-lurk-tls13-04, 25 January 2021, . 1347 [json-schema-07] 1348 Wright, A., Andrews, H., and G. Luff, "JSON Schema 1349 Validation: A Vocabulary for Structural Validation of 1350 JSON", 2018, . 1353 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1354 Verification of Domain-Based Application Service Identity 1355 within Internet Public Key Infrastructure Using X.509 1356 (PKIX) Certificates in the Context of Transport Layer 1357 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1358 2011, . 1360 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1361 "Framework for Content Distribution Network 1362 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1363 August 2014, . 1365 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1366 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1367 . 1369 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 1370 Credentials: Certificates", RFC 8226, 1371 DOI 10.17487/RFC8226, February 2018, 1372 . 1374 Appendix A. Document History 1376 [[Note to RFC Editor: please remove before publication.]] 1378 A.1. draft-ietf-acme-star-delegation-05 1380 * Detailed AD review by Roman Danyliw. 1381 * Some comments that were left unaddressed in Ryan Sleevi's review. 1382 * Numerous other edits for clarity and consistency. 1384 A.2. draft-ietf-acme-star-delegation-04 1386 * Delegation of non-STAR certificates. 1387 * More IANA clarity, specifically on certificate extensions. 1388 * Add delegation configuration object and extend account and order 1389 objects accordingly. 1390 * A lot more depth on Security Considerations. 1392 A.3. draft-ietf-acme-star-delegation-03 1394 * Consistency with the latest changes in the base ACME STAR 1395 document, e.g. star-delegation-enabled capability renamed and 1396 moved. 1397 * Proxy use cases (recursive delegation) and the definition of proxy 1398 behavior. 1399 * More detailed analysis of the CDNI and STIR use cases, including 1400 sequence diagrams. 1402 A.4. draft-ietf-acme-star-delegation-02 1404 * Security considerations: review by Ryan Sleevi. 1405 * CSR template simplified: instead of being a JSON Schema document 1406 itself, it is now a simple JSON document which validates to a JSON 1407 Schema. 1409 A.5. draft-ietf-acme-star-delegation-01 1411 * Refinement of the CDNI use case. 1412 * Addition of the CSR template (partial, more work required). 1413 * Further security considerations (work in progress). 1415 A.6. draft-ietf-acme-star-delegation-00 1417 * Republished as a working group draft. 1419 A.7. draft-sheffer-acme-star-delegation-01 1421 * Added security considerations about disallowing CDNs from issuing 1422 certificates for a delegated domain. 1424 A.8. draft-sheffer-acme-star-delegation-00 1426 * Initial version, some text extracted from draft-sheffer-acme-star- 1427 requests-02 1429 Appendix B. CSR Template Schema 1431 Following is a JSON Schema definition of the CSR template. The 1432 syntax used is that of draft 7 of JSON Schema, which is documented in 1433 [json-schema-07]. Note that later versions of this (now expired) 1434 draft describe later versions of the JSON Schema syntax. At the time 1435 of writing, a stable reference for this syntax is not yet available, 1436 and we have chosen to use the draft version which is currently best 1437 supported by tool implementations. 1439 While the CSR template must follow the syntax defined here, neither 1440 the IdO nor the NDC are expected to validate it at run-time. 1442 { 1443 "title": "JSON Schema for the STAR Delegation CSR template", 1444 "$schema": "http://json-schema.org/draft-07/schema#", 1445 "$id": "http://ietf.org/acme/drafts/star-delegation/csr-template", 1446 "$defs": { 1447 "distinguished-name": { 1448 "$id": "#distinguished-name", 1449 "type": "object", 1450 "properties": { 1451 "country": { 1452 "type": "string" 1453 }, 1454 "stateOrProvince": { 1455 "type": "string" 1456 }, 1457 "locality": { 1458 "type": "string" 1459 }, 1460 "organization": { 1461 "type": "string" 1462 }, 1463 "organizationalUnit": { 1464 "type": "string" 1465 }, 1466 "emailAddress": { 1467 "type": "string" 1468 }, 1469 "commonName": { 1470 "type": "string" 1471 } 1472 }, 1473 "additionalProperties": false 1474 }, 1475 "rsaKeyType": { 1476 "$id": "#rsaKeyType", 1477 "type": "object", 1478 "properties": { 1479 "PublicKeyType": { 1480 "type": "string", 1481 "const": "RSA" 1482 }, 1483 "PublicKeyLength": { 1484 "type": "integer" 1485 }, 1486 "SignatureType": { 1487 "type": "string", 1488 "enum": [ 1489 "sha256WithRSAEncryption" 1490 ] 1491 } 1492 }, 1493 "additionalProperties": false 1494 }, 1495 "ecKeyTYpe": { 1496 "$id": "#ecKeyType", 1497 "type": "object", 1498 "properties": { 1499 "PublicKeyType": { 1500 "type": "string", 1501 "const": "ecPublicKey" 1502 }, 1503 "Curve": { 1504 "type": "string", 1505 "enum": [ 1506 "secp521r1" 1507 ] 1508 }, 1509 "SignatureType": { 1510 "type": "string", 1511 "enum": [ 1512 "ecdsa-with-SHA256" 1513 ] 1514 } 1515 }, 1516 "additionalProperties": false 1517 } 1518 }, 1519 "type": "object", 1520 "properties": { 1521 "keyTypes": { 1522 "type": "array", 1523 "items": { 1524 "oneOf": [ 1525 { 1526 "$ref": "#rsaKeyType" 1527 }, 1528 { 1529 "$ref": "#ecKeyType" 1530 } 1531 ] 1532 } 1533 }, 1534 "subject": { 1535 "$ref": "#distinguished-name" 1536 }, 1537 "extensions": { 1538 "type": "object", 1539 "properties": { 1540 "keyUsage": { 1541 "type": "array", 1542 "items": { 1543 "type": "string", 1544 "enum": [ 1545 "digitalSignature", 1546 "nonRepudiation", 1547 "keyEncipherment", 1548 "dataEncipherment", 1549 "keyAgreement", 1550 "keyCertSign", 1551 "cRLSign", 1552 "encipherOnly", 1553 "decipherOnly" 1554 ] 1555 } 1556 }, 1557 "extendedKeyUsage": { 1558 "type": "array", 1559 "items": { 1560 "type": "string", 1561 "enum": [ 1562 "serverAuth", 1563 "clientAuth", 1564 "codeSigning", 1565 "emailProtection", 1566 "timeStamping", 1567 "OCSPSigning" 1568 ] 1569 } 1570 }, 1571 "subjectAltName": { 1572 "type": "object", 1573 "properties": { 1574 "DNS": { 1575 "type": "array", 1576 "items": { 1577 "type": "string", 1578 "format": "hostname" 1579 } 1580 }, 1581 "IP": { 1582 "type": "array", 1583 "items": { 1584 "oneOf": [ 1585 { 1586 "type": "string", 1587 "format": "ipv4" 1588 }, 1589 { 1590 "type": "string", 1591 "format": "ipv6" 1592 } 1593 ] 1595 } 1596 }, 1597 "Email": { 1598 "type": "array", 1599 "items": { 1600 "type": "string", 1601 "format": "email" 1602 } 1603 } 1604 }, 1605 "additionalProperties": false 1606 } 1607 }, 1608 "additionalProperties": false 1609 } 1610 }, 1611 "additionalProperties": false 1612 } 1614 Authors' Addresses 1616 Yaron Sheffer 1617 Intuit 1619 Email: yaronf.ietf@gmail.com 1621 Diego López 1622 Telefonica I+D 1624 Email: diego.r.lopez@telefonica.com 1626 Antonio Agustín Pastor Perales 1627 Telefonica I+D 1629 Email: antonio.pastorperales@telefonica.com 1631 Thomas Fossati 1632 ARM 1634 Email: thomas.fossati@arm.com