RFC 9538

Content Delivery Network Interconnection (CDNI) Delegation Using the Automated Certificate Management Environment

📅 published February 2024, from ietf

RFC 9538 💖 CDNI Delegation Using the Automated Certificate Management Environment

Okay bestie, let's talk about RFC 9538 🧚✨. It's a Standards Track document from the IETF, published February 2024 (ISSN 2070-1721). The authors are F. Fieau (Ed.) and E. Stephan from Orange, and S. Mishra from Verizon 🎀. Its title block doesn't list anything it obsoletes or updates, so it's a fresh one! 🌸

Abstract

Okay so this doc defines metadata for delivering HTTPS content across two or more interconnected CDNs 🌐💅. The main star is a CDNI Metadata interface object that lets you delegate X.509 certificates using the delegation schemes from RFC 9115 🔐. Per RFC 9115, the delegating entities stay in full control and can revoke the delegation at any time 🙅‍♀️. The best part? Nobody has to share private cryptographic key material, which is literally so iconic 😭🫶.

Status of This Memo

This is an Internet Standards Track document 🔥.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 📚.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9538 🦋.

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. Please read these carefully, because they explain 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 they come without warranty as described in the Revised BSD License 🌈.

Table of Contents

  1.  Introduction
     1.1.  Terminology
   2.  Advertising Delegation Metadata for CDNI through FCI
   3.  ACME Delegation Metadata for CDNI
     3.1.  ACMEDelegationMethod Object
       3.1.1.  Examples
   4.  IANA Considerations
     4.1.  CDNI MI ACMEDelegationMethod Payload Type
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

Okay so content delivery over HTTPS with two or more cooperating CDNs along the path needs credential management 🔑. This gets extra spicy when DNS-based redirection is in play 🌀. In that case, an upstream CDN (uCDN) has to delegate its credentials to a downstream CDN (dCDN) so the content can actually get delivered 🎀.

[RFC9115] defines delegation methods that let a uCDN, acting on behalf of the content provider (the holder of the domain), generate an X.509 certificate on demand. That certificate binds the designated domain name to a key pair owned by the dCDN 🧚. For more details, check Sections 1 and 5.1.2.1 of [RFC9115] 📖.

This document defines CDNI Metadata so you can use HTTPS delegation between a uCDN and a dCDN, based on the mechanism in [RFC9115] 💅. It also adds a delegation method to the "CDNI Payload Types" IANA registry 🌸.

Section 2 covers delegation metadata for the Footprint & Capabilities Advertisement interface (FCI) 🦋. Section 3 handles the metadata for HTTPS delegation through the Metadata interface 🍓.

1.1. Terminology

This document uses terminology from CDNI framework documents, like the CDNI framework document [RFC7336], and from CDNI interface specifications, like the CDNI Metadata interface [RFC8006] and the CDNI Footprint and Capabilities Advertisement interface [RFC8008] 📚. It also borrows terms from Section 1.2 of [RFC8739] and Section 1.1 of [RFC9115], 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀.

2. Advertising Delegation Metadata for CDNI through FCI

Okay so the Footprint & Capabilities Advertisement interface (FCI), defined in [RFC8008], lets a dCDN send an FCI capability type object to a uCDN 💌.

This document uses the CDNI Metadata capability object serialization from [RFC8008] for a CDN that supports delegation methods 🌈.

Here's an example of the supported delegated methods capability object for a dCDN that implements 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

Okay, so 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 so it can successfully authenticate to the end-user 🔐🫶. (See also Section 5.1.2.1 of [RFC9115].)

To make that happen, this section defines the AcmeDelegationMethod object 💖. It describes the metadata for using the ACME delegation interface [RFC9115] ✨.

The ACMEDelegationMethod applies to both ACME STAR delegation, which is a delegation model built on short-term certificates with automatic renewal (Section 2.3.2 of [RFC9115]), and non-STAR delegation, which lets CDNs delegate using long-term certificates (Section 2.3.3 of [RFC9115]) 🦋.

Figure 1 gives you the big-picture view of the combined CDNI and ACME delegation message flows for getting a STAR certificate from the Certification Authority (CA) bound to the Content Provider's (CP) 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
                       Two Levels of Delegation
📝 Quick heads-up from the doc: the delegation object defined in Section 2.3.1.3 of [RFC9115] only allows DNS mappings to be specified using CNAME RRs. A future document that updates [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 delegation method between a uCDN and a delegate dCDN 🎀.

3.1. ACMEDelegationMethod Object ✨

okay so the ACMEDelegationMethod object is the one that lets a uCDN set up BOTH STAR and non-STAR delegations 💅. The dCDN (the consumer of the delegation) can tell which kind it's getting just by checking whether the lifetime property is there. If lifetime shows up, it's a short-term delegation, and the certificate's lifetime comes from that property (plus the optional lifetime-adjust attribute) 🦋. If it's missing, it's non-STAR, no cap. Check out Section 3.1.1 for examples 🌸

Here's the full property list for the object 🎀

  • Property: acme-delegation
    • Description: A URL pointing at an ACME delegation object, either STAR or non-STAR, tied to the dCDN account on the uCDN ACME server. (Go read Section 2.3.1.3 of [RFC9115] for all the details 🧚) The URL MUST use the https scheme.
    • Type: String
    • Mandatory-to-Specify: Yes
  • Property: time-window
    • Description: The validity period of the certificate 💖. According to Section 4.3.4 of [RFC8006], a TimeWindow object has a window "start" time and a window "end" time. For a STAR method, the "start" and "end" properties MUST be understood as the start-date and end-date of the certificate validity. For a non-STAR method, the "start" and "end" properties MUST be understood as the notBefore and notAfter fields of the certificate. (Yes, both of those are a big deal, bestie 😭)
    • Type: TimeWindow
    • Mandatory-to-Specify: Yes
  • Property: lifetime
    • Description: See lifetime in Section 3.1.1 of [RFC8739]
    • Type: Integer
    • Mandatory-to-Specify: Yes, only if a STAR delegation method is specified
  • Property: lifetime-adjust
    • Description: See lifetime-adjust in Section 3.1.1 of [RFC8739]
    • Type: Integer
    • Mandatory-to-Specify: No

3.1.1. Examples 🧁

first up, here's an ACMEDelegationMethod object for a STAR-based ACME delegation. It's giving STAR energy ⭐

{
  "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
  }
}

next one is an ACMEDelegationMethod object for a non-STAR ACME delegation. Notice there's no lifetime anywhere, which is how you know 🙈 The delegation object is defined as per Section 4.3 of [RFC8006].

{
  "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 📝

okay so per this document, the following type gets registered in the "CDNI Payload Types" registry 🎀

                +=========================+===========+
                | Payload Type            | Reference |
                +=========================+===========+
                | MI.ACMEDelegationMethod | RFC 9538  |
                +-------------------------+-----------+

                                Table 1

4.1. 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 Section 3.1

5. Security Considerations 🚨

okay bestie, this part is SERIOUS 😭 The metadata object defined in this document doesn't bring any NEW security or privacy concerns on top of the ones already covered in [RFC9115], [RFC8006], and [RFC8008]. Still, you need to get these right 🫶

The reader is expected to understand the ACME delegation trust model (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of [RFC9115]). Most importantly, it is CRITICAL to protect the user account tied to the delegation, because that account authorizes ALL the security-relevant operations between a dCDN and a uCDN over the ACME channel. 💀

The dCDN's ACME account also matters for the privacy of the entire scheme 🙈. For example, the acme-delegation resource in the Metadata object can only be accessed by the holder of the account key, and they're only allowed to fetch its content via POST-as-GET (Section 2.3.1.2 of [RFC9115]). Main character security energy 👑

On top of all that, the Metadata interface authentication and confidentiality requirements defined in Section 8 of [RFC8006] MUST be followed 🔒.

Implementers MUST adhere to the security considerations defined in Section 7 of [RFC8008], "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics". No skipping this one, periodt 💅

When TLS is used to hit the security objectives above, the general TLS usage guidance in [RFC9325] MUST be followed 🦋.

6. References 📚

6.1. Normative References 💖

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC8006]  Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
           "Content Delivery Network Interconnection (CDNI)
           Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
           <https://www.rfc-editor.org/info/rfc8006>.

[RFC8008]  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, December 2016,
           <https://www.rfc-editor.org/info/rfc8008>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8739]  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, March 2020,
           <https://www.rfc-editor.org/info/rfc8739>.

[RFC9115]  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, September 2021,
           <https://www.rfc-editor.org/info/rfc9115>.

[RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,
           "Recommendations for Secure Use of Transport Layer Security
           (TLS) and Datagram Transport Layer Security (DTLS)",
           BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
           2022, <https://www.rfc-editor.org/info/rfc9325>.

6.2. Informative References 🌸

[RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
           "Framework for Content Distribution Network
           Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
           August 2014, <https://www.rfc-editor.org/info/rfc7336>.

[RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
           and Parameter Specification via the DNS (SVCB and HTTPS
           Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
           November 2023, <https://www.rfc-editor.org/info/rfc9460>.

Acknowledgments 🫶

we'd like to thank the authors of [RFC9115]: Antonio Augustín Pastor Perales, Diego López, Thomas Fossati, and Yaron Sheffer 🧚. Extra love to Thomas Fossati, who helped with drafting, reviewing, and giving feedback to finalise this document. We also thank CDNI co-chair Kevin Ma for his constant review and feedback while this doc was being developed 💜

Authors' Addresses 🦋

Frédéric Fieau (editor)
Orange
40-48, avenue de la République
92320 Châtillon
France
Email: frederic.fieau@orange.com


Emile Stephan
Orange
2, avenue Pierre Marzin
22300 Lannion
France
Email: emile.stephan@orange.com


Sanjay Mishra
Verizon
13100 Columbia Pike
Silver Spring, MD 20904
United States of America
Email: sanjay.mishra@verizon.com
📦 where this page comes from