Internet-Draft CDNI extensions for HTTPS delegation October 2022
Fieau, et al. Expires 26 April 2023 [Page]
Content Delivery Networks Interconnection
Intended Status:
Standards Track
F. Fieau, Ed.
E. Stephan
S. Mishra

CDNI extensions for HTTPS delegation


This document defines metadata objects to support delegating the delivery of HTTPS content between two or more interconnected CDNs. Specifically, this document defines CDNI Metadata interface objects to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC9115. RFC 9115 allows delegating entity to remain in full control of the delegation and be able to revoke it any time and avoids the need to share private cryptographic key material between the involved entities.

About This Document

This note is to be removed before publishing as an RFC.

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

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 26 April 2023.

Table of Contents

1. 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 case an upstream CDN (uCDN) needs to delegate its credentials to a downstream (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.509 certificate that binds the designated domain name with a key-pair owned by the dCDN. For further details, please refer to Section 1 of [RFC9115] and Section of [RFC9115].

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

Section 1.1 defines terminology used in this document. Section 2 presents delegation metadata for the FCI interface. Section 3 addresses the metadata for handling HTTPS delegation with the Metadata Interface. Section 4 addresses IANA registry for delegation methods. Section 5 covers the security considerations.

1.1. Terminology

This document uses terminology from CDNI framework documents such as: CDNI framework document [RFC7336], CDNI requirements [RFC7337] and CDNI interface specifications documents: CDNI Metadata interface [RFC8006] and CDNI Footprint and capabilities [RFC8008]. It also uses terminology from Section 1.1 of [RFC8739].

2. Advertising Delegation Metadata for CDNI through FCI

The Footprint and Capabilities interface defined in [RFC8008] allows a dCDN to send a FCI capability type object to a uCDN.

The FCI.Metadata object allows a dCDN to advertise the capabilities regarding the supported delegation methods and their configuration.

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

  "capabilities": [
      "capability-type": "FCI.Metadata",
      "capability-value": {
        "metadata": [
          "... Other supported delegation methods ..."
      "footprints": [
        "Footprint objects"

3. ACME Delegation Metadata for CDNI

When a uCDN delegates a dCDN to deliver HTTPS traffic using DNS Redirection [RFC7975], the dCDN must use a certificate bound to the origin's name to successfully authenticate to the end-user (see also Section of [RFC9115]).

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

The ACMEDelegationMethod applies to both ACME STAR delegation, which provides a delegation model based on short-term certificates with automatic renewal Section 2.3.2 of [RFC9115], and non-STAR delegation, which allows delegation between CDNs using long-term certificates Section 2.3.3 of [RFC9115].

Figure 1 provides a high-level view of the combined CDNI and ACME delegation message flows to obtain STAR certificate bound to the origin's name.

dCDN uCDN CP CA GET metadata [CDNI] 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 ...
Figure 1: Example call-flow of STAR delegation in CDNI showing 2 levels of delegation

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

3.1. ACMEDelegationMethod Object

The ACMEDelegationMethod object allows a uCDN to both define STAR and non-STAR delegation objects depending on the delegation certificate validity. The ACMEDelegationMethod object is defined with several properties as 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 Section 2.3.1 of [RFC9115] for the details).
    • Type: Source object, according to [RFC8006]
    • Mandatory-to-Specify: Yes
  • Property: TimeWindow

    • Description: Validity period of the certificate. According to [RFC8006], TimeWindow is defined by defining "start" time of the window, and "end" time of the window. 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 case of 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

In the case that the delegation is STAR-based, the following properties are mandatory to specify:

  • Property: Lifetime

  • Property: Lifetime-adjust

    • Description: See Section 3.1.1 of [RFC8739]
    • Type: Time
    • Mandatory-to-Specify: Yes, only if a STAR delegation method is specified

3.2. Examples

The following example shows an ACMEDelegationMethod object for a STAR-based ACME delegation.

  "generic-metadata-type": "MI.ACMEDelegationMethod",
  "generic-metadata-value": {
    "ACME-delegation": "https://acme.ucdn.example/delegation/ogfr",
    "TimeWindow": {
      "start": "2022-10-10T00:00:00Z",
      "end": "2022-10-13T00:00:00Z"
    "Lifetime": 345600,
    "Lifetime-adjust": 259200

The example below shows an ACMEDelegationMethod object for a non-STAR ACME delegation.

  "generic-metadata-type": "MI.ACMEDelegationMethod",
  "generic-metadata-value": {
    "ACME-delegation": "https://acme.ucdn.example/delegation/wSi5",
    "TimeWindow": {
      "start": "2019-01-10T00:00:00Z",
      "end": "2023-01-20T00:00:00Z"

The following is a complete example showing how a HostMatch [RFC8006] and its Metadata related to a host hold associated delegation metadata.

  • HostMatch:
  "host": "",
  "host-metadata": {
    "type": "MI.HostMetadata",
    "href": "https://metadata.ucdn.example/host1234"
  • HostMetadata:
  "paths": "/video",
  "metadata": [ // defining here a STAR delegation
      "generic-metadata-type": "MI.ACMEDelegationMethod",
      "generic-metadata-value": {
        "ACME-delegation": "https://acme.ucdn.example/delegation/wSi5",
        "TimeWindow": {
          "start": "2019-01-10T00:00:00Z",
          "end": "2023-01-20T00:00:00Z"

4. IANA Considerations

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

Table 1
Payload Type Specification
MI.ACMEDelegationMethod RFCthis

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

4.1. CDNI MI ACMEDelegationMethod Payload Type


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




See Section 3

5. Security considerations

Delegation metadata proposed here do not alter nor change Security Considerations as outlined in the following RFCs: An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates [RFC9115]; the CDNI Metadata [RFC8006] and CDNI Footprint and Capabilities [RFC8008].

The delegation objects properties such as the list of delegation objects mentioned in Section 3are critical. They should be protected by the proper/mandated encryption and authentication. Please refer to Sections 7.1, 7.2 and 7.4 of [RFC9115].

6. References

6.1. Normative References

Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, , <>.
Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, R., and K. Ma, "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics", RFC 8008, DOI 10.17487/RFC8008, , <>.
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, , <>.
Sheffer, Y., López, D., Pastor Perales, A., and T. Fossati, "An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates", RFC 9115, DOI 10.17487/RFC9115, , <>.

6.2. Informative References

Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, , <>.
Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, , <>.
Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., "Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection", RFC 7975, DOI 10.17487/RFC7975, , <>.


We would like to thank authors of the [RFC9115], 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.

Authors' Addresses

Frédéric Fieau (editor)
40-48, avenue de la Republique
92320 Chatillon
Emile Stephan
2, avenue Pierre Marzin
22300 Lannion
Sanjay Mishra
13100 Columbia Pike
Silver Spring, MD 20904
United States of America