]> Orange

40-48, avenue de la Republique Chatillon 92320 France frederic.fieau@orange.com

Orange

2, avenue Pierre Marzin Lannion 22300 France emile.stephan@orange.com

Verizon

13100 Columbia Pike Silver Spring MD 20904 United States of America sanjay.mishra@verizon.com

Applications and Real-Time Content Delivery Networks Interconnection HTTPS delegation ACME STAR This document defines metadata to support delegating the delivery of HTTPS content between two or more interconnected Content Delivery Networks (CDNs). Specifically, this document defines a Content Delivery Network Interconnection (CDNI) Metadata interface object to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC9115. Per RFC 9115, delegating entities can remain in full control of the delegation and can revoke it at any time. This avoids the need to share private cryptographic key material between the involved entities. About This Document Status information for this document may be found at . Discussion of this document takes place on the Content Delivery Networks Interconnection Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

 Introduction Content delivery over HTTPS using two or more cooperating 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. presents delegation metadata for the Footprint & Capabilities Advertisement interface (FCI). addresses the metadata for handling HTTPS delegation with the Metadata Interface.

Terminology This document uses terminology from CDNI framework documents such as: CDNI framework document and CDNI interface specifications documents: CDNI Metadata interface and CDNI Footprint and Capabilities Advertisement interface . It also uses terminology from and , including Short-Term, Automatically Renewed (STAR), as applied to X.509 certificates. 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.

Advertising Delegation Metadata for CDNI through FCI The Footprint and Capabilities Advertisement interface (FCI) defined in allows a dCDN to send a FCI capability type object to a uCDN. This document uses the CDNI Metadata capability object serialization from for a CDN that supports delegation methods. The following is an example of the supported delegated methods capability object for a dCDN implementing the ACME delegation method.

 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 from the Certificate Authority (CA) bound to the Content Provider's (CP) name.

Example call-flow of STAR delegation in CDNI showing 2 levels of delegation | | | | 200 OK, metadata | | | | (inc. dele config) | | | |<-------[CDNI]-------+ | | | | | | | GET delegation | | | +-----[ACME dele]---->| | | | 200 OK, delegation | | | | (inc. CSR template) | | | |<----[ACME dele]-----+ | | | | | | +----. | | | | | | | | | create key pair and| | | | CSR w/ delegated | | | | name | | | | | | | | |<---' | | | | | | | | POST Order1 | | | +-----[ACME dele]---->| | | | | forward Order1 | | | +-----[ACME dele]---->| | | | | POST Order2 | | | +-----[ACME STAR]----->| | | | | | | |<---authorizations--->| | | | | |<---wait issuance--->|<---wait issuance--->|<---wait issuance---->| | | | (unauthenticated) GET star-certificate | +----------------------------------------------------------------->| | certificate #1 | |<-----------------------------------------------------------------+ | ... | ]]>

defines the objects used for bootstrapping the ACME delegation method between a uCDN and a delegate dCDN.

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 "lifetime" property. That is, the presence of the "lifetime" property explicitly means a short-term delegation with lifetime of the certificate based on that property (and the optional "lifetime-adjust" attribute). A non-STAR delegation will not have the "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). The URL MUST use the https scheme.
  • 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: lifetime
  • Description: See lifetime in
  • Type: Integer
  • Mandatory-to-Specify: Yes, only if a STAR delegation method is specified
• Property: lifetime-adjust
  • Description: See lifetime-adjust in
  • 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 .

 IANA Considerations This document requests the registration of the following entry under the "CDNI Payload Types" registry:

Payload Type	Specification
MI.ACMEDelegationMethod	RFCthis

RFC Editor: please replace RFCthis with the RFC number of this RFC and remove this note.

CDNI MI ACMEDelegationMethod Payload Type

Purpose:

The purpose of this Payload Type is to distinguish AcmeDelegationMethod MI objects (and any associated capability advertisement)

Interface:

MI/FCI

Encoding:

See

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 reader is expected to understand the criticality of the protection of the user account associated with the delegation; this account authorizes all the security-relevant operations between a dCDN and a 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.

References Normative References The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata. <p>This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.</p> Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates. 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. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.

Acknowledgments We would like to thank authors of the , Antonio Augustin Pastor Perales, Diego Lopez, Thomas Fossati and Yaron Sheffer. Additionally, our gratitude to Thomas Fossati who participated in the drafting, reviewing and giving his feedback in finalizing this document. We also thank CDNI co-chair Kevin Ma for his continual review and feedback during the development of this document.