An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates
Extracted elements (27)
STAR certificate delegation is terminated by the IdO canceling automatic renewal (letting the short-lived cert expire), rather than by revocation, because STAR explicitly disables the revokeCert interface; non-STAR delegation is terminated by explicit revocation via the CA's 'revokeCert' URL.
The interactive identifier authorization phase of ACME (RFC 8555 Section 7.5) is suppressed on the NDC-IdO side because the delegated identity in the NDC's CSR is validated against the configured CSR template rather than via DNS/HTTP challenges, so the NDC sends the 'finalize' request immediately after Order1 is acknowledged.
Unlike TLS Delegated Credentials (TLS-SUBCERTS) or LURK, this mechanism requires no changes to deployed TLS clients or servers and introduces no additional TLS handshake latency, because delegation is handled entirely at the certificate provisioning layer.
For the STIR use case, the STAR delegation profile applies directly; the only additional requirement is a CSR template extension to convey allowed TNAuthList values to the NDC (SP2), which is not defined in this document and requires a separate extension.
The 'allow-certificate-get' elements defined here for non-STAR certificates have the same names and semantics as those in RFC 8739 Section 3.4 for STAR, but differ in position: they appear at the top level of the directory meta and order objects rather than inside an 'auto-renewal' subobject.
A CA that wishes to support certificate delegation MUST also support unauthenticated certificate fetching, declared via the 'allow-certificate-get' attribute in the directory object.
An ACME server supporting the delegation profile MUST include the 'delegation-enabled' key in its directory 'meta' field and MUST set it to true, regardless of whether it supports STAR, non-STAR, or both.
For non-STAR delegation, the IdO's request to the CA MUST copy the identifiers sent by the NDC, MUST strip the 'delegation' attribute, and MUST copy the 'allow-certificate-get' attribute.
For STAR delegation, the NDC's order request MUST include a 'delegation' attribute, MUST include all delegated identifiers, MUST NOT contain 'notBefore'/'notAfter', and MUST contain an 'auto-renewal' object with 'allow-certificate-get' set to true.
If the CSR fails validation against the template for any identifier, the IdO MUST return HTTP 403 with an appropriate error type (e.g., 'rejectedIdentifier' or 'badCSR'); the error response SHOULD contain subproblems for each failed identifier.
If the CSR template includes a wildcard 'subjectAltName' of type DNS, the IdO MUST apply application-specific checks on top of the CSR template control rules to ensure the requested domain name is legitimate per local policy.
If the 'delegation' attribute in an order object contains a URL not corresponding to a configuration available to the requesting ACME account, the IdO MUST return HTTP 403 with a problem document of type 'urn:ietf:params:acme:error:unknownDelegation'.
If the server accepts a client's request for unauthenticated GET, it MUST reflect the 'allow-certificate-get' attribute setting in the resulting order object. Even when unauthenticated GET is allowed, the server MUST also allow POST-as-GET requests to the certificate resource.
In proxy behavior, the 'identifiers' and 'auto-renewal' objects in new-order requests MUST be copied as-is; the 'finalize' URL and 'Location' header MUST be rewritten to point to the proxy.
The NDC MUST NOT include any fields in the CSR, including extensions, unless they are specified in the template. When the IdO receives the CSR, it MUST verify that the CSR is consistent with the template in the referenced 'delegation' object.
The order object created on the IdO for a STAR delegation MUST start in the 'ready' state, MUST contain an 'authorizations' array with zero elements, and MUST NOT contain 'notBefore' and 'notAfter' fields.
The result of a GET on the delegations URL MUST be a JSON object whose 'delegations' field is an array of URLs, each identifying a delegation configuration. The server MAY return an incomplete list with a 'Link: next' header.
When the CA does not support unauthenticated GET of STAR certificates, the IdO MUST NOT forward the order request and MUST instead move the order status to 'invalid' and set 'allow-certificate-get' to false.
When the CA issues the certificate, the IdO MUST move its Order resource status to 'valid' and MUST copy the 'star-certificate' field from the CA's STAR Order into its own Order resource.
The ACME account object on the IdO is extended with a 'delegations' attribute (required, string): a URL from which a list of delegation configurations for that account can be fetched via POST-as-GET.
The 'allow-certificate-get' boolean attribute in the ACME directory 'meta' object and in order objects enables unauthenticated HTTP GET (and HEAD) access to certificate resources, negotiated per-order between client and server.
The CSR template is a JSON document using three field markers: a literal string (mandatory, IdO-specified value), '**' (mandatory, client-defined value), and '*' (optional, client decides). The 'keyTypes' property constrains SubjectPublicKeyInfo but is not copied into the CSR.
The 'delegation' object is a new read-only ACME resource representing a delegation configuration for a given NDC. It contains a mandatory 'csr-template' field and an optional 'cname-map' field mapping delegated FQDNs to NDC FQDNs.
RFC 9115 adds 'delegation-enabled' (boolean) and 'allow-certificate-get' (boolean) to the 'ACME Directory Metadata Fields' registry; adds 'allow-certificate-get' (boolean) and 'delegation' (string) to the 'ACME Order Object Fields' registry; adds 'delegations' (string) to the 'ACME Account Object Fields' registry; adds error type 'unknownDelegation' to 'ACME Error Types'; and establishes the new 'STAR Delegation CSR Template Extensions' registry.
The IdO MUST ensure each NDC account is associated with exact delegation policies (via matching 'delegation' objects) defining which domain names can be delegated and how; out-of-band means are expected to preregister each NDC. The ACME account key pair's security is critical since delegation bypasses the normal ACME authorization challenge procedures.
The NDC SHOULD NOT directly use the revocation interface exposed by the CA unless doing so is necessary because the certificate private key is compromised and the IdO is unreachable, as this would bypass IdO control.
To prevent a rogue CDN from obtaining unauthorized certificates, the domain holder should: (1) ensure only it can modify DNS records, (2) use a CAA record restricting issuance to specific CAs that implement RFC 8657, and (3) use the ACME-specific CAA mechanism to restrict issuance to a specific CA account and require 'dns-01' as the sole validation method.