rfc9538.original   rfc9538.txt 
Content Delivery Networks Interconnection F. Fieau, Ed. Internet Engineering Task Force (IETF) F. Fieau, Ed.
Internet-Draft E. Stephan Request for Comments: 9538 E. Stephan
Intended status: Standards Track Orange Category: Standards Track Orange
Expires: 9 June 2024 S. Mishra ISSN: 2070-1721 S. Mishra
Verizon Verizon
7 December 2023 February 2024
CDNI delegation using Automated Certificate Management Environment Content Delivery Network Interconnection (CDNI) Delegation Using the
draft-ietf-cdni-delegation-acme-04 Automated Certificate Management Environment
Abstract Abstract
This document defines metadata to support delegating the delivery of This document defines metadata to support delegating the delivery of
HTTPS content between two or more interconnected Content Delivery HTTPS content between two or more interconnected Content Delivery
Networks (CDNs). Specifically, this document defines a Content Networks (CDNs). Specifically, this document defines a Content
Delivery Network Interconnection (CDNI) Metadata interface object to Delivery Network Interconnection (CDNI) Metadata interface object to
enable delegation of X.509 certificates leveraging delegation schemes enable delegation of X.509 certificates leveraging delegation schemes
defined in RFC9115. RFC9115 allows delegating entities to remain in defined in RFC 9115. Per RFC 9115, delegating entities can remain in
full control of the delegation and be able to revoke it any time and full control of the delegation and can revoke it at any time. This
this avoids the need to share private cryptographic key material avoids the need to share private cryptographic key material between
between the involved entities. 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
https://datatracker.ietf.org/doc/draft-ietf-cdni-delegation-acme/.
Discussion of this document takes place on the Content Delivery
Networks Interconnection Working Group mailing list
(mailto:cdni@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/cdni/. Subscribe at
https://www.ietf.org/mailman/listinfo/cdni/.
Source for this draft and an issue tracker can be found at
https://github.com/FredericFi/cdni-wg.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 9 June 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9538.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Advertising Delegation Metadata for CDNI through FCI . . . . 3 2. Advertising Delegation Metadata for CDNI through FCI
3. ACME Delegation Metadata for CDNI . . . . . . . . . . . . . 4 3. ACME Delegation Metadata for CDNI
3.1. ACMEDelegationMethod Object . . . . . . . . . . . . . . . 6 3.1. ACMEDelegationMethod Object
3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Examples
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations
4.1. CDNI MI ACMEDelegationMethod Payload Type . . . . . . . . 8 4.1. CDNI MI ACMEDelegationMethod Payload Type
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. References
6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.1. Normative References
6.2. Informative References . . . . . . . . . . . . . . . . . 10 6.2. Informative References
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses
1. Introduction 1. Introduction
Content delivery over HTTPS using two or more cooperating CDNs along Content delivery over HTTPS using two or more cooperating CDNs along
the path requires credential management, specifically when DNS-based the path requires credential management, specifically when DNS-based
redirection is used. In such cases, an upstream CDN (uCDN) needs to redirection is used. In such cases, an upstream CDN (uCDN) needs to
delegate its credentials to a downstream (dCDN) for content delivery. delegate its credentials to a downstream CDN (dCDN) for content
delivery.
[RFC9115] defines delegation methods that allow a uCDN on behalf of [RFC9115] defines delegation methods that allow a uCDN on behalf of
the content provider, the holder of the domain, to generate on-demand the content provider, the holder of the domain, to generate on-demand
an X.509 certificate that binds the designated domain name with a an X.509 certificate that binds the designated domain name with a key
key-pair owned by the dCDN. For further details, please refer to pair owned by the dCDN. For further details, please refer to
Section 1 of [RFC9115] and Section 5.1.2.1 of [RFC9115]. Sections 1 and 5.1.2.1 of [RFC9115].
This document defines CDNI Metadata to make use of HTTPS delegation This document defines CDNI Metadata to make use of HTTPS delegation
between a uCDN and a dCDN based on the mechanism specified in between a uCDN and a dCDN based on the mechanism specified in
[RFC9115]. Furthermore, it adds a delegation method to the "CDNI [RFC9115]. Furthermore, it adds a delegation method to the "CDNI
Payload Types" IANA registry. Payload Types" IANA registry.
Section 2 presents delegation metadata for the Footprint & Section 2 presents delegation metadata for the Footprint &
Capabilities Advertisement interface (FCI). Section 3 addresses the Capabilities Advertisement interface (FCI). Section 3 addresses the
metadata for handling HTTPS delegation with the Metadata Interface. metadata for handling HTTPS delegation with the Metadata interface.
1.1. Terminology 1.1. Terminology
This document uses terminology from CDNI framework documents such as: This document uses terminology from CDNI framework documents such as:
CDNI framework document [RFC7336] and CDNI interface specifications CDNI framework document [RFC7336] and CDNI interface specifications
documents: CDNI Metadata interface [RFC8006] and CDNI Footprint and documents: CDNI Metadata interface [RFC8006] and CDNI Footprint and
Capabilities Advertisement interface [RFC8008]. It also uses Capabilities Advertisement interface [RFC8008]. It also uses
terminology from Section 1.2 of [RFC8739] and Section 1.1 of terminology from Section 1.2 of [RFC8739] and Section 1.1 of
[RFC9115]. [RFC9115], including Short-Term, Automatically Renewed (STAR), as
applied to X.509 certificates.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Advertising Delegation Metadata for CDNI through FCI 2. Advertising Delegation Metadata for CDNI through FCI
The Footprint and Capabilities Advertisement interface (FCI) defined The Footprint & Capabilities Advertisement interface (FCI) defined in
in [RFC8008] allows a dCDN to send a FCI capability type object to a [RFC8008] allows a dCDN to send a FCI capability type object to a
uCDN. uCDN.
This document uses the CDNI Metadata capability object serialization This document uses the CDNI Metadata capability object serialization
from [RFC8008] for a CDN that supports delegation methods. from [RFC8008] for a CDN that supports delegation methods.
The following is an example of the supported delegated methods The following is an example of the supported delegated methods
capability object for a dCDN implementing the ACME delegation method. capability object for a dCDN implementing the ACME delegation method.
{ {
"capabilities": [ "capabilities": [
skipping to change at page 4, line 22 skipping to change at line 138
"ACMEDelegationMethod" "ACMEDelegationMethod"
] ]
}, },
"footprints": [ "footprints": [
"Footprint objects" "Footprint objects"
] ]
} }
] ]
} }
3. ACME Delegation Metadata for CDNI 3. ACME Delegation Metadata for CDNI
When a uCDN delegates the delivery of HTTPS traffic to a dCDN using When a uCDN delegates the delivery of HTTPS traffic to a dCDN using
DNS Redirection [RFC7336], the dCDN must use a certificate bound to DNS redirection [RFC7336], the dCDN must use a certificate bound to
the origin's name to successfully authenticate to the end-user (see the origin's name to successfully authenticate to the end-user (see
also Section 5.1.2.1 of [RFC9115]). also Section 5.1.2.1 of [RFC9115]).
To that end, this section defines the AcmeDelegationMethod object To that end, this section defines the AcmeDelegationMethod object,
which describes metadata for using the ACME delegation interface which describes metadata for using the ACME delegation interface
[RFC9115]. [RFC9115].
The ACMEDelegationMethod applies to both ACME STAR delegation, which The ACMEDelegationMethod applies to both ACME STAR delegation, which
provides a delegation model based on short-term certificates with provides a delegation model based on short-term certificates with
automatic renewal (Section 2.3.2 of [RFC9115]), and non-STAR automatic renewal (Section 2.3.2 of [RFC9115]), and non-STAR
delegation, which allows delegation between CDNs using long-term delegation, which allows delegation between CDNs using long-term
certificates (Section 2.3.3 of [RFC9115]). certificates (Section 2.3.3 of [RFC9115]).
Figure 1 provides a high-level view of the combined CDNI and ACME Figure 1 provides a high-level view of the combined CDNI and ACME
delegation message flows to obtain STAR certificate from the delegation message flows to obtain a STAR certificate from the
Certificate Authority (CA) bound to the Content Provider's (CP) name. Certification Authority (CA) bound to the Content Provider's (CP)
name.
.----. .----. .----. .----. .----. .----. .----. .----.
|dCDN| |uCDN| | CP | | CA | |dCDN| |uCDN| | CP | | CA |
'-+--' '-+--' '--+-' '--+-' '-+--' '-+--' '--+-' '--+-'
| GET metadata | | | | GET metadata | | |
+--------[CDNI]------>| | | +--------[CDNI]------>| | |
| 200 OK, metadata | | | | 200 OK, metadata | | |
| (inc. dele config) | | | | (inc. dele config) | | |
|<-------[CDNI]-------+ | | |<-------[CDNI]-------+ | |
| | | | | | | |
skipping to change at page 5, line 45 skipping to change at line 200
| | |<---authorizations--->| | | |<---authorizations--->|
| | | | | | | |
|<---wait issuance--->|<---wait issuance--->|<---wait issuance---->| |<---wait issuance--->|<---wait issuance--->|<---wait issuance---->|
| | | |
| (unauthenticated) GET star-certificate | | (unauthenticated) GET star-certificate |
+----------------------------------------------------------------->| +----------------------------------------------------------------->|
| certificate #1 | | certificate #1 |
|<-----------------------------------------------------------------+ |<-----------------------------------------------------------------+
| ... | | ... |
Figure 1: Example call-flow of STAR delegation in CDNI showing 2 Figure 1: Example Call Flow of STAR Delegation in CDNI Showing
levels of delegation Two Levels of Delegation
| Note: The delegation object defined in Section 2.3.1.3 of | Note: The delegation object defined in Section 2.3.1.3 of
| [RFC9115] only allows to specify DNS mappings using CNAME RRs. | [RFC9115] only allows DNS mappings to be specified using CNAME
| A future document updating [RFC9115] could expand the | RRs. A future document updating [RFC9115] could expand the
| delegation object to also include SVCB/HTTPS-based [RFC9460] | delegation object to also include SVCB/HTTPS-based mappings
| mappings. | [RFC9460].
Section 3.1 defines the objects used for bootstrapping the ACME Section 3.1 defines the objects used for bootstrapping the ACME
delegation method between a uCDN and a delegate dCDN. delegation method between a uCDN and a delegate dCDN.
3.1. ACMEDelegationMethod Object 3.1. ACMEDelegationMethod Object
The ACMEDelegationMethod object allows a uCDN to define both STAR and The ACMEDelegationMethod object allows a uCDN to define both STAR and
non-STAR delegation. The dCDN, the consumer of the delegation, can non-STAR delegations. The dCDN, the consumer of the delegation, can
determine the type of delegation by the presence (or absence) of the determine the type of delegation by the presence (or absence) of the
"lifetime" property. That is, the presence of the "lifetime" "lifetime" property. That is, the presence of the "lifetime"
property explicitly means a short-term delegation with lifetime of property explicitly means a short-term delegation with lifetime of
the certificate based on that property (and the optional "lifetime- the certificate based on that property (and the optional "lifetime-
adjust" attribute). A non-STAR delegation will not have the adjust" attribute). A non-STAR delegation will not have the
"lifetime" property in the delegation. See also the examples in "lifetime" property in the delegation. See also the examples in
Section 3.1.1. Section 3.1.1.
The ACMEDelegationMethod object is defined with the properties shown The ACMEDelegationMethod object is defined with the properties shown
below. below.
* Property: acme-delegation * Property: acme-delegation
- Description: a URL pointing at an ACME delegation object, - Description: A URL pointing at an ACME delegation object,
either STAR or non-STAR, associated with the dCDN account on either STAR or non-STAR, associated with the dCDN account on
the uCDN ACME server (see Section 2.3.1.3 of [RFC9115] for the the uCDN ACME server (see Section 2.3.1.3 of [RFC9115] for the
details). The URL MUST use the https scheme. details). The URL MUST use the https scheme.
- Type: String - Type: String
- Mandatory-to-Specify: Yes - Mandatory-to-Specify: Yes
* Property: time-window * Property: time-window
- Description: Validity period of the certificate. According to - Description: Validity period of the certificate. According to
Section 4.3.4 of [RFC8006], a TimeWindow object is defined by a Section 4.3.4 of [RFC8006], a TimeWindow object is defined by a
window "start" time, and a window "end" time. In case of STAR window "start" time and a window "end" time. In the case of a
method, the "start" and "end" properties of the window MUST be STAR method, the "start" and "end" properties of the window
understood respectively as the start-date and end-date of the MUST be understood respectively as the start-date and end-date
certificate validity. In the case of the non-STAR method, the of the certificate validity. In the case of a non-STAR method,
"start" and "end" properties of the window MUST be understood the "start" and "end" properties of the window MUST be
respectively as the notBefore and notAfter fields of the understood, respectively, as the notBefore and notAfter fields
certificate. of the certificate.
- Type: TimeWindow - Type: TimeWindow
- Mandatory-to-Specify: Yes - Mandatory-to-Specify: Yes
* Property: lifetime * Property: lifetime
- Description: See lifetime in Section 3.1.1 of [RFC8739] - Description: See lifetime in Section 3.1.1 of [RFC8739]
- Type: Integer - Type: Integer
- Mandatory-to-Specify: Yes, only if a STAR delegation method is - Mandatory-to-Specify: Yes, only if a STAR delegation method is
specified specified
* Property: lifetime-adjust * Property: lifetime-adjust
- Description: See lifetime-adjust in Section 3.1.1 of [RFC8739] - Description: See lifetime-adjust in Section 3.1.1 of [RFC8739]
- Type: Integer - Type: Integer
skipping to change at page 8, line 5 skipping to change at line 304
"generic-metadata-type": "MI.ACMEDelegationMethod", "generic-metadata-type": "MI.ACMEDelegationMethod",
"generic-metadata-value": { "generic-metadata-value": {
"acme-delegation": "https://acme.ucdn.example/delegation/wSi5", "acme-delegation": "https://acme.ucdn.example/delegation/wSi5",
"time-window": { "time-window": {
"start": 1570982234, "start": 1570982234,
"end": 1665417434 "end": 1665417434
} }
} }
} }
4. IANA Considerations 4. IANA Considerations
This document requests the registration of the following entry under Per this document, the following type has been registered in the
the "CDNI Payload Types" registry: "CDNI Payload Types" registry:
+=========================+===============+ +=========================+===========+
| Payload Type | Specification | | Payload Type | Reference |
+=========================+===============+ +=========================+===========+
| MI.ACMEDelegationMethod | RFCthis | | MI.ACMEDelegationMethod | RFC 9538 |
+-------------------------+---------------+ +-------------------------+-----------+
Table 1 Table 1
// RFC Editor: please replace RFCthis with the RFC number of this RFC
// and remove this note.
4.1. CDNI MI ACMEDelegationMethod Payload Type 4.1. CDNI MI ACMEDelegationMethod Payload Type
Purpose: The purpose of this Payload Type is to distinguish Purpose: The purpose of this Payload Type is to distinguish
AcmeDelegationMethod MI objects (and any associated capability AcmeDelegationMethod MI objects (and any associated capability
advertisement) advertisement)
Interface: MI/FCI Interface: MI/FCI
Encoding: See Section 3.1 Encoding: See Section 3.1
5. Security Considerations 5. Security Considerations
The metadata object defined in this document does not introduce any The metadata object defined in this document does not introduce any
new security or privacy concerns over those already discussed in new security or privacy concerns over those already discussed in
[RFC9115], [RFC8006] and [RFC8008]. [RFC9115], [RFC8006], and [RFC8008].
The reader is expected to understand the ACME delegation trust model The reader is expected to understand the ACME delegation trust model
(Section 7.1 of [RFC9115]) and security goal (Section 7.2 of (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of
[RFC9115]), in particular the criticality around the protection of [RFC9115]). In particular, the reader is expected to understand that
the user account associated with the delegation, which authorizes all it is critical to protect the user account associated with the
the security relevant operations between dCDN and uCDN over the ACME delegation; this account authorizes all the security-relevant
channel. The dCDN's ACME account is also relevant to the privacy of operations between a dCDN and a uCDN over the ACME channel. The
the entire scheme; for example, the acme-delegation resource in the dCDN's ACME account is also relevant to the privacy of the entire
Metadata object is only accessible to the holder of the account key, scheme; for example, the acme-delegation resource in the Metadata
who is allowed to fetch its content exclusively via POST-as-GET object is only accessible to the holder of the account key, who is
allowed to fetch its content exclusively via POST-as-GET
(Section 2.3.1.2 of [RFC9115]). (Section 2.3.1.2 of [RFC9115]).
In addition, the Metadata interface authentication and In addition, the Metadata interface authentication and
confidentiality requirements defined in Section 8 of [RFC8006] MUST confidentiality requirements defined in Section 8 of [RFC8006] MUST
be followed. be followed.
Implementers MUST adhere to the security considerations defined in Implementers MUST adhere to the security considerations defined in
the CDNI Request Routing: Footprint and Capabilities Semantics, Section 7 of [RFC8008], "Content Delivery Network Interconnection
Section 7 of [RFC8008]. (CDNI) Request Routing: Footprint and Capabilities Semantics".
When TLS is used to achieve the above security objectives, the When TLS is used to achieve the above security objectives, the
general TLS usage guidance in [RFC9325] MUST be followed. general TLS usage guidance in [RFC9325] MUST be followed.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI) "Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<https://www.rfc-editor.org/rfc/rfc8006>. <https://www.rfc-editor.org/info/rfc8006>.
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
R., and K. Ma, "Content Delivery Network Interconnection R., and K. Ma, "Content Delivery Network Interconnection
(CDNI) Request Routing: Footprint and Capabilities (CDNI) Request Routing: Footprint and Capabilities
Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
<https://www.rfc-editor.org/rfc/rfc8008>. <https://www.rfc-editor.org/info/rfc8008>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor
Perales, A., and T. Fossati, "Support for Short-Term, Perales, A., and T. Fossati, "Support for Short-Term,
Automatically Renewed (STAR) Certificates in the Automated Automatically Renewed (STAR) Certificates in the Automated
Certificate Management Environment (ACME)", RFC 8739, Certificate Management Environment (ACME)", RFC 8739,
DOI 10.17487/RFC8739, March 2020, DOI 10.17487/RFC8739, March 2020,
<https://www.rfc-editor.org/rfc/rfc8739>. <https://www.rfc-editor.org/info/rfc8739>.
[RFC9115] Sheffer, Y., López, D., Pastor Perales, A., and T. [RFC9115] Sheffer, Y., López, D., Pastor Perales, A., and T.
Fossati, "An Automatic Certificate Management Environment Fossati, "An Automatic Certificate Management Environment
(ACME) Profile for Generating Delegated Certificates", (ACME) Profile for Generating Delegated Certificates",
RFC 9115, DOI 10.17487/RFC9115, September 2021, RFC 9115, DOI 10.17487/RFC9115, September 2021,
<https://www.rfc-editor.org/rfc/rfc9115>. <https://www.rfc-editor.org/info/rfc9115>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/rfc/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
6.2. Informative References 6.2. Informative References
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <https://www.rfc-editor.org/rfc/rfc7336>. August 2014, <https://www.rfc-editor.org/info/rfc7336>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460, Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>. November 2023, <https://www.rfc-editor.org/info/rfc9460>.
Acknowledgments Acknowledgments
We would like to thank authors of the [RFC9115], Antonio Augustin We would like to thank authors of the [RFC9115], Antonio Augustín
Pastor Perales, Diego Lopez, Thomas Fossati and Yaron Sheffer. Pastor Perales, Diego López, Thomas Fossati, and Yaron Sheffer.
Additionally, our gratitude to Thomas Fossati who participated in the Additionally, our gratitude to Thomas Fossati who participated in the
drafting, reviewing and giving his feedback in finalizing this drafting, reviewing, and giving his feedback in finalizing this
document. We also thank CDNI co-chair Kevin Ma for his continual document. We also thank CDNI co-chair Kevin Ma for his continual
review and feedback during the development of this document. review and feedback during the development of this document.
Authors' Addresses Authors' Addresses
Frédéric Fieau (editor) Frédéric Fieau (editor)
Orange Orange
40-48, avenue de la Republique 40-48, avenue de la République
92320 Chatillon 92320 Châtillon
France France
Email: frederic.fieau@orange.com Email: frederic.fieau@orange.com
Emile Stephan Emile Stephan
Orange Orange
2, avenue Pierre Marzin 2, avenue Pierre Marzin
22300 Lannion 22300 Lannion
France France
Email: emile.stephan@orange.com Email: emile.stephan@orange.com
Sanjay Mishra Sanjay Mishra
Verizon Verizon
13100 Columbia Pike 13100 Columbia Pike
Silver Spring, MD 20904 Silver Spring, MD 20904
United States of America United States of America
Email: sanjay.mishra@verizon.com Email: sanjay.mishra@verizon.com
 End of changes. 47 change blocks. 
126 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.48.