idnits 2.17.1 draft-ietf-acme-star-delegation-06.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 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == 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 (7 March 2021) is 1146 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 1212 == 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: 1 error (**), 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: 8 September 2021 A. Pastor Perales 6 Telefonica I+D 7 T. Fossati 8 ARM 9 7 March 2021 11 An ACME Profile for Generating Delegated STAR Certificates 12 draft-ietf-acme-star-delegation-06 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 8 September 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 4. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 18 78 4.1. CDNI . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 4.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 19 80 4.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 19 81 4.2. STIR . . . . . . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 5.3. New Fields in the Order Object . . . . . . . . . . . . . 24 87 5.4. New Fields in the Account Object . . . . . . . . . . . . 25 88 5.5. New Error Types . . . . . . . . . . . . . . . . . . . . . 25 89 5.6. CSR Template Extensions . . . . . . . . . . . . . . . . . 25 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . . . 29 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 98 8.2. Informative References . . . . . . . . . . . . . . . . . 30 99 Appendix A. Document History . . . . . . . . . . . . . . . . . . 32 100 A.1. draft-ietf-acme-star-delegation-06 . . . . . . . . . . . 32 101 A.2. draft-ietf-acme-star-delegation-05 . . . . . . . . . . . 32 102 A.3. draft-ietf-acme-star-delegation-04 . . . . . . . . . . . 32 103 A.4. draft-ietf-acme-star-delegation-03 . . . . . . . . . . . 32 104 A.5. draft-ietf-acme-star-delegation-02 . . . . . . . . . . . 32 105 A.6. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 33 106 A.7. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 33 107 A.8. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 33 108 A.9. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 33 109 Appendix B. CSR Template: CDDL . . . . . . . . . . . . . . . . . 33 110 Appendix C. CSR Template: JSON Schema . . . . . . . . . . . . . 35 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 113 1. Introduction 115 This document is a companion document to [RFC8739]. To avoid 116 duplication, we give here a bare-bones description of the motivation 117 for this solution. For more details and further use cases, please 118 refer to the introductory sections of [RFC8739]. 120 An Identifier Owner (IdO) has agreements in place with one or more 121 NDC (Name Delegation Consumer) to use and attest its identity. 123 In the primary use case the IdO is a content provider, and we 124 consider a Content Delivery Network (CDN) provider contracted to 125 serve the content over HTTPS. The CDN terminates the HTTPS 126 connection at one of its edge cache servers and needs to present its 127 clients (browsers, mobile apps, set-top-boxes) a certificate whose 128 name matches the authority of the URL that is requested, i.e., that 129 of the IdO. Understandably, some IdOs may balk at sharing their 130 long-term private keys with another organization and, equally, 131 delegates would rather not have to handle other parties' long-term 132 secrets. Other relevant use cases are discussed in Section 4. 134 This document describes a profile of the ACME protocol [RFC8555] that 135 allows the NDC to request from the IdO, acting as a profiled ACME 136 server, a certificate for a delegated identity - i.e., one belonging 137 to the IdO. The IdO then uses the ACME protocol (with the extensions 138 described in [RFC8739]) to request issuance of a STAR certificate for 139 the same delegated identity. The generated short-term certificate is 140 automatically renewed by the ACME Certification Authority (CA), 141 periodically fetched by the NDC and used to terminate HTTPS 142 connections in lieu of the IdO. The IdO can end the delegation at 143 any time by simply instructing the CA to stop the automatic renewal 144 and letting the certificate expire shortly thereafter. 146 In case the delegated identity is a domain name, this document also 147 provides a way for the NDC to inform the IdO about the CNAME mappings 148 that need to be installed in the IdO's DNS zone to enable the 149 aliasing of the delegated name, thus allowing the complete name 150 delegation workflow to be handled using a single interface. 152 While the primary use case we address is delegation of STAR 153 certificates, the mechanism proposed here accommodates any 154 certificate managed with the ACME protocol. See Section 2.4 for 155 details. 157 We note that other ongoing efforts address the problem of certificate 158 delegation for TLS connections, specifically [I-D.ietf-tls-subcerts] 159 and [I-D.mglt-lurk-tls13]. Compared to these other solutions, the 160 current draft does not introduce additional latency to the TLS 161 connection, nor does it require changes to the TLS network stack of 162 either the client or the server. 164 1.1. Terminology 166 IdO Identifier Owner, the owner of an identifier (e.g., a domain 167 name) that needs to be delegated. 168 NDC Name Delegation Consumer, the entity to which the domain name is 169 delegated for a limited time. This is a CDN in the primary use 170 case (in fact, readers may note the symmetry of the two acronyms). 171 CDN Content Delivery Network, a widely distributed network that 172 serves the domain's web content to a wide audience at high 173 performance. 174 STAR Short-Term, Automatically Renewed X.509 certificates. 175 ACME The IETF Automated Certificate Management Environment, a 176 certificate management protocol. 177 CA A Certificate Authority that implements the ACME protocol. 178 Synonymous with "ACME server". 180 1.2. Conventions used in this document 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL" in this document are to be interpreted as described in 185 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 186 capitals, as shown here. 188 2. Protocol Flow 190 This section presents the protocol flow. For completeness, we 191 include the ACME profile proposed in this draft as well as the 192 extended ACME protocol described in [RFC8739]. 194 2.1. Preconditions 196 The protocol assumes the following preconditions are met: 198 * The IdO exposes an ACME server interface to the NDC(s) comprising 199 the account management interface; 200 * The NDC has registered an ACME account with the IdO; 201 * NDC and IdO have agreed on a "CSR template" to use, including at a 202 minimum: subject name (e.g., "somesite.example.com"), requested 203 algorithms and key length, key usage, extensions (e.g., 204 TNAuthList). The NDC is required to use this template for every 205 CSR created under the same delegation; 206 * IdO has registered an ACME account with the Certificate Authority 207 (CA) 209 Note that even if the IdO implements the ACME server role, it is not 210 acting as a CA: in fact, from the point of view of the certificate 211 issuance process, the IdO only works as a "policing" forwarder of the 212 NDC's key-pair and is responsible for completing the identity 213 verification process towards the ACME server. 215 2.2. Overview 217 The interaction between the NDC and the IdO is governed by the 218 profiled ACME workflow detailed in Section 2.3. The interaction 219 between the IdO and the CA is ruled by ACME STAR [RFC8739] as well as 220 any other ACME extension that applies (e.g., 221 [I-D.ietf-acme-authority-token-tnauthlist] for STIR). 223 The outline of the combined protocol is as follow (Figure 1): 225 * NDC sends an order Order1 for the delegated identifier to IdO; 226 * IdO creates an Order1 resource in state "ready" with a "finalize" 227 URL; 228 * NDC immediately sends a finalize request (which includes the CSR) 229 to the IdO; 230 * IdO verifies the CSR according to the agreed upon CSR template; 231 * If the CSR verification fails, Order1 is moved to an "invalid" 232 state and everything stops; 233 * If the CSR verification is successful, IdO moves Order1 to state 234 "processing", and sends a new Order2 (using its own account) for 235 the delegated identifier to the CA; 236 * If the ACME STAR protocol fails, Order2 moves to "invalid" and the 237 same state is reflected in Order1 (i.e., the NDC Order); 238 * If the ACME STAR run is successful (i.e., Order2 is "valid"), IdO 239 copies the "star-certificate" URL from Order2 to Order1 and 240 updates the Order1 state to "valid". 242 The NDC can now download, install and use the short-term certificate 243 bearing the name delegated by the IdO. This can continue until the 244 STAR certificate expires or the IdO decides to cancel the automatic 245 renewal process with the CA. 247 Note that the interactive identifier authorization phase described in 248 Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because 249 the delegated identity contained in the CSR presented to the IdO is 250 validated against the configured CSR template (Section 2.3.1). 251 Therefore, the NDC sends the finalize request, including the CSR, to 252 the IdO immediately after Order1 has been acknowledged. The IdO 253 SHALL buffer a (valid) CSR until the Validation phase completes 254 successfully. 256 .------. .---------------. .------. 257 | NDC | | IdO | | ACME | 258 +--------+ +--------+--------+ +--------+ 259 | Client | | Server | Client | | Server | 260 '---+----' '----+---+---+----' '----+---' 261 | | | | 262 | Order1 | | | 263 | Signature | | | 264 o------------------->| | | 265 | | | | 266 | [ No identity ] | | | 267 | [ validation via ] | | | 268 | [ authorizations ] | | | 269 | | | | 270 | CSR | | | 271 | Signature | | | 272 o------------------->| | | 273 | Acknowledgement | | Order2 | 274 |<-------------------o | Signature | 275 | | o------------------->| 276 | | | Required | 277 | | | Authorizations | 278 | | |<-------------------o 279 | | | Responses | 280 | | | Signature | 281 | | o------------------->| 282 | | | | 283 | | |<~~~~Validation~~~~>| 284 | | | | 285 | | | CSR | 286 | | | Signature | 287 | | o------------------->| 288 | | | Acknowledgement | 289 | | |<-------------------o 290 | | | | 291 |<~~Await issuance~->| |<~~Await issuance~~>| 292 | | 293 | (unauthenticated) GET STAR certificate | 294 o------------------------------------------------>| 295 | Certificate #1 | 296 |<------------------------------------------------o 297 | (unauthenticated) GET STAR certificate | 298 o------------------------------------------------>| 299 | Certificate #2 | 300 |<------------------------------------------------o 301 | [...] | 302 | (unauthenticated) GET STAR certificate | 303 o------------------------------------------------>| 304 | Certificate #n | 305 |<------------------------------------------------o 307 Figure 1: End to end STAR delegation flow 309 2.3. Delegated Identity Profile 311 This section defines a profile of the ACME protocol, to be used 312 between the NDC and IdO. 314 2.3.1. Delegation Configuration 316 2.3.1.1. Account Object Extensions 318 An NDC identifies itself to the IdO as an ACME account. The IdO can 319 delegate multiple names to a NDC, and these configurations are 320 described through "delegation" objects associated with the NDC's 321 Account object on the IdO. 323 As shown in Figure 2, the ACME account resource on the IdO is 324 extended with a new "delegations" attribute: 326 * delegations (required, string): A URL from which a list of 327 delegations configured for this account can be fetched via a POST- 328 as-GET request. 330 { 331 "status": "valid", 332 "contact": [ 333 "mailto:delegation-admin@ido.example" 334 ], 335 "termsOfServiceAgreed": true, 336 "orders": "https://example.com/acme/orders/rzGoeA", 337 "delegations": "https://acme.ido.example/acme/delegations/adFqoz" 338 } 340 Figure 2: Example Account object with delegations 342 2.3.1.2. Delegation Objects 344 This profile extends the ACME resource model with a new read-only 345 delegation object that represents a delegation configuration that 346 applies to a given NDC. 348 A delegation object contains the CSR template (see Section 3) that 349 applies to that delegation, and optionally any related CNAME mapping 350 for the delegated identifiers. Its structure is as follows: 352 * csr-template (required, object): CSR template as defined in 353 Section 3. 354 * cname-map (optional, object): a map of FQDN pairs. In each pair, 355 the name is the delegated identifier, the value is the 356 corresponding IdO name that is aliased in the IdO's zone file to 357 redirect the resolvers to the delegated entity. Both names and 358 values MUST be FQDNs with a terminating '.'. This field is only 359 meaningful for identifiers of type "dns". 361 An example delegation object is shown in Figure 3. 363 { 364 "csr-template": { 365 "keyTypes": [ 366 { 367 "PublicKeyType": "ecPublicKey", 368 "Curve": "secp521r1", 369 "SignatureType": "ecdsa-with-SHA256" 370 } 371 ], 372 "subject": { 373 "country": "CA", 374 "stateOrProvince": "**", 375 "locality": "**", 376 "commonName": "**" 377 }, 378 "extensions": { 379 "subjectAltName": { 380 "DNS": [ 381 "abc.ndc.ido.example" 382 ] 383 }, 384 "keyUsage": [ 385 "digitalSignature" 386 ], 387 "extendedKeyUsage": [ 388 "serverAuth" 389 ] 390 } 391 }, 392 "cname-map": { 393 "abc.ndc.ido.example.": "abc.ndc.example." 394 } 395 } 397 Figure 3: Example Delegation Configuration object 399 In order to indicate which specific delegation applies to the 400 requested certificate a new "delegation" attribute is added to the 401 identifier in the Order object on the NDC-IdO side (see 402 Section 2.3.2). The value of this attribute is the URL pointing to 403 the delegation configuration object that is to be used for this 404 certificate request. If the "delegation" attribute in the Order 405 object contains a URL that does not correspond to a configuration 406 available to the requesting NDC, the IdO MUST return an error 407 response with status code 403 (Forbidden) and type 408 "urn:ietf:params:acme:error:unknownDelegation". 410 2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server 412 The Order object created by the NDC: 414 * MUST have the delegated name as the identifier value with a 415 "delegation" attribute indicating the configuration used for the 416 identifier. 418 Besides, when delegation is for a STAR certificate, the Order: 420 * MUST NOT contain the "notBefore" and "notAfter" fields; 421 * MUST contain an "auto-renewal" object and inside it, the fields 422 listed in Section 3.1.1 of [RFC8739]. 424 POST /acme/new-order HTTP/1.1 425 Host: acme.ido.example 426 Content-Type: application/jose+json 428 { 429 "protected": base64url({ 430 "alg": "ES256", 431 "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg", 432 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 433 "url": "https://acme.ido.example/acme/new-order" 434 }), 435 "payload": base64url({ 436 "identifiers": [ 437 { 438 "type": "dns", 439 "value": "abc.ndc.ido.example.", 440 "delegation": 441 "https://acme.ido.example/acme/delegations/adFqoz/2" 442 } 443 ], 444 "auto-renewal": { 445 "end-date": "2020-04-20T00:00:00Z", 446 "lifetime": 345600, // 4 days 447 "allow-certificate-get": true 448 } 449 }), 450 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 451 } 453 The Order object that is created on the IdO: 455 * MUST start in the "ready" state; 456 * MUST contain an "authorizations" array with zero elements; 457 * MUST contain the indicated "delegation" configurations. 459 Besides, when delegation is for a STAR certificate, the Order: 461 * MUST NOT contain the "notBefore" and "notAfter" fields. 463 { 464 "status": "ready", 465 "expires": "2019-05-01T00:00:00Z", 467 "identifiers": [ 468 { 469 "type": "dns", 470 "value": "abc.ndc.ido.example.", 471 "delegation": 472 "https://acme.ido.example/acme/delegations/adFqoz/2" 473 } 474 ], 476 "auto-renewal": { 477 "end-date": "2020-04-20T00:00:00Z", 478 "lifetime": 345600, 479 "allow-certificate-get": true 480 }, 482 "authorizations": [], 484 "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize" 485 } 487 The Order is then finalized by the NDC supplying the CSR containing 488 the delegated identifiers. The IdO checks the provided CSR against 489 the template that applies to each delegated identifier, as described 490 in Section 3.1. If the CSR fails validation for any of the 491 identifiers, the IdO MUST return an error response with status code 492 403 (Forbidden) and an appropriate type, e.g., "rejectedIdentifier" 493 or "badCSR". The error response SHOULD contain subproblems 494 (Section 6.7.1 of [RFC8555]) for each failed identifier. If the CSR 495 is successfully validated, the Order object status moves to 496 "processing" and the twin ACME protocol instance is initiated on the 497 IdO-CA side. 499 The Order object created by the IdO: 501 * MUST copy the identifiers sent by the NDC and strip the 502 "delegation" attribute; 504 Besides, when delegation is for a STAR certificate, the Order: 506 * MUST carry a copy of the "auto-renewal" object sent by the NDC and 507 augment it with an "allow-certificate-get" attribute set to true. 509 Instead, when the delegation is for a non-STAR certificate, the 510 Order: 512 * MUST include the "allow-certificate-get" attribute set to true. 514 When the validation of the identifiers has been successfully 515 completed and the certificate has been issued by the CA, the IdO: 517 * MUST move its Order resource status to "valid". 519 Besides, when delegation is for a STAR certificate, the IdO: 521 * MUST copy the "star-certificate" field from the STAR Order. The 522 latter indirectly includes (via the NotBefore and NotAfter HTTP 523 headers) the renewal timers needed by the NDC to inform its 524 certificate reload logic. 526 Instead, when the delegation is for a non-STAR certificate, the IdO: 528 * MUST copy the "certificate" field from the Order, as well as 529 "notBefore" and "notAfter" if these fields exist. 531 { 532 "status": "valid", 533 "expires": "2019-05-01T00:00:00Z", 535 "identifiers": [ 536 { 537 "type": "dns", 538 "value": "abc.ndc.ido.example.", 539 "delegation": 540 "https://acme.ido.example/acme/delegations/adFqoz/2" 541 } 542 ], 544 "auto-renewal": { 545 "end-date": "2020-04-20T00:00:00Z", 546 "lifetime": 345600, 547 "allow-certificate-get": true 548 }, 550 "authorizations": [], 552 "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize", 554 "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" 555 } 557 If an identifier object of type "dns" was included, the IdO can add 558 the corresponding CNAME records to its zone, e.g.: 560 abc.ndc.ido.example. CNAME abc.ndc.example. 562 2.3.3. Capability Discovery 564 In order to help a client to discover support for this profile, the 565 directory object of an ACME server MUST contain the following 566 attribute in the "meta" field: 568 * delegation-enabled: boolean flag indicating support for the 569 profile specified in this memo. An ACME server that supports this 570 delegation profile MUST include this key, and MUST set it to true. 572 The "delegation-enabled" flag may be specified regardless of the 573 existence or setting of the "auto-renewal" flag. 575 2.3.4. On Cancellation 577 It is worth noting that cancellation of the ACME STAR certificate is 578 a prerogative of the IdO. The NDC does not own the relevant account 579 key on the ACME server, therefore it can't issue a cancellation 580 request for the STAR cert. Potentially, since it holds the STAR 581 certificate's private key, it could request the revocation of a 582 single STAR certificate. However, STAR explicitly disables the 583 revokeCert interface. 585 2.4. Delegation of Non-STAR Certificates 587 The mechanism defined here can be used to delegate regular ACME 588 certificates whose expiry is not "short term". 590 To allow delegation of non-STAR certificates, this document allows 591 use of "allow-certificate-get" directly in the Order object and 592 independently of the "auto-renewal" object, so that the NDC can fetch 593 the certificate without having to authenticate into the ACME server. 595 The following differences exist between STAR and non-STAR certificate 596 delegation: 598 * With STAR certificates, the "star-certificate" field is copied by 599 the IdO; with non-STAR certificates, the "certificate" field is 600 copied. 601 * The "auto-renewal" object is not used (either in the request or 602 response) for non-STAR certificates. The field "allow- 603 certificate-get" MUST be included in the order object, and its 604 value MUST be "true". 605 * The "notBefore" and "notAfter" order fields are omitted only in 606 STAR certificates. 608 When delegating a non-STAR certificate, standard certificate 609 revocation still applies. The ACME certificate revocation endpoint 610 is explicitly unavailable for STAR certificates but it is available 611 for all other certificates. We note that according to Sec. 7.6 of 612 [RFC8555], the revocation endpoint can be used with either the 613 account keypair, or the certificate keypair. In other words, the NDC 614 would be able to revoke the certificate. However, given the trust 615 relationship between NDC and IdO expected by the delegation trust 616 model (Section 6.1) as well as the lack of incentives for the NDC - 617 which, doing so, would create a self-inflicted DoS - this does not 618 represent a security risk. 620 2.5. Proxy Behavior 622 There are cases where the ACME Delegation flow should be proxied, 623 such as the use case described in Section 4.1.2. This section 624 describes the behavior of such proxies. 626 An entity implementing the IdO server role - an "ACME Delegation 627 server" - can decide, on a per-identity case, whether to act as a 628 proxy into another ACME Delegation server, or to behave as an IdO and 629 obtain a certificate directly. The determining factor is whether it 630 can successfully be authorized by the ACME server for the identity 631 associated with the certificate request. 633 The identities supported by each server and the disposition for each 634 of them are preconfigured. 636 Following is the proxy's behavior for each of the messages exchanged 637 in the ACME Delegation process: 639 * New-order request: 640 - The complete "identifiers" object MUST be copied as-is. 641 - Similarly, the "auto-renewal" object MUST be copied as-is. 642 * New-order response: 643 - The "status", "expires", "authorizations", "identifiers" and 644 "auto-renewal" attributes/objects MUST be copied as-is. 645 - The "finalize" URL is rewritten, so that the "finalize" request 646 will be made to the proxy. 647 - Similarly, the "Location" header MUST be rewritten to point to 648 an Order object on the proxy. 649 - And similarly, any "Link" relations. 650 * Get Order response: 651 - The "status", "expires", "authorizations", "identifiers" and 652 "auto-renewal" attributes/objects MUST be copied as-is. 653 - Similarly, the "star-certificate" URL MUST be copied as-is. 654 - The "finalize" URL is rewritten, so that the "finalize" request 655 will be made to the proxy. 656 - The "Location" header MUST be rewritten to point to an Order 657 object on the proxy. 658 - Any "Link" relations MUST be rewritten to point to the proxy. 659 * Finalize request: 660 - The CSR MUST be copied as-is. 661 * Finalize response: 662 - The "Location" header, "Link" relations and the "finalize" URLs 663 are rewritten as for Get Order. 665 We note that all the above messages are authenticated, and therefore 666 each proxy must be able to authenticate any subordinate server. 668 3. CSR Template 670 The CSR template is used to express and constrain the shape of the 671 CSR that the NDC uses to request the certificate. The CSR is used 672 for every certificate created under the same delegation. Its 673 validation by the IdO is a critical element in the security of the 674 whole delegation mechanism. 676 Instead of defining every possible CSR attribute, this document takes 677 a minimalist approach by declaring only the minimum attribute set and 678 deferring the registration of further, more specific, attributes to 679 future documents. 681 3.1. Template Syntax 683 The template is a JSON document. Each field (with the exception of 684 "keyTypes", see below) denotes one of: 686 * A mandatory field, where the template specifies the literal value 687 of that field. This is denoted by a literal string, such as 688 "client1.ndc.ido.example.com". 689 * A mandatory field, where the content of the field is defined by 690 the client. This is denoted by "**". 691 * An optional field, where the client decides whether the field is 692 included in the CSR and if so, what its value is. This is denoted 693 by "*". 695 The NDC MUST NOT include in the CSR any fields, including any 696 extensions, unless they are specified in the template. 698 The structure of the template object is defined by the CDDL [RFC8610] 699 document in Appendix B. 701 An alternative, non-normative JSON Schema syntax is given in 702 Appendix C. 704 The "subject" field and its subfields are mapped into the "subject" 705 field of the CSR, as per [RFC5280], Sec. 4.1.2.6. Other extension 706 fields of the CSR template are mapped into the CSR according to the 707 table in Section 5.6. 709 The "keyTypes" property is not copied into the CSR. Instead, this 710 property constrains the "SubjectPublicKeyInfo" field of the CSR, 711 which MUST have the type/size defined by one of the array members of 712 the "keyTypes" property. 714 When the CSR is received by the IdO, it MUST verify that the CSR is 715 consistent with the template that the IdO sent earlier. The IdO MAY 716 enforce additional constraints, e.g. by restricting field lengths. 717 In this regard, note that a "subjectAltName" of type "DNS" can be 718 specified using the wildcard notation, meaning that the NDC can be 719 required ("**") or offered the possibility ("*") to define the 720 delegated domain name by itself. If this is the case, the IdO needs 721 to have a further layer of checks on top of the control rules already 722 provided by the CSR template to fully validate the CSR input. 724 3.2. Example 726 The CSR template in Figure 4 represents one possible CSR template 727 governing the delegation exchanges provided in the rest of this 728 document. 730 { 731 "keyTypes": [ 732 { 733 "PublicKeyType": "rsaEncryption", 734 "PublicKeyLength": 2048, 735 "SignatureType": "sha256WithRSAEncryption" 736 }, 737 { 738 "PublicKeyType": "id-ecPublicKey", 739 "namedCurve": "secp256r1", 740 "SignatureType": "ecdsa-with-SHA256" 741 } 742 ], 743 "subject": { 744 "country": "CA", 745 "stateOrProvince": "**", 746 "locality": "**", 747 "commonName": "**" 748 }, 749 "extensions": { 750 "subjectAltName": { 751 "DNS": [ 752 "client1.ndc.ido.example" 753 ] 754 }, 755 "keyUsage": [ 756 "digitalSignature" 757 ], 758 "extendedKeyUsage": [ 759 "serverAuth", 760 "clientAuth" 761 ] 762 } 763 } 765 Figure 4: Example CSR template 767 4. Further Use Cases 769 This non-normative section describes additional use cases that use 770 STAR certificate delegation in non-trivial ways. 772 4.1. CDNI 774 [I-D.ietf-cdni-interfaces-https-delegation] discusses several 775 solutions addressing different delegation requirements for the CDNI 776 (CDN Interconnection) environment. This section discusses two of the 777 stated requirements in the context of the STAR delegation workflow. 779 This section uses specifically CDNI terminology, e.g. "uCDN" and 780 "dCDN", as defined in [RFC7336]. 782 4.1.1. Multiple Parallel Delegates 784 In some cases the content owner (IdO) would like to delegate 785 authority over a web site to multiple NDCs (CDNs). This could happen 786 if the IdO has agreements in place with different regional CDNs for 787 different geographical regions, or if a "backup" CDN is used to 788 handle overflow traffic by temporarily altering some of the CNAME 789 mappings in place. The STAR delegation flow enables this use case 790 naturally, since each CDN can authenticate separately to the IdO (via 791 its own separate account) specifying its CSR, and the IdO is free to 792 allow or deny each certificate request according to its own policy. 794 4.1.2. Chained Delegation 796 In other cases, a content owner (IdO) delegates some domains to a 797 large CDN (uCDN), which in turn delegates to a smaller regional CDN, 798 dCDN. The IdO has a contractual relationship with uCDN, and uCDN has 799 a similar relationship with dCDN. However IdO may not even know 800 about dCDN. 802 If needed, the STAR protocol can be chained to support this use case: 803 uCDN could forward requests from dCDN to IdO, and forward responses 804 back to dCDN. Whether such proxying is allowed is governed by policy 805 and contracts between the parties. 807 A mechanism is necessary at the interface between uCDN and dCDN by 808 which the uCDN can advertise: 810 * The namespace that is made available to the dCDN to mint its 811 delegated names; 812 * The policy for creating the key material (allowed algorithms, 813 minimum key lengths, key usage, etc.) that the dCDN needs to 814 satisfy. 816 Note that such mechanism is provided by the CSR template. 818 4.1.2.1. Two-Level Delegation in CDNI 820 A User Agent (UA), browser or set-top-box, wants to fetch the video 821 resource at the following URI: "https://video.cp.example/movie". 822 Redirection between Content Provider (CP), upstream, and downstream 823 CDNs is arranged as a CNAME-based aliasing chain as illustrated in 824 Figure 5. 826 .------------. 827 video.cp.example ? | .-----. | 828 .---------------------------------->| | | 829 | (a) | | DNS | CP | 830 | .-------------------------------+ | | 831 | | CNAME video.ucdn.example | '-----' | 832 | | '------------' 833 | | 834 | | 835 .-----------|---v--. .------------. 836 | .-----.-+-----. | video.ucdn.example ? | .-----. | 837 | | | +----------------------------->| | | 838 | UA | TLS | DNS | | (b) | | DNS | uCDN | 839 | | | |<-----------------------------+ | | 840 | '--+--'-----+-' | CNAME video.dcdn.example | '-----' | 841 '------|----^---|--' '------------' 842 | | | 843 | | | 844 | | | .------------. 845 | | | video.dcdn.example ? | .-----. | 846 | | '------------------------------>| | | 847 | | (c) | | DNS | | 848 | '-----------------------------------+ | | 849 | A 192.0.2.1 | +-----+ dCDN | 850 | | | | | 851 '--------------------------------------->| TLS | | 852 SNI: video.cp.example | | | | 853 | '-----' | 854 '------------' 856 Figure 5: DNS Redirection 858 Unlike HTTP based redirection, where the original URL is supplanted 859 by the one found in the Location header of the 302 response, DNS 860 redirection is completely transparent to the User Agent. As a 861 result, the TLS connection to the dCDN edge is done with an SNI equal 862 to the "host" in the original URI - in the example, 863 "video.cp.example". So, in order to successfully complete the 864 handshake, the landing dCDN node has to be configured with a 865 certificate whose subjectAltName matches "video.cp.example", i.e., a 866 Content Provider's name. 868 Figure 6 illustrates the cascaded delegation flow that allows dCDN to 869 obtain a STAR certificate that bears a name belonging to the Content 870 Provider with a private key that is only known to the dCDN. 872 .--------------------. 873 | .------.------. | 874 | | STAR | ACME |<-------------. 875 .------->| CP | dele | STAR | | | 876 | | | srv | cli +-----. | 877 | | '---+--'------' | | 6 878 | '---------|------^---' 5 | 879 | | | | .--|-------. 880 | | | | | .-+----. | 881 | 7 | '---->| ACME | | 882 | | | | | STAR | C | 883 0 | 4 | +------| A | 884 | | | | | HTTP | | 885 | | | | '----+-' | 886 | | .-' '--^--|----' 887 | .--------------v--|--. | | 888 | | .------.----+-. | | 10 889 | | | | STAR | | | | 890 '-->| uCDN | CDNI | dele | | | | 891 | | | fwd | | | | 892 | '----+-'-+----' | | | 893 '-------^--|---|--^--' | | 894 | | | | | | 895 | 2 8 | | | 896 1 | | 3 | | 897 | | | | 9 | 898 .-------|--v---v--|---------. | | 899 | .-+----.----+-.------. | | | 900 | | | STAR | +------------' | 901 | dCDN | CDNI | dele | HTTP | | | 902 | | | cli | |<--------------' 903 | '------'------'------' | 904 '---------------------------' 906 Figure 6: Two levels delegation in CDNI 908 uCDN is configured to delegate to dCDN, and CP is configured to 909 delegate to uCDN, both as defined in Section 2.3.1. 911 1. dCDN requests CDNI path metadata to uCDN; 912 2. uCDN replies with, among other CDNI metadata, the STAR 913 delegation configuration, which includes the delegated Content 914 Provider's name; 915 3. dCDN creates a key-pair and the CSR with the delegated name. It 916 then places an order for the delegated name to uCDN; 917 4. uCDN forwards the received order to the Content Provider (CP); 918 5. CP creates an order for a STAR certificate and sends it to the 919 CA. The order also requests unauthenticated access to the 920 certificate resource; 921 6. After all authorizations complete successfully, the STAR 922 certificate is issued; 923 7. CP notifies uCDN that the STAR certificate is available at the 924 order's star-certificate URL; 925 8. uCDN forwards the information to dCDN. At this point the ACME 926 signalling is complete; 927 9. dCDN requests the STAR certificate using unauthenticated GET 928 from the ACME server; 929 10. the CA returns the certificate. Now dCDN is fully configured to 930 handle HTTPS traffic in-lieu of the Content Provider. 932 Note that 9. and 10. repeat until the delegation expires or is 933 terminated. 935 4.2. STIR 937 As a second use case, we consider the delegation of credentials in 938 the STIR ecosystem [I-D.ietf-stir-cert-delegation]. 940 In the STIR "delegated" mode, a service provider SP2 - the NDC - 941 needs to sign PASSPorT's [RFC8225] for telephone numbers (e.g., 942 TN=+123) belonging to another service provider, SP1 - the IdO. In 943 order to do that, SP2 needs a STIR certificate, and private key, that 944 includes TN=+123 in the TNAuthList [RFC8226] certificate extension. 946 In details (Figure 7): 948 1. SP1 and SP2 agree on the configuration of the delegation - in 949 particular, the CSR template that applies; 950 2. SP2 generates a private/public key-pair and sends a CSR to SP1 951 requesting creation of a certificate with: SP1 name, SP2 public 952 key, and a TNAuthList extension with the list of TNs that SP1 953 delegates to SP2. (Note that the CSR sent by SP2 to SP1 needs to 954 be validated against the CSR template agreed upon in step 1.); 955 3. SP1 sends an Order for the CSR to the CA; 956 4. Subsequently, after the required TNAuthList authorizations are 957 successfully completed, the CA moves the Order to a "valid" 958 state; at the same time the star-certificate endpoint is 959 populated. 960 5. The Order contents are forwarded from SP1 to SP2 by means of the 961 paired "delegation" Order. 962 6. SP2 dereferences the star-certificate URL in the Order to fetch 963 the rolling STAR certificate bearing the delegated identifiers. 965 .-------------------. 966 | .------.------. | 967 | | STAR | STAR |<--------------. 968 .-->| SP1 | dele | dele | | | 969 | | | srv | cli +-----. | 970 | | '----+-'------' | | 4 971 | '------^--|---------' 3 | 972 | | | | .----|-----. 973 | | 5 | | .---+--. | 974 | | | '--->| ACME | | 975 | | | | | STAR | C | 976 1 | | | +------| A | 977 | | | .--->| HTTP | | 978 | 2 | | | '---+--' | 979 | | | | '----|-----' 980 | .------|--v---------. 6 | 981 | | .-+----.------. | | 7 982 | | | STAR | +-----' | 983 '-->| SP2 | dele | HTTP | | | 984 | | cli | |<--------------' 985 | '----+-'-+----' | 986 '-------------------' 988 Figure 7: Delegation in STIR 990 As shown, the STAR delegation profile described in this document 991 applies straightforwardly, the only extra requirement being the 992 ability to instruct the NDC about the allowed TNAuthList values. 993 This can be achieved by a simple extension to the CSR template. 995 5. IANA Considerations 997 [[RFC Editor: please replace XXXX below by the RFC number.]] 999 5.1. New ACME Identifier Object Fields 1001 This document requests that IANA create the following new registry 1002 under the Automated Certificate Management Environment (ACME) 1003 Protocol: 1005 * ACME Identifier Object Fields 1007 This registry is administered under a Specification Required policy 1008 [RFC8126]. 1010 The "ACME Identifier Object Fields" registry lists field names that 1011 are defined for use in the ACME identifier object. 1013 Template: 1015 * Field name: The string to be used as a field name in the JSON 1016 object 1017 * Field type: The type of value to be provided, e.g., string, 1018 boolean, array of string 1019 * Reference: Where this field is defined 1021 +============+============+===========================+ 1022 | Field Name | Field Type | Reference | 1023 +============+============+===========================+ 1024 | type | string | Section 7.1.3 of RFC 8555 | 1025 +------------+------------+---------------------------+ 1026 | value | string | Section 7.1.3 of RFC 8555 | 1027 +------------+------------+---------------------------+ 1028 | delegation | string | RFC XXXX | 1029 +------------+------------+---------------------------+ 1031 Table 1 1033 Note: this registry was not created at the time [RFC8555] was 1034 standardized likely because it was not anticipated that the 1035 identifier object would be extended. It is retrospectively 1036 introduced to record the status quo and allow controlled 1037 extensibility of the identifier object. 1039 5.2. New Fields in the "meta" Object within a Directory Object 1041 This document adds the following entries to the ACME Directory 1042 Metadata Fields registry: 1044 +====================+============+===========+ 1045 | Field Name | Field Type | Reference | 1046 +====================+============+===========+ 1047 | delegation-enabled | boolean | RFC XXXX | 1048 +--------------------+------------+-----------+ 1050 Table 2 1052 5.3. New Fields in the Order Object 1054 This document adds the following entries to the ACME Order Object 1055 Fields registry: 1057 +=======================+============+==============+===========+ 1058 | Field Name | Field Type | Configurable | Reference | 1059 +=======================+============+==============+===========+ 1060 | allow-certificate-get | boolean | true | RFC XXXX | 1061 +-----------------------+------------+--------------+-----------+ 1063 Table 3 1065 5.4. New Fields in the Account Object 1067 This document adds the following entries to the ACME Account Object 1068 Fields registry: 1070 +=============+============+==========+===========+ 1071 | Field Name | Field Type | Requests | Reference | 1072 +=============+============+==========+===========+ 1073 | delegations | string | none | RFC XXXX | 1074 +-------------+------------+----------+-----------+ 1076 Table 4 1078 Note that the "delegations" field is only reported by ACME servers 1079 that have "delegation-enabled" set to true in their meta Object. 1081 5.5. New Error Types 1083 This document adds the following entries to the ACME Error Type 1084 registry: 1086 +===================+================================+===========+ 1087 | Type | Description | Reference | 1088 +===================+================================+===========+ 1089 | unknownDelegation | An unknown configuration is | RFC XXXX | 1090 | | listed in the "delegations" | | 1091 | | attribute of the request Order | | 1092 +-------------------+--------------------------------+-----------+ 1094 Table 5 1096 5.6. CSR Template Extensions 1098 IANA is requested to establish a registry "STAR Delegation CSR 1099 Template Extensions", with "Expert Review" as its registration 1100 procedure. 1102 Each extension registered must specify: 1104 * An extension name. 1106 * An extension syntax, as a reference to a JSON Schema document that 1107 defines this extension. 1108 * The extension's mapping into an X.509 certificate extension. 1110 The initial contents of this registry are the extensions defined by 1111 the JSON Schema document in Appendix C. 1113 +==================+===========+===============================+ 1114 | Extension Name | Extension | Mapping to X.509 Certificate | 1115 | | Syntax | Extension | 1116 +==================+===========+===============================+ 1117 | keyUsage | See | [RFC5280], Sec. 4.2.1.3 | 1118 | | Appendix | | 1119 | | C | | 1120 +------------------+-----------+-------------------------------+ 1121 | extendedKeyUsage | See | [RFC5280], Sec. 4.2.1.12 | 1122 | | Appendix | | 1123 | | C | | 1124 +------------------+-----------+-------------------------------+ 1125 | subjectAltName | See | [RFC5280], Sec. 4.2.1.6 (note | 1126 | | Appendix | that only specific name | 1127 | | C | formats are allowed: URI, DNS | 1128 | | | name, email address) | 1129 +------------------+-----------+-------------------------------+ 1131 Table 6 1133 6. Security Considerations 1135 6.1. Trust Model 1137 The ACME trust model needs to be extended to include the trust 1138 relationship between NDC and IdO. Note that once this trust link is 1139 established, it potentially becomes recursive. Therefore, there has 1140 to be a trust relationship between each of the nodes in the 1141 delegation chain; for example, in case of cascading CDNs this is 1142 contractually defined. Note that using standard [RFC6125] identity 1143 verification there are no mechanisms available to the IdO to restrict 1144 the use of the delegated name once the name has been handed over to 1145 the first NDC. 1147 6.2. Delegation Security Goal 1149 Delegation introduces a new security goal: only an NDC that has been 1150 authorised by the IdO, either directly or transitively, can obtain a 1151 certificate with an IdO identity. 1153 From a security point of view, the delegation process has five 1154 separate parts: 1156 1. Enabling a specific third party (the intended NDC) to submit 1157 requests for delegated certificates; 1158 2. Making sure that any request for a delegated certificate matches 1159 the intended "shape" in terms of delegated identities as well as 1160 any other certificate metadata, e.g., key length, x.509 1161 extensions, etc.; 1162 3. Serving the certificate back to the NDC; 1163 4. A process for handling revocation of the delegation; 1164 5. A process for handling revocation of the certificate itself. 1166 The first part is covered by the NDC's ACME account that is 1167 administered by the IdO, whose security relies on the correct 1168 handling of the associated key pair. When a compromise of the 1169 private key is detected, the delegate MUST use the account 1170 deactivation procedures defined in Section 7.3.6 of [RFC8555]. 1172 The second part is covered by the act of checking an NDC's 1173 certificate request against the intended CSR template. The steps of 1174 shaping the CSR template correctly, selecting the right CSR template 1175 to check against the presented CSR, and making sure that the 1176 presented CSR matches the selected CSR template are all security 1177 relevant. 1179 The third part builds on the trust relationship between NDC and IdO 1180 that is responsible for correctly forwarding the certificate URL from 1181 the Order returned by the ACME server. 1183 The fourth part is associated with the ability of the IdO to 1184 unilaterally remove the delegation object associated with the revoked 1185 identity, therefore disabling any further NDC requests for such 1186 identity. Note that, in more extreme circumstances, the IdO might 1187 decide to disable the NDC account thus entirely blocking any further 1188 interaction. 1190 The fifth is covered by two different mechanisms, depending on the 1191 nature of the certificate. For STAR, the IdO shall use the 1192 cancellation interface defined in Section 2.3 of [RFC8739]. For non- 1193 STAR, the certificate revocation interface defined in Section 7.6 of 1194 [RFC8555]). 1196 6.3. New ACME Channels 1198 Using the model established in Section 10.1 of [RFC8555], we can 1199 decompose the interactions of the basic delegation workflow as shown 1200 in Figure 8. 1202 ACME Channel 1203 .------------>------------. 1204 .-----. ACME Channel .--+--. .--+----------. 1205 | NDC +------------->| IdO | | ACME server | 1206 '--+--' '--+--' '--+-+--------' 1207 | '-----------<-------------' | 1208 | Validation Channel | 1209 '-------------------->---------------------------' 1210 (subset of) ACME Channel [1] 1212 [1] Unauthenticated certificate fetch and non-STAR certificate 1213 revocation. 1215 Figure 8: Delegation Channels Topology 1217 The considerations regarding the security of the ACME Channel and 1218 Validation Channel discussed in [RFC8555] apply verbatim to the IdO/ 1219 ACME server leg. The same can be said for the ACME channel on the 1220 NDC/IdO leg. A slightly different set of considerations apply to the 1221 ACME Channel between NDC and ACME server, which consists of a subset 1222 of the ACME interface comprising two API endpoints: the 1223 unauthenticated certificate retrieval and, potentially, non-STAR 1224 revocation via certificate private key. No specific security 1225 considerations apply to the former, but the privacy considerations in 1226 Section 6.3 of [RFC8739] do. With regards to the latter, it should 1227 be noted that there is currently no means for an IdO to disable 1228 authorising revocation based on certificate private keys. So, in 1229 theory, an NDC could use the revocation API directly with the ACME 1230 server, therefore bypassing the IdO. The NDC SHOULD NOT directly use 1231 the revocation interface exposed by the ACME server unless failing to 1232 do so would compromise the overall security, for example if the 1233 certificate private key is compromised and the IdO is not currently 1234 reachable. 1236 All other security considerations from [RFC8555] and [RFC8739] apply 1237 as-is to the delegation topology. 1239 6.4. Restricting CDNs to the Delegation Mechanism 1241 When a web site is delegated to a CDN, the CDN can in principle 1242 modify the web site at will, create and remove pages. This means 1243 that a malicious or breached CDN can pass the ACME (as well as common 1244 non-ACME) HTTPS-based validation challenges and generate a 1245 certificate for the site. This is true regardless of whether the 1246 CNAME mechanisms defined in the current document is used or not. 1248 In some cases, this is the desired behavior: the domain owner trusts 1249 the CDN to have full control of the cryptographic credentials for the 1250 site. The current document however assumes that the domain owner 1251 only wants to delegate restricted control, and wishes to retain the 1252 capability to cancel the CDN's credentials at a short notice. 1254 The following is a possible mitigation when the IdO wishes to ensure 1255 that a rogue CDN cannot issue unauthorized certificates: 1257 * The domain owner makes sure that the CDN cannot modify the DNS 1258 records for the domain. The domain owner should ensure it is the 1259 only entity authorized to modify the DNS zone. Typically, it 1260 establishes a CNAME resource record from a subdomain into a CDN- 1261 managed domain. 1262 * The domain owner uses a CAA record [RFC8659] to restrict 1263 certificate issuance for the domain to specific CAs that comply 1264 with ACME and are known to implement [RFC8657]. 1265 * The domain owner uses the ACME-specific CAA mechanism [RFC8657] to 1266 restrict issuance to a specific account key which is controlled by 1267 it, and MUST require "dns-01" as the sole validation method. 1269 We note that the above solution may need to be tweaked depending on 1270 the exact capabilities and authorisation flows supported by the 1271 selected CAs. 1273 7. Acknowledgments 1275 We would like to thank the following people who contributed 1276 significantly to this document with their review comments and design 1277 proposals: Roman Danyliw, Frédéric Fieau, Sanjay Mishra, Jon 1278 Peterson, Ryan Sleevi, Emile Stephan. 1280 This work is partially supported by the European Commission under 1281 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 1282 for a Middleboxed Internet (MAMI). This support does not imply 1283 endorsement. 1285 8. References 1287 8.1. Normative References 1289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1290 Requirement Levels", BCP 14, RFC 2119, 1291 DOI 10.17487/RFC2119, March 1997, 1292 . 1294 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1295 Housley, R., and W. Polk, "Internet X.509 Public Key 1296 Infrastructure Certificate and Certificate Revocation List 1297 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1298 . 1300 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1301 Writing an IANA Considerations Section in RFCs", BCP 26, 1302 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1303 . 1305 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1306 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1307 May 2017, . 1309 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1310 Kasten, "Automatic Certificate Management Environment 1311 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1312 . 1314 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1315 Definition Language (CDDL): A Notational Convention to 1316 Express Concise Binary Object Representation (CBOR) and 1317 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1318 June 2019, . 1320 [RFC8657] Landau, H., "Certification Authority Authorization (CAA) 1321 Record Extensions for Account URI and Automatic 1322 Certificate Management Environment (ACME) Method Binding", 1323 RFC 8657, DOI 10.17487/RFC8657, November 2019, 1324 . 1326 [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, 1327 "DNS Certification Authority Authorization (CAA) Resource 1328 Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, 1329 . 1331 [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor 1332 Perales, A., and T. Fossati, "Support for Short-Term, 1333 Automatically Renewed (STAR) Certificates in the Automated 1334 Certificate Management Environment (ACME)", RFC 8739, 1335 DOI 10.17487/RFC8739, March 2020, 1336 . 1338 8.2. Informative References 1340 [I-D.ietf-acme-authority-token-tnauthlist] 1341 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 1342 "TNAuthList profile of ACME Authority Token", Work in 1343 Progress, Internet-Draft, draft-ietf-acme-authority-token- 1344 tnauthlist-06, 9 March 2020, . 1348 [I-D.ietf-cdni-interfaces-https-delegation] 1349 Fieau, F., Emile, S., and S. Mishra, "CDNI extensions for 1350 HTTPS delegation", Work in Progress, Internet-Draft, 1351 draft-ietf-cdni-interfaces-https-delegation-04, 9 1352 September 2020, . 1355 [I-D.ietf-stir-cert-delegation] 1356 Peterson, J., "STIR Certificate Delegation", Work in 1357 Progress, Internet-Draft, draft-ietf-stir-cert-delegation- 1358 03, 13 July 2020, . 1361 [I-D.ietf-tls-subcerts] 1362 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 1363 "Delegated Credentials for TLS", Work in Progress, 1364 Internet-Draft, draft-ietf-tls-subcerts-10, 24 January 1365 2021, . 1368 [I-D.mglt-lurk-tls13] 1369 Migault, D., "LURK Extension version 1 for (D)TLS 1.3 1370 Authentication", Work in Progress, Internet-Draft, draft- 1371 mglt-lurk-tls13-04, 25 January 2021, . 1374 [json-schema-07] 1375 Wright, A., Andrews, H., and G. Luff, "JSON Schema 1376 Validation: A Vocabulary for Structural Validation of 1377 JSON", 2018, . 1380 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1381 Verification of Domain-Based Application Service Identity 1382 within Internet Public Key Infrastructure Using X.509 1383 (PKIX) Certificates in the Context of Transport Layer 1384 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1385 2011, . 1387 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1388 "Framework for Content Distribution Network 1389 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1390 August 2014, . 1392 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1393 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1394 . 1396 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 1397 Credentials: Certificates", RFC 8226, 1398 DOI 10.17487/RFC8226, February 2018, 1399 . 1401 Appendix A. Document History 1403 [[Note to RFC Editor: please remove before publication.]] 1405 A.1. draft-ietf-acme-star-delegation-06 1407 * CDDL schema to address Roman's remaining comments. 1409 A.2. draft-ietf-acme-star-delegation-05 1411 * Detailed AD review by Roman Danyliw. 1412 * Some comments that were left unaddressed in Ryan Sleevi's review. 1413 * Numerous other edits for clarity and consistency. 1415 A.3. draft-ietf-acme-star-delegation-04 1417 * Delegation of non-STAR certificates. 1418 * More IANA clarity, specifically on certificate extensions. 1419 * Add delegation configuration object and extend account and order 1420 objects accordingly. 1421 * A lot more depth on Security Considerations. 1423 A.4. draft-ietf-acme-star-delegation-03 1425 * Consistency with the latest changes in the base ACME STAR 1426 document, e.g. star-delegation-enabled capability renamed and 1427 moved. 1428 * Proxy use cases (recursive delegation) and the definition of proxy 1429 behavior. 1430 * More detailed analysis of the CDNI and STIR use cases, including 1431 sequence diagrams. 1433 A.5. draft-ietf-acme-star-delegation-02 1434 * Security considerations: review by Ryan Sleevi. 1435 * CSR template simplified: instead of being a JSON Schema document 1436 itself, it is now a simple JSON document which validates to a JSON 1437 Schema. 1439 A.6. draft-ietf-acme-star-delegation-01 1441 * Refinement of the CDNI use case. 1442 * Addition of the CSR template (partial, more work required). 1443 * Further security considerations (work in progress). 1445 A.7. draft-ietf-acme-star-delegation-00 1447 * Republished as a working group draft. 1449 A.8. draft-sheffer-acme-star-delegation-01 1451 * Added security considerations about disallowing CDNs from issuing 1452 certificates for a delegated domain. 1454 A.9. draft-sheffer-acme-star-delegation-00 1456 * Initial version, some text extracted from draft-sheffer-acme-star- 1457 requests-02 1459 Appendix B. CSR Template: CDDL 1461 Following is the normative definition of the CSR template, using CDDL 1462 [RFC8610]. The CSR template MUST be a valid JSON document, compliant 1463 with the syntax defined here. 1465 An additional constraint that is not expressed in CDDL but MUST be 1466 validated by the recipient is that all objects (e.g. 1467 "distinguishedName") MUST NOT be empty when they are included, even 1468 when each separate property is optional. 1470 csr-template-schema = { 1471 keyTypes: [ 1* $keyType ] 1472 ? subject: distinguishedName 1473 extensions: extensions 1474 } 1476 mandatory-wildcard = "**" 1477 optional-wildcard = "*" 1478 wildcard = mandatory-wildcard / optional-wildcard 1480 ; regtext matches all text strings but "*" and "**" 1481 regtext = text .regexp "([^\*].*)|([\*][^\*].*)|([\*][\*].+)" 1482 regtext-or-wildcard = regtext / wildcard 1484 distinguishedName = { 1485 ? country: regtext-or-wildcard 1486 ? stateOrProvince: regtext-or-wildcard 1487 ? locality: regtext-or-wildcard 1488 ? organization: regtext-or-wildcard 1489 ? organizationalUnit: regtext-or-wildcard 1490 ? emailAddress: regtext-or-wildcard 1491 ? commonName: regtext-or-wildcard 1492 } 1494 $keyType /= rsaKeyType 1495 $keyType /= ecdsaKeyType 1497 rsaKeyType = { 1498 PublicKeyType: "rsaEncryption" ; OID: 1.2.840.113549.1.1.1 1499 PublicKeyLength: rsaKeySize 1500 SignatureType: $rsaSignatureType 1501 } 1503 rsaKeySize = int .ge 2048 1505 ; RSASSA-PKCS1-v1_5 with SHA-256 1506 $rsaSignatureType /= "sha256WithRSAEncryption" 1507 ; RSASSA-PCKS1-v1_5 with SHA-384 1508 $rsaSignatureType /= "sha384WithRSAEncryption" 1509 ; RSASSA-PCKS1-v1_5 with SHA-512 1510 $rsaSignatureType /= "sha512WithRSAEncryption" 1511 ; RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes 1512 $rsaSignatureType /= "sha256WithRSAandMGF1" 1513 ; RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes 1514 $rsaSignatureType /= "sha384WithRSAandMGF1" 1515 ; RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes 1516 $rsaSignatureType /= "sha512WithRSAandMGF1" 1518 ecdsaKeyType = { 1519 PublicKeyType: "id-ecPublicKey" ; OID: 1.2.840.10045.2.1 1520 namedCurve: $ecdsaCurve 1521 SignatureType: $ecdsaSignatureType 1522 } 1524 $ecdsaCurve /= "secp256r1" ; OID: 1.2.840.10045.3.1.7 1525 $ecdsaCurve /= "secp384r1" ; OID: 1.3.132.0.34 1526 $ecdsaCurve /= "secp521r1" ; OID: 1.3.132.0.3 1528 $ecdsaSignatureType /= "ecdsa-with-SHA256" ; paired with secp256r1 1529 $ecdsaSignatureType /= "ecdsa-with-SHA384" ; paired with secp384r1 1530 $ecdsaSignatureType /= "ecdsa-with-SHA512" ; paired with secp521r1 1532 subjectaltname = { 1533 ? DNS: [ 1* regtext-or-wildcard ] 1534 ? Email: [ 1* regtext ] 1535 ? URI: [ 1* regtext ] 1536 * $$subjectaltname-extension 1537 } 1539 extensions = { 1540 ? keyUsage: [ 1* keyUsageType ] 1541 ? extendedKeyUsage: [ 1* extendedKeyUsageType ] 1542 subjectAltName: subjectaltname 1543 } 1545 keyUsageType /= "digitalSignature" 1546 keyUsageType /= "nonRepudiation" 1547 keyUsageType /= "keyEncipherment" 1548 keyUsageType /= "dataEncipherment" 1549 keyUsageType /= "keyAgreement" 1550 keyUsageType /= "keyCertSign" 1551 keyUsageType /= "cRLSign" 1552 keyUsageType /= "encipherOnly" 1553 keyUsageType /= "decipherOnly" 1555 extendedKeyUsageType /= "serverAuth" 1556 extendedKeyUsageType /= "clientAuth" 1557 extendedKeyUsageType /= "codeSigning" 1558 extendedKeyUsageType /= "emailProtection" 1559 extendedKeyUsageType /= "timeStamping" 1560 extendedKeyUsageType /= "OCSPSigning" 1562 Appendix C. CSR Template: JSON Schema 1564 This appendix includes an alternative, non-normative, JSON Schema 1565 definition of the CSR template. The syntax used is that of draft 7 1566 of JSON Schema, which is documented in [json-schema-07]. Note that 1567 later versions of this (now expired) draft describe later versions of 1568 the JSON Schema syntax. At the time of writing, a stable reference 1569 for this syntax is not yet available, and we have chosen to use the 1570 draft version which is currently best supported by tool 1571 implementations. 1573 While the CSR template must follow the syntax defined here, neither 1574 the IdO nor the NDC are expected to validate it at run-time. 1576 { 1577 "title": "JSON Schema for the STAR Delegation CSR template", 1578 "$schema": "http://json-schema.org/draft-07/schema#", 1579 "$id": "http://ietf.org/acme/drafts/star-delegation/csr-template", 1580 "$defs": { 1581 "distinguished-name": { 1582 "$id": "#distinguished-name", 1583 "type": "object", 1584 "minProperties": 1, 1585 "properties": { 1586 "country": { 1587 "type": "string" 1588 }, 1589 "stateOrProvince": { 1590 "type": "string" 1591 }, 1592 "locality": { 1593 "type": "string" 1594 }, 1595 "organization": { 1596 "type": "string" 1597 }, 1598 "organizationalUnit": { 1599 "type": "string" 1600 }, 1601 "emailAddress": { 1602 "type": "string" 1603 }, 1604 "commonName": { 1605 "type": "string" 1606 } 1607 }, 1608 "additionalProperties": false 1609 }, 1610 "rsaKeyType": { 1611 "$id": "#rsaKeyType", 1612 "type": "object", 1613 "properties": { 1614 "PublicKeyType": { 1615 "type": "string", 1616 "const": "rsaEncryption" 1617 }, 1618 "PublicKeyLength": { 1619 "type": "integer", 1620 "minimum": 2048, 1621 "multipleOf": 8 1622 }, 1623 "SignatureType": { 1624 "type": "string", 1625 "enum": [ 1626 "sha256WithRSAEncryption", 1627 "sha384WithRSAEncryption", 1628 "sha512WithRSAEncryption", 1629 "sha256WithRSAandMGF1", 1630 "sha384WithRSAandMGF1", 1631 "sha512WithRSAandMGF1" 1632 ] 1633 } 1634 }, 1635 "required": [ 1636 "PublicKeyType", 1637 "PublicKeyLength", 1638 "SignatureType" 1639 ], 1640 "additionalProperties": false 1641 }, 1642 "ecdsaKeyType": { 1643 "$id": "#ecdsaKeyType", 1644 "type": "object", 1645 "properties": { 1646 "PublicKeyType": { 1647 "type": "string", 1648 "const": "id-ecPublicKey" 1649 }, 1650 "namedCurve": { 1651 "type": "string", 1652 "enum": [ 1653 "secp256r1", 1654 "secp384r1", 1655 "secp521r1" 1656 ] 1657 }, 1658 "SignatureType": { 1659 "type": "string", 1660 "enum": [ 1661 "ecdsa-with-SHA256", 1662 "ecdsa-with-SHA384", 1663 "ecdsa-with-SHA512" 1664 ] 1665 } 1666 }, 1667 "required": [ 1668 "PublicKeyType", 1669 "namedCurve", 1670 "SignatureType" 1671 ], 1672 "additionalProperties": false 1673 } 1674 }, 1675 "type": "object", 1676 "properties": { 1677 "keyTypes": { 1678 "type": "array", 1679 "items": { 1680 "oneOf": [ 1681 { 1682 "$ref": "#rsaKeyType" 1683 }, 1684 { 1685 "$ref": "#ecdsaKeyType" 1686 } 1687 ] 1688 } 1689 }, 1690 "subject": { 1691 "$ref": "#distinguished-name" 1692 }, 1693 "extensions": { 1694 "type": "object", 1695 "properties": { 1696 "keyUsage": { 1697 "type": "array", 1698 "minItems": 1, 1699 "items": { 1700 "type": "string", 1701 "enum": [ 1702 "digitalSignature", 1703 "nonRepudiation", 1704 "keyEncipherment", 1705 "dataEncipherment", 1706 "keyAgreement", 1707 "keyCertSign", 1708 "cRLSign", 1709 "encipherOnly", 1710 "decipherOnly" 1711 ] 1712 } 1713 }, 1714 "extendedKeyUsage": { 1715 "type": "array", 1716 "minItems": 1, 1717 "items": { 1718 "type": "string", 1719 "enum": [ 1720 "serverAuth", 1721 "clientAuth", 1722 "codeSigning", 1723 "emailProtection", 1724 "timeStamping", 1725 "OCSPSigning" 1726 ] 1727 } 1728 }, 1729 "subjectAltName": { 1730 "type": "object", 1731 "minProperties": 1, 1732 "properties": { 1733 "DNS": { 1734 "type": "array", 1735 "minItems": 1, 1736 "items": { 1737 "type": "string", 1738 "format": "hostname" 1739 } 1740 }, 1741 "Email": { 1742 "type": "array", 1743 "minItems": 1, 1744 "items": { 1745 "type": "string", 1746 "format": "email" 1747 } 1748 }, 1749 "URI": { 1750 "type": "array", 1751 "minItems": 1, 1752 "items": { 1753 "type": "string", 1754 "format": "uri" 1755 } 1756 } 1757 }, 1758 "additionalProperties": false 1759 } 1760 }, 1761 "required": [ 1762 "subjectAltName" 1763 ], 1764 "additionalProperties": false 1765 } 1766 }, 1767 "required": [ 1768 "extensions", 1769 "keyTypes" 1770 ], 1771 "additionalProperties": false 1772 } 1774 Authors' Addresses 1776 Yaron Sheffer 1777 Intuit 1779 Email: yaronf.ietf@gmail.com 1781 Diego López 1782 Telefonica I+D 1784 Email: diego.r.lopez@telefonica.com 1786 Antonio Agustín Pastor Perales 1787 Telefonica I+D 1789 Email: antonio.pastorperales@telefonica.com 1791 Thomas Fossati 1792 ARM 1794 Email: thomas.fossati@arm.com