rfc9677xml2.original.xml   rfc9677.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc linkmailto="no" ?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-references-in-index="yes" ?>
<!DOCTYPE rfc []>
<rfc ipr="trust200902" docName="draft-ietf-cdni-https-delegation-subcerts-12" ca
tegory="std">
<front>
<title abbrev="RFC XML Examples">CDNI Metadata for Delegated Credentials</title>
<author initials="F." surname="Fieau" fullname="Frederic Fieau">
<organization>Orange</organization>
<address>
<postal>
<street>40-48, avenue de la Republique</street>
<city>Chatillon</city>
<code>92320</code>
<country>France</country>
</postal>
<email>frederic.fieau@orange.com</email></address>
</author>
<author initials='E.' surname='Stephan' fullname='Emile Stephan'>
<organization>Orange</organization>
<address>
<postal>
<street>2, avenue Pierre Marzin</street>
<city>Lannion</city>
<code>22300</code>
<country>France</country>
</postal>
<email>emile.stephan@orange.com</email></address>
</author>
<author initials='G.' surname='Guillaume' fullname='Guillaume Bichot'>
<organization>Broadpeak</organization>
<address>
<postal>
<street>15, rue Claude Chappe</street>
<city>Cesson-Sevigne</city>
<code>35510</code>
<country>France</country>
</postal>
<email>guillaume.bichot@broadpeak.tv</email></address>
</author>
<author initials='C.' surname='Christoph' fullname='Christoph Neumann'>
<organization>Broadpeak</organization>
<address>
<postal>
<street>15, rue Claude Chappe</street>
<city>Cesson-Sevigne</city>
<code>35510</code>
<country>France</country>
</postal>
<email>christoph.neumann@broadpeak.tv</email></address>
</author>
<date/> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<abstract> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<t> -ietf-cdni-https-delegation-subcerts-12" number="9677" submissionType="IETF" con
The delivery of content over HTTPS involving multiple Content Delivery Networks sensus="true" category="std" tocInclude="true" symRefs="true" sortRefs="true" ve
(CDNs) rsion="3" xml:lang="en" obsoletes="" updates="">
raises credential management issues. This document defines
metadata in the CDNI Control and Metadata interface to setup HTTPS
delegation using delegated credentials from an Upstream CDN (uCDN)
to a Downstream CDN (dCDN).
</t>
</abstract>
</front> <front>
<title abbrev="CDNI Metadata for Delegated Credentials">Content Delivery
Network Interconnection (CDNI) Metadata for Delegated Credentials</title>
<seriesInfo name="RFC" value="9677"/>
<middle> <author initials="F." surname="Fieau" fullname="Frédéric Fieau">
<organization>Orange</organization>
<address>
<postal>
<street>40-48, avenue de la République</street>
<city>Châtillon</city>
<code>92320</code>
<country>France</country>
</postal>
<email>frederic.fieau@orange.com</email>
</address>
</author>
<author initials="E." surname="Stephan" fullname="Emile Stephan">
<organization>Orange</organization>
<address>
<postal>
<street>2, avenue Pierre Marzin</street>
<city>Lannion</city>
<code>22300</code>
<country>France</country>
</postal>
<email>emile.stephan@orange.com</email>
</address>
</author>
<author initials="G." surname="Bichot" fullname="Guillaume Bichot">
<organization>Broadpeak</organization>
<address>
<postal>
<street>15, rue Claude Chappe</street>
<city>Cesson-Sevigne</city>
<code>35510</code>
<country>France</country>
</postal>
<email>guillaume.bichot@broadpeak.tv</email>
</address>
</author>
<author initials="C." surname="Neumann" fullname="Christoph Neumann">
<organization>Broadpeak</organization>
<address>
<postal>
<street>15, rue Claude Chappe</street>
<city>Cesson-Sevigne</city>
<code>35510</code>
<country>France</country>
</postal>
<email>christoph.neumann@broadpeak.tv</email>
</address>
</author>
<date month="October" year="2024"/>
<area>WIT</area>
<workgroup>cdni</workgroup>
<section title="Introduction"> <keyword>HTTPS</keyword>
<keyword>TLS</keyword>
<t> <abstract>
<t>
The delivery of content over HTTPS involving multiple Content Delivery
Networks (CDNs) raises credential management issues. This document defines
metadata in the Content Delivery Network Interconnection (CDNI) Control and
Metadata interface to set up HTTPS delegation using delegated credentials from
an upstream CDN (uCDN) to a downstream CDN (dCDN).
</t>
</abstract>
</front>
<middle>
<section>
<name>Introduction</name>
<t>
Content delivery over HTTPS utilizing one or more Content Delivery Networks Content delivery over HTTPS utilizing one or more Content Delivery Networks
(CDNs) along the delivery path necessitates the management of credentials. (CDNs) along the delivery path necessitates the management of credentials.
This requirement is particularly pertinent when an entity delegates the delivery of content via HTTPS to another trusted entity. This requirement is particularly pertinent when an entity delegates the delivery of content via HTTPS to another trusted entity.
</t> </t>
<t>
<t> This document specifies the CDNI Metadata interface for establishing HTTPS deleg
This document specifies the CDNI Metadata interface for establishing HTTPS deleg ation through the use of delegated credentials, as defined in <xref target="RFC
ation through the use of delegated credentials, as defined in <xref target="RFC 9345"/>,
9345"/>)
between an upstream CDN (uCDN) and a downstream CDN (dCDN). between an upstream CDN (uCDN) and a downstream CDN (dCDN).
</t> </t>
</section>
</section> <section anchor="terminology">
<name>Terminology</name>
<section anchor="terminology" title="Terminology"> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTI ",
ONAL" "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
in this document are to be interpreted as described in BCP 14 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appe "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
ar in all be
capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
<t> shown here.
This document uses terminology from CDNI framework documents: </t>
CDNI framework document <xref target="RFC7336"/>, CDNI requirements <xref target <t>
="RFC7337"/> and This document uses terminology from the CDNI specifications -- CDNI framework
CDNI interface specifications documents: CDNI Metadata interface <xref target="R <xref target="RFC7336"/>, CDNI requirements <xref target="RFC7337"/>, and CDNI
FC8006"/>. Metadata interface <xref target="RFC8006"/>.
</t> </t>
</section>
</section> <section anchor="FCI">
<name>CDNI Footprint and Capabilities Advertisement Interface (FCI) Capabi
<section anchor="FCI" title="CDNI Footprint and Capabilities Advertisement inter lities Object for Delegated Credentials</name>
face (FCI) capabilities object for delegated credentials"> <t>
<t>
A dCDN should advertise its supported delegation methods using the A dCDN should advertise its supported delegation methods using the
Footprint and Capabilities Advertisement interface (FCI) as defined in <xref tar get="RFC8008"/>. Footprint and Capabilities Advertisement interface (FCI) as defined in <xref tar get="RFC8008"/>.
The FCI.Metadata object enables a dCDN to communicate its capabilities and the M etadata Interface (MI) objects it supports. The FCI.Metadata object enables a dCDN to communicate its capabilities and the M etadata interface (MI) objects it supports.
To indicate support for delegated credentials, the dCDN should announce the supp ort for MI.DelegatedCredentials, as illustrated in the example below. To indicate support for delegated credentials, the dCDN should announce the supp ort for MI.DelegatedCredentials, as illustrated in the example below.
</t> </t>
<figure><artwork align="left"> <sourcecode><![CDATA[
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.Metadata", "capability-type": "FCI.Metadata",
"capability-value": { "capability-value": {
"metadata": [ "metadata": [
"MI.DelegatedCredentials", "MI.DelegatedCredentials",
"... other supported MI objects ..." "... other supported MI objects ..."
] ]
}, },
"footprints": [ "footprints": [
"Footprint objects" "Footprint objects"
] ]
} }
] ]
} }
</artwork></figure> ]]></sourcecode>
<t>
<t>
This document also defines an object that informs the uCDN of the number of dele gated credentials supported by the dCDN, This document also defines an object that informs the uCDN of the number of dele gated credentials supported by the dCDN,
enabling the uCDN to supply the appropriate number of delegated credentials. To this end, the FCI object, FCI.DelegationCredentials, is introduced. enabling the uCDN to supply the appropriate number of delegated credentials. To this end, the FCI object, FCI.DelegationCredentials, is introduced.
</t> </t>
<section anchor="FCI_DelegatedCredentials">
<section anchor="FCI_DelegatedCredentials" title="FCI.DelegatedCredentials"> <name>FCI.DelegatedCredentials</name>
<t> <t>
The FCI.DelegationCredentials object enables advertising the maximum number of d elegated credentials supported by the dCDN. The FCI.DelegationCredentials object enables advertising the maximum number of d elegated credentials supported by the dCDN.
This number typically (but not necessarily) corresponds to the number of servers designated by the dCDN to support delegated credentials. This number typically (but not necessarily) corresponds to the number of servers designated by the dCDN to support delegated credentials.
</t> </t>
<t> <t>
The property PrivateKeyEncryptionKey contains a public key provided by the dCDN The property PrivateKeyEncryptionKey contains a public key provided by the dCDN
that MUST be used by the uCDN to that <bcp14>MUST</bcp14> be used by the uCDN to
encrypt private keys whenever such private keys are transmitted to the dCDN usin g MI.DelegatedCredentials (see <xref target="MI"/>). encrypt private keys whenever such private keys are transmitted to the dCDN usin g MI.DelegatedCredentials (see <xref target="MI"/>).
</t> </t>
<dl newline="false" spacing="compact">
<t> <dt>Property: </dt>
<dl> <dd>number-delegated-certs-supported</dd>
<dt>Property: </dt> <dt>Description:</dt>
<dd>number-delegated-certs-supported <dd>Number of delegated credentials supported by the dCDN.</dd>
<dl> <dt>Type:</dt>
<dt>Description:</dt> <dd>integer</dd>
<dd>Number of delegated credentials supported by the dCDN.</dd> <dt>Mandatory-to-Specify:</dt>
<dt>Type:</dt> <dd>Yes</dd>
<dd>integer</dd>
<dt>Mandatory-to-Specify:</dt>
<dd>Yes</dd>
</dl> </dl>
</dd> <dl newline="false" spacing="compact">
</dl> <dt>Property: </dt>
<dl> <dd>PrivateKeyEncryptionKey</dd>
<dt>Property: </dt> <dt>Description:</dt>
<dd>PrivateKeyEncryptionKey <dd>Public key in JSON Web Key (JWK) format <xref target="RFC7517"/> o
<dl> f the dCDN to be used by the uCDN to encrypt private keys.</dd>
<dt>Description:</dt> <dt>Type:</dt>
<dd>Public key in JWK format (<xref target="RFC7517"/>) of the dCDN to b <dd>string</dd>
e used by the uCDN to encrypt private keys.</dd> <dt>Mandatory-to-Specify:</dt>
<dt>Type:</dt> <dd>No</dd>
<dd>string</dd>
<dt>Mandatory-to-Specify:</dt>
<dd>No</dd>
</dl> </dl>
</dd> <t>
</dl>
</t>
<t>
The following is an example of the FCI.DelegatedCredentials. The following is an example of the FCI.DelegatedCredentials.
</t> </t>
<sourcecode><![CDATA[
<figure><artwork align="left">
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.DelegatedCredentials", "capability-type": "FCI.DelegatedCredentials",
"capability-value": { "capability-value": {
"number-delegated-certs-supported": 10 "number-delegated-certs-supported": 10
} }
"footprints": [ "footprints": [
&lt;Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
</artwork></figure> ]]></sourcecode>
</section>
</section> <section anchor="usage_FCI">
<name>Expected Usage of the Property Number of Supported Delegated Crede
<section anchor="usage_FCI" title="Expected usage of the property number of supp ntials</name>
orted delegated credentials"> <t>The dCDN uses the FCI.DelegatedCredentials object to announce the num
<t>The dCDN uses the FCI.DelegatedCredentials object to announce the number of s ber of servers that support delegated credentials.</t>
ervers that support delegated credentials</t> <t>When the uCDN receives the FCI.DelegatedCredentials object, it can is
sue the supported number of delegated credentials to the dCDN.
<t>When the uCDN receives the FCI.DelegatedCredentials object it can issue the s When configuring the dCDN, the uCDN <bcp14>MAY</bcp14> decide to provide less th
upported number of delegated credentials to the dCDN. an the maximum supported delegated credentials to the dCDN.
When configuring the dCDN, the uCDN MAY decide to provide less than the maximum
supported delegated credentials to the dCDN.
Note that, within a dCDN, different deployment possibilities of the delegated cr edentials on the Note that, within a dCDN, different deployment possibilities of the delegated cr edentials on the
endpoints exist. The dCDN MAY use one single delegated credential and deploy it endpoints exist. The dCDN <bcp14>MAY</bcp14> use one single delegated credential
on multiple endpoints. and deploy it on multiple endpoints.
Alternatively, the dCDN MAY deploy a different delegated credential for each end Alternatively, the dCDN <bcp14>MAY</bcp14> deploy a different delegated credenti
point al for each endpoint
(provided that the uCDN delivers enough different delegated credentials). (provided that the uCDN delivers enough different delegated credentials).
This choice is at the discretion of the dCDN and depends on the number of delega ted credentials provided by the uCDN.</t> This choice is at the discretion of the dCDN and depends on the number of delega ted credentials provided by the uCDN.</t>
<t>The FCI.DelegationCredentials object does not address expiry or renew
<t>The FCI.DelegationCredentials object does not address expiry and renewal of d al of delegated credentials.
elegated credentials. Once the uCDN has provided
Once the uCDN has provided delegated credentials via the MI, uCDN SHOULD monitor delegated credentials via the MI, the uCDN <bcp14>SHOULD</bcp14> monitor the p
the provided credentials rovided
and their expiry times and timely refresh dCDN credentials via the MI. credentials and their expiry times and <bcp14>SHOULD</bcp14> refresh dCDN
credentials via the MI in a timely manner.
The uCDN may decide not to monitor the validity period of delegated credentials The uCDN may decide not to monitor the validity period of delegated credentials
and not to refresh the credentials, for example in cases of short-term one shot and not to refresh the credentials, for example, in cases of short-term one-shot
deployments or once it decided to deprovision a dCDN. deployments or once it has decided to deprovision a dCDN.
If the delegated credential is not renewed on time by the uCDN, the servers of t If the delegated credential is not renewed on time by the uCDN, the servers of t
he dCDN that only have expired delegated credentials MUST refuse he dCDN that only have expired delegated credentials <bcp14>MUST</bcp14> refuse
any new TLS connection that requires an up-to-date delegated credential. any new TLS connection that requires an up-to-date delegated credential.
</t> </t>
</section>
</section> </section>
<section anchor="MI">
</section> <name>CDNI Metadata Interface (MI) Metadata Object for Delegated Credentia
ls</name>
<section anchor="MI" title="CDNI Metadata interface (MI) metadata object for del <t>As expressed in <xref target="RFC9345"/>, when an uCDN has delegated to
egated credentials"> a dCDN, the dCDN presents the
"delegated_credential" (rather than its own certificate) during the TLS handshak
<t>As expressed in <xref target="RFC9345"/>, when an uCDN has delegated to a dCD e <xref target="RFC8446"/> to the User Agent. This implies that the dCDN is also
N, the dCDN presents the in the possession of the private key corresponding to the public key in Delegat
"delegated_credential" during the TLS handshake <xref target="RFC8446"/> to the edCredential.cred <xref target="RFC9345"/>.
User Agent, This allows the User Agent to verify the signature in a CertificateVerify messag
instead of its own certificate. This implies that the dCDN is also in the posses e (<xref target="RFC8446" sectionFormat="of" section="4.4.3"/>) sent and signed
sion of the private key corresponding to the public key in DelegatedCredential.c by the dCDN.</t>
red <xref target="RFC9345"/>. <t>
This allows the User Agent to verify the signature in CertificateVerify message
(<xref target="RFC8446"/> Section 4.4.3.) sent and signed by the dCDN.</t>
<t>
This section defines the MI.DelegatedCredentials object containing an array of d elegated This section defines the MI.DelegatedCredentials object containing an array of d elegated
credentials and optionally the corresponding private keys. credentials and optionally the corresponding private keys.
The CDNI MI <xref target="RFC8006"/> describes the CDNI metadata distribution The CDNI MI <xref target="RFC8006"/> describes the CDNI metadata distribution
mechanisms according to which a dCDN can retrieve the MI.DelegatedCredentials ob ject mechanisms according to which a dCDN can retrieve the MI.DelegatedCredentials ob ject
from the uCDN. from the uCDN.
</t> </t>
<t>
<t>
The properties of the MI.DelegatedCredentials object are as follows: The properties of the MI.DelegatedCredentials object are as follows:
</t> </t>
<dl newline="false" spacing="compact">
<t> <dt>Property: </dt>
<dl> <dd>delegated-credentials</dd>
<dt>Property: </dt>
<dd>delegated-credentials
<dl>
<dt>Description:</dt> <dt>Description:</dt>
<dd>Array of delegated credentials</dd> <dd>Array of delegated credentials</dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd>Array of DelegatedCredentialObject objects</dd> <dd>Array of DelegatedCredentialObject objects</dd>
<dt>Mandatory-to-Specify:</dt> <dt>Mandatory-to-Specify:</dt>
<dd>Yes</dd> <dd>Yes</dd>
</dl> </dl>
</dd> <t>
</dl>
</t>
<t>
The DelegatedCredentialObject object is composed of the following properties: The DelegatedCredentialObject object is composed of the following properties:
</t> </t>
<dl newline="false" spacing="compact">
<t> <dt>Property: </dt>
<dl> <dd>delegated-credential</dd>
<dt>Property: </dt>
<dd>delegated-credential
<dl>
<dt>Description:</dt> <dt>Description:</dt>
<dd>Base64-encoded (as defined in Section 4 of <xref target="RFC4648"/>) version of a CertificateEntry as defined in <xref target="RFC8446"/> Section 4. 4.2. The CertificateEntry MUST contain a DelegatedCredential structure (as defin ed in <xref target="RFC9345"/>) using the extension in the CertificateEntry of i ts end-entity certificate (see <xref target="RFC9345"/> section 4.1.1)</dd> <dd>Base64-encoded (as defined in <xref target="RFC4648" sectionFormat=" of" section="4"/>) version of a CertificateEntry as defined in <xref target="RFC 8446" sectionFormat="of" section="4.4.2"/>. The CertificateEntry <bcp14>MUST</bc p14> contain a DelegatedCredential structure (as defined in <xref target="RFC934 5"/>) using the extension in the CertificateEntry of its end-entity certificate (see <xref target="RFC9345" sectionFormat="of" section="4.1.1"/>).</dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd>string</dd> <dd>string</dd>
<dt>Mandatory-to-Specify:</dt> <dt>Mandatory-to-Specify:</dt>
<dd>Yes</dd> <dd>Yes</dd>
</dl> </dl>
</dd> <dl newline="false" spacing="compact">
</dl> <dt>Property: </dt>
<dd>private-key</dd>
<dl>
<dt>Property: </dt>
<dd>private-key
<dl>
<dt>Description:</dt> <dt>Description:</dt>
<dd>Encrypted private key corresponding to the public key contained in t he DelegatedCredential. The envelope format for this property is JWE <xref targe t="RFC7516"/> using the base64 compact serialization (Section 7.1 of <xref targe t="RFC7516"/>).</dd> <dd>Encrypted private key corresponding to the public key contained in t he DelegatedCredential. The envelope format for this property is JSON Web Encryp tion (JWE) <xref target="RFC7516"/> using the base64 compact serialization (<xre f target="RFC7516" sectionFormat="of" section="7.1"/>).</dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd>string</dd> <dd>string</dd>
<dt>Mandatory-to-Specify:</dt> <dt>Mandatory-to-Specify:</dt>
<dd>No</dd> <dd>No</dd>
</dl> </dl>
</dd> <t>
</dl>
</t>
<t>
The private-key property is not mandatory. If not specified, it is assumed that the dCDN generated the public-private key pair for the delegated credential itse lf and provided The private-key property is not mandatory. If not specified, it is assumed that the dCDN generated the public-private key pair for the delegated credential itse lf and provided
the public key information with an out-of-band mechanism to the uCDN. the public key information with an out-of-band mechanism to the uCDN.
See <xref target="security" /> for constraints regarding the usage of the privat e key. See <xref target="security"/> for constraints regarding the usage of the private key.
</t> </t>
<t>
<t> If the private-key property is used, the transported private key <bcp14>MUST</bc
If the private-key property is used, the transported private key MUST be encrypt p14> be encrypted using the PrivateKeyEncryptionKey specified in FCI.DelegatedCr
ed using the PrivateKeyEncryptionKey specified in FCI.DelegatedCredentials. edentials.
The envelope format for this property MUST use JWE <xref target="RFC7516"/> usin The envelope format for this property <bcp14>MUST</bcp14> use JWE <xref target="
g the base64 compact serialization (Section 7.1 of <xref target="RFC7516"/>), wh RFC7516"/> using the base64 compact serialization (<xref target="RFC7516" sectio
ereas the private key is included as JWE Ciphertext in the JWE. nFormat="of" section="7.1"/>), whereas the private key is included as JWE Cipher
The JWE content-type field MAY be used signal the media type of the encrypted ke text in the JWE.
y. The JWE content-type field <bcp14>MAY</bcp14> be used to signal the media type o
f the encrypted key.
</t> </t>
<t>
<t> Below, please see an example of an MI.DelegatedCredentials object.
Below, please see an example MI.DelegatedCredential Object.
</t> </t>
<figure><artwork align="left"> <sourcecode><![CDATA[
{ {
"generic-metadata-type": "MI.DelegatedCredentials", "generic-metadata-type": "MI.DelegatedCredentials",
"generic-metadata-value": { "generic-metadata-value": {
"delegated-credentials": [ "delegated-credentials": [
{"delegated-credential": {"delegated-credential":
"cBBfm8KK6pPz/tdgKyedwA... "cBBfm8KK6pPz/tdgKyedwA...
iXCCIAmzMM0R8FLI3Ba0UQ=="}, iXCCIAmzMM0R8FLI3Ba0UQ=="},
{"delegated-credential": {"delegated-credential":
"4pyIGtjFdys1+9y/4sS/Fg... "4pyIGtjFdys1+9y/4sS/Fg...
J+h9lnRY/xgmi65RLGKoRw=="}, J+h9lnRY/xgmi65RLGKoRw=="},
{"delegated-credential": {"delegated-credential":
"6PWFO0g2AXvUaULXLObcVA... "6PWFO0g2AXvUaULXLObcVA...
HXoldT/qaYCCNEyCc8JM2A=="} HXoldT/qaYCCNEyCc8JM2A=="}
] ]
} }
} }
</artwork></figure> ]]></sourcecode>
</section> </section>
<section anchor="callflow">
<section anchor="callflow" title="Delegated credentials call flow"> <name>Delegated Credentials Call Flow</name>
<t>An example call-flow using delegated credentials is depicted in <t>An example call-flow using delegated credentials is depicted in
Figure 1.</t> <xref target="call-flow"/>. The steps are as follows.</t>
<ol type="1">
<t> <li>It is assumed that the uCDN has been provisioned and configured
1. It is assumed that the uCDN has been provisioned and configured with a certificate.
with a certificate. Note that it is out of scope of CDNI and the Note that it is out of scope of CDNI and the
present document how and from where (e.g., CSP) the uCDN acquired present document how and from where (e.g., which Content
its certificate. Service Provider) the uCDN acquired its certificate.
</t> </li>
<li>The uCDN generates a set of delegated credentials
<t>
2. The uCDN generates a set of delegated credentials
(here it is assumed that public keys of the dCDN are known). (here it is assumed that public keys of the dCDN are known).
Note that the uCDN may generate this material at different points in time, e.g., in advance to have a pool of delegated Note that the uCDN may generate this material at different points in time, e.g., in advance to have a pool of delegated
credentials or on-demand when the dCDN announces its maximum number of supported credentials or on demand when the dCDN announces its maximum number of supported
delegated credentials. delegated credentials.
</t> </li>
<li>Using the CDNI FCI <xref target="RFC8008"/>, the
<t>
3. Using the CDNI FCI <xref target="RFC8008"/>, the
dCDN advertises MI.DelegatedCredentials capabilities to the uCDN. dCDN advertises MI.DelegatedCredentials capabilities to the uCDN.
The dCDN further uses FCI.DelegatedCredentials to advertise the maximum number The dCDN further uses FCI.DelegatedCredentials to advertise the maximum number
of supported delegated credentials. of supported delegated credentials.
</t> </li>
<li>Using the CDNI MI <xref target="RFC8006"/>, the dCDN acquires
<t>
4. Using the CDNI MI <xref target="RFC8006"/>, the dCDN acquires
the MI.DelegatedCredentials, retrieving an array of delegated the MI.DelegatedCredentials, retrieving an array of delegated
credentials. credentials.
</t> </li>
<li>The client establishes a TLS connection with an endpoint of
<t>
5. The client establishes a TLS connection with an endpoint of
the dCDN according to <xref target="RFC9345"/> using the delegated the dCDN according to <xref target="RFC9345"/> using the delegated
credentials retrieved in step 4. credentials retrieved in step 4.
</t> </li>
<li>When some delegated credentials are about to expire, the uCDN uses the CDNI
<t> MI <xref target="RFC8006"/> to provide new, valid delegated credentials.
6. When some delegated credentials are about to expire, the uCDN uses the CDNI M </li>
I <xref target="RFC8006"/> to provide new, valid delegated credentials. </ol>
</t>
<figure title="Example call-flow of Delegated credentials in CDNI"><artwork alig <figure anchor="call-flow">
n="center"> <name>Example Call Flow of Delegated Credentials in CDNI</name>
<artwork align="center"><![CDATA[
User-Agent dCDN uCDN User-Agent dCDN uCDN
| | | | | |
| | [1.uCDN acquires its certificate | | [1. uCDN acquires its certificate
| | out of scope of CDNI] | | out of scope of CDNI]
| | | | | |
| | [2.generation of | | [2. generation of
| | delegated credentials] | | delegated credentials]
| | | | | |
| 3. CDNI FCI used to | 3. CDNI FCI used to
| advertise support of MI.DelegatedCredentials | advertise support of MI.DelegatedCredentials
| and announce number of delegated credentials | and announce number of delegated credentials
| supported using FCI.DelegatedCredentials | supported using FCI.DelegatedCredentials
| |-------------------->+ | |-------------------->+
| | | | | |
| 4. CDNI MI used to | 4. CDNI MI used to
| provide the MI.DelegatedCredential object | provide the MI.DelegatedCredentials object
| |&lt;--------------------+ | |<--------------------+
| | | | | |
. .
. .
. .
[5. TLS handshake according | [5. TLS handshake according |
to [RFC9345]] . | to [RFC9345]] . |
|&lt;------------------->| | |<------------------->| |
| | | | | |
. .
. .
. .
| 6.Some delegated credentials about to expire. | 6. Some delegated credentials about to expire.
| CDNI MI used to | CDNI MI used to
| provide new MI.DelegatedCredential object | provide new MI.DelegatedCredentials object
| |&lt;--------------------+ | |<--------------------+
| | | | | |
</artwork></figure> ]]></artwork>
</figure>
</section> </section>
<section anchor="iana">
<section anchor="iana" title="IANA Considerations"> <name>IANA Considerations</name>
<t> <t>
This document requests IANA registration of the following entries IANA has registered the following payload types in the "CDNI Payload Types"
under the "CDNI Payload Types" registry hosted by IANA regarding registry in the "Content Delivery Network Interconnection (CDNI) Parameters"
"CDNI delegation": registry group.
</t> </t>
<table> <table>
<tbody> <thead>
<tr> <tr>
<td>Payload Type</td> <th>Payload Type</th>
<td>Specification</td> <th>Specification</th>
</tr> </tr>
<tr> </thead>
<td>MI.DelegatedCredentials</td> <tbody>
<td>RFCthis</td> <tr>
</tr> <td>MI.DelegatedCredentials</td>
<tr> <td>RFC 9677</td>
<td>FCI.DelegatedCredentials</td> </tr>
<td>RFCthis</td> <tr>
</tr> <td>FCI.DelegatedCredentials</td>
</tbody> <td>RFC 9677</td>
</table> </tr>
</tbody>
<t> </table>
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
</t>
<t> <t>
The <xref target="iana_MI" /> and <xref target="iana_FCI" /> below provide addit Sections <xref target="iana_MI" format="counter"/> and <xref target="iana_FCI"
ional necessary information for the IANA registration of CDNI payload-types para format="counter"/> provide additional necessary information for the
meters (see <xref target="RFC7736"/> Section 2.2). registration of those CDNI payload types (see <xref target="RFC7736"
sectionFormat="of" section="2.2"/>).
</t> </t>
<section anchor="iana_MI">
<section anchor="iana_MI" title="CDNI MI DelegatedCredentials Payload Type"> <name>CDNI MI.DelegatedCredentials Payload Type</name>
<t> <dl>
<dl> <dt>Purpose:</dt>
<dt>Purpose:</dt> <dd>The purpose of this payload type is to distinguish delegated
<dd>The purpose of this Payload Type is to distinguish delegated credentials MI objects.
credentials MI Objects
</dd> </dd>
<dt>Interface:</dt> <dt>Interface:</dt>
<dd>MI/FCI</dd> <dd>MI/FCI</dd>
<dt>Encoding:</dt> <dt>Encoding:</dt>
<dd>see <xref target="MI" /></dd> <dd>See <xref target="MI"/>.</dd>
</dl> </dl>
</t> </section>
</section> <section anchor="iana_FCI">
<name>CDNI FCI.DelegatedCredentials Payload Type</name>
<section anchor="iana_FCI" title="CDNI FCI DelegatedCredentials Payload Type"> <dl>
<t> <dt>Purpose:</dt>
<dl> <dd>The purpose of this payload type is to advertise the number
<dt>Purpose:</dt>
<dd>The purpose of this Payload Type is to advertise the number
of delegated credentials needed (and any associated capability of delegated credentials needed (and any associated capability
advertisement) advertisement).
</dd> </dd>
<dt>Interface:</dt> <dt>Interface:</dt>
<dd>FCI</dd> <dd>FCI</dd>
<dt>Encoding:</dt> <dt>Encoding:</dt>
<dd>see <xref target="FCI_DelegatedCredentials" /></dd> <dd>See <xref target="FCI_DelegatedCredentials"/>.</dd>
</dl> </dl>
</t> </section>
</section> </section>
<section anchor="security">
</section> <name>Security Considerations</name>
<t>
<section anchor="security" title="Security Considerations">
<t>
The extensions defined enable providing delegated credentials to dCDNs. The extensions defined enable providing delegated credentials to dCDNs.
A delegated credential can only be used by a dCDN if it is in possession of the associated private key. A delegated credential can only be used by a dCDN if it is in possession of the associated private key.
Similarly, an attacker requires access to the private key in order to exploit de legated credential and impersonate dCDN nodes. Similarly, an attacker requires access to the private key in order to exploit a delegated credential and impersonate dCDN nodes.
Thus, leakage of only the delegated credential without the private key represent s a limited security risk. Thus, leakage of only the delegated credential without the private key represent s a limited security risk.
</t> </t>
<t>
<t> Delegated credentials and associated private keys are short-lived (per default,
Delegated credentials and associated private keys are short-lived (per default t the maximum validity period is set to 7 days in <xref target="RFC9345"/>) and as
he maximum validity period set to 7 days in <xref target="RFC9345"/>) and as suc such a single leaked delegated credential with its private key represents a lim
h a single leaked delegated credential with its private key represents a limited ited security risk.
security risk. Still, it is <bcp14>NOT RECOMMENDED</bcp14> to send private keys through the MI.
Still, it is NOT RECOMMENDED to send private keys through the MI. Omitting the p Omitting the private key further limits the possible ways an attacker could expl
rivate key further limits the possibility exploits by an attacker to exploit the oits the delegated credential.
delegated credential.
</t> </t>
<t>
<t> If this recommendation is not followed, i.e., the private key is communicated vi
If despite this recommendation, the private key is communicated via the MI, the a the MI, the transported private key <bcp14>MUST</bcp14> be encrypted within a
transported private key MUST be encrypted within a JWE envelope using the encryp JWE envelope using the encryption key (PrivateKeyEncryptionKey) provided within
tion key (PrivateKeyEncryptionKey) provided within the FCI.DelegatedCredentials the FCI.DelegatedCredentials by the dCDN.
by the dCDN. The JWE encryption key (PrivateKeyEncryptionKey) <bcp14>MUST</bcp14> have a stre
The JWE encryption key (PrivateKeyEncryptionKey) MUST have a strength equal or l ngth equal to or larger than the private key it is encrypting for transport.
arger than the private key it is encrypting for transport.
Note that the specified encryption method does not offer forward secrecy. If the dCDN's encryption key becomes compromised in the future, then all encrypted JWE s will become compromised. Due to the short-lived nature of delegated credential s, the impact is limited. Note that the specified encryption method does not offer forward secrecy. If the dCDN's encryption key becomes compromised in the future, then all encrypted JWE s will become compromised. Due to the short-lived nature of delegated credential s, the impact is limited.
</t> </t>
<t>
<t>
It is also important to ensure that an attacker is not able to systematically re trieve a consecutive or consistent set of delegated credentials and associated p rivate keys. It is also important to ensure that an attacker is not able to systematically re trieve a consecutive or consistent set of delegated credentials and associated p rivate keys.
Such an attack would allow the attacker to systematically impersonate dCDN nodes . Such an attack would allow the attacker to systematically impersonate dCDN nodes .
The MI objects defined in the present document are transferred via the interface s defined in CDNI <xref target="RFC8006"/>. The MI objects defined in the present document are transferred via the interface s defined in CDNI <xref target="RFC8006"/>.
<xref target="RFC8006"/> describes how to secure these interfaces, protecting th <xref target="RFC8006"/> describes how to secure these interfaces, protecting th
e integrity, confidentiality and ensuring the e integrity and confidentiality, as well as ensuring the
authenticity of the dCDN and uCDN, which should prevent an attacker to systemati authenticity of the dCDN and uCDN, which should prevent an attacker from systema
cally retrieve delegated credential and associated private keys. tically retrieving delegated credentials and associated private keys.
</t> </t>
</section>
<section anchor="privacy">
<name>Privacy Considerations</name>
</section> <t>
The FCI and MI objects and the information defined in the present document do no
<section anchor="privacy" title="Privacy Considerations"> t contain any personally identifiable information (PII).
<t> As such, this document does not change or alter the confidentiality and
The information, FCI, and MI objects defined in the present document do not cont privacy considerations outlined in <xref target="RFC8006" section="8.2"/> and
ain any personally identifiable information (PII). <xref target="RFC8008" section="7"/>.
As such this document does not change or alter the Confidentiality and Privacy C </t>
onsideration outlined in the CDNI Metadata and Footprint and Capabilities RFCs < <t>
xref target="RFC8006"/>.</t>
<t>
A single or systematic retrieval of delegated credentials and associated private keys would allow the attacker to decrypt any data sent by the end user intended for the end service, which may include PII.</t> A single or systematic retrieval of delegated credentials and associated private keys would allow the attacker to decrypt any data sent by the end user intended for the end service, which may include PII.</t>
</section> </section>
</middle>
</middle> <back>
<references>
<back> <name>References</name>
<references>
<references title="Normative References"> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<reference anchor="RFC7516" target="https://www.rfc-editor.org/info/rfc7516" 516.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 517.xml"/>
<title>JSON Web Encryption (JWE)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="M. Jones" initials="M." surname="Jones"/> 006.xml"/>
<author fullname="J. Hildebrand" initials="J." surname="Hildebrand"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="May" year="2015"/> 008.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>JSON Web Encryption (JWE) represents encrypted content using JSON-bas 446.xml"/>
ed data structures. Cryptographic algorithms and identifiers for use with this s <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
pecification are described in the separate JSON Web Algorithms (JWA) specificati 345.xml"/>
on and IANA registries defined by that specification. Related digital signature <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
and Message Authentication Code (MAC) capabilities are described in the separate 119.xml"/>
JSON Web Signature (JWS) specification.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 174.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<seriesInfo name="RFC" value="7516"/> 648.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC7516"/> </references>
</reference> <references>
<name>Informative References</name>
<reference anchor="RFC7517" target="https://www.rfc-editor.org/info/rfc7517" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
> 336.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<title>JSON Web Key (JWK)</title> 337.xml"/>
<author fullname="M. Jones" initials="M." surname="Jones"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="May" year="2015"/> 736.xml"/>
<abstract> </references>
<t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data stru </references>
cture that represents a cryptographic key. This specification also defines a JWK </back>
Set JSON data structure that represents a set of JWKs. Cryptographic algorithms
and identifiers for use with this specification are described in the separate J
SON Web Algorithms (JWA) specification and IANA registries established by that s
pecification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7517"/>
<seriesInfo name="DOI" value="10.17487/RFC7517"/>
</reference>
<reference anchor="RFC8006" target="https://www.rfc-editor.org/info/rfc8006"
>
<front>
<title>Content Delivery Network Interconnection (CDNI) Metadata</title>
<author fullname="B. Niven-Jenkins" initials="B." surname="Niven-Jenkins
"/>
<author fullname="R. Murray" initials="R." surname="Murray"/>
<author fullname="M. Caulfield" initials="M." surname="Caulfield"/>
<author fullname="K. Ma" initials="K." surname="Ma"/>
<date month="December" year="2016"/>
<abstract>
<t>The Content Delivery Network Interconnection (CDNI) Metadata interfac
e enables interconnected Content Delivery Networks (CDNs) to exchange content di
stribution metadata in order to enable content acquisition and delivery. The CD
NI Metadata associated with a piece of content provides a downstream CDN with su
fficient information for the downstream CDN to service content requests on behal
f of an upstream CDN. This document describes both a base set of CDNI Metadata
and the protocol for exchanging that metadata.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8006"/>
<seriesInfo name="DOI" value="10.17487/RFC8006"/>
</reference>
<reference anchor="RFC8008" target="https://www.rfc-editor.org/info/rfc8008"
>
<front>
<title>Content Delivery Network Interconnection (CDNI) Request Routing:
Footprint and Capabilities Semantics</title>
<author fullname="J. Seedorf" initials="J." surname="Seedorf"/>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="S. Previdi" initials="S." surname="Previdi"/>
<author fullname="R. van Brandenburg" initials="R." surname="van Branden
burg"/>
<author fullname="K. Ma" initials="K." surname="Ma"/>
<date month="December" year="2016"/>
<abstract>
<t>&lt;p&gt;This document captures the semantics of the "Footprint and C
apabilities 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 &amp; Capabilities Adv
ertisement interface (FCI)" offers within CDNI. The document also provides guid
elines for the CDNI FCI protocol. It further defines a Base Advertisement Objec
t, the necessary registries for capabilities and footprints, and guidelines on h
ow these registries can be extended in the future.&lt;/p&gt;</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8008"/>
<seriesInfo name="DOI" value="10.17487/RFC8008"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446"
>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Security (
TLS) protocol. TLS allows client/server applications to communicate over the Int
ernet in a way that is designed to prevent eavesdropping, tampering, and message
forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 52
46, and 6961. This document also specifies new requirements for TLS 1.2 implemen
tations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9345" target="https://www.rfc-editor.org/info/rfc9345"
>
<front>
<title>Delegated Credentials for TLS and DTLS</title>
<author fullname="R. Barnes" initials="R." surname="Barnes"/>
<author fullname="S. Iyengar" initials="S." surname="Iyengar"/>
<author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="July" year="2023"/>
<abstract>
<t>The organizational separation between operators of TLS and DTLS endpo
ints and the certification authority can create limitations. For example, the li
fetime of certificates, how they may be used, and the algorithms they support ar
e ultimately determined by the Certification Authority (CA). This document descr
ibes a mechanism to overcome some of these limitations by enabling operators to
delegate their own credentials for use in TLS and DTLS without breaking compatib
ility with peers that do not support this specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9345"/>
<seriesInfo name="DOI" value="10.17487/RFC9345"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"
>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify t
he requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents. T
his document specifies an Internet Best Current Practices for the Internet Commu
nity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174"
>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol spec
ifications. This document aims to reduce the ambiguity by clarifying that only U
PPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648"
>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="October" year="2006"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and base
16 encoding schemes. It also discusses the use of line-feeds in encoded data, us
e of padding in encoded data, use of non-alphabet characters in encoded data, us
e of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC7336" target="https://www.rfc-editor.org/info/rfc7336"
>
<front>
<title>Framework for Content Distribution Network Interconnection (CDNI)
</title>
<author fullname="L. Peterson" initials="L." surname="Peterson"/>
<author fullname="B. Davie" initials="B." surname="Davie"/>
<author fullname="R. van Brandenburg" initials="R." role="editor" surnam
e="van Brandenburg"/>
<date month="August" year="2014"/>
<abstract>
<t>This document presents a framework for Content Distribution Network I
nterconnection (CDNI). The purpose of the framework is to provide an overall pi
cture of the problem space of CDNI and to describe the relationships among the v
arious components necessary to interconnect CDNs. CDNI requires the specificati
on of interfaces and mechanisms to address issues such as request routing, distr
ibution metadata exchange, and logging information exchange across CDNs. The in
tent of this document is to outline what each interface needs to accomplish and
to describe how these interfaces and mechanisms fit together, while leaving thei
r detailed specification to other documents. This document, in combination with
RFC 6707, obsoletes RFC 3466.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7336"/>
<seriesInfo name="DOI" value="10.17487/RFC7336"/>
</reference>
<reference anchor="RFC7337" target="https://www.rfc-editor.org/info/rfc7337"
>
<front>
<title>Content Distribution Network Interconnection (CDNI) Requirements<
/title>
<author fullname="K. Leung" initials="K." role="editor" surname="Leung"/
>
<author fullname="Y. Lee" initials="Y." role="editor" surname="Lee"/>
<date month="August" year="2014"/>
<abstract>
<t>Content delivery is frequently provided by specifically architected a
nd provisioned Content Delivery Networks (CDNs). As a result of significant grow
th in content delivered over IP networks, existing CDN providers are scaling up
their infrastructure. Many Network Service Providers (NSPs) and Enterprise Servi
ce Providers (ESPs) are also deploying their own CDNs. To deliver contents from
the Content Service Provider (CSP) to end users, the contents may traverse acros
s multiple CDNs. This creates a need for interconnecting (previously) standalone
CDNs so that they can collectively act as a single delivery platform from the C
SP to the end users.</t>
<t>The goal of the present document is to outline the requirements for t
he solution and interfaces to be specified by the CDNI working group.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7337"/>
<seriesInfo name="DOI" value="10.17487/RFC7337"/>
</reference>
<reference anchor="RFC7736" target="https://www.rfc-editor.org/info/rfc7736"
>
<front>
<title>Content Delivery Network Interconnection (CDNI) Media Type Regist
ration</title>
<author fullname="K. Ma" initials="K." surname="Ma"/>
<date month="December" year="2015"/>
<abstract>
<t>This document defines the standard media type used by the Content Del
ivery Network Interconnection (CDNI) protocol suite, including the registration
procedure and recommended usage of the required payload- type parameter.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7736"/>
<seriesInfo name="DOI" value="10.17487/RFC7736"/>
</reference>
</references>
</back>
</rfc> </rfc>
 End of changes. 66 change blocks. 
670 lines changed or deleted 382 lines changed or added

This html diff was produced by rfcdiff 1.48.