CDNI delegation using Automated Certificate Management Environment

Introduction Content delivery over HTTPS using two or more cooperating Content Delivery Networks (CDNs) along the path requires credential management, specifically when DNS-based redirection is used. In such cases, an upstream CDN (uCDN) needs to delegate its credentials to a downstream (dCDN) for content delivery. defines delegation methods that allow a uCDN on behalf of the content provider, the holder of the domain, to generate on-demand an X.509 certificate that binds the designated domain name with a key-pair owned by the dCDN. For further details, please refer to and . This document defines CDNI Metadata to make use of HTTPS delegation between a uCDN and a dCDN based on the mechanism specified in . Furthermore, it adds a delegation method to the "CDNI Payload Types" IANA registry. defines terminology used in this document. presents delegation metadata for the FCI interface. addresses the metadata for handling HTTPS delegation with the Metadata Interface. addresses IANA registry for delegation methods. covers the security considerations.

Terminology This document uses terminology from CDNI framework documents such as: CDNI framework document , CDNI requirements and CDNI interface specifications documents: CDNI Metadata interface and CDNI Footprint and Capabilities Advertisement interface . It also uses terminology from . 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 when, and only when, they appear in all capitals, as shown here.

ACME Delegation Metadata for CDNI When a uCDN delegates the delivery of HTTPS traffic to a dCDN using DNS Redirection , the dCDN must use a certificate bound to the origin's name to successfully authenticate to the end-user (see also ). To that end, this section defines the AcmeDelegationMethod object which describes metadata for using the ACME delegation interface . The ACMEDelegationMethod applies to both ACME STAR delegation, which provides a delegation model based on short-term certificates with automatic renewal (), and non-STAR delegation, which allows delegation between CDNs using long-term certificates . provides a high-level view of the combined CDNI and ACME delegation message flows to obtain STAR certificate bound to the origin's name.

ACMEDelegationMethod Object The ACMEDelegationMethod object allows a uCDN to define both STAR and non-STAR delegation. The dCDN, the consumer of the delegation, can determine the type of delegation by the presence (or absence) of the "star-lifetime" property. That is, the presence of the "star-lifetime" property explicitly means a short-term delegation with lifetime of the certificate based on that property (and the optional "star-lifetime-adjust" attribute). A non-STAR delegation will not have the "star-lifetime" property in the delegation. See also the examples in . The ACMEDelegationMethod object is defined with the properties shown below.

Property: acme-delegation
- Description: a URL pointing at an ACME delegation object, either STAR or non-STAR, associated with the dCDN account on the uCDN ACME server (see for the details).
- Type: String
- Mandatory-to-Specify: Yes
Property: time-window
- Description: Validity period of the certificate. According to , a TimeWindow object is defined by a window "start" time, and a window "end" time. In case of STAR method, the "start" and "end" properties of the window MUST be understood respectively as the start-date and end-date of the certificate validity. In the case of the non-STAR method, the "start" and "end" properties of the window MUST be understood respectively as the notBefore and notAfter fields of the certificate.
- Type: TimeWindow
- Mandatory-to-Specify: Yes
Property: star-lifetime
- Description: See
- Type: Integer
- Mandatory-to-Specify: Yes, only if a STAR delegation method is specified
Property: star-lifetime-adjust
- Description: See
- Type: Integer
- Mandatory-to-Specify: No

Examples The following example shows an ACMEDelegationMethod object for a STAR-based ACME delegation. The example below shows an ACMEDelegationMethod object for a non-STAR ACME delegation. The delegation object is defined as per .

Payload Type	Specification
MI.ACMEDelegationMethod	RFCthis

Payload Type

Specification

MI.ACMEDelegationMethod

RFCthis

Security Considerations The metadata object defined in this document does not introduce any new security or privacy concerns over those already discussed in , and . The reader is expected to understand the ACME delegation trust model () and security goal (), in particular the criticality around the protection of the user account associated with the delegation, which authorizes all the security relevant operations between dCDN and uCDN over the ACME channel. The dCDN's ACME account is also relevant to the privacy of the entire scheme; for example, the acme-delegation resource in the Metadata object is only accessible to the holder of the account key, who is allowed to fetch its content exclusively via POST-as-GET (). In addition, the Metadata interface authentication and confidentiality requirements defined in MUST be followed. Implementers MUST adhere to the security considerations defined in the CDNI Request Routing: Footprint and Capabilities Semantics, . When TLS is used to achieve the above security objectives, the general TLS usage guidance in MUST be followed.