diff options
Diffstat (limited to 'doc/rfc/rfc9115.txt')
| -rw-r--r-- | doc/rfc/rfc9115.txt | 2103 |
1 files changed, 2103 insertions, 0 deletions
diff --git a/doc/rfc/rfc9115.txt b/doc/rfc/rfc9115.txt new file mode 100644 index 0000000..48283e7 --- /dev/null +++ b/doc/rfc/rfc9115.txt @@ -0,0 +1,2103 @@ + + + + +Internet Engineering Task Force (IETF) Y. Sheffer +Request for Comments: 9115 Intuit +Category: Standards Track D. López +ISSN: 2070-1721 A. Pastor Perales + Telefonica I+D + T. Fossati + ARM + September 2021 + + + An Automatic Certificate Management Environment (ACME) Profile for + Generating Delegated Certificates + +Abstract + + This document defines a profile of the Automatic Certificate + Management Environment (ACME) protocol by which the holder of an + identifier (e.g., a domain name) can allow a third party to obtain an + X.509 certificate such that the certificate subject is the delegated + identifier while the certified public key corresponds to a private + key controlled by the third party. A primary use case is that of a + Content Delivery Network (CDN), the third party, terminating TLS + sessions on behalf of a content provider (the holder of a domain + name). The presented mechanism allows the holder of the identifier + to retain control over the delegation and revoke it at any time. + Importantly, this mechanism does not require any modification to the + deployed TLS clients and servers. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9115. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 1.1. Terminology + 1.2. Conventions Used in This Document + 2. Protocol Flow + 2.1. Preconditions + 2.2. Overview + 2.3. Delegated Identity Profile + 2.3.1. Delegation Configuration + 2.3.2. Order Object Transmitted from NDC to IdO and to ACME + Server (STAR) + 2.3.3. Order Object Transmitted from NDC to IdO and to ACME + Server (Non-STAR) + 2.3.4. Capability Discovery + 2.3.5. Negotiating an Unauthenticated GET + 2.3.6. Terminating the Delegation + 2.4. Proxy Behavior + 3. CA Behavior + 4. CSR Template + 4.1. Template Syntax + 4.2. Example + 5. Further Use Cases + 5.1. CDN Interconnection (CDNI) + 5.1.1. Multiple Parallel Delegates + 5.1.2. Chained Delegation + 5.2. Secure Telephone Identity Revisited (STIR) + 6. IANA Considerations + 6.1. New Fields in the "meta" Object within a Directory Object + 6.2. New Fields in the Order Object + 6.3. New Fields in the Account Object + 6.4. New Error Types + 6.5. CSR Template Extensions + 7. Security Considerations + 7.1. Trust Model + 7.2. Delegation Security Goal + 7.3. New ACME Channels + 7.4. Restricting CDNs to the Delegation Mechanism + 8. References + 8.1. Normative References + 8.2. Informative References + Appendix A. CSR Template: CDDL + Appendix B. CSR Template: JSON Schema + Acknowledgements + Authors' Addresses + +1. Introduction + + This document is related to [RFC8739], in that some important use + cases require both documents to be implemented. To avoid + duplication, we give here a bare-bones description of the motivation + for this solution. For more details, please refer to the + introductory sections of [RFC8739]. + + An Identifier Owner (IdO) has agreements in place with one or more + Name Delegation Consumer (NDC) to use and attest its identity. + + In the primary use case, the IdO is a content provider, and we + consider a Content Delivery Network (CDN) provider contracted to + serve the content over HTTPS. The CDN terminates the HTTPS + connection at one of its edge cache servers and needs to present its + clients (browsers, mobile apps, set-top boxes) a certificate whose + name matches the domain name of the URL that is requested, i.e., that + of the IdO. Understandably, some IdOs may balk at sharing their + long-term private keys with another organization; equally, delegates + would rather not have to handle other parties' long-term secrets. + Other relevant use cases are discussed in Section 5. + + This document describes a profile of the ACME protocol [RFC8555] that + allows the NDC to request from the IdO, acting as a profiled ACME + server, a certificate for a delegated identity -- i.e., one belonging + to the IdO. The IdO then uses the ACME protocol (with the extensions + described in [RFC8739]) to request issuance of a Short-Term, + Automatically Renewed (STAR) certificate for the same delegated + identity. The generated short-term certificate is automatically + renewed by the ACME Certification Authority (CA), is periodically + fetched by the NDC, and is used to terminate HTTPS connections in + lieu of the IdO. The IdO can end the delegation at any time by + simply instructing the CA to stop the automatic renewal and letting + the certificate expire shortly thereafter. + + While the primary use case we address is a delegation of STAR + certificates, the mechanism proposed here also accommodates long- + lived certificates managed with the ACME protocol. The most + noticeable difference between long-lived and STAR certificates is the + way the termination of the delegation is managed. In the case of + long-lived certificates, the IdO uses the "revokeCert" URL exposed by + the CA and waits for the explicit revocation based on the Certificate + Revocation List (CRL) and Online Certificate Status Protocol (OCSP) + to propagate to the relying parties. + + In case the delegated identity is a domain name, this document also + provides a way for the NDC to inform the IdO about the CNAME mappings + that need to be installed in the IdO's DNS zone to enable the + aliasing of the delegated name, thus allowing the complete name + delegation workflow to be handled using a single interface. + + We note that other standardization efforts address the problem of + certificate delegation for TLS connections, specifically + [TLS-SUBCERTS] and [MGLT-LURK-TLS13]. The former extends the TLS + certificate chain with a customer-owned signing certificate; the + latter separates the server's private key into a dedicated, more- + secure component. Compared to these other approaches, the current + document does not require changes to the TLS network stack of the + client or the server, nor does it introduce additional latency to the + TLS connection. + +1.1. Terminology + + IdO Identifier Owner, the holder (current owner) of an identifier + (e.g., a domain name) that needs to be delegated. Depending + on the context, the term IdO may also be used to designate + the (profiled) ACME server deployed by the Identifier Owner + or the ACME client used by the Identifier Owner to interact + with the CA. + + NDC Name Delegation Consumer, the entity to which the domain name + is delegated for a limited time. This is a CDN in the + primary use case (in fact, readers may note the similarity of + the two abbreviations). Depending on the context, the term + NDC may also be used to designate the (profiled) ACME client + used by the Name Delegation Consumer. + + CDN Content Delivery Network, a widely distributed network that + serves the domain's web content to a wide audience at high + performance. + + STAR Short-Term, Automatically Renewed, as applied to X.509 + certificates. + + ACME Automated Certificate Management Environment, a certificate + management protocol [RFC8555]. + + CA Certification Authority, specifically one that implements the + ACME protocol. In this document, the term is synonymous with + "ACME server deployed by the Certification Authority". + + CSR Certificate Signing Request, specifically a PKCS#10 [RFC2986] + Certificate Signing Request, as supported by ACME. + + FQDN Fully Qualified Domain Name. + +1.2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Protocol Flow + + This section presents the protocol flow. For completeness, we + include the ACME profile proposed in this document as well as the + ACME STAR protocol described in [RFC8739]. + +2.1. Preconditions + + The protocol assumes the following preconditions are met: + + * The IdO exposes an ACME server interface to the NDC(s) comprising + the account management interface. + + * The NDC has registered an ACME account with the IdO. + + * The NDC and IdO have agreed on a "CSR template" to use, including + at a minimum: subject name (e.g., "abc.ido.example"), requested + algorithms and key length, key usage, and extensions. The NDC + will use this template for every CSR created under the same + delegation. + + * The IdO has registered an ACME account with the Certification + Authority (CA). + + Note that even if the IdO implements the ACME server role, it is not + acting as a CA; in fact, from the point of view of the certificate + issuance process, the IdO only works as a "policing" forwarder of the + NDC's key pair and is responsible for completing the identity + verification process towards the CA. + +2.2. Overview + + For clarity, the protocol overview presented here covers the main use + case of this protocol, namely delegation of STAR certificates. + Protocol behavior for non-STAR certificates is similar, and the + detailed differences are listed in the following sections. + + The interaction between the NDC and the IdO is governed by the + profiled ACME workflow detailed in Section 2.3. The interaction + between the IdO and the CA is ruled by ACME [RFC8555], ACME STAR + [RFC8739], and any other ACME extension that applies (e.g., + [TOKEN-TNAUTHLIST] for Secure Telephone Identity Revisited (STIR)). + + The outline of the combined protocol for STAR certificates is as + follows (Figure 1): + + * NDC sends an Order1 for the delegated identifier to IdO. + + * IdO creates an Order1 resource in state "ready" with a "finalize" + URL. + + * NDC immediately sends a "finalize" request (which includes the + CSR) to the IdO. + + * IdO verifies the CSR according to the agreed upon CSR template. + + * If the CSR verification fails, Order1 is moved to an "invalid" + state and everything stops. + + * If the CSR verification is successful, IdO moves Order1 to state + "processing" and sends a new Order2 (using its own account) for + the delegated identifier to the CA. + + * If the ACME STAR protocol fails, Order2 moves to "invalid", and + the same state is reflected in Order1 (i.e., the NDC Order). + + * If the ACME STAR run is successful (i.e., Order2 is "valid"), IdO + copies the "star-certificate" URL from Order2 to Order1 and + updates the Order1 state to "valid". + + The NDC can now download, install, and use the short-term certificate + bearing the name delegated by the IdO. The STAR certificate can be + used until it expires, at which time the NDC is guaranteed to find a + new certificate it can download, install, and use. This continues + with subsequent certificates until either Order1 expires or the IdO + decides to cancel the automatic renewal process with the CA. + + Note that the interactive identifier authorization phase described in + Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because + the delegated identity contained in the CSR presented to the IdO is + validated against the configured CSR template (Section 4.1). + Therefore, the NDC sends the "finalize" request, including the CSR, + to the IdO immediately after Order1 has been acknowledged. The IdO + SHALL buffer a (valid) CSR until the Validation phase completes + successfully. + + Also note that the successful negotiation of the unauthenticated GET + (Section 3.4 of [RFC8739]) is required in order to allow the NDC to + access the "star-certificate" URL on the CA. + + .------. .---------------. .------. + | NDC | | IdO | | ACME | + +--------+ +--------+--------+ +--------+ + | Client | | Server | Client | | Server | + '---+----' '----+---+---+----' '----+---' + | | | | + | Order1 | | | + | Signature | | | + o------------------->| | | + | | | | + | [ No identity ] | | | + | [ validation via ] | | | + | [ authorizations ] | | | + | | | | + | CSR | | | + | Signature | | | + o------------------->| | | + | Acknowledgement | | Order2 | + |<-------------------o | Signature | + | | o------------------->| + | | | Required | + | | | Authorizations | + | | |<-------------------o + | | | Responses | + | | | Signature | + | | o------------------->| + | | | | + | | |<~~~~Validation~~~~>| + | | | | + | | | CSR | + | | | Signature | + | | o------------------->| + | | | Acknowledgement | + | | |<-------------------o + | | | | + |<~~Await issuance~->| |<~~Await issuance~~>| + | | + | (unauthenticated) GET STAR certificate | + o------------------------------------------------>| + | Certificate #1 | + |<------------------------------------------------o + | (unauthenticated) GET STAR certificate | + o------------------------------------------------>| + | Certificate #2 | + |<------------------------------------------------o + | [...] | + | (unauthenticated) GET STAR certificate | + o------------------------------------------------>| + | Certificate #n | + |<------------------------------------------------o + + Figure 1: End-to-End STAR Delegation Flow + +2.3. Delegated Identity Profile + + This section defines a profile of the ACME protocol to be used + between the NDC and IdO. + +2.3.1. Delegation Configuration + + The IdO must be preconfigured to recognize one or more NDCs and + present them with details about certificate delegations that apply to + each one. + +2.3.1.1. Account Object Extensions + + An NDC identifies itself to the IdO as an ACME account. The IdO can + delegate multiple names to an NDC, and these configurations are + described through "delegation" objects associated with the NDC's + account object on the IdO. + + As shown in Figure 2, the ACME account resource on the IdO is + extended with a new "delegations" attribute: + + delegations (required, string): A URL from which a list of + delegations configured for this account (Section 2.3.1.3) can be + fetched via a POST-as-GET request. + + { + "status": "valid", + "contact": [ + "mailto:delegation-admin@ido.example" + ], + "termsOfServiceAgreed": true, + "orders": "https://example.com/acme/orders/saHpfB", + "delegations": "https://acme.ido.example/acme/delegations/adFqoz" + } + + Figure 2: Example Account Object with Delegations + +2.3.1.2. Delegation Lists + + Each account object includes a "delegations" URL from which a list of + delegation configurations created by the IdO can be fetched via a + POST-as-GET request. The result of the request MUST be a JSON object + whose "delegations" field is an array of URLs, each identifying a + delegation configuration made available to the NDC account + (Section 2.3.1.3). The server MAY return an incomplete list, along + with a "Link" header field with a "next" link relation indicating + where further entries can be acquired. + + HTTP/1.1 200 OK + Content-Type: application/json + Link: <https://acme.ido.example/acme/directory>;rel="index" + Link: <https://acme.ido.example/acme/delegations/adFqoz?/ + cursor=2>;rel="next" + + { + "delegations": [ + "https://acme.ido.example/acme/delegation/ogfr8EcolOT", + "https://acme.ido.example/acme/delegation/wSi5Lbb61E4", + /* more URLs not shown for example brevity */ + "https://acme.ido.example/acme/delegation/gm0wfLYHBen" + ] + } + + Note that in the figure above, + https://acme.ido.example/acme/delegations/adFqoz?cursor=2 includes a + line break for the sake of presentation. + +2.3.1.3. Delegation Objects + + This profile extends the ACME resource model with a new read-only + "delegation" object that represents a delegation configuration that + applies to a given NDC. + + A "delegation" object contains the CSR template (see Section 4) that + applies to that delegation and, optionally, any related CNAME mapping + for the delegated identifiers. Its structure is as follows: + + csr-template (required, object): CSR template, as defined in + Section 4. + + cname-map (optional, object): A map of FQDN pairs. In each pair, + the name is the delegated identifier; the value is the + corresponding NDC name that is aliased in the IdO's zone file to + redirect the resolvers to the delegated entity. Both names and + values MUST be FQDNs with a terminating '.'. This field is only + meaningful for identifiers of type "dns". + + An example "delegation" object in JSON format is shown in Figure 3. + + { + "csr-template": { + "keyTypes": [ + { + "PublicKeyType": "id-ecPublicKey", + "namedCurve": "secp256r1", + "SignatureType": "ecdsa-with-SHA256" + } + ], + "subject": { + "country": "CA", + "stateOrProvince": "**", + "locality": "**" + }, + "extensions": { + "subjectAltName": { + "DNS": [ + "abc.ido.example" + ] + }, + "keyUsage": [ + "digitalSignature" + ], + "extendedKeyUsage": [ + "serverAuth" + ] + } + }, + "cname-map": { + "abc.ido.example.": "abc.ndc.example." + } + } + + Figure 3: Example Delegation Configuration Object + + In order to indicate which specific delegation applies to the + requested certificate, a new "delegation" attribute is added to the + order object on the NDC-IdO side (see Figures 4 and 7). The value of + this attribute is the URL pointing to the delegation configuration + object that is to be used for this certificate request. If the + "delegation" attribute in the order object contains a URL that does + not correspond to a configuration available to the requesting ACME + account, the IdO MUST return an error response with status code 403 + (Forbidden), providing a problem document [RFC7807] with type + "urn:ietf:params:acme:error:unknownDelegation". + +2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server + (STAR) + + If the delegation is for a STAR certificate, the request object + created by the NDC: + + * MUST have a "delegation" attribute indicating the preconfigured + delegation that applies to this Order; + + * MUST have entries in the "identifiers" field for each delegated + name present in the configuration; + + * MUST NOT contain the "notBefore" and "notAfter" fields; and + + * MUST contain an "auto-renewal" object and, inside it, the fields + listed in Section 3.1.1 of [RFC8739]. In particular, the "allow- + certificate-get" attribute MUST be present and set to true. + + POST /acme/new-order HTTP/1.1 + Host: acme.ido.example + Content-Type: application/jose+json + + { + "protected": base64url({ + "alg": "ES256", + "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg", + "nonce": "Alc00Ap6Rt7GMkEl3L1JX5", + "url": "https://acme.ido.example/acme/new-order" + }), + "payload": base64url({ + "identifiers": [ + { + "type": "dns", + "value": "abc.ido.example" + } + ], + "auto-renewal": { + "end-date": "2021-04-20T00:00:00Z", + "lifetime": 345600, // 4 days + "allow-certificate-get": true + }, + "delegation": + "https://acme.ido.example/acme/delegation/gm0wfLYHBen" + }), + "signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H" + } + + Figure 4: New STAR Order from NDC + + The order object that is created on the IdO: + + * MUST start in the "ready" state; + + * MUST contain an "authorizations" array with zero elements; + + * MUST contain the indicated "delegation" configuration; + + * MUST contain the indicated "auto-renewal" settings; and + + * MUST NOT contain the "notBefore" and "notAfter" fields. + + { + "status": "ready", + "expires": "2021-05-01T00:00:00Z", + + "identifiers": [ + { + "type": "dns", + "value": "abc.ido.example" + } + ], + + "auto-renewal": { + "end-date": "2021-04-20T00:00:00Z", + "lifetime": 345600, + "allow-certificate-get": true + }, + + "delegation": + "https://acme.ido.example/acme/delegation/gm0wfLYHBen", + + "authorizations": [], + + "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize" + } + + Figure 5: STAR Order Resource Created on IdO + + The Order is then finalized by the NDC supplying the CSR containing + the delegated identifiers. The IdO checks the provided CSR against + the template contained in the "delegation" object that applies to + this request, as described in Section 4.1. If the CSR fails + validation for any of the identifiers, the IdO MUST return an error + response with status code 403 (Forbidden) and an appropriate type, + e.g., "rejectedIdentifier" or "badCSR". The error response SHOULD + contain subproblems (Section 6.7.1 of [RFC8555]) for each failed + identifier. If the CSR is successfully validated, the order object + status moves to "processing" and the twin ACME protocol instance is + initiated on the IdO-CA side. + + The request object created by the IdO: + + * MUST copy the identifiers sent by the NDC; + + * MUST strip the "delegation" attribute; and + + * MUST carry a copy of the "auto-renewal" object sent by the NDC. + + When the identifiers' authorization has been successfully completed + and the certificate has been issued by the CA, the IdO: + + * MUST move its Order resource status to "valid" and + + * MUST copy the "star-certificate" field from the STAR Order + returned by the CA into its Order resource. When dereferenced, + the "star-certificate" URL includes (via the "Cert-Not-Before" and + "Cert-Not-After" HTTP header fields) the renewal timers needed by + the NDC to inform its certificate reload logic. + + { + "status": "valid", + "expires": "2021-05-01T00:00:00Z", + + "identifiers": [ + { + "type": "dns", + "value": "abc.ido.example" + } + ], + + "auto-renewal": { + "end-date": "2021-04-20T00:00:00Z", + "lifetime": 345600, + "allow-certificate-get": true + }, + + "delegation": + "https://acme.ido.example/acme/delegation/gm0wfLYHBen", + + "authorizations": [], + + "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize", + + "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" + } + + Figure 6: STAR Order Resource Updated on IdO + + This delegation protocol is predicated on the NDC being able to fetch + certificates periodically using an unauthenticated HTTP GET, since, + in general, the NDC does not possess an account on the CA; as a + consequence, it cannot issue the standard POST-as-GET ACME request. + Therefore, before forwarding the Order request to the CA, the IdO + SHOULD ensure that the selected CA supports unauthenticated GET by + inspecting the relevant settings in the CA's directory object, as per + Section 3.4 of [RFC8739]. If the CA does not support unauthenticated + GET of STAR certificates, the IdO MUST NOT forward the Order request. + Instead, it MUST move the Order status to "invalid" and set the + "allow-certificate-get" in the "auto-renewal" object to "false". The + same occurs in case the Order request is forwarded and the CA does + not reflect the "allow-certificate-get" setting in its Order + resource. The combination of "invalid" status and denied "allow- + certificate-get" in the Order resource at the IdO provides an + unambiguous (asynchronous) signal to the NDC about the failure + reason. + +2.3.2.1. CNAME Installation + + If one of the objects in the "identifiers" list is of type "dns", the + IdO can add the CNAME records specified in the "delegation" object to + its zone, for example: + + abc.ido.example. CNAME abc.ndc.example. + +2.3.3. Order Object Transmitted from NDC to IdO and to ACME Server + (Non-STAR) + + If the delegation is for a non-STAR certificate, the request object + created by the NDC: + + * MUST have a "delegation" attribute indicating the preconfigured + delegation that applies to this Order; + + * MUST have entries in the "identifiers" field for each delegated + name present in the configuration; and + + * MUST have the "allow-certificate-get" attribute set to true. + + POST /acme/new-order HTTP/1.1 + Host: acme.ido.example + Content-Type: application/jose+json + + { + "protected": base64url({ + "alg": "ES256", + "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg", + "nonce": "IYBkoQfaCS80UcCn9qH8Gt", + "url": "https://acme.ido.example/acme/new-order" + }), + "payload": base64url({ + "identifiers": [ + { + "type": "dns", + "value": "abc.ido.example" + } + ], + "delegation": + "https://acme.ido.example/acme/delegation/gm0wfLYHBen", + "allow-certificate-get": true + }), + "signature": "j9JBUvMigi4zodud...acYkEKaa8gqWyZ6H" + } + + Figure 7: New Non-STAR Order from NDC + + The order object that is created on the IdO: + + * MUST start in the "ready" state; + + * MUST contain an "authorizations" array with zero elements; + + * MUST contain the indicated "delegation" configuration; and + + * MUST contain the indicated "allow-certificate-get" setting. + + { + "status": "ready", + "expires": "2021-05-01T00:00:00Z", + + "identifiers": [ + { + "type": "dns", + "value": "abc.ido.example" + } + ], + + "delegation": + "https://acme.ido.example/acme/delegation/gm0wfLYHBen", + + "allow-certificate-get": true, + + "authorizations": [], + + "finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize" + } + + Figure 8: Non-STAR Order Resource Created on IdO + + The Order finalization by the NDC and the subsequent validation of + the CSR by the IdO proceed in the same way as for the STAR case. If + the CSR is successfully validated, the order object status moves to + "processing" and the twin ACME protocol instance is initiated on the + IdO-CA side. + + The request object created by the IdO: + + * MUST copy the identifiers sent by the NDC; + + * MUST strip the "delegation" attribute; and + + * MUST copy the "allow-certificate-get" attribute. + + When the identifiers' authorization has been successfully completed + and the certificate has been issued by the CA, the IdO: + + * MUST move its Order resource status to "valid" and + + * MUST copy the "certificate" field from the Order returned by the + CA into its Order resource, as well as "notBefore" and "notAfter" + if these fields exist. + + { + "status": "valid", + "expires": "2021-05-01T00:00:00Z", + + "identifiers": [ + { + "type": "dns", + "value": "abc.ido.example" + } + ], + + "delegation": + "https://acme.ido.example/acme/delegation/gm0wfLYHBen", + + "allow-certificate-get": true, + + "authorizations": [], + + "finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize", + + "certificate": "https://acme.ca.example/acme/order/YtR23SsdG9" + } + + Figure 9: Non-STAR Order Resource Updated on IdO + + At this point of the protocol flow, the same considerations as in + Section 2.3.2.1 apply. + + Before forwarding the Order request to the CA, the IdO SHOULD ensure + that the selected CA supports unauthenticated GET by inspecting the + relevant settings in the CA's directory object, as per Section 2.3.5. + If the CA does not support unauthenticated GET of certificate + resources, the IdO MUST NOT forward the Order request. Instead, it + MUST move the Order status to "invalid" and set the "allow- + certificate-get" attribute to "false". The same occurs in case the + Order request is forwarded and the CA does not reflect the "allow- + certificate-get" setting in its Order resource. The combination of + "invalid" status and denied "allow-certificate-get" in the Order + resource at the IdO provides an unambiguous (asynchronous) signal to + the NDC about the failure reason. + +2.3.4. Capability Discovery + + In order to help a client discover support for this profile, the + directory object of an ACME server (typically, one deployed by the + IdO) contains the following attribute in the "meta" field: + + delegation-enabled (optional, boolean): Boolean flag indicating + support for the profile specified in this memo. An ACME server + that supports this delegation profile MUST include this key and + MUST set it to true. + + The IdO MUST declare its support for delegation using "delegation- + enabled" regardless of whether it supports delegation of STAR + certificates, non-STAR certificates, or both. + + In order to help a client discover support for certificate fetching + using unauthenticated HTTP GET, the directory object of an ACME + server (typically, one deployed by the CA) contains the following + attribute in the "meta" field: + + allow-certificate-get (optional, boolean): See Section 2.3.5. + +2.3.5. Negotiating an Unauthenticated GET + + In order to enable the name delegation of non-STAR certificates, this + document defines a mechanism that allows a server to advertise + support for accessing certificate resources via unauthenticated GET + (in addition to POST-as-GET) and a client to enable this service with + per-Order granularity. + + It is worth pointing out that the protocol elements described in this + section have the same names and semantics as those introduced in + Section 3.4 of [RFC8739] for the STAR use case (except, of course, + they apply to the certificate resource rather than the star- + certificate resource). However, they differ in terms of their + position in the directory meta and order objects; rather than being + wrapped in an "auto-renewal" subobject, they are located at the top + level. + + A server states its availability to grant unauthenticated access to a + client's Order certificate by setting the "allow-certificate-get" + attribute to "true" in the "meta" field inside the directory object: + + allow-certificate-get (optional, boolean): If this field is present + and set to "true", the server allows GET (and HEAD) requests to + certificate URLs. + + A client states its desire to access the issued certificate via + unauthenticated GET by adding an "allow-certificate-get" attribute to + the payload of its newOrder request and setting it to "true". + + allow-certificate-get (optional, boolean): If this field is present + and set to "true", the client requests the server to allow + unauthenticated GET (and HEAD) to the certificate associated with + this Order. + + If the server accepts the request, it MUST reflect the attribute + setting in the resulting order object. + + Note that even when the use of unauthenticated GET has been agreed + upon, the server MUST also allow POST-as-GET requests to the + certificate resource. + +2.3.6. Terminating the Delegation + + Identity delegation is terminated differently depending on whether or + not this is a STAR certificate. + +2.3.6.1. By Cancellation (STAR) + + The IdO can terminate the delegation of a STAR certificate by + requesting its cancellation (see Section 3.1.2 of [RFC8739]). + + Cancellation of the ACME STAR certificate is a prerogative of the + IdO. The NDC does not own the relevant account key on the CA; + therefore, it can't issue a cancellation request for the STAR + certificate. Potentially, since it holds the STAR certificate's + private key, it could request the revocation of a single STAR + certificate. However, STAR explicitly disables the revokeCert + interface. + + Shortly after the automatic renewal process is stopped by the IdO, + the last issued STAR certificate expires and the delegation + terminates. + +2.3.6.2. By Revocation (Non-STAR) + + The IdO can terminate the delegation of a non-STAR certificate by + requesting it to be revoked using the "revokeCert" URL exposed by the + CA. + + According to Section 7.6 of [RFC8555], the revocation endpoint can be + used with either the account key pair or the certificate key pair. + In other words, an NDC that learns the "revokeCert" URL of the CA + (which is publicly available via the CA's directory object) would be + able to revoke the certificate using the associated private key. + However, given the trust relationship between the NDC and IdO + expected by the delegation trust model (Section 7.1), as well as the + lack of incentives for the NDC to prematurely terminate the + delegation, this does not represent a significant security risk. + +2.4. Proxy Behavior + + There are cases where the ACME Delegation flow should be proxied, + such as the use case described in Section 5.1.2. This section + describes the behavior of such proxies. + + An entity implementing the IdO server role -- an "ACME Delegation + server" -- may behave, on a per-identity case, either as a proxy into + another ACME Delegation server or as an IdO and obtain a certificate + directly. The determining factor is whether it can successfully be + authorized by the next-hop ACME server for the identity associated + with the certificate request. + + The identities supported by each server and the disposition for each + of them are preconfigured. + + Following is the proxy's behavior for each of the messages exchanged + in the ACME Delegation process: + + New-order request: + * The complete "identifiers" attribute MUST be copied as is. + * Similarly, the "auto-renewal" object MUST be copied as is. + New-order response: + * The "status", "expires", "authorizations", "identifiers", and + "auto-renewal" attributes/objects MUST be copied as is. + * The "finalize" URL is rewritten so that the "finalize" request + will be made to the proxy. + * Similarly, the "Location" header MUST be rewritten to point to + an order object on the proxy. + * Any "Link" relations MUST be rewritten to point to the proxy. + Get Order response: + * The "status", "expires", "authorizations", "identifiers", and + "auto-renewal" attributes/objects MUST be copied as is. + * Similarly, the "star-certificate" URL (or the "certificate" URL + in case of non-STAR requests) MUST be copied as is. + * The "finalize" URL is rewritten so that the "finalize" request + will be made to the proxy. + * The "Location" header MUST be rewritten to point to an order + object on the proxy. + * Any "Link" relations MUST be rewritten to point to the proxy. + "finalize" request: + * The CSR MUST be copied as is. + "finalize" response: + * The "Location" header, "Link" relations, and the "finalize" + URLs are rewritten as for Get Order. + + We note that all the above messages are authenticated; therefore, + each proxy must be able to authenticate any subordinate server. + +3. CA Behavior + + Although most of this document, and in particular Section 2, is + focused on the protocol between the NDC and IdO, the protocol does + affect the ACME server running in the CA. A CA that wishes to + support certificate delegation MUST also support unauthenticated + certificate fetching, which it declares using "allow-certificate-get" + (Section 2.3.5, Paragraph 3). + +4. CSR Template + + The CSR template is used to express and constrain the shape of the + CSR that the NDC uses to request the certificate. The CSR is used + for every certificate created under the same delegation. Its + validation by the IdO is a critical element in the security of the + whole delegation mechanism. + + Instead of defining every possible CSR attribute, this document takes + a minimalist approach by declaring only the minimum attribute set and + deferring the registration of further, more-specific attributes to + future documents. + +4.1. Template Syntax + + The template is a JSON document. Each field (with the exception of + "keyTypes", see below) denotes one of the following: + + * A mandatory field where the template specifies the literal value + of that field. This is denoted by a literal string, such as + "abc.ido.example". + + * A mandatory field where the content of the field is defined by the + client. This is denoted by "**". + + * An optional field where the client decides whether the field is + included in the CSR and, if so, what its value is. This is + denoted by "*". + + The NDC MUST NOT include any fields in the CSR, including any + extensions, unless they are specified in the template. + + The structure of the template object is defined by the Concise Data + Definition Language (CDDL) [RFC8610] document in Appendix A. An + alternative, nonnormative JSON Schema syntax is given in Appendix B. + While the CSR template must follow the syntax defined here, neither + the IdO nor the NDC are expected to validate it at runtime. + + The "subject" field and its subfields are mapped into the "subject" + field of the CSR, as per Section 4.1.2.6 of [RFC5280]. Other + extension fields of the CSR template are mapped into the CSR + according to the table in Section 6.5. + + The "subjectAltName" field is currently defined for the following + identifiers: DNS names, email addresses, and URIs. New identifier + types may be added in the future by documents that extend this + specification. Each new identifier type SHALL have an associated + identifier validation challenge that the CA can use to obtain proof + of the requester's control over it. + + The "keyTypes" property is not copied into the CSR. Instead, this + property constrains the "SubjectPublicKeyInfo" field of the CSR, + which MUST have the type/size defined by one of the array members of + the "keyTypes" property. + + When the IdO receives the CSR, it MUST verify that the CSR is + consistent with the template contained in the "delegation" object + referenced in the Order. The IdO MAY enforce additional constraints, + e.g., by restricting field lengths. In this regard, note that a + "subjectAltName" of type "DNS" can be specified using the wildcard + notation, meaning that the NDC can be required ("**") or offered the + possibility ("*") to define the delegated domain name by itself. If + this is the case, the IdO MUST apply application-specific checks on + top of the control rules already provided by the CSR template to + ensure the requested domain name is legitimate according to its local + policy. + +4.2. Example + + The CSR template in Figure 10 represents one possible CSR template + governing the delegation exchanges provided in the rest of this + document. + + { + "keyTypes": [ + { + "PublicKeyType": "rsaEncryption", + "PublicKeyLength": 2048, + "SignatureType": "sha256WithRSAEncryption" + }, + { + "PublicKeyType": "id-ecPublicKey", + "namedCurve": "secp256r1", + "SignatureType": "ecdsa-with-SHA256" + } + ], + "subject": { + "country": "CA", + "stateOrProvince": "**", + "locality": "**" + }, + "extensions": { + "subjectAltName": { + "DNS": [ + "abc.ido.example" + ] + }, + "keyUsage": [ + "digitalSignature" + ], + "extendedKeyUsage": [ + "serverAuth", + "clientAuth" + ] + } + } + + Figure 10: Example CSR Template + +5. Further Use Cases + + This nonnormative section describes additional use cases implementing + the STAR certificate delegation in nontrivial ways. + +5.1. CDN Interconnection (CDNI) + + [HTTPS-DELEGATION] discusses several solutions addressing different + delegation requirements for the CDN Interconnection (CDNI) + environment. This section discusses two of the stated requirements + in the context of the STAR delegation workflow. + + This section uses specific CDNI terminology, e.g., Upstream CDN + (uCDN) and Downstream (dCDN), as defined in [RFC7336]. + +5.1.1. Multiple Parallel Delegates + + In some cases, the content owner (IdO) would like to delegate + authority over a website to multiple NDCs (CDNs). This could happen + if the IdO has agreements in place with different regional CDNs for + different geographical regions or if a "backup" CDN is used to handle + overflow traffic by temporarily altering some of the CNAME mappings + in place. The STAR delegation flow enables this use case naturally, + since each CDN can authenticate separately to the IdO (via its own + separate account) specifying its CSR, and the IdO is free to allow or + deny each certificate request according to its own policy. + +5.1.2. Chained Delegation + + In other cases, a content owner (IdO) delegates some domains to a + large CDN (uCDN), which in turn delegates to a smaller regional CDN + (dCDN). The IdO has a contractual relationship with uCDN, and uCDN + has a similar relationship with dCDN. However, IdO may not even know + about dCDN. + + If needed, the STAR protocol can be chained to support this use case: + uCDN could forward requests from dCDN to IdO and forward responses + back to dCDN. Whether such proxying is allowed is governed by policy + and contracts between the parties. + + A mechanism is necessary at the interface between uCDN and dCDN, by + which the uCDN can advertise: + + * the names that the dCDN is allowed to use and + + * the policy for creating the key material (allowed algorithms, + minimum key lengths, key usage, etc.) that the dCDN needs to + satisfy. + + Note that such mechanism is provided by the CSR template. + +5.1.2.1. Two-Level Delegation in CDNI + + A User Agent (UA), e.g., a browser or set-top box, wants to fetch the + video resource at the following URI: "https://video.cp.example/ + movie". Redirection between the content provider (CP) and upstream + and downstream CDNs is arranged as a CNAME-based aliasing chain, as + illustrated in Figure 11. + + .------------. + video.cp.example ? | .-----. | + .---------------------------------->| | | + | (a) | | DNS | CP | + | .-------------------------------+ | | + | | CNAME video.ucdn.example | '-----' | + | | '------------' + | | + | | + .-----------|---v--. .------------. + | .-----.-+-----. | video.ucdn.example ? | .-----. | + | | | +----------------------------->| | | + | UA | TLS | DNS | | (b) | | DNS | uCDN | + | | | |<-----------------------------+ | | + | '--+--'-----+-' | CNAME video.dcdn.example | '-----' | + '------|----^---|--' '------------' + | | | + | | | + | | | .------------. + | | | video.dcdn.example ? | .-----. | + | | '------------------------------>| | | + | | (c) | | DNS | | + | '-----------------------------------+ | | + | A 192.0.2.1 | +-----+ dCDN | + | | | | | + '--------------------------------------->| TLS | | + SNI: video.cp.example | | | | + | '-----' | + '------------' + + Figure 11: DNS Redirection + + Unlike HTTP-based redirection, where the original URL is supplanted + by the one found in the "Location" header of the 302 response, DNS + redirection is completely transparent to the User Agent. As a + result, the TLS connection to the dCDN edge is done with a Server + Name Indication (SNI) equal to the "host" in the original URI -- in + the example, "video.cp.example". So, in order to successfully + complete the handshake, the landing dCDN node has to be configured + with a certificate whose "subjectAltName" field matches + "video.cp.example", i.e., a content provider's name. + + Figure 12 illustrates the cascaded delegation flow that allows dCDN + to obtain a STAR certificate that bears a name belonging to the + content provider with a private key that is only known to the dCDN. + + .--------------------. + | .------.------. | + | | STAR | ACME |<-------------. + | CP | dele | STAR | | | + | | srv | cli +-----. | + | '---+--'------' | | 6 + '---------|------^---' 5 | + | | | .--|-------. + | | | | .-+----. | + 7 | '---->| ACME | | + | | | | STAR | C | + | 4 | +------| A | + | | | | HTTP | | + | | | '----+-' | + | .-' '--^--|----' + .--------------v--|--. | | + | .------.----+-. | | 10 + | | | STAR | | | | + | uCDN | CDNI | dele | | | | + | | | fwd | | | | + | '----+-'-+----' | | | + '-------^--|---|--^--' | | + | | | | | | + | 2 8 | | | + 1 | | 3 | | + | | | | 9 | + .-------|--v---v--|---------. | | + | .-+----.----+-.------. | | | + | | | STAR | +------------' | + | dCDN | CDNI | dele | HTTP | | | + | | | cli | |<--------------' + | '------'------'------' | + '---------------------------' + + Figure 12: Two-Level Delegation in CDNI + + uCDN is configured to delegate to dCDN, and CP is configured to + delegate to uCDN, both as defined in Section 2.3.1. + + 1. dCDN requests CDNI path metadata to uCDN. + + 2. uCDN replies with, among other CDNI metadata, the STAR + delegation configuration, which includes the delegated content + provider's name. + + 3. dCDN creates a key pair and the CSR with the delegated name. It + then places an order for the delegated name to uCDN. + + 4. uCDN forwards the received order to the content provider (CP). + + 5. CP creates an order for a STAR certificate and sends it to the + CA. The order also requests unauthenticated access to the + certificate resource. + + 6. After all authorizations complete successfully, the STAR + certificate is issued. + + 7. CP notifies uCDN that the STAR certificate is available at the + order's "star-certificate" URL. + + 8. uCDN forwards the information to dCDN. At this point, the ACME + signaling is complete. + + 9. dCDN requests the STAR certificate using unauthenticated GET + from the CA. + + 10. The CA returns the certificate. Now dCDN is fully configured to + handle HTTPS traffic in lieu of the content provider. + + Note that 9 and 10 repeat until the delegation expires or is + terminated. + +5.2. Secure Telephone Identity Revisited (STIR) + + As a second use case, we consider the delegation of credentials in + the STIR ecosystem [RFC9060]. + + This section uses STIR terminology. The term Personal Assertion + Token (PASSporT) is defined in [RFC8225], and "TNAuthList" is defined + in [RFC8226]. + + In the STIR delegated mode, a service provider SP2 -- the NDC -- + needs to sign PASSporTs [RFC8225] for telephone numbers (e.g., + TN=+123) belonging to another service provider, SP1 -- the IdO. In + order to do that, SP2 needs a STIR certificate and a private key that + includes TN=+123 in the TNAuthList [RFC8226] certificate extension. + + In detail (Figure 13): + + 1. SP1 and SP2 agree on the configuration of the delegation -- in + particular, the CSR template that applies. + + 2. SP2 generates a private/public key pair and sends a CSR to SP1, + requesting creation of a certificate with an SP1 name, an SP2 + public key, and a TNAuthList extension with the list of TNs that + SP1 delegates to SP2. (Note that the CSR sent by SP2 to SP1 + needs to be validated against the CSR template agreed upon in + step 1.). + + 3. SP1 sends an order for the CSR to the CA. The order also + requests unauthenticated access to the certificate resource. + + 4. Subsequently, after the required TNAuthList authorizations are + successfully completed, the CA moves the order to a "valid" + state; at the same time, the star-certificate endpoint is + populated. + + 5. The contents of the order are forwarded from SP1 to SP2 by means + of the paired "delegation" order. + + 6. SP2 dereferences the "star-certificate" URL in the order to fetch + the rolling STAR certificate bearing the delegated identifiers. + + 7. The STAR certificate is returned to SP2. + + .-------------------. + | .------.------. | + | | STAR | STAR |<--------------. + .-->| SP1 | dele | dele | | | + | | | srv | cli +-----. | + | | '----+-'------' | | 4 + | '------^--|---------' 3 | + | | | | .----|-----. + | | 5 | | .---+--. | + | | | '--->| ACME | | + | | | | | STAR | C | + 1 | | | +------| A | + | | | .--->| HTTP | | + | 2 | | | '---+--' | + | | | | '----|-----' + | .------|--v---------. 6 | + | | .-+----.------. | | 7 + | | | STAR | +-----' | + '-->| SP2 | dele | HTTP | | | + | | cli | |<--------------' + | '----+-'-+----' | + '-------------------' + + Figure 13: Delegation in STIR + + As shown, the STAR delegation profile described in this document + applies straightforwardly; the only extra requirement being the + ability to instruct the NDC about the allowed TNAuthList values. + This can be achieved by a simple extension to the CSR template. + +6. IANA Considerations + +6.1. New Fields in the "meta" Object within a Directory Object + + This document adds the following entries to the "ACME Directory + Metadata Fields" registry: + + +=======================+============+===========+ + | Field Name | Field Type | Reference | + +=======================+============+===========+ + | delegation-enabled | boolean | RFC 9115 | + +-----------------------+------------+-----------+ + | allow-certificate-get | boolean | RFC 9115 | + +-----------------------+------------+-----------+ + + Table 1 + +6.2. New Fields in the Order Object + + This document adds the following entries to the "ACME Order Object + Fields" registry: + + +=======================+============+==============+===========+ + | Field Name | Field Type | Configurable | Reference | + +=======================+============+==============+===========+ + | allow-certificate-get | boolean | true | RFC 9115 | + +-----------------------+------------+--------------+-----------+ + | delegation | string | true | RFC 9115 | + +-----------------------+------------+--------------+-----------+ + + Table 2 + +6.3. New Fields in the Account Object + + This document adds the following entries to the "ACME Account Object + Fields" registry: + + +=============+============+==========+===========+ + | Field Name | Field Type | Requests | Reference | + +=============+============+==========+===========+ + | delegations | string | none | RFC 9115 | + +-------------+------------+----------+-----------+ + + Table 3 + + Note that the "delegations" field is only reported by ACME servers + that have "delegation-enabled" set to true in their meta Object. + +6.4. New Error Types + + This document adds the following entries to the "ACME Error Types" + registry: + + +===================+================================+===========+ + | Type | Description | Reference | + +===================+================================+===========+ + | unknownDelegation | An unknown configuration is | RFC 9115 | + | | listed in the "delegation" | | + | | attribute of the order request | | + +-------------------+--------------------------------+-----------+ + + Table 4 + +6.5. CSR Template Extensions + + IANA has established the "STAR Delegation CSR Template Extensions" + registry, with "Specification Required" as its registration + procedure. + + Each extension registered must specify: + + * an extension name, + + * an extension syntax, as a reference to a CDDL document that + defines this extension, and + + * the extension's mapping into an X.509 certificate extension. + + The initial contents of this registry are the extensions defined by + the CDDL in Appendix A. + + +==================+===========+===============================+ + | Extension Name | Extension | Mapping to X.509 Certificate | + | | Syntax | Extension | + +==================+===========+===============================+ + | keyUsage | See | [RFC5280], Section 4.2.1.3 | + | | Appendix | | + | | A | | + +------------------+-----------+-------------------------------+ + | extendedKeyUsage | See | [RFC5280], Section 4.2.1.12 | + | | Appendix | | + | | A | | + +------------------+-----------+-------------------------------+ + | subjectAltName | See | [RFC5280], Section 4.2.1.6 | + | | Appendix | (note that only specific name | + | | A | formats are allowed: URI, DNS | + | | | name, email address) | + +------------------+-----------+-------------------------------+ + + Table 5 + + When evaluating a request for an assignment in this registry, the + designated expert should follow this guidance: + + * The definition must include a full CDDL definition, which the + expert will validate. + + * The definition must include both positive and negative test cases. + + * Additional requirements that are not captured by the CDDL + definition are allowed but must be explicitly specified. + +7. Security Considerations + +7.1. Trust Model + + The ACME trust model needs to be extended to include the trust + relationship between NDC and IdO. Note that once this trust link is + established, it potentially becomes recursive. Therefore, there has + to be a trust relationship between each of the nodes in the + delegation chain; for example, in case of cascading CDNs, this is + contractually defined. Note that when using standard [RFC6125] + identity verification, there are no mechanisms available to the IdO + to restrict the use of the delegated name once the name has been + handed over to the first NDC. It is, therefore, expected that + contractual measures are in place to get some assurance that + redelegation is not being performed. + +7.2. Delegation Security Goal + + Delegation introduces a new security goal: only an NDC that has been + authorized by the IdO, either directly or transitively, can obtain a + certificate with an IdO identity. + + From a security point of view, the delegation process has five + separate parts: + + 1. enabling a specific third party (the intended NDC) to submit + requests for delegated certificates + + 2. making sure that any request for a delegated certificate matches + the intended "shape" in terms of delegated identities as well as + any other certificate metadata, e.g., key length, x.509 + extensions, etc. + + 3. serving the certificate back to the NDC + + 4. handling revocation of the delegation + + 5. handling revocation of the certificate itself + + The first part is covered by the NDC's ACME account that is + administered by the IdO, whose security relies on the correct + handling of the associated key pair. When a compromise of the + private key is detected, the delegate MUST use the account + deactivation procedures defined in Section 7.3.6 of [RFC8555]. + + The second part is covered by the act of checking an NDC's + certificate request against the intended CSR template. The steps of + shaping the CSR template correctly, selecting the right CSR template + to check against the presented CSR, and making sure that the + presented CSR matches the selected CSR template are all security + relevant. + + The third part builds on the trust relationship between NDC and IdO + that is responsible for correctly forwarding the certificate URL from + the Order returned by the CA. + + The fourth part is associated with the ability of the IdO to + unilaterally remove the "delegation" object associated with the + revoked identity, therefore, disabling any further NDC requests for + such identity. Note that, in more extreme circumstances, the IdO + might decide to disable the NDC account, thus entirely blocking any + further interaction. + + The fifth is covered by two different mechanisms, depending on the + nature of the certificate. For STAR, the IdO shall use the + cancellation interface defined in Section 2.3 of [RFC8739]. For non- + STAR, the certificate revocation interface defined in Section 7.6 of + [RFC8555]) is used. + + The ACME account associated with the delegation plays a crucial role + in the overall security of the presented protocol. This, in turn, + means that (in delegation scenarios) the security requirements and + verification associated with an ACME account may be more stringent + than in base ACME deployments, since the out-of-band configuration of + delegations that an account is authorized to use (combined with + account authentication) takes the place of the normal ACME + authorization challenge procedures. Therefore, the IdO MUST ensure + that each account is associated with the exact policies (via their + matching "delegation" objects) that define which domain names can be + delegated to the account and how. The IdO is expected to use out-of- + band means to preregister each NDC to the corresponding account. + +7.3. New ACME Channels + + Using the model established in Section 10.1 of [RFC8555], we can + decompose the interactions of the basic delegation workflow, as shown + in Figure 14. + + .-----. ACME Channel .--------. + | NDC +------------->| IdO | + '--+--' | server | + | '--o-----' + | | + | | ACME Channel + | | .------------>-------------. + | | | | + | .--o--+--. .--+---. + | | IdO | | CA | + | | client | '--+-+-' + | '-----+--' | | + | '-----------<--------------' | + | Validation Channel | + '-------------------->-------------------------------' + (subset of) ACME Channel [1] + + [1] Unauthenticated certificate fetch and non-STAR certificate + revocation. + + Figure 14: Delegation Channels Topology + + The considerations regarding the security of the ACME Channel and + Validation Channel discussed in [RFC8555] apply verbatim to the IdO- + CA leg. The same can be said for the ACME Channel on the NDC-IdO + leg. A slightly different set of considerations apply to the ACME + Channel between the NDC and CA, which consists of a subset of the + ACME interface comprising two API endpoints: the unauthenticated + certificate retrieval and, potentially, non-STAR revocation via + certificate private key. No specific security considerations apply + to the former, but the privacy considerations in Section 6.3 of + [RFC8739] do. With regard to the latter, it should be noted that + there is currently no means for an IdO to disable authorizing + revocation based on certificate private keys. So, in theory, an NDC + could use the revocation API directly with the CA, therefore, + bypassing the IdO. The NDC SHOULD NOT directly use the revocation + interface exposed by the CA unless failing to do so would compromise + the overall security, for example, if the certificate private key is + compromised and the IdO is not currently reachable. + + All other security considerations from [RFC8555] and [RFC8739] apply + as is to the delegation topology. + +7.4. Restricting CDNs to the Delegation Mechanism + + When a website is delegated to a CDN, the CDN can in principle modify + the website at will, e.g., create and remove pages. This means that + a malicious or breached CDN can pass the ACME (as well as common non- + ACME) HTTPS-based validation challenges and generate a certificate + for the site. This is true regardless of whether or not the CNAME + mechanisms defined in the current document is used. + + In some cases, this is the desired behavior; the domain holder trusts + the CDN to have full control of the cryptographic credentials for the + site. However, this document assumes a scenario where the domain + holder only wants to delegate restricted control and wishes to retain + the capability to cancel the CDN's credentials at a short notice. + + The following is a possible mitigation when the IdO wishes to ensure + that a rogue CDN cannot issue unauthorized certificates: + + * The domain holder makes sure that the CDN cannot modify the DNS + records for the domain. The domain holder should ensure it is the + only entity authorized to modify the DNS zone. Typically, it + establishes a CNAME resource record from a subdomain into a CDN- + managed domain. + + * The domain holder uses a Certification Authority Authorization + (CAA) record [RFC8659] to restrict certificate issuance for the + domain to specific CAs that comply with ACME and are known to + implement [RFC8657]. + + * The domain holder uses the ACME-specific CAA mechanism [RFC8657] + to restrict issuance to a specific CA account that is controlled + by it and MUST require "dns-01" as the sole validation method. + + We note that the above solution may need to be tweaked depending on + the exact capabilities and authorization flows supported by the + selected CA. In addition, this mitigation may be bypassed if a + malicious or misconfigured CA does not comply with CAA restrictions. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification + Request Syntax Specification Version 1.7", RFC 2986, + DOI 10.17487/RFC2986, November 2000, + <https://www.rfc-editor.org/info/rfc2986>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <https://www.rfc-editor.org/info/rfc5280>. + + [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP + APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, + <https://www.rfc-editor.org/info/rfc7807>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. + Kasten, "Automatic Certificate Management Environment + (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, + <https://www.rfc-editor.org/info/rfc8555>. + + [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data + Definition Language (CDDL): A Notational Convention to + Express Concise Binary Object Representation (CBOR) and + JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, + June 2019, <https://www.rfc-editor.org/info/rfc8610>. + + [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor + Perales, A., and T. Fossati, "Support for Short-Term, + Automatically Renewed (STAR) Certificates in the Automated + Certificate Management Environment (ACME)", RFC 8739, + DOI 10.17487/RFC8739, March 2020, + <https://www.rfc-editor.org/info/rfc8739>. + +8.2. Informative References + + [HTTPS-DELEGATION] + Fieau, F., Stephan, E., and S. Mishra, "CDNI extensions + for HTTPS delegation", Work in Progress, Internet-Draft, + draft-ietf-cdni-interfaces-https-delegation-06, 10 + September 2021, <https://datatracker.ietf.org/doc/html/ + draft-ietf-cdni-interfaces-https-delegation-06>. + + [json-schema-07] + Wright, A., Andrews, H., and B. Hutton, "JSON Schema + Validation: A Vocabulary for Structural Validation of + JSON", Work in Progress, Internet-Draft, draft-handrews- + json-schema-validation-02, 17 September 2019, + <https://datatracker.ietf.org/doc/html/draft-handrews- + json-schema-validation-02>. + + [MGLT-LURK-TLS13] + Migault, D., "LURK Extension version 1 for (D)TLS 1.3 + Authentication", Work in Progress, Internet-Draft, draft- + mglt-lurk-tls13-05, 26 July 2021, + <https://datatracker.ietf.org/doc/html/draft-mglt-lurk- + tls13-05>. + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March + 2011, <https://www.rfc-editor.org/info/rfc6125>. + + [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., + "Framework for Content Distribution Network + Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, + August 2014, <https://www.rfc-editor.org/info/rfc7336>. + + [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion + Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, + <https://www.rfc-editor.org/info/rfc8225>. + + [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity + Credentials: Certificates", RFC 8226, + DOI 10.17487/RFC8226, February 2018, + <https://www.rfc-editor.org/info/rfc8226>. + + [RFC8657] Landau, H., "Certification Authority Authorization (CAA) + Record Extensions for Account URI and Automatic + Certificate Management Environment (ACME) Method Binding", + RFC 8657, DOI 10.17487/RFC8657, November 2019, + <https://www.rfc-editor.org/info/rfc8657>. + + [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, + "DNS Certification Authority Authorization (CAA) Resource + Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, + <https://www.rfc-editor.org/info/rfc8659>. + + [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) + Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, + September 2021, <https://www.rfc-editor.org/info/rfc9060>. + + [TLS-SUBCERTS] + Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, + "Delegated Credentials for TLS", Work in Progress, + Internet-Draft, draft-ietf-tls-subcerts-10, 24 January + 2021, <https://datatracker.ietf.org/doc/html/draft-ietf- + tls-subcerts-10>. + + [TOKEN-TNAUTHLIST] + Wendt, C., Hancock, D., Barnes, M., and J. Peterson, + "TNAuthList profile of ACME Authority Token", Work in + Progress, Internet-Draft, draft-ietf-acme-authority-token- + tnauthlist-08, 27 March 2021, + <https://datatracker.ietf.org/doc/html/draft-ietf-acme- + authority-token-tnauthlist-08>. + +Appendix A. CSR Template: CDDL + + Following is the normative definition of the CSR template using CDDL + [RFC8610]. The CSR template MUST be a valid JSON document that is + compliant with the syntax defined here. + + There are additional constraints not expressed in CDDL that MUST be + validated by the recipient, including: + + * the value of each "subjectAltName" entry is compatible with its + type and + + * the parameters in each "keyTypes" entry form an acceptable + combination. + + csr-template-schema = { + keyTypes: [ + $keyType ] + ? subject: non-empty<distinguishedName> + extensions: extensions + } + + non-empty<M> = (M) .and ({ + any => any }) + + mandatory-wildcard = "**" + optional-wildcard = "*" + wildcard = mandatory-wildcard / optional-wildcard + + ; regtext matches all text strings but "*" and "**" + regtext = text .regexp "([^\*].*)|([\*][^\*].*)|([\*][\*].+)" + + regtext-or-wildcard = regtext / wildcard + + distinguishedName = { + ? country: regtext-or-wildcard + ? stateOrProvince: regtext-or-wildcard + ? locality: regtext-or-wildcard + ? organization: regtext-or-wildcard + ? organizationalUnit: regtext-or-wildcard + ? emailAddress: regtext-or-wildcard + ? commonName: regtext-or-wildcard + } + + $keyType /= rsaKeyType + $keyType /= ecdsaKeyType + + rsaKeyType = { + PublicKeyType: "rsaEncryption" ; OID: 1.2.840.113549.1.1.1 + PublicKeyLength: rsaKeySize + SignatureType: $rsaSignatureType + } + + rsaKeySize = uint + + ; RSASSA-PKCS1-v1_5 with SHA-256 + $rsaSignatureType /= "sha256WithRSAEncryption" + ; RSASSA-PCKS1-v1_5 with SHA-384 + $rsaSignatureType /= "sha384WithRSAEncryption" + ; RSASSA-PCKS1-v1_5 with SHA-512 + $rsaSignatureType /= "sha512WithRSAEncryption" + ; RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a 32 byte salt + $rsaSignatureType /= "sha256WithRSAandMGF1" + ; RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a 48 byte salt + $rsaSignatureType /= "sha384WithRSAandMGF1" + ; RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a 64 byte salt + $rsaSignatureType /= "sha512WithRSAandMGF1" + + ecdsaKeyType = { + PublicKeyType: "id-ecPublicKey" ; OID: 1.2.840.10045.2.1 + namedCurve: $ecdsaCurve + SignatureType: $ecdsaSignatureType + } + + $ecdsaCurve /= "secp256r1" ; OID: 1.2.840.10045.3.1.7 + $ecdsaCurve /= "secp384r1" ; OID: 1.3.132.0.34 + $ecdsaCurve /= "secp521r1" ; OID: 1.3.132.0.3 + + $ecdsaSignatureType /= "ecdsa-with-SHA256" ; paired with secp256r1 + $ecdsaSignatureType /= "ecdsa-with-SHA384" ; paired with secp384r1 + $ecdsaSignatureType /= "ecdsa-with-SHA512" ; paired with secp521r1 + + subjectaltname = { + ? DNS: [ + regtext-or-wildcard ] + ? Email: [ + regtext ] + ? URI: [ + regtext ] + * $$subjectaltname-extension + } + + extensions = { + ? keyUsage: [ + keyUsageType ] + ? extendedKeyUsage: [ + extendedKeyUsageType ] + subjectAltName: non-empty<subjectaltname> + } + + keyUsageType /= "digitalSignature" + keyUsageType /= "nonRepudiation" + keyUsageType /= "keyEncipherment" + keyUsageType /= "dataEncipherment" + keyUsageType /= "keyAgreement" + keyUsageType /= "keyCertSign" + keyUsageType /= "cRLSign" + keyUsageType /= "encipherOnly" + keyUsageType /= "decipherOnly" + + extendedKeyUsageType /= "serverAuth" + extendedKeyUsageType /= "clientAuth" + extendedKeyUsageType /= "codeSigning" + extendedKeyUsageType /= "emailProtection" + extendedKeyUsageType /= "timeStamping" + extendedKeyUsageType /= "OCSPSigning" + extendedKeyUsageType /= oid + + oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*" + +Appendix B. CSR Template: JSON Schema + + This appendix includes an alternative, nonnormative JSON Schema + definition of the CSR template. The syntax used is that of draft 7 + of JSON Schema, which is documented in [json-schema-07]. Note that + later versions of this (now-expired) draft describe later versions of + the JSON Schema syntax. At the time of writing, a stable reference + for this syntax is not yet available, and we have chosen to use the + draft version, which is currently best supported by tool + implementations. + + The same considerations about additional constraints checking + discussed in Appendix A apply here as well. + + { + "title": "JSON Schema for the STAR Delegation CSR template", + "$schema": "http://json-schema.org/draft-07/schema#", + "$id": "http://ietf.org/acme/drafts/star-delegation/csr-template", + "$defs": { + "distinguished-name": { + "$id": "#distinguished-name", + "type": "object", + "minProperties": 1, + "properties": { + "country": { + "type": "string" + }, + "stateOrProvince": { + "type": "string" + }, + "locality": { + "type": "string" + }, + "organization": { + "type": "string" + }, + "organizationalUnit": { + "type": "string" + }, + "emailAddress": { + "type": "string" + }, + "commonName": { + "type": "string" + } + }, + "additionalProperties": false + }, + "rsaKeyType": { + "$id": "#rsaKeyType", + "type": "object", + "properties": { + "PublicKeyType": { + "type": "string", + "const": "rsaEncryption" + }, + "PublicKeyLength": { + "type": "integer" + }, + "SignatureType": { + "type": "string", + "enum": [ + "sha256WithRSAEncryption", + "sha384WithRSAEncryption", + "sha512WithRSAEncryption", + "sha256WithRSAandMGF1", + "sha384WithRSAandMGF1", + "sha512WithRSAandMGF1" + ] + } + }, + "required": [ + "PublicKeyType", + "PublicKeyLength", + "SignatureType" + ], + "additionalProperties": false + }, + "ecdsaKeyType": { + "$id": "#ecdsaKeyType", + "type": "object", + "properties": { + "PublicKeyType": { + "type": "string", + "const": "id-ecPublicKey" + }, + "namedCurve": { + "type": "string", + "enum": [ + "secp256r1", + "secp384r1", + "secp521r1" + ] + }, + "SignatureType": { + "type": "string", + "enum": [ + "ecdsa-with-SHA256", + "ecdsa-with-SHA384", + "ecdsa-with-SHA512" + ] + } + }, + "required": [ + "PublicKeyType", + "namedCurve", + "SignatureType" + ], + "additionalProperties": false + } + }, + "type": "object", + "properties": { + "keyTypes": { + "type": "array", + "minItems": 1, + "items": { + "anyOf": [ + { + "$ref": "#rsaKeyType" + }, + { + "$ref": "#ecdsaKeyType" + } + ] + } + }, + "subject": { + "$ref": "#distinguished-name" + }, + "extensions": { + "type": "object", + "properties": { + "keyUsage": { + "type": "array", + "minItems": 1, + "items": { + "type": "string", + "enum": [ + "digitalSignature", + "nonRepudiation", + "keyEncipherment", + "dataEncipherment", + "keyAgreement", + "keyCertSign", + "cRLSign", + "encipherOnly", + "decipherOnly" + ] + } + }, + "extendedKeyUsage": { + "type": "array", + "minItems": 1, + "items": { + "anyOf": [ + { + "type": "string", + "enum": [ + "serverAuth", + "clientAuth", + "codeSigning", + "emailProtection", + "timeStamping", + "OCSPSigning" + ] + }, + { + "type": "string", + "pattern": "^([0-2])((\\.0)|(\\.[1-9][0-9]*))*$", + "description": "Used for OID values" + } + ] + } + }, + "subjectAltName": { + "type": "object", + "minProperties": 1, + "properties": { + "DNS": { + "type": "array", + "minItems": 1, + "items": { + "anyOf": [ + { + "type": "string", + "enum": [ + "*", + "**" + ] + }, + { + "type": "string", + "format": "hostname" + } + ] + } + }, + "Email": { + "type": "array", + "minItems": 1, + "items": { + "type": "string", + "format": "email" + } + }, + "URI": { + "type": "array", + "minItems": 1, + "items": { + "type": "string", + "format": "uri" + } + } + }, + "additionalProperties": false + } + }, + "required": [ + "subjectAltName" + ], + "additionalProperties": false + } + }, + "required": [ + "extensions", + "keyTypes" + ], + "additionalProperties": false + } + +Acknowledgements + + We would like to thank the following people who contributed + significantly to this document with their review comments and design + proposals: Richard Barnes, Carsten Bormann, Roman Danyliw, Lars + Eggert, Frédéric Fieau, Russ Housley, Ben Kaduk, Eric Kline, Sanjay + Mishra, Francesca Palombini, Jon Peterson, Ryan Sleevi, Emile + Stephan, and Éric Vyncke. + + This work is partially supported by the European Commission under + Horizon 2020 grant agreement no. 688421 Measurement and Architecture + for a Middleboxed Internet (MAMI). This support does not imply + endorsement. + +Authors' Addresses + + Yaron Sheffer + Intuit + + Email: yaronf.ietf@gmail.com + + + Diego López + Telefonica I+D + + Email: diego.r.lopez@telefonica.com + + + Antonio Agustín Pastor Perales + Telefonica I+D + + Email: antonio.pastorperales@telefonica.com + + + Thomas Fossati + ARM + + Email: thomas.fossati@arm.com |