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 athttps://www.rfc-editor.org/info/rfc9538.¶

Copyright Notice

Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1.Introduction

Content delivery over HTTPS using two or more cooperating CDNs along the path requirescredential management, specifically when DNS-based redirection is used. In such cases, an upstream CDN (uCDN) needs to delegate its credentials to a downstream CDN (dCDN) for content delivery.¶

[RFC9115] defines delegation methods that allow a uCDN on behalf of the content provider, the holder of the domain, to generate on-demand an X.509certificate that binds the designated domain name with a key pair owned by the dCDN. For further details, please referto Sections1 and5.1.2.1 of[RFC9115].¶

This document defines CDNI Metadata to make use of HTTPS delegation between auCDN and a dCDN based on the mechanism specified in[RFC9115]. Furthermore,it adds a delegation method to the "CDNI Payload Types" IANA registry.¶

Section 2 presents delegation metadata for the Footprint & Capabilities Advertisement interface (FCI).Section 3 addresses the metadata for handling HTTPS delegation with the Metadata interface.¶

2.Advertising Delegation Metadata for CDNI through FCI

The Footprint & Capabilities Advertisement interface (FCI) defined in[RFC8008] allows adCDN to send a FCI capability type object to a uCDN.¶

This document uses the CDNI Metadata capability object serialization from[RFC8008] for a CDN that supportsdelegation methods.¶

The following is an example of the supported delegated methods capabilityobject for a dCDN implementing the ACME delegation method.¶

{  "capabilities": [    {      "capability-type": "FCI.Metadata",      "capability-value": {        "metadata": [          // list of supported delegation methods          "ACMEDelegationMethod"        ]      },      "footprints": [        "Footprint objects"      ]    }  ]}

3.ACME Delegation Metadata for CDNI

When a uCDN delegates the delivery of HTTPS traffic to a dCDN using DNS redirection[RFC7336], the dCDN must use a certificate bound to the origin's name tosuccessfully authenticate to the end-user (see alsoSection 5.1.2.1 of [RFC9115]).¶

To that end, this section defines the AcmeDelegationMethod object, whichdescribes metadata for using the ACME delegation interface[RFC9115].¶

The ACMEDelegationMethod applies to both ACME STAR delegation, which provides adelegation model based on short-term certificates with automatic renewal (Section 2.3.2 of [RFC9115]), andnon-STAR delegation, which allows delegation between CDNs using long-termcertificates (Section 2.3.3 of [RFC9115]).¶

Figure 1 provides a high-level view of the combined CDNI and ACMEdelegation message flows to obtain a STAR certificate from the Certification Authority (CA) bound to the Content Provider's (CP) name.¶

Note: The delegation object defined inSection 2.3.1.3 of [RFC9115] only allows DNS mappings to be specified using CNAME RRs. A future document updating[RFC9115] could expand the delegation object to also include SVCB/HTTPS-based mappings[RFC9460].¶

Section 3.1 defines the objects used for bootstrapping the ACME delegationmethod between a uCDN and a delegate dCDN.¶

{  "generic-metadata-type": "MI.ACMEDelegationMethod",  "generic-metadata-value": {    "acme-delegation": "https://acme.ucdn.example/delegation/ogfr",    "time-window": {      "start": 1665417434,      "end": 1665676634    },    "lifetime": 345600,    "lifetime-adjust": 259200  }}

{  "generic-metadata-type": "MI.ACMEDelegationMethod",  "generic-metadata-value": {    "acme-delegation": "https://acme.ucdn.example/delegation/wSi5",    "time-window": {      "start": 1570982234,      "end": 1665417434    }  }}

4.IANA Considerations

Per this document, the following type has been registered in the"CDNI Payload Types" registry:¶

5.Security Considerations

The metadata object defined in this document does not introduce any newsecurity or privacy concerns over those already discussed in[RFC9115],[RFC8006], and[RFC8008].¶

The reader is expected to understand the ACME delegation trust model (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of [RFC9115]). In particular, the reader is expected to understand that it is critical to protect 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, theacme-delegation resource in the Metadata object is onlyaccessible to the holder of the account key, who is allowed to fetch itscontent exclusively via POST-as-GET (Section 2.3.1.2 of [RFC9115]).¶

In addition, the Metadata interface authentication and confidentialityrequirements defined inSection 8 of [RFC8006]MUST be followed.¶

ImplementersMUST adhere to the security considerations defined inSection 7 of [RFC8008], "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics".¶

When TLS is used to achieve the above security objectives, the general TLSusage guidance in[RFC9325]MUST be followed.¶

Acknowledgments

We would like to thank authors of the[RFC9115],Antonio Augustín Pastor Perales,Diego López,Thomas Fossati, andYaron Sheffer. Additionally, our gratitude toThomas Fossati who participated in the drafting, reviewing, and giving his feedback in finalizing this document. We also thank CDNI co-chairKevin Ma for his continual review and feedback during the development of this document.¶

Authors' Addresses