idnits 2.17.1 draft-ietf-acme-star-delegation-07.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 : ---------------------------------------------------------------------------- -- 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 (26 March 2021) is 1099 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 1341 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-13) exists of draft-ietf-acme-authority-token-tnauthlist-07 == Outdated reference: A later version (-13) exists of draft-ietf-cdni-interfaces-https-delegation-05 == 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 (~~), 6 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: 27 September 2021 A. Pastor Perales 6 Telefonica I+D 7 T. Fossati 8 ARM 9 26 March 2021 11 An ACME Profile for Generating Delegated Certificates 12 draft-ietf-acme-star-delegation-07 14 Abstract 16 This memo defines a profile of the Automatic Certificate Management 17 Environment (ACME) protocol by which the owner of an identifier 18 (e.g., a domain name) can allow a third party to obtain an X.509 19 certificate such that the certificate subject is the delegated 20 identifier while the certified public key corresponds to a private 21 key controlled by the third party. A primary use case is that of a 22 Content Delivery Network (CDN, the third party) terminating TLS 23 sessions on behalf of a content provider (the owner of a domain 24 name). The presented mechanism allows the owner of the identifier to 25 retain control over the delegation and revoke it at any time. A key 26 property of this mechanism is it does not require any modification to 27 the deployed TLS ecosystem. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 27 September 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2. Conventions used in this document . . . . . . . . . . . . 5 65 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5 67 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 8 69 2.3.1. Delegation Configuration . . . . . . . . . . . . . . 8 70 2.3.2. Order Object Transmitted from NDC to IdO and to ACME 71 Server (STAR) . . . . . . . . . . . . . . . . . . . . 10 72 2.3.3. Order Object Transmitted from NDC to IdO and to ACME 73 Server (non-STAR) . . . . . . . . . . . . . . . . . . 13 74 2.3.4. Capability Discovery . . . . . . . . . . . . . . . . 16 75 2.3.5. Terminating the Delegation . . . . . . . . . . . . . 16 76 2.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 17 77 3. CSR Template . . . . . . . . . . . . . . . . . . . . . . . . 18 78 3.1. Template Syntax . . . . . . . . . . . . . . . . . . . . . 19 79 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 4. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 21 81 4.1. CDN Interconnection (CDNI) . . . . . . . . . . . . . . . 21 82 4.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 22 83 4.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 22 84 4.2. Secure Telephone Identity Revisited (STIR) . . . . . . . 25 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 86 5.1. New ACME Identifier Object Fields . . . . . . . . . . . . 26 87 5.2. New Fields in the "meta" Object within a Directory 88 Object . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 5.3. New Fields in the Order Object . . . . . . . . . . . . . 27 90 5.4. New Fields in the Account Object . . . . . . . . . . . . 28 91 5.5. New Error Types . . . . . . . . . . . . . . . . . . . . . 28 92 5.6. CSR Template Extensions . . . . . . . . . . . . . . . . . 28 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 94 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 29 95 6.2. Delegation Security Goal . . . . . . . . . . . . . . . . 29 96 6.3. New ACME Channels . . . . . . . . . . . . . . . . . . . . 30 97 6.4. Restricting CDNs to the Delegation Mechanism . . . . . . 31 98 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 101 8.2. Informative References . . . . . . . . . . . . . . . . . 34 102 Appendix A. Document History . . . . . . . . . . . . . . . . . . 35 103 A.1. draft-ietf-acme-star-delegation-07 . . . . . . . . . . . 35 104 A.2. draft-ietf-acme-star-delegation-06 . . . . . . . . . . . 35 105 A.3. draft-ietf-acme-star-delegation-05 . . . . . . . . . . . 35 106 A.4. draft-ietf-acme-star-delegation-04 . . . . . . . . . . . 35 107 A.5. draft-ietf-acme-star-delegation-03 . . . . . . . . . . . 36 108 A.6. draft-ietf-acme-star-delegation-02 . . . . . . . . . . . 36 109 A.7. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 36 110 A.8. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 36 111 A.9. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 36 112 A.10. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 36 113 Appendix B. CSR Template: CDDL . . . . . . . . . . . . . . . . . 36 114 Appendix C. CSR Template: JSON Schema . . . . . . . . . . . . . 39 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 117 1. Introduction 119 This document is a companion document to [RFC8739]. To avoid 120 duplication, we give here a bare-bones description of the motivation 121 for this solution. For more details and further use cases, please 122 refer to the introductory sections of [RFC8739]. 124 An Identifier Owner (IdO) has agreements in place with one or more 125 NDC (Name Delegation Consumer) to use and attest its identity. 127 In the primary use case the IdO is a content provider, and we 128 consider a Content Delivery Network (CDN) provider contracted to 129 serve the content over HTTPS. The CDN terminates the HTTPS 130 connection at one of its edge cache servers and needs to present its 131 clients (browsers, mobile apps, set-top-boxes) a certificate whose 132 name matches the domain name of the URL that is requested, i.e., that 133 of the IdO. Understandably, some IdOs may balk at sharing their 134 long-term private keys with another organization and, equally, 135 delegates would rather not have to handle other parties' long-term 136 secrets. Other relevant use cases are discussed in Section 4. 138 This document describes a profile of the ACME protocol [RFC8555] that 139 allows the NDC to request from the IdO, acting as a profiled ACME 140 server, a certificate for a delegated identity - i.e., one belonging 141 to the IdO. The IdO then uses the ACME protocol (with the extensions 142 described in [RFC8739]) to request issuance of a Short-Term, 143 Automatically Renewed (STAR) certificate for the same delegated 144 identity. The generated short-term certificate is automatically 145 renewed by the ACME Certification Authority (CA), periodically 146 fetched by the NDC and used to terminate HTTPS connections in lieu of 147 the IdO. The IdO can end the delegation at any time by simply 148 instructing the CA to stop the automatic renewal and letting the 149 certificate expire shortly thereafter. 151 While the primary use case we address is delegation of STAR 152 certificates, the mechanism proposed here accommodates also long- 153 lived certificates managed with the ACME protocol. The most 154 noticeable difference between long-lived and STAR certificates is the 155 way the termination of the delegation is managed. In the case of 156 long-lived certificates, the IdO uses the revokeCert URL exposed by 157 the ACME CA and waits for the explicit revocation based on CRL and 158 OCSP to propagate to the relying parties. 160 In case the delegated identity is a domain name, this document also 161 provides a way for the NDC to inform the IdO about the CNAME mappings 162 that need to be installed in the IdO's DNS zone to enable the 163 aliasing of the delegated name, thus allowing the complete name 164 delegation workflow to be handled using a single interface. 166 We note that other ongoing efforts address the problem of certificate 167 delegation for TLS connections, specifically [I-D.ietf-tls-subcerts] 168 and [I-D.mglt-lurk-tls13]. Compared to these other solutions, the 169 current document does not introduce additional latency to the TLS 170 connection, nor does it require changes to the TLS network stack of 171 either the client or the server. 173 1.1. Terminology 175 IdO Identifier Owner, the owner of an identifier (e.g., a domain 176 name) that needs to be delegated. 178 NDC Name Delegation Consumer, the entity to which the domain name is 179 delegated for a limited time. This is a CDN in the primary use 180 case (in fact, readers may note the symmetry of the two acronyms). 182 CDN Content Delivery Network, a widely distributed network that 183 serves the domain's web content to a wide audience at high 184 performance. 186 STAR Short-Term, Automatically Renewed X.509 certificates. 188 ACME Automated Certificate Management Environment, a certificate 189 management protocol [RFC8555]. 191 CA A Certification Authority that implements the ACME protocol. In 192 this document, the term is synonymous with "ACME server". 194 CSR A PKCS#10 [RFC2986] Certificate Signing Request, as supported by 195 ACME. 197 FQDN Fully Qualified Domain Name. 199 1.2. Conventions used in this document 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in 204 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 2. Protocol Flow 209 This section presents the protocol flow. For completeness, we 210 include the ACME profile proposed in this document as well as the 211 extended ACME protocol described in [RFC8739]. 213 2.1. Preconditions 215 The protocol assumes the following preconditions are met: 217 * The IdO exposes an ACME server interface to the NDC(s) comprising 218 the account management interface; 219 * The NDC has registered an ACME account with the IdO; 220 * NDC and IdO have agreed on a "CSR template" to use, including at a 221 minimum: subject name (e.g., "somesite.example.com"), requested 222 algorithms and key length, key usage, extensions (e.g., 223 TNAuthList). The NDC is required to use this template for every 224 CSR created under the same delegation; 225 * IdO has registered an ACME account with the Certification 226 Authority (CA) 228 Note that even if the IdO implements the ACME server role, it is not 229 acting as a CA: in fact, from the point of view of the certificate 230 issuance process, the IdO only works as a "policing" forwarder of the 231 NDC's key-pair and is responsible for completing the identity 232 verification process towards the ACME server. 234 2.2. Overview 236 For clarity, the protocol overview presented here covers the main use 237 case of this protocol, namely delegation of STAR certificates. 238 Protocol behavior for non-STAR certificates is similar, and the 239 detailed differences are listed in the following sections. 241 The interaction between the NDC and the IdO is governed by the 242 profiled ACME workflow detailed in Section 2.3. The interaction 243 between the IdO and the CA is ruled by ACME [RFC8555], ACME STAR 244 [RFC8739] as well as any other ACME extension that applies (e.g., 245 [I-D.ietf-acme-authority-token-tnauthlist] for STIR). 247 The outline of the combined protocol for STAR certificates is as 248 follow (Figure 1): 250 * NDC sends an order Order1 for the delegated identifier to IdO; 251 * IdO creates an Order1 resource in state "ready" with a "finalize" 252 URL; 253 * NDC immediately sends a finalize request (which includes the CSR) 254 to the IdO; 255 * IdO verifies the CSR according to the agreed upon CSR template; 256 * If the CSR verification fails, Order1 is moved to an "invalid" 257 state and everything stops; 258 * If the CSR verification is successful, IdO moves Order1 to state 259 "processing", and sends a new Order2 (using its own account) for 260 the delegated identifier to the CA; 261 * If the ACME STAR protocol fails, Order2 moves to "invalid" and the 262 same state is reflected in Order1 (i.e., the NDC Order); 263 * If the ACME STAR run is successful (i.e., Order2 is "valid"), IdO 264 copies the "star-certificate" URL from Order2 to Order1 and 265 updates the Order1 state to "valid". 267 The NDC can now download, install and use the short-term certificate 268 bearing the name delegated by the IdO. This can continue until the 269 STAR certificate expires or the IdO decides to cancel the automatic 270 renewal process with the CA. 272 Note that the interactive identifier authorization phase described in 273 Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because 274 the delegated identity contained in the CSR presented to the IdO is 275 validated against the configured CSR template (Section 2.3.1). 276 Therefore, the NDC sends the finalize request, including the CSR, to 277 the IdO immediately after Order1 has been acknowledged. The IdO 278 SHALL buffer a (valid) CSR until the Validation phase completes 279 successfully. 281 .------. .---------------. .------. 282 | NDC | | IdO | | ACME | 283 +--------+ +--------+--------+ +--------+ 284 | Client | | Server | Client | | Server | 285 '---+----' '----+---+---+----' '----+---' 286 | | | | 287 | Order1 | | | 288 | Signature | | | 289 o------------------->| | | 290 | | | | 291 | [ No identity ] | | | 292 | [ validation via ] | | | 293 | [ authorizations ] | | | 294 | | | | 295 | CSR | | | 296 | Signature | | | 297 o------------------->| | | 298 | Acknowledgement | | Order2 | 299 |<-------------------o | Signature | 300 | | o------------------->| 301 | | | Required | 302 | | | Authorizations | 303 | | |<-------------------o 304 | | | Responses | 305 | | | Signature | 306 | | o------------------->| 307 | | | | 308 | | |<~~~~Validation~~~~>| 309 | | | | 310 | | | CSR | 311 | | | Signature | 312 | | o------------------->| 313 | | | Acknowledgement | 314 | | |<-------------------o 315 | | | | 316 |<~~Await issuance~->| |<~~Await issuance~~>| 317 | | 318 | (unauthenticated) GET STAR certificate | 319 o------------------------------------------------>| 320 | Certificate #1 | 321 |<------------------------------------------------o 322 | (unauthenticated) GET STAR certificate | 323 o------------------------------------------------>| 324 | Certificate #2 | 325 |<------------------------------------------------o 326 | [...] | 327 | (unauthenticated) GET STAR certificate | 328 o------------------------------------------------>| 329 | Certificate #n | 330 |<------------------------------------------------o 332 Figure 1: End to end STAR delegation flow 334 2.3. Delegated Identity Profile 336 This section defines a profile of the ACME protocol, to be used 337 between the NDC and IdO. 339 2.3.1. Delegation Configuration 341 The IdO must be preconfigured to recognize one or more NDCs, and 342 present them with details about certificate delegations that apply to 343 each one. 345 2.3.1.1. Account Object Extensions 347 An NDC identifies itself to the IdO as an ACME account. The IdO can 348 delegate multiple names to a NDC, and these configurations are 349 described through "delegation" objects associated with the NDC's 350 Account object on the IdO. 352 As shown in Figure 2, the ACME account resource on the IdO is 353 extended with a new "delegations" attribute: 355 * delegations (required, string): A URL from which a list of 356 delegations configured for this account can be fetched via a POST- 357 as-GET request. 359 { 360 "status": "valid", 361 "contact": [ 362 "mailto:delegation-admin@ido.example" 363 ], 364 "termsOfServiceAgreed": true, 365 "orders": "https://example.com/acme/orders/rzGoeA", 366 "delegations": "https://acme.ido.example/acme/delegations/adFqoz" 367 } 369 Figure 2: Example Account object with delegations 371 2.3.1.2. Delegation Objects 373 This profile extends the ACME resource model with a new read-only 374 delegation object that represents a delegation configuration that 375 applies to a given NDC. 377 A delegation object contains the CSR template (see Section 3) that 378 applies to that delegation, and optionally any related CNAME mapping 379 for the delegated identifiers. Its structure is as follows: 381 * csr-template (required, object): CSR template as defined in 382 Section 3. 383 * cname-map (optional, object): a map of FQDN pairs. In each pair, 384 the name is the delegated identifier, the value is the 385 corresponding IdO name that is aliased in the IdO's zone file to 386 redirect the resolvers to the delegated entity. Both names and 387 values MUST be FQDNs with a terminating '.'. This field is only 388 meaningful for identifiers of type "dns". 390 An example delegation object is shown in Figure 3. 392 { 393 "csr-template": { 394 "keyTypes": [ 395 { 396 "PublicKeyType": "id-ecPublicKey", 397 "namedCurve": "secp256r1", 398 "SignatureType": "ecdsa-with-SHA256" 399 } 400 ], 401 "subject": { 402 "country": "CA", 403 "stateOrProvince": "**", 404 "locality": "**", 405 "commonName": "**" 406 }, 407 "extensions": { 408 "subjectAltName": { 409 "DNS": [ 410 "abc.ndc.ido.example" 411 ] 412 }, 413 "keyUsage": [ 414 "digitalSignature" 415 ], 416 "extendedKeyUsage": [ 417 "serverAuth" 418 ] 419 } 420 }, 421 "cname-map": { 422 "abc.ndc.ido.example.": "abc.ndc.example." 423 } 424 } 425 Figure 3: Example Delegation Configuration object 427 In order to indicate which specific delegation applies to the 428 requested certificate a new "delegation" attribute is added to the 429 identifier in the Order object on the NDC-IdO side (see Figure 4). 430 The value of this attribute is the URL pointing to the delegation 431 configuration object that is to be used for this certificate request. 432 If the "delegation" attribute in the Order object contains a URL that 433 does not correspond to a configuration available to the requesting 434 NDC, the IdO MUST return an error response with status code 403 435 (Forbidden) and type "urn:ietf:params:acme:error:unknownDelegation". 437 2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server 438 (STAR) 440 If the delegation is for a STAR certificate, the Order object created 441 by the NDC: 443 * MUST have the delegated name as the identifier value with a 444 "delegation" attribute indicating the configuration used for the 445 identifier. 446 * MUST NOT contain the "notBefore" and "notAfter" fields; 447 * MUST contain an "auto-renewal" object and inside it, the fields 448 listed in Section 3.1.1 of [RFC8739]. 450 POST /acme/new-order HTTP/1.1 451 Host: acme.ido.example 452 Content-Type: application/jose+json 454 { 455 "protected": base64url({ 456 "alg": "ES256", 457 "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg", 458 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 459 "url": "https://acme.ido.example/acme/new-order" 460 }), 461 "payload": base64url({ 462 "identifiers": [ 463 { 464 "type": "dns", 465 "value": "abc.ndc.ido.example.", 466 "delegation": 467 "https://acme.ido.example/acme/delegations/adFqoz/2" 468 } 469 ], 470 "auto-renewal": { 471 "end-date": "2020-04-20T00:00:00Z", 472 "lifetime": 345600, // 4 days 473 "allow-certificate-get": true 474 } 475 }), 476 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 477 } 479 Figure 4: New STAR Order from NDC 481 The Order object that is created on the IdO: 483 * MUST start in the "ready" state; 484 * MUST contain an "authorizations" array with zero elements; 485 * MUST contain the indicated "delegation" configurations. 486 * MUST NOT contain the "notBefore" and "notAfter" fields. 488 { 489 "status": "ready", 490 "expires": "2019-05-01T00:00:00Z", 492 "identifiers": [ 493 { 494 "type": "dns", 495 "value": "abc.ndc.ido.example.", 496 "delegation": 497 "https://acme.ido.example/acme/delegations/adFqoz/2" 498 } 499 ], 501 "auto-renewal": { 502 "end-date": "2020-04-20T00:00:00Z", 503 "lifetime": 345600, 504 "allow-certificate-get": true 505 }, 507 "authorizations": [], 509 "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize" 510 } 512 Figure 5: STAR Order Resource Created on IdO 514 The Order is then finalized by the NDC supplying the CSR containing 515 the delegated identifiers. The IdO checks the provided CSR against 516 the template that applies to each delegated identifier, as described 517 in Section 3.1. If the CSR fails validation for any of the 518 identifiers, the IdO MUST return an error response with status code 519 403 (Forbidden) and an appropriate type, e.g., "rejectedIdentifier" 520 or "badCSR". The error response SHOULD contain subproblems 521 (Section 6.7.1 of [RFC8555]) for each failed identifier. If the CSR 522 is successfully validated, the Order object status moves to 523 "processing" and the twin ACME protocol instance is initiated on the 524 IdO-CA side. 526 The Order object created by the IdO: 528 * MUST copy the identifiers sent by the NDC and strip the 529 "delegation" attribute; 530 * MUST carry a copy of the "auto-renewal" object sent by the NDC and 531 augment it with an "allow-certificate-get" attribute set to true. 533 When the validation of the identifiers has been successfully 534 completed and the certificate has been issued by the CA, the IdO: 536 * MUST move its Order resource status to "valid". 537 * MUST copy the "star-certificate" field from the STAR Order. The 538 latter indirectly includes (via the NotBefore and NotAfter HTTP 539 headers) the renewal timers needed by the NDC to inform its 540 certificate reload logic. 542 { 543 "status": "valid", 544 "expires": "2019-05-01T00:00:00Z", 546 "identifiers": [ 547 { 548 "type": "dns", 549 "value": "abc.ndc.ido.example.", 550 "delegation": 551 "https://acme.ido.example/acme/delegations/adFqoz/2" 552 } 553 ], 555 "auto-renewal": { 556 "end-date": "2020-04-20T00:00:00Z", 557 "lifetime": 345600, 558 "allow-certificate-get": true 559 }, 561 "authorizations": [], 563 "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize", 565 "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" 566 } 568 Figure 6: STAR Order Resource Updated on IdO 570 2.3.2.1. CNAME Installation 572 If an identifier object of type "dns" was included, the IdO can add 573 the corresponding CNAME records to its zone, e.g.: 575 abc.ndc.ido.example. CNAME abc.ndc.example. 577 2.3.3. Order Object Transmitted from NDC to IdO and to ACME Server 578 (non-STAR) 580 If the delegation is for a non-STAR certificate, the Order object 581 created by the NDC: 583 * MUST have the delegated name as the identifier value with a 584 "delegation" attribute indicating the configuration used for the 585 identifier. 587 POST /acme/new-order HTTP/1.1 588 Host: acme.ido.example 589 Content-Type: application/jose+json 591 { 592 "protected": base64url({ 593 "alg": "ES256", 594 "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg", 595 "nonce": "IYBkoQfaCS80UcCn9qH8Gt", 596 "url": "https://acme.ido.example/acme/new-order" 597 }), 598 "payload": base64url({ 599 "identifiers": [ 600 { 601 "type": "dns", 602 "value": "abc.ndc.ido.example.", 603 "delegation": 604 "https://acme.ido.example/acme/delegations/adFqoz/2" 605 } 606 ] 607 }), 608 "signature": "H6ZyWqg8aaKEkYca...dudoz4igiMvUBJ9j" 609 } 611 Figure 7: New Non-STAR Order from NDC 613 The Order object that is created on the IdO: 615 * MUST start in the "ready" state; 616 * MUST contain an "authorizations" array with zero elements; 617 * MUST contain the indicated "delegation" configurations. 619 { 620 "status": "ready", 621 "expires": "2019-05-01T00:00:00Z", 623 "identifiers": [ 624 { 625 "type": "dns", 626 "value": "abc.ndc.ido.example.", 627 "delegation": 628 "https://acme.ido.example/acme/delegations/adFqoz/2" 629 } 630 ], 632 "authorizations": [], 634 "finalize": "https://acme.ido.example/acme/order/to8RFGO/finalize" 635 } 637 Figure 8: Non-STAR Order Resource Created on IdO 639 The Order finalization by the NDC and the subsequent validation of 640 the CSR by the IdO proceed in the same way as for the STAR case. If 641 the CSR is successfully validated, the Order object status moves to 642 "processing" and the twin ACME protocol instance is initiated on the 643 IdO-CA side. 645 The Order object created by the IdO: 647 * MUST copy the identifiers sent by the NDC and strip the 648 "delegation" attribute; 649 * MUST include the "allow-certificate-get" attribute set to true. 651 When the validation of the identifiers has been successfully 652 completed and the certificate has been issued by the CA, the IdO: 654 * MUST move its Order resource status to "valid". 655 * MUST copy the "certificate" field from the Order, as well as 656 "notBefore" and "notAfter" if these fields exist. 658 { 659 "status": "valid", 660 "expires": "2019-05-01T00:00:00Z", 662 "identifiers": [ 663 { 664 "type": "dns", 665 "value": "abc.ndc.ido.example.", 666 "delegation": 667 "https://acme.ido.example/acme/delegations/adFqoz/2" 668 } 669 ], 671 "allow-certificate-get": true, 673 "authorizations": [], 675 "finalize": "https://acme.ido.example/acme/order/to8RFGO/finalize", 677 "certificate": "https://acme.ca.example/acme/order/YtR23SsdG9" 678 } 680 Figure 9: Non-STAR Order Resource Updated on IdO 682 At this point of the protocol flow, the same considerations as in 683 Section 2.3.2.1 apply. 685 2.3.4. Capability Discovery 687 In order to help a client to discover support for this profile, the 688 directory object of an ACME server MUST contain the following 689 attribute in the "meta" field: 691 * delegation-enabled: boolean flag indicating support for the 692 profile specified in this memo. An ACME server that supports this 693 delegation profile MUST include this key, and MUST set it to true. 695 The "delegation-enabled" flag may be specified regardless of the 696 existence or setting of the "auto-renewal" flag. 698 2.3.5. Terminating the Delegation 700 Identity delegation is terminated differently, depending on whether 701 this is a STAR certificate or not. 703 2.3.5.1. By Cancellation (STAR) 705 The IdO can terminate the delegation of a STAR certificate by 706 requesting its cancellation (see Section 3.1.2 of [RFC8739]). 708 Cancellation of the ACME STAR certificate is a prerogative of the 709 IdO. The NDC does not own the relevant account key on the ACME 710 server, therefore it can't issue a cancellation request for the STAR 711 certificate. Potentially, since it holds the STAR certificate's 712 private key, it could request the revocation of a single STAR 713 certificate. However, STAR explicitly disables the revokeCert 714 interface. 716 Shortly after the automatic renewal process is stopped by the IdO, 717 the last issued STAR certificate expires and the delegation 718 terminates. 720 2.3.5.2. By Revocation (non-STAR) 722 The IdO can terminate the delegation of a non-STAR certificate by 723 requesting it to be revoked using the revokeCert URL exposed by the 724 ACME server. 726 According to Section 7.6 of [RFC8555], the revocation endpoint can be 727 used with either the account keypair, or the certificate keypair. In 728 other words, an NDC that learns the revokeCert URL of the CA (which 729 is publicly available via the CA's Directory object) would be able to 730 revoke the certificate using the associated private key. However, 731 given the trust relationship between NDC and IdO expected by the 732 delegation trust model (Section 6.1), as well as the lack of 733 incentives for the NDC to prematurely terminate the delegation, this 734 does not represent a security risk. 736 2.4. Proxy Behavior 738 There are cases where the ACME Delegation flow should be proxied, 739 such as the use case described in Section 4.1.2. This section 740 describes the behavior of such proxies. 742 An entity implementing the IdO server role - an "ACME Delegation 743 server" - can decide, on a per-identity case, whether to act as a 744 proxy into another ACME Delegation server, or to behave as an IdO and 745 obtain a certificate directly. The determining factor is whether it 746 can successfully be authorized by the ACME server for the identity 747 associated with the certificate request. 749 The identities supported by each server and the disposition for each 750 of them are preconfigured. 752 Following is the proxy's behavior for each of the messages exchanged 753 in the ACME Delegation process: 755 * New-order request: 756 - The complete "identifiers" object MUST be copied as-is. 757 - Similarly, the "auto-renewal" object MUST be copied as-is. 758 * New-order response: 759 - The "status", "expires", "authorizations", "identifiers" and 760 "auto-renewal" attributes/objects MUST be copied as-is. 761 - The "finalize" URL is rewritten, so that the "finalize" request 762 will be made to the proxy. 763 - Similarly, the "Location" header MUST be rewritten to point to 764 an Order object on the proxy. 765 - And similarly, any "Link" relations. 766 * Get Order response: 767 - The "status", "expires", "authorizations", "identifiers" and 768 "auto-renewal" attributes/objects MUST be copied as-is. 769 - Similarly, the "star-certificate" URL (or the "certificate" URL 770 in case of non-STAR requests) MUST be copied as-is. 771 - The "finalize" URL is rewritten, so that the "finalize" request 772 will be made to the proxy. 773 - The "Location" header MUST be rewritten to point to an Order 774 object on the proxy. 775 - Any "Link" relations MUST be rewritten to point to the proxy. 776 * Finalize request: 777 - The CSR MUST be copied as-is. 778 * Finalize response: 779 - The "Location" header, "Link" relations and the "finalize" URLs 780 are rewritten as for Get Order. 782 We note that all the above messages are authenticated, and therefore 783 each proxy must be able to authenticate any subordinate server. 785 3. CSR Template 787 The CSR template is used to express and constrain the shape of the 788 CSR that the NDC uses to request the certificate. The CSR is used 789 for every certificate created under the same delegation. Its 790 validation by the IdO is a critical element in the security of the 791 whole delegation mechanism. 793 Instead of defining every possible CSR attribute, this document takes 794 a minimalist approach by declaring only the minimum attribute set and 795 deferring the registration of further, more specific, attributes to 796 future documents. 798 3.1. Template Syntax 800 The template is a JSON document. Each field (with the exception of 801 "keyTypes", see below) denotes one of: 803 * A mandatory field, where the template specifies the literal value 804 of that field. This is denoted by a literal string, such as 805 "client1.ndc.ido.example.com". 806 * A mandatory field, where the content of the field is defined by 807 the client. This is denoted by "**". 808 * An optional field, where the client decides whether the field is 809 included in the CSR and if so, what its value is. This is denoted 810 by "*". 812 The NDC MUST NOT include in the CSR any fields, including any 813 extensions, unless they are specified in the template. 815 The structure of the template object is defined by the CDDL [RFC8610] 816 document in Appendix B. 818 An alternative, non-normative JSON Schema syntax is given in 819 Appendix C. 821 The "subject" field and its subfields are mapped into the "subject" 822 field of the CSR, as per [RFC5280], Section 4.1.2.6. Other extension 823 fields of the CSR template are mapped into the CSR according to the 824 table in Section 5.6. 826 The "subjectAltName" field is currently defined for the following 827 identifiers: DNS names, email addresses, and URIs. New identifier 828 types may be added in the future by documents that extend this 829 specification. Each new identifier type SHALL have an associated 830 identifier validation challenge that the ACME CA can use to obtain 831 proof of the requester's control over it. 833 The "keyTypes" property is not copied into the CSR. Instead, this 834 property constrains the "SubjectPublicKeyInfo" field of the CSR, 835 which MUST have the type/size defined by one of the array members of 836 the "keyTypes" property. 838 When the IdO receives the CSR, it MUST verify that the CSR is 839 consistent with the template contained in the "delegation" object 840 referenced in the Order. The IdO MAY enforce additional constraints, 841 e.g. by restricting field lengths. In this regard, note that a 842 "subjectAltName" of type "DNS" can be specified using the wildcard 843 notation, meaning that the NDC can be required ("**") or offered the 844 possibility ("*") to define the delegated domain name by itself. If 845 this is the case, the IdO needs to have a further layer of checks on 846 top of the control rules already provided by the CSR template to 847 fully validate the CSR input. 849 3.2. Example 851 The CSR template in Figure 10 represents one possible CSR template 852 governing the delegation exchanges provided in the rest of this 853 document. 855 { 856 "keyTypes": [ 857 { 858 "PublicKeyType": "rsaEncryption", 859 "PublicKeyLength": 2048, 860 "SignatureType": "sha256WithRSAEncryption" 861 }, 862 { 863 "PublicKeyType": "id-ecPublicKey", 864 "namedCurve": "secp256r1", 865 "SignatureType": "ecdsa-with-SHA256" 866 } 867 ], 868 "subject": { 869 "country": "CA", 870 "stateOrProvince": "**", 871 "locality": "**", 872 "commonName": "**" 873 }, 874 "extensions": { 875 "subjectAltName": { 876 "DNS": [ 877 "client1.ndc.ido.example" 878 ] 879 }, 880 "keyUsage": [ 881 "digitalSignature" 882 ], 883 "extendedKeyUsage": [ 884 "serverAuth", 885 "clientAuth" 886 ] 887 } 888 } 890 Figure 10: Example CSR template 892 4. Further Use Cases 894 This non-normative section describes additional use cases that use 895 STAR certificate delegation in non-trivial ways. 897 4.1. CDN Interconnection (CDNI) 899 [I-D.ietf-cdni-interfaces-https-delegation] discusses several 900 solutions addressing different delegation requirements for the CDNI 901 (CDN Interconnection) environment. This section discusses two of the 902 stated requirements in the context of the STAR delegation workflow. 904 This section uses specifically CDNI terminology, e.g. "uCDN" and 905 "dCDN", as defined in [RFC7336]. 907 4.1.1. Multiple Parallel Delegates 909 In some cases the content owner (IdO) would like to delegate 910 authority over a web site to multiple NDCs (CDNs). This could happen 911 if the IdO has agreements in place with different regional CDNs for 912 different geographical regions, or if a "backup" CDN is used to 913 handle overflow traffic by temporarily altering some of the CNAME 914 mappings in place. The STAR delegation flow enables this use case 915 naturally, since each CDN can authenticate separately to the IdO (via 916 its own separate account) specifying its CSR, and the IdO is free to 917 allow or deny each certificate request according to its own policy. 919 4.1.2. Chained Delegation 921 In other cases, a content owner (IdO) delegates some domains to a 922 large CDN (uCDN), which in turn delegates to a smaller regional CDN, 923 dCDN. The IdO has a contractual relationship with uCDN, and uCDN has 924 a similar relationship with dCDN. However IdO may not even know 925 about dCDN. 927 If needed, the STAR protocol can be chained to support this use case: 928 uCDN could forward requests from dCDN to IdO, and forward responses 929 back to dCDN. Whether such proxying is allowed is governed by policy 930 and contracts between the parties. 932 A mechanism is necessary at the interface between uCDN and dCDN by 933 which the uCDN can advertise: 935 * The namespace that is made available to the dCDN to mint its 936 delegated names; 937 * The policy for creating the key material (allowed algorithms, 938 minimum key lengths, key usage, etc.) that the dCDN needs to 939 satisfy. 941 Note that such mechanism is provided by the CSR template. 943 4.1.2.1. Two-Level Delegation in CDNI 945 A User Agent (UA), browser or set-top-box, wants to fetch the video 946 resource at the following URI: "https://video.cp.example/movie". 947 Redirection between Content Provider (CP), upstream, and downstream 948 CDNs is arranged as a CNAME-based aliasing chain as illustrated in 949 Figure 11. 951 .------------. 952 video.cp.example ? | .-----. | 953 .---------------------------------->| | | 954 | (a) | | DNS | CP | 955 | .-------------------------------+ | | 956 | | CNAME video.ucdn.example | '-----' | 957 | | '------------' 958 | | 959 | | 960 .-----------|---v--. .------------. 961 | .-----.-+-----. | video.ucdn.example ? | .-----. | 962 | | | +----------------------------->| | | 963 | UA | TLS | DNS | | (b) | | DNS | uCDN | 964 | | | |<-----------------------------+ | | 965 | '--+--'-----+-' | CNAME video.dcdn.example | '-----' | 966 '------|----^---|--' '------------' 967 | | | 968 | | | 969 | | | .------------. 970 | | | video.dcdn.example ? | .-----. | 971 | | '------------------------------>| | | 972 | | (c) | | DNS | | 973 | '-----------------------------------+ | | 974 | A 192.0.2.1 | +-----+ dCDN | 975 | | | | | 976 '--------------------------------------->| TLS | | 977 SNI: video.cp.example | | | | 978 | '-----' | 979 '------------' 981 Figure 11: DNS Redirection 983 Unlike HTTP based redirection, where the original URL is supplanted 984 by the one found in the Location header of the 302 response, DNS 985 redirection is completely transparent to the User Agent. As a 986 result, the TLS connection to the dCDN edge is done with an SNI equal 987 to the "host" in the original URI - in the example, 988 "video.cp.example". So, in order to successfully complete the 989 handshake, the landing dCDN node has to be configured with a 990 certificate whose subjectAltName matches "video.cp.example", i.e., a 991 Content Provider's name. 993 Figure 12 illustrates the cascaded delegation flow that allows dCDN 994 to obtain a STAR certificate that bears a name belonging to the 995 Content Provider with a private key that is only known to the dCDN. 997 .--------------------. 998 | .------.------. | 999 | | STAR | ACME |<-------------. 1000 .------->| CP | dele | STAR | | | 1001 | | | srv | cli +-----. | 1002 | | '---+--'------' | | 6 1003 | '---------|------^---' 5 | 1004 | | | | .--|-------. 1005 | | | | | .-+----. | 1006 | 7 | '---->| ACME | | 1007 | | | | | STAR | C | 1008 0 | 4 | +------| A | 1009 | | | | | HTTP | | 1010 | | | | '----+-' | 1011 | | .-' '--^--|----' 1012 | .--------------v--|--. | | 1013 | | .------.----+-. | | 10 1014 | | | | STAR | | | | 1015 '-->| uCDN | CDNI | dele | | | | 1016 | | | fwd | | | | 1017 | '----+-'-+----' | | | 1018 '-------^--|---|--^--' | | 1019 | | | | | | 1020 | 2 8 | | | 1021 1 | | 3 | | 1022 | | | | 9 | 1023 .-------|--v---v--|---------. | | 1024 | .-+----.----+-.------. | | | 1025 | | | STAR | +------------' | 1026 | dCDN | CDNI | dele | HTTP | | | 1027 | | | cli | |<--------------' 1028 | '------'------'------' | 1029 '---------------------------' 1031 Figure 12: Two levels delegation in CDNI 1033 uCDN is configured to delegate to dCDN, and CP is configured to 1034 delegate to uCDN, both as defined in Section 2.3.1. 1036 1. dCDN requests CDNI path metadata to uCDN; 1037 2. uCDN replies with, among other CDNI metadata, the STAR 1038 delegation configuration, which includes the delegated Content 1039 Provider's name; 1040 3. dCDN creates a key-pair and the CSR with the delegated name. It 1041 then places an order for the delegated name to uCDN; 1042 4. uCDN forwards the received order to the Content Provider (CP); 1043 5. CP creates an order for a STAR certificate and sends it to the 1044 CA. The order also requests unauthenticated access to the 1045 certificate resource; 1046 6. After all authorizations complete successfully, the STAR 1047 certificate is issued; 1048 7. CP notifies uCDN that the STAR certificate is available at the 1049 order's star-certificate URL; 1050 8. uCDN forwards the information to dCDN. At this point the ACME 1051 signalling is complete; 1052 9. dCDN requests the STAR certificate using unauthenticated GET 1053 from the ACME server; 1054 10. the CA returns the certificate. Now dCDN is fully configured to 1055 handle HTTPS traffic in-lieu of the Content Provider. 1057 Note that 9. and 10. repeat until the delegation expires or is 1058 terminated. 1060 4.2. Secure Telephone Identity Revisited (STIR) 1062 As a second use case, we consider the delegation of credentials in 1063 the STIR ecosystem [I-D.ietf-stir-cert-delegation]. 1065 This section uses STIR terminology. The term PASSPorT is defined in 1066 [RFC8225], and "TNAuthList" in [RFC8226]. 1068 In the STIR "delegated" mode, a service provider SP2 - the NDC - 1069 needs to sign PASSPorT's [RFC8225] for telephone numbers (e.g., 1070 TN=+123) belonging to another service provider, SP1 - the IdO. In 1071 order to do that, SP2 needs a STIR certificate, and private key, that 1072 includes TN=+123 in the TNAuthList [RFC8226] certificate extension. 1074 In details (Figure 13): 1076 1. SP1 and SP2 agree on the configuration of the delegation - in 1077 particular, the CSR template that applies; 1078 2. SP2 generates a private/public key-pair and sends a CSR to SP1 1079 requesting creation of a certificate with: SP1 name, SP2 public 1080 key, and a TNAuthList extension with the list of TNs that SP1 1081 delegates to SP2. (Note that the CSR sent by SP2 to SP1 needs to 1082 be validated against the CSR template agreed upon in step 1.); 1083 3. SP1 sends an Order for the CSR to the CA; 1084 4. Subsequently, after the required TNAuthList authorizations are 1085 successfully completed, the CA moves the Order to a "valid" 1086 state; at the same time the star-certificate endpoint is 1087 populated. 1088 5. The Order contents are forwarded from SP1 to SP2 by means of the 1089 paired "delegation" Order. 1091 6. SP2 dereferences the star-certificate URL in the Order to fetch 1092 the rolling STAR certificate bearing the delegated identifiers. 1094 .-------------------. 1095 | .------.------. | 1096 | | STAR | STAR |<--------------. 1097 .-->| SP1 | dele | dele | | | 1098 | | | srv | cli +-----. | 1099 | | '----+-'------' | | 4 1100 | '------^--|---------' 3 | 1101 | | | | .----|-----. 1102 | | 5 | | .---+--. | 1103 | | | '--->| ACME | | 1104 | | | | | STAR | C | 1105 1 | | | +------| A | 1106 | | | .--->| HTTP | | 1107 | 2 | | | '---+--' | 1108 | | | | '----|-----' 1109 | .------|--v---------. 6 | 1110 | | .-+----.------. | | 7 1111 | | | STAR | +-----' | 1112 '-->| SP2 | dele | HTTP | | | 1113 | | cli | |<--------------' 1114 | '----+-'-+----' | 1115 '-------------------' 1117 Figure 13: Delegation in STIR 1119 As shown, the STAR delegation profile described in this document 1120 applies straightforwardly, the only extra requirement being the 1121 ability to instruct the NDC about the allowed TNAuthList values. 1122 This can be achieved by a simple extension to the CSR template. 1124 5. IANA Considerations 1126 [[RFC Editor: please replace XXXX below by the RFC number.]] 1128 5.1. New ACME Identifier Object Fields 1130 This document requests that IANA create the following new registry 1131 under the Automated Certificate Management Environment (ACME) 1132 Protocol: 1134 * ACME Identifier Object Fields 1136 This registry is administered under a Specification Required policy 1137 [RFC8126]. 1139 The "ACME Identifier Object Fields" registry lists field names that 1140 are defined for use in the ACME identifier object. 1142 Template: 1144 * Field name: The string to be used as a field name in the JSON 1145 object 1146 * Field type: The type of value to be provided, e.g., string, 1147 boolean, array of string 1148 * Reference: Where this field is defined 1150 +============+============+===========================+ 1151 | Field Name | Field Type | Reference | 1152 +============+============+===========================+ 1153 | type | string | Section 7.1.3 of RFC 8555 | 1154 +------------+------------+---------------------------+ 1155 | value | string | Section 7.1.3 of RFC 8555 | 1156 +------------+------------+---------------------------+ 1157 | delegation | string | RFC XXXX | 1158 +------------+------------+---------------------------+ 1160 Table 1 1162 Note: this registry was not created at the time [RFC8555] was 1163 standardized likely because it was not anticipated that the 1164 identifier object would be extended. It is retrospectively 1165 introduced to record the status quo and allow controlled 1166 extensibility of the identifier object. 1168 5.2. New Fields in the "meta" Object within a Directory Object 1170 This document adds the following entries to the ACME Directory 1171 Metadata Fields registry: 1173 +====================+============+===========+ 1174 | Field Name | Field Type | Reference | 1175 +====================+============+===========+ 1176 | delegation-enabled | boolean | RFC XXXX | 1177 +--------------------+------------+-----------+ 1179 Table 2 1181 5.3. New Fields in the Order Object 1183 This document adds the following entries to the ACME Order Object 1184 Fields registry: 1186 +=======================+============+==============+===========+ 1187 | Field Name | Field Type | Configurable | Reference | 1188 +=======================+============+==============+===========+ 1189 | allow-certificate-get | boolean | true | RFC XXXX | 1190 +-----------------------+------------+--------------+-----------+ 1192 Table 3 1194 5.4. New Fields in the Account Object 1196 This document adds the following entries to the ACME Account Object 1197 Fields registry: 1199 +=============+============+==========+===========+ 1200 | Field Name | Field Type | Requests | Reference | 1201 +=============+============+==========+===========+ 1202 | delegations | string | none | RFC XXXX | 1203 +-------------+------------+----------+-----------+ 1205 Table 4 1207 Note that the "delegations" field is only reported by ACME servers 1208 that have "delegation-enabled" set to true in their meta Object. 1210 5.5. New Error Types 1212 This document adds the following entries to the ACME Error Type 1213 registry: 1215 +===================+================================+===========+ 1216 | Type | Description | Reference | 1217 +===================+================================+===========+ 1218 | unknownDelegation | An unknown configuration is | RFC XXXX | 1219 | | listed in the "delegations" | | 1220 | | attribute of the request Order | | 1221 +-------------------+--------------------------------+-----------+ 1223 Table 5 1225 5.6. CSR Template Extensions 1227 IANA is requested to establish a registry "STAR Delegation CSR 1228 Template Extensions", with "Expert Review" as its registration 1229 procedure. 1231 Each extension registered must specify: 1233 * An extension name. 1235 * An extension syntax, as a reference to a JSON Schema document that 1236 defines this extension. 1237 * The extension's mapping into an X.509 certificate extension. 1239 The initial contents of this registry are the extensions defined by 1240 the CDDL in Appendix B. 1242 +==================+===========+===============================+ 1243 | Extension Name | Extension | Mapping to X.509 Certificate | 1244 | | Syntax | Extension | 1245 +==================+===========+===============================+ 1246 | keyUsage | See | [RFC5280], Section 4.2.1.3 | 1247 | | Appendix | | 1248 | | B | | 1249 +------------------+-----------+-------------------------------+ 1250 | extendedKeyUsage | See | [RFC5280], Section 4.2.1.12 | 1251 | | Appendix | | 1252 | | B | | 1253 +------------------+-----------+-------------------------------+ 1254 | subjectAltName | See | [RFC5280], Section 4.2.1.6 | 1255 | | Appendix | (note that only specific name | 1256 | | B | formats are allowed: URI, DNS | 1257 | | | name, email address) | 1258 +------------------+-----------+-------------------------------+ 1260 Table 6 1262 6. Security Considerations 1264 6.1. Trust Model 1266 The ACME trust model needs to be extended to include the trust 1267 relationship between NDC and IdO. Note that once this trust link is 1268 established, it potentially becomes recursive. Therefore, there has 1269 to be a trust relationship between each of the nodes in the 1270 delegation chain; for example, in case of cascading CDNs this is 1271 contractually defined. Note that using standard [RFC6125] identity 1272 verification there are no mechanisms available to the IdO to restrict 1273 the use of the delegated name once the name has been handed over to 1274 the first NDC. 1276 6.2. Delegation Security Goal 1278 Delegation introduces a new security goal: only an NDC that has been 1279 authorised by the IdO, either directly or transitively, can obtain a 1280 certificate with an IdO identity. 1282 From a security point of view, the delegation process has five 1283 separate parts: 1285 1. Enabling a specific third party (the intended NDC) to submit 1286 requests for delegated certificates; 1287 2. Making sure that any request for a delegated certificate matches 1288 the intended "shape" in terms of delegated identities as well as 1289 any other certificate metadata, e.g., key length, x.509 1290 extensions, etc.; 1291 3. Serving the certificate back to the NDC; 1292 4. A process for handling revocation of the delegation; 1293 5. A process for handling revocation of the certificate itself. 1295 The first part is covered by the NDC's ACME account that is 1296 administered by the IdO, whose security relies on the correct 1297 handling of the associated key pair. When a compromise of the 1298 private key is detected, the delegate MUST use the account 1299 deactivation procedures defined in Section 7.3.6 of [RFC8555]. 1301 The second part is covered by the act of checking an NDC's 1302 certificate request against the intended CSR template. The steps of 1303 shaping the CSR template correctly, selecting the right CSR template 1304 to check against the presented CSR, and making sure that the 1305 presented CSR matches the selected CSR template are all security 1306 relevant. 1308 The third part builds on the trust relationship between NDC and IdO 1309 that is responsible for correctly forwarding the certificate URL from 1310 the Order returned by the ACME server. 1312 The fourth part is associated with the ability of the IdO to 1313 unilaterally remove the delegation object associated with the revoked 1314 identity, therefore disabling any further NDC requests for such 1315 identity. Note that, in more extreme circumstances, the IdO might 1316 decide to disable the NDC account thus entirely blocking any further 1317 interaction. 1319 The fifth is covered by two different mechanisms, depending on the 1320 nature of the certificate. For STAR, the IdO shall use the 1321 cancellation interface defined in Section 2.3 of [RFC8739]. For non- 1322 STAR, the certificate revocation interface defined in Section 7.6 of 1323 [RFC8555]). 1325 6.3. New ACME Channels 1327 Using the model established in Section 10.1 of [RFC8555], we can 1328 decompose the interactions of the basic delegation workflow as shown 1329 in Figure 14. 1331 ACME Channel 1332 .------------>------------. 1333 .-----. ACME Channel .--+--. .--+----------. 1334 | NDC +------------->| IdO | | ACME server | 1335 '--+--' '--+--' '--+-+--------' 1336 | '-----------<-------------' | 1337 | Validation Channel | 1338 '-------------------->---------------------------' 1339 (subset of) ACME Channel [1] 1341 [1] Unauthenticated certificate fetch and non-STAR certificate 1342 revocation. 1344 Figure 14: Delegation Channels Topology 1346 The considerations regarding the security of the ACME Channel and 1347 Validation Channel discussed in [RFC8555] apply verbatim to the IdO/ 1348 ACME server leg. The same can be said for the ACME channel on the 1349 NDC/IdO leg. A slightly different set of considerations apply to the 1350 ACME Channel between NDC and ACME server, which consists of a subset 1351 of the ACME interface comprising two API endpoints: the 1352 unauthenticated certificate retrieval and, potentially, non-STAR 1353 revocation via certificate private key. No specific security 1354 considerations apply to the former, but the privacy considerations in 1355 Section 6.3 of [RFC8739] do. With regards to the latter, it should 1356 be noted that there is currently no means for an IdO to disable 1357 authorising revocation based on certificate private keys. So, in 1358 theory, an NDC could use the revocation API directly with the ACME 1359 server, therefore bypassing the IdO. The NDC SHOULD NOT directly use 1360 the revocation interface exposed by the ACME server unless failing to 1361 do so would compromise the overall security, for example if the 1362 certificate private key is compromised and the IdO is not currently 1363 reachable. 1365 All other security considerations from [RFC8555] and [RFC8739] apply 1366 as-is to the delegation topology. 1368 6.4. Restricting CDNs to the Delegation Mechanism 1370 When a web site is delegated to a CDN, the CDN can in principle 1371 modify the web site at will, create and remove pages. This means 1372 that a malicious or breached CDN can pass the ACME (as well as common 1373 non-ACME) HTTPS-based validation challenges and generate a 1374 certificate for the site. This is true regardless of whether the 1375 CNAME mechanisms defined in the current document is used or not. 1377 In some cases, this is the desired behavior: the domain owner trusts 1378 the CDN to have full control of the cryptographic credentials for the 1379 site. The current document however assumes that the domain owner 1380 only wants to delegate restricted control, and wishes to retain the 1381 capability to cancel the CDN's credentials at a short notice. 1383 The following is a possible mitigation when the IdO wishes to ensure 1384 that a rogue CDN cannot issue unauthorized certificates: 1386 * The domain owner makes sure that the CDN cannot modify the DNS 1387 records for the domain. The domain owner should ensure it is the 1388 only entity authorized to modify the DNS zone. Typically, it 1389 establishes a CNAME resource record from a subdomain into a CDN- 1390 managed domain. 1391 * The domain owner uses a CAA record [RFC8659] to restrict 1392 certificate issuance for the domain to specific CAs that comply 1393 with ACME and are known to implement [RFC8657]. 1394 * The domain owner uses the ACME-specific CAA mechanism [RFC8657] to 1395 restrict issuance to a specific account key which is controlled by 1396 it, and MUST require "dns-01" as the sole validation method. 1398 We note that the above solution may need to be tweaked depending on 1399 the exact capabilities and authorisation flows supported by the 1400 selected CAs. 1402 7. Acknowledgments 1404 We would like to thank the following people who contributed 1405 significantly to this document with their review comments and design 1406 proposals: Roman Danyliw, Frédéric Fieau, Russ Housley, Sanjay 1407 Mishra, Jon Peterson, Ryan Sleevi, Emile Stephan. 1409 This work is partially supported by the European Commission under 1410 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 1411 for a Middleboxed Internet (MAMI). This support does not imply 1412 endorsement. 1414 8. References 1416 8.1. Normative References 1418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1419 Requirement Levels", BCP 14, RFC 2119, 1420 DOI 10.17487/RFC2119, March 1997, 1421 . 1423 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1424 Request Syntax Specification Version 1.7", RFC 2986, 1425 DOI 10.17487/RFC2986, November 2000, 1426 . 1428 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1429 Housley, R., and W. Polk, "Internet X.509 Public Key 1430 Infrastructure Certificate and Certificate Revocation List 1431 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1432 . 1434 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1435 Writing an IANA Considerations Section in RFCs", BCP 26, 1436 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1437 . 1439 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1440 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1441 May 2017, . 1443 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1444 Kasten, "Automatic Certificate Management Environment 1445 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1446 . 1448 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1449 Definition Language (CDDL): A Notational Convention to 1450 Express Concise Binary Object Representation (CBOR) and 1451 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1452 June 2019, . 1454 [RFC8657] Landau, H., "Certification Authority Authorization (CAA) 1455 Record Extensions for Account URI and Automatic 1456 Certificate Management Environment (ACME) Method Binding", 1457 RFC 8657, DOI 10.17487/RFC8657, November 2019, 1458 . 1460 [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, 1461 "DNS Certification Authority Authorization (CAA) Resource 1462 Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, 1463 . 1465 [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor 1466 Perales, A., and T. Fossati, "Support for Short-Term, 1467 Automatically Renewed (STAR) Certificates in the Automated 1468 Certificate Management Environment (ACME)", RFC 8739, 1469 DOI 10.17487/RFC8739, March 2020, 1470 . 1472 8.2. Informative References 1474 [I-D.ietf-acme-authority-token-tnauthlist] 1475 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 1476 "TNAuthList profile of ACME Authority Token", Work in 1477 Progress, Internet-Draft, draft-ietf-acme-authority-token- 1478 tnauthlist-07, 22 February 2021, 1479 . 1482 [I-D.ietf-cdni-interfaces-https-delegation] 1483 Fieau, F., Stephan, E., and S. Mishra, "CDNI extensions 1484 for HTTPS delegation", Work in Progress, Internet-Draft, 1485 draft-ietf-cdni-interfaces-https-delegation-05, 12 March 1486 2021, . 1489 [I-D.ietf-stir-cert-delegation] 1490 Peterson, J., "STIR Certificate Delegation", Work in 1491 Progress, Internet-Draft, draft-ietf-stir-cert-delegation- 1492 04, 22 February 2021, . 1495 [I-D.ietf-tls-subcerts] 1496 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 1497 "Delegated Credentials for TLS", Work in Progress, 1498 Internet-Draft, draft-ietf-tls-subcerts-10, 24 January 1499 2021, . 1502 [I-D.mglt-lurk-tls13] 1503 Migault, D., "LURK Extension version 1 for (D)TLS 1.3 1504 Authentication", Work in Progress, Internet-Draft, draft- 1505 mglt-lurk-tls13-04, 25 January 2021, 1506 . 1509 [json-schema-07] 1510 Wright, A., Andrews, H., and G. Luff, "JSON Schema 1511 Validation: A Vocabulary for Structural Validation of 1512 JSON", 2018, . 1515 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1516 Verification of Domain-Based Application Service Identity 1517 within Internet Public Key Infrastructure Using X.509 1518 (PKIX) Certificates in the Context of Transport Layer 1519 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1520 2011, . 1522 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1523 "Framework for Content Distribution Network 1524 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1525 August 2014, . 1527 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1528 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1529 . 1531 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 1532 Credentials: Certificates", RFC 8226, 1533 DOI 10.17487/RFC8226, February 2018, 1534 . 1536 Appendix A. Document History 1538 [[Note to RFC Editor: please remove before publication.]] 1540 A.1. draft-ietf-acme-star-delegation-07 1542 * SecDir comments by Russ Housley. 1543 * In particular, reorganized some parts of the document to clarify 1544 handling of non-STAR certificates. 1545 * And changed the document's title accordingly. 1547 A.2. draft-ietf-acme-star-delegation-06 1549 * CDDL schema to address Roman's remaining comments. 1551 A.3. draft-ietf-acme-star-delegation-05 1553 * Detailed AD review by Roman Danyliw. 1554 * Some comments that were left unaddressed in Ryan Sleevi's review. 1555 * Numerous other edits for clarity and consistency. 1557 A.4. draft-ietf-acme-star-delegation-04 1559 * Delegation of non-STAR certificates. 1560 * More IANA clarity, specifically on certificate extensions. 1561 * Add delegation configuration object and extend account and order 1562 objects accordingly. 1564 * A lot more depth on Security Considerations. 1566 A.5. draft-ietf-acme-star-delegation-03 1568 * Consistency with the latest changes in the base ACME STAR 1569 document, e.g. star-delegation-enabled capability renamed and 1570 moved. 1571 * Proxy use cases (recursive delegation) and the definition of proxy 1572 behavior. 1573 * More detailed analysis of the CDNI and STIR use cases, including 1574 sequence diagrams. 1576 A.6. draft-ietf-acme-star-delegation-02 1578 * Security considerations: review by Ryan Sleevi. 1579 * CSR template simplified: instead of being a JSON Schema document 1580 itself, it is now a simple JSON document which validates to a JSON 1581 Schema. 1583 A.7. draft-ietf-acme-star-delegation-01 1585 * Refinement of the CDNI use case. 1586 * Addition of the CSR template (partial, more work required). 1587 * Further security considerations (work in progress). 1589 A.8. draft-ietf-acme-star-delegation-00 1591 * Republished as a working group draft. 1593 A.9. draft-sheffer-acme-star-delegation-01 1595 * Added security considerations about disallowing CDNs from issuing 1596 certificates for a delegated domain. 1598 A.10. draft-sheffer-acme-star-delegation-00 1600 * Initial version, some text extracted from draft-sheffer-acme-star- 1601 requests-02 1603 Appendix B. CSR Template: CDDL 1605 Following is the normative definition of the CSR template, using CDDL 1606 [RFC8610]. The CSR template MUST be a valid JSON document, compliant 1607 with the syntax defined here. 1609 An additional constraint that is not expressed in CDDL but MUST be 1610 validated by the recipient is that all objects (e.g. 1611 "distinguishedName") MUST NOT be empty when they are included, even 1612 when each separate property is optional. 1614 csr-template-schema = { 1615 keyTypes: [ 1* $keyType ] 1616 ? subject: distinguishedName 1617 extensions: extensions 1618 } 1620 mandatory-wildcard = "**" 1621 optional-wildcard = "*" 1622 wildcard = mandatory-wildcard / optional-wildcard 1624 ; regtext matches all text strings but "*" and "**" 1625 regtext = text .regexp "([^\*].*)|([\*][^\*].*)|([\*][\*].+)" 1627 regtext-or-wildcard = regtext / wildcard 1629 distinguishedName = { 1630 ? country: regtext-or-wildcard 1631 ? stateOrProvince: regtext-or-wildcard 1632 ? locality: regtext-or-wildcard 1633 ? organization: regtext-or-wildcard 1634 ? organizationalUnit: regtext-or-wildcard 1635 ? emailAddress: regtext-or-wildcard 1636 ? commonName: regtext-or-wildcard 1637 } 1639 $keyType /= rsaKeyType 1640 $keyType /= ecdsaKeyType 1642 rsaKeyType = { 1643 PublicKeyType: "rsaEncryption" ; OID: 1.2.840.113549.1.1.1 1644 PublicKeyLength: rsaKeySize 1645 SignatureType: $rsaSignatureType 1646 } 1648 rsaKeySize = int .ge 2048 1650 ; RSASSA-PKCS1-v1_5 with SHA-256 1651 $rsaSignatureType /= "sha256WithRSAEncryption" 1652 ; RSASSA-PCKS1-v1_5 with SHA-384 1653 $rsaSignatureType /= "sha384WithRSAEncryption" 1654 ; RSASSA-PCKS1-v1_5 with SHA-512 1655 $rsaSignatureType /= "sha512WithRSAEncryption" 1656 ; RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a 32 byte salt 1657 $rsaSignatureType /= "sha256WithRSAandMGF1" 1658 ; RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a 48 byte salt 1659 $rsaSignatureType /= "sha384WithRSAandMGF1" 1660 ; RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a 64 byte salt 1661 $rsaSignatureType /= "sha512WithRSAandMGF1" 1663 ecdsaKeyType = { 1664 PublicKeyType: "id-ecPublicKey" ; OID: 1.2.840.10045.2.1 1665 namedCurve: $ecdsaCurve 1666 SignatureType: $ecdsaSignatureType 1667 } 1669 $ecdsaCurve /= "secp256r1" ; OID: 1.2.840.10045.3.1.7 1670 $ecdsaCurve /= "secp384r1" ; OID: 1.3.132.0.34 1671 $ecdsaCurve /= "secp521r1" ; OID: 1.3.132.0.3 1673 $ecdsaSignatureType /= "ecdsa-with-SHA256" ; paired with secp256r1 1674 $ecdsaSignatureType /= "ecdsa-with-SHA384" ; paired with secp384r1 1675 $ecdsaSignatureType /= "ecdsa-with-SHA512" ; paired with secp521r1 1677 subjectaltname = { 1678 ? DNS: [ 1* regtext-or-wildcard ] 1679 ? Email: [ 1* regtext ] 1680 ? URI: [ 1* regtext ] 1681 * $$subjectaltname-extension 1682 } 1684 extensions = { 1685 ? keyUsage: [ 1* keyUsageType ] 1686 ? extendedKeyUsage: [ 1* extendedKeyUsageType ] 1687 subjectAltName: subjectaltname 1688 } 1690 keyUsageType /= "digitalSignature" 1691 keyUsageType /= "nonRepudiation" 1692 keyUsageType /= "keyEncipherment" 1693 keyUsageType /= "dataEncipherment" 1694 keyUsageType /= "keyAgreement" 1695 keyUsageType /= "keyCertSign" 1696 keyUsageType /= "cRLSign" 1697 keyUsageType /= "encipherOnly" 1698 keyUsageType /= "decipherOnly" 1700 extendedKeyUsageType /= "serverAuth" 1701 extendedKeyUsageType /= "clientAuth" 1702 extendedKeyUsageType /= "codeSigning" 1703 extendedKeyUsageType /= "emailProtection" 1704 extendedKeyUsageType /= "timeStamping" 1705 extendedKeyUsageType /= "OCSPSigning" 1706 extendedKeyUsageType /= oid 1708 oid = text .regexp "[0-9]+(\\.[0-9]+)*" 1710 Appendix C. CSR Template: JSON Schema 1712 This appendix includes an alternative, non-normative, JSON Schema 1713 definition of the CSR template. The syntax used is that of draft 7 1714 of JSON Schema, which is documented in [json-schema-07]. Note that 1715 later versions of this (now expired) draft describe later versions of 1716 the JSON Schema syntax. At the time of writing, a stable reference 1717 for this syntax is not yet available, and we have chosen to use the 1718 draft version which is currently best supported by tool 1719 implementations. 1721 While the CSR template must follow the syntax defined here, neither 1722 the IdO nor the NDC are expected to validate it at run-time. 1724 { 1725 "title": "JSON Schema for the STAR Delegation CSR template", 1726 "$schema": "http://json-schema.org/draft-07/schema#", 1727 "$id": "http://ietf.org/acme/drafts/star-delegation/csr-template", 1728 "$defs": { 1729 "distinguished-name": { 1730 "$id": "#distinguished-name", 1731 "type": "object", 1732 "minProperties": 1, 1733 "properties": { 1734 "country": { 1735 "type": "string" 1736 }, 1737 "stateOrProvince": { 1738 "type": "string" 1739 }, 1740 "locality": { 1741 "type": "string" 1742 }, 1743 "organization": { 1744 "type": "string" 1745 }, 1746 "organizationalUnit": { 1747 "type": "string" 1748 }, 1749 "emailAddress": { 1750 "type": "string" 1751 }, 1752 "commonName": { 1753 "type": "string" 1754 } 1755 }, 1756 "additionalProperties": false 1757 }, 1758 "rsaKeyType": { 1759 "$id": "#rsaKeyType", 1760 "type": "object", 1761 "properties": { 1762 "PublicKeyType": { 1763 "type": "string", 1764 "const": "rsaEncryption" 1765 }, 1766 "PublicKeyLength": { 1767 "type": "integer", 1768 "minimum": 2048, 1769 "multipleOf": 8 1770 }, 1771 "SignatureType": { 1772 "type": "string", 1773 "enum": [ 1774 "sha256WithRSAEncryption", 1775 "sha384WithRSAEncryption", 1776 "sha512WithRSAEncryption", 1777 "sha256WithRSAandMGF1", 1778 "sha384WithRSAandMGF1", 1779 "sha512WithRSAandMGF1" 1780 ] 1781 } 1782 }, 1783 "required": [ 1784 "PublicKeyType", 1785 "PublicKeyLength", 1786 "SignatureType" 1787 ], 1788 "additionalProperties": false 1789 }, 1790 "ecdsaKeyType": { 1791 "$id": "#ecdsaKeyType", 1792 "type": "object", 1793 "properties": { 1794 "PublicKeyType": { 1795 "type": "string", 1796 "const": "id-ecPublicKey" 1797 }, 1798 "namedCurve": { 1799 "type": "string", 1800 "enum": [ 1801 "secp256r1", 1802 "secp384r1", 1803 "secp521r1" 1804 ] 1805 }, 1806 "SignatureType": { 1807 "type": "string", 1808 "enum": [ 1809 "ecdsa-with-SHA256", 1810 "ecdsa-with-SHA384", 1811 "ecdsa-with-SHA512" 1812 ] 1813 } 1814 }, 1815 "required": [ 1816 "PublicKeyType", 1817 "namedCurve", 1818 "SignatureType" 1819 ], 1820 "additionalProperties": false 1821 } 1822 }, 1823 "type": "object", 1824 "properties": { 1825 "keyTypes": { 1826 "type": "array", 1827 "items": { 1828 "oneOf": [ 1829 { 1830 "$ref": "#rsaKeyType" 1831 }, 1832 { 1833 "$ref": "#ecdsaKeyType" 1834 } 1835 ] 1836 } 1837 }, 1838 "subject": { 1839 "$ref": "#distinguished-name" 1840 }, 1841 "extensions": { 1842 "type": "object", 1843 "properties": { 1844 "keyUsage": { 1845 "type": "array", 1846 "minItems": 1, 1847 "items": { 1848 "type": "string", 1849 "enum": [ 1850 "digitalSignature", 1851 "nonRepudiation", 1852 "keyEncipherment", 1853 "dataEncipherment", 1854 "keyAgreement", 1855 "keyCertSign", 1856 "cRLSign", 1857 "encipherOnly", 1858 "decipherOnly" 1859 ] 1860 } 1861 }, 1862 "extendedKeyUsage": { 1863 "type": "array", 1864 "minItems": 1, 1865 "items": { 1866 "oneOf": [ 1867 { 1868 "type": "string", 1869 "enum": [ 1870 "serverAuth", 1871 "clientAuth", 1872 "codeSigning", 1873 "emailProtection", 1874 "timeStamping", 1875 "OCSPSigning" 1876 ] 1877 }, 1878 { 1879 "type": "string", 1880 "pattern": "^[0-9]+(\\.[0-9]+)*$", 1881 "description": "Used for OID values" 1882 } 1883 ] 1884 } 1885 }, 1886 "subjectAltName": { 1887 "type": "object", 1888 "minProperties": 1, 1889 "properties": { 1890 "DNS": { 1891 "type": "array", 1892 "minItems": 1, 1893 "items": { 1894 "type": "string", 1895 "format": "hostname" 1896 } 1898 }, 1899 "Email": { 1900 "type": "array", 1901 "minItems": 1, 1902 "items": { 1903 "type": "string", 1904 "format": "email" 1905 } 1906 }, 1907 "URI": { 1908 "type": "array", 1909 "minItems": 1, 1910 "items": { 1911 "type": "string", 1912 "format": "uri" 1913 } 1914 } 1915 }, 1916 "additionalProperties": false 1917 } 1918 }, 1919 "required": [ 1920 "subjectAltName" 1921 ], 1922 "additionalProperties": false 1923 } 1924 }, 1925 "required": [ 1926 "extensions", 1927 "keyTypes" 1928 ], 1929 "additionalProperties": false 1930 } 1932 Authors' Addresses 1934 Yaron Sheffer 1935 Intuit 1937 Email: yaronf.ietf@gmail.com 1939 Diego López 1940 Telefonica I+D 1942 Email: diego.r.lopez@telefonica.com 1943 Antonio Agustín Pastor Perales 1944 Telefonica I+D 1946 Email: antonio.pastorperales@telefonica.com 1948 Thomas Fossati 1949 ARM 1951 Email: thomas.fossati@arm.com