rfc9538.original.xml   rfc9538.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.4 (Ruby 3.2.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
) --> ipr="trust200902"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft number="9538"
-ietf-cdni-delegation-acme-04" category="std" consensus="true" submissionType="I docName="draft-ietf-cdni-delegation-acme-04"
ETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"> category="std"
consensus="true"
submissionType="IETF"
tocInclude="true"
obsoletes=""
updates=""
sortRefs="true"
symRefs="true"
xml:lang="en"
version="3">
<!-- xml2rfc v2v3 conversion 3.18.2 --> <!-- xml2rfc v2v3 conversion 3.18.2 -->
<front> <front>
<title abbrev="CDNI delegation using ACME">CDNI delegation using Automated C <title abbrev="CDNI Delegation Using ACME">Content Delivery Network Intercon
ertificate Management Environment</title> nection (CDNI) Delegation Using the Automated Certificate Management Environment
<seriesInfo name="Internet-Draft" value="draft-ietf-cdni-delegation-acme-04" </title>
/> <seriesInfo name="RFC" value="9538"/>
<author initials="F." surname="Fieau" fullname="Frédéric Fieau" role="editor "> <author initials="F." surname="Fieau" fullname="Frédéric Fieau" role="editor ">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street>40-48, avenue de la Republique</street> <street>40-48, avenue de la République</street>
<city>Chatillon</city> <city>Châtillon</city>
<code>92320</code> <code>92320</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>frederic.fieau@orange.com</email> <email>frederic.fieau@orange.com</email>
</address> </address>
</author> </author>
<author initials="E." surname="Stephan" fullname="Emile Stephan"> <author initials="E." surname="Stephan" fullname="Emile Stephan">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
skipping to change at line 45 skipping to change at line 59
</postal> </postal>
<email>emile.stephan@orange.com</email> <email>emile.stephan@orange.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Mishra" fullname="Sanjay Mishra"> <author initials="S." surname="Mishra" fullname="Sanjay Mishra">
<organization>Verizon</organization> <organization>Verizon</organization>
<address> <address>
<postal> <postal>
<street>13100 Columbia Pike</street> <street>13100 Columbia Pike</street>
<city>Silver Spring</city> <city>Silver Spring</city>
<code>MD 20904</code> <region>MD</region><code>20904</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>sanjay.mishra@verizon.com</email> <email>sanjay.mishra@verizon.com</email>
</address> </address>
</author> </author>
<date year="2023" month="December" day="07"/>
<area>Applications and Real-Time</area> <date year="2024" month="February"/>
<workgroup>Content Delivery Networks Interconnection</workgroup>
<area>art</area>
<workgroup>cdni</workgroup>
<keyword>HTTPS</keyword> <keyword>HTTPS</keyword>
<keyword>delegation</keyword> <keyword>delegation</keyword>
<keyword>ACME</keyword> <keyword>ACME</keyword>
<keyword>STAR</keyword> <keyword>STAR</keyword>
<abstract>
<?line 64?>
<t>This document defines metadata to support delegating the delivery of <abstract><t>This document defines metadata to support delegating the
HTTPS content between two or more interconnected Content Delivery Networks (CDNs delivery of HTTPS content between two or more interconnected Content
). Specifically, this Delivery Networks (CDNs). Specifically, this document defines a Content
document defines a Content Delivery Network Interconnection (CDNI) Metadata inte Delivery Network Interconnection (CDNI) Metadata interface object to
rface object to enable delegation of enable delegation of X.509 certificates leveraging delegation schemes
X.509 certificates leveraging delegation schemes defined in defined in RFC 9115. Per RFC 9115, delegating entities can remain in full c
RFC9115. RFC9115 allows delegating entities to remain in full ontrol of the delegation and can revoke it at any time. This avoids the need to
control of the delegation and be able to revoke it any time and this avoids share private cryptographic key material between the involved entities.</t>
the need to share private cryptographic key material between the involved entiti
es.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-cdni-delegation-acme/"/>.
</t>
<t>
Discussion of this document takes place on the
Content Delivery Networks Interconnection Working Group mailing list (<e
ref target="mailto:cdni@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/cdni/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/cdni/"/
>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/FredericFi/cdni-wg"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 74?>
<section anchor="introduction"> <section anchor="introduction">
<name> Introduction</name> <name>Introduction</name>
<t>Content delivery over HTTPS using two or more cooperating CDNs along th e path requires <t>Content delivery over HTTPS using two or more cooperating CDNs along th e path requires
credential management, specifically when DNS-based redirection is used. In such cases, an upstream CDN (uCDN) needs to delegate its credentials to a downstream (dCDN) for content delivery.</t> credential management, specifically when DNS-based redirection is used. In such cases, an upstream CDN (uCDN) needs to delegate its credentials to a downstream CDN (dCDN) for content delivery.</t>
<t><xref target="RFC9115"/> defines delegation methods that allow a uCDN o n behalf of the content provider, the holder of the domain, to generate on-deman d an X.509 <t><xref target="RFC9115"/> defines delegation methods that allow a uCDN o n behalf of the content provider, the holder of the domain, to generate on-deman d an X.509
certificate that binds the designated domain name with a key-pair owned by the d certificate that binds the designated domain name with a key pair owned by the d
CDN. For further details, please refer CDN. For further details, please refer
to <xref section="1" sectionFormat="of" target="RFC9115"/> and <xref section="5. to Sections <xref section="1" sectionFormat="bare" target="RFC9115"/> and <xref
1.2.1" sectionFormat="of" target="RFC9115"/>.</t> section="5.1.2.1" sectionFormat="bare" target="RFC9115"/> of <xref target="RFC91
15"/>.</t>
<t>This document defines CDNI Metadata to make use of HTTPS delegation bet ween a <t>This document defines CDNI Metadata to make use of HTTPS delegation bet ween a
uCDN and a dCDN based on the mechanism specified in <xref target="RFC9115"/>. F urthermore, uCDN and a dCDN based on the mechanism specified in <xref target="RFC9115"/>. F urthermore,
it adds a delegation method to the "CDNI Payload Types" IANA registry.</t> it adds a delegation method to the "CDNI Payload Types" IANA registry.</t>
<t><xref target="fci-metadata"/> presents delegation metadata for the Foot print &amp; Capabilities Advertisement interface (FCI). <xref target="mi-metada ta"/> addresses the metadata for handling HTTPS delegation with the Metadata Int erface.</t> <t><xref target="fci-metadata"/> presents delegation metadata for the Foot print &amp; Capabilities Advertisement interface (FCI). <xref target="mi-metada ta"/> addresses the metadata for handling HTTPS delegation with the Metadata int erface.</t>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>This document uses terminology from CDNI framework documents such as: CDNI <t>This document uses terminology from CDNI framework documents such as: CDNI
framework document <xref target="RFC7336"/> and CDNI framework document <xref target="RFC7336"/> and CDNI
interface specifications documents: CDNI Metadata interface <xref target="RFC800 6"/> and interface specifications documents: CDNI Metadata interface <xref target="RFC800 6"/> and
CDNI Footprint and Capabilities Advertisement interface <xref target="RFC8008"/> . It also uses terminology from CDNI Footprint and Capabilities Advertisement interface <xref target="RFC8008"/> . It also uses terminology from
<xref section="1.2" sectionFormat="of" target="RFC8739"/> and <xref section="1.1 <xref section="1.2" sectionFormat="of" target="RFC8739"/> and <xref section="1.1
" sectionFormat="of" target="RFC9115"/>.</t> " sectionFormat="of" target="RFC9115"/>, including Short-Term, Automatically Ren
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL ewed (STAR), as applied to X.509 certificates.</t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
only when, they NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
<?line -6?>
</t> </t>
</section> </section>
</section> </section>
<section anchor="fci-metadata"> <section anchor="fci-metadata">
<name>Advertising Delegation Metadata for CDNI through FCI</name> <name>Advertising Delegation Metadata for CDNI through FCI</name>
<t>The Footprint and Capabilities Advertisement interface (FCI) defined in <xref target="RFC8008"/> allows a <t>The Footprint &amp; Capabilities Advertisement interface (FCI) defined in <xref target="RFC8008"/> allows a
dCDN to send a FCI capability type object to a uCDN.</t> dCDN to send a FCI capability type object to a uCDN.</t>
<t>This document uses the CDNI Metadata capability object serialization fr om <xref target="RFC8008"/> for a CDN that supports <t>This document uses the CDNI Metadata capability object serialization fr om <xref target="RFC8008"/> for a CDN that supports
delegation methods.</t> delegation methods.</t>
<t>The following is an example of the supported delegated methods capabili ty <t>The following is an example of the supported delegated methods capabili ty
object for a dCDN implementing the ACME delegation method.</t> object for a dCDN implementing the ACME delegation method.</t>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.Metadata", "capability-type": "FCI.Metadata",
skipping to change at line 142 skipping to change at line 142
}, },
"footprints": [ "footprints": [
"Footprint objects" "Footprint objects"
] ]
} }
] ]
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="mi-metadata"> <section anchor="mi-metadata">
<name> ACME Delegation Metadata for CDNI</name> <name>ACME Delegation Metadata for CDNI</name>
<t>When a uCDN delegates the delivery of HTTPS traffic to a dCDN using DNS <t>When a uCDN delegates the delivery of HTTPS traffic to a dCDN using DNS
Redirection redirection
<xref target="RFC7336"/>, the dCDN must use a certificate bound to the origin's name to <xref target="RFC7336"/>, the dCDN must use a certificate bound to the origin's name to
successfully authenticate to the end-user (see also <xref section="5.1.2.1" sect ionFormat="of" target="RFC9115"/>).</t> successfully authenticate to the end-user (see also <xref section="5.1.2.1" sect ionFormat="of" target="RFC9115"/>).</t>
<t>To that end, this section defines the AcmeDelegationMethod object which <t>To that end, this section defines the AcmeDelegationMethod object, whic h
describes metadata for using the ACME delegation interface <xref target="RFC9115 "/>.</t> describes metadata for using the ACME delegation interface <xref target="RFC9115 "/>.</t>
<t>The ACMEDelegationMethod applies to both ACME STAR delegation, which pr ovides a <t>The ACMEDelegationMethod applies to both ACME STAR delegation, which pr ovides a
delegation model based on short-term certificates with automatic renewal (<xref section="2.3.2" sectionFormat="of" target="RFC9115"/>), and delegation model based on short-term certificates with automatic renewal (<xref section="2.3.2" sectionFormat="of" target="RFC9115"/>), and
non-STAR delegation, which allows delegation between CDNs using long-term non-STAR delegation, which allows delegation between CDNs using long-term
certificates (<xref section="2.3.3" sectionFormat="of" target="RFC9115"/>).</t> certificates (<xref section="2.3.3" sectionFormat="of" target="RFC9115"/>).</t>
<t><xref target="fig-call-flow"/> provides a high-level view of the combin ed CDNI and ACME <t><xref target="fig-call-flow"/> provides a high-level view of the combin ed CDNI and ACME
delegation message flows to obtain STAR certificate from the Certificate Authori ty (CA) bound to the Content Provider's (CP) name.</t> delegation message flows to obtain a STAR certificate from the Certification Aut hority (CA) bound to the Content Provider's (CP) name.</t>
<figure anchor="fig-call-flow"> <figure anchor="fig-call-flow">
<name>Example call-flow of STAR delegation in CDNI showing 2 levels of d elegation</name> <name>Example Call Flow of STAR Delegation in CDNI Showing Two Levels of Delegation</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="656" width="584" viewBox="0 0 584 656" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" viewBox="0 0 584 656" class="diagram" text-anchor="middle" fo nt-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,64" fill="none" stroke="black"/> <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
<path d="M 24,64 L 24,640" fill="none" stroke="black"/> <path d="M 24,64 L 24,640" fill="none" stroke="black"/>
<path d="M 48,32 L 48,64" fill="none" stroke="black"/> <path d="M 48,32 L 48,64" fill="none" stroke="black"/>
<path d="M 64,272 L 64,288" fill="none" stroke="black"/> <path d="M 64,272 L 64,288" fill="none" stroke="black"/>
<path d="M 64,352 L 64,368" fill="none" stroke="black"/> <path d="M 64,352 L 64,368" fill="none" stroke="black"/>
<path d="M 184,32 L 184,64" fill="none" stroke="black"/> <path d="M 184,32 L 184,64" fill="none" stroke="black"/>
<path d="M 200,64 L 200,544" fill="none" stroke="black"/> <path d="M 200,64 L 200,544" fill="none" stroke="black"/>
<path d="M 224,32 L 224,64" fill="none" stroke="black"/> <path d="M 224,32 L 224,64" fill="none" stroke="black"/>
<path d="M 352,32 L 352,64" fill="none" stroke="black"/> <path d="M 352,32 L 352,64" fill="none" stroke="black"/>
<path d="M 376,64 L 376,544" fill="none" stroke="black"/> <path d="M 376,64 L 376,544" fill="none" stroke="black"/>
skipping to change at line 331 skipping to change at line 331
| | | |
| (unauthenticated) GET star-certificate | | (unauthenticated) GET star-certificate |
+----------------------------------------------------------------->| +----------------------------------------------------------------->|
| certificate #1 | | certificate #1 |
|<-----------------------------------------------------------------+ |<-----------------------------------------------------------------+
| ... | | ... |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<aside> <aside>
<t>Note: The delegation object defined in <xref section="2.3.1.3" sectio
nFormat="of" target="RFC9115"/> only allows to specify DNS mappings using CNAME <t>Note: The delegation object defined in <xref section="2.3.1.3" sectio
RRs. A future document updating <xref target="RFC9115"/> could expand the deleg nFormat="of" target="RFC9115"/> only allows DNS mappings to be specified using C
ation object to also include SVCB/HTTPS-based <xref target="RFC9460"/> mappings. NAME RRs. A future document updating <xref target="RFC9115"/> could expand the
</t> delegation object to also include SVCB/HTTPS-based mappings <xref target="RFC946
0"/>.</t>
</aside> </aside>
<t><xref target="acmedeleobj"/> defines the objects used for bootstrapping the ACME delegation <t><xref target="acmedeleobj"/> defines the objects used for bootstrapping the ACME delegation
method between a uCDN and a delegate dCDN.</t> method between a uCDN and a delegate dCDN.</t>
<section anchor="acmedeleobj"> <section anchor="acmedeleobj">
<name>ACMEDelegationMethod Object</name> <name>ACMEDelegationMethod Object</name>
<t>The ACMEDelegationMethod object allows a uCDN to define both STAR and non-STAR delegation. The dCDN, the consumer of the delegation, can determine th e type of delegation by the presence (or absence) of the "lifetime" property. Th at is, the presence of the "lifetime" property explicitly means a short-term del egation with lifetime of the certificate based on that property (and the optiona l "lifetime-adjust" attribute). A non-STAR delegation will not have the "lifetim e" property in the delegation. See also the examples in <xref target="examples" />.</t> <t>The ACMEDelegationMethod object allows a uCDN to define both STAR and non-STAR delegations. The dCDN, the consumer of the delegation, can determine t he type of delegation by the presence (or absence) of the "lifetime" property. T hat is, the presence of the "lifetime" property explicitly means a short-term de legation with lifetime of the certificate based on that property (and the option al "lifetime-adjust" attribute). A non-STAR delegation will not have the "lifeti me" property in the delegation. See also the examples in <xref target="examples "/>.</t>
<t>The ACMEDelegationMethod object is defined with the properties shown below.</t> <t>The ACMEDelegationMethod object is defined with the properties shown below.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Property: acme-delegation </t> <t>Property: acme-delegation </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Description: a URL pointing at an ACME delegation object, eit her STAR or non-STAR, associated with the dCDN account on the uCDN ACME server ( see <xref section="2.3.1.3" sectionFormat="of" target="RFC9115"/> for the detail s). The URL MUST use the https scheme.</t> <t>Description: A URL pointing at an ACME delegation object, eit her STAR or non-STAR, associated with the dCDN account on the uCDN ACME server ( see <xref section="2.3.1.3" sectionFormat="of" target="RFC9115"/> for the detail s). The URL <bcp14>MUST</bcp14> use the https scheme.</t>
</li> </li>
<li> <li>
<t>Type: String</t> <t>Type: String</t>
</li> </li>
<li> <li>
<t>Mandatory-to-Specify: Yes</t> <t>Mandatory-to-Specify: Yes</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>Property: time-window </t> <t>Property: time-window </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Description: Validity period of the certificate. According to <xref section="4.3.4" sectionFormat="of" target="RFC8006"/>, a TimeWindow objec t is defined by a window "start" time, and a window "end" time. In case of STAR method, the "start" and "end" properties of the window MUST be understood respec tively as the start-date and end-date of the certificate validity. In the case o f the non-STAR method, the "start" and "end" properties of the window MUST be un derstood respectively as the notBefore and notAfter fields of the certificate.</ t> <t>Description: Validity period of the certificate. According to <xref section="4.3.4" sectionFormat="of" target="RFC8006"/>, a TimeWindow objec t is defined by a window "start" time and a window "end" time. In the case of a STAR method, the "start" and "end" properties of the window <bcp14>MUST</bcp14> be understood respectively as the start-date and end-date of the certificate val idity. In the case of a non-STAR method, the "start" and "end" properties of the window <bcp14>MUST</bcp14> be understood, respectively, as the notBefore and no tAfter fields of the certificate.</t>
</li> </li>
<li> <li>
<t>Type: TimeWindow</t> <t>Type: TimeWindow</t>
</li> </li>
<li> <li>
<t>Mandatory-to-Specify: Yes</t> <t>Mandatory-to-Specify: Yes</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
skipping to change at line 433 skipping to change at line 434
"start": 1570982234, "start": 1570982234,
"end": 1665417434 "end": 1665417434
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name> IANA Considerations</name> <name>IANA Considerations</name>
<t>This document requests the registration of the following entry under th <t>Per this document, the following type has been registered in the
e
"CDNI Payload Types" registry:</t> "CDNI Payload Types" registry:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Payload Type</th> <th align="left">Payload Type</th>
<th align="left">Specification</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">MI.ACMEDelegationMethod</td> <td align="left">MI.ACMEDelegationMethod</td>
<td align="left">RFCthis</td> <td align="left">RFC 9538</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t><cref anchor="to-be-removed">RFC Editor: please replace RFCthis with th e RFC number of this RFC and remove this note.</cref></t>
<section anchor="cdni-mi-acmedelegationmethod-payload-type"> <section anchor="cdni-mi-acmedelegationmethod-payload-type">
<name>CDNI MI ACMEDelegationMethod Payload Type</name> <name>CDNI MI ACMEDelegationMethod Payload Type</name>
<dl> <dl>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd> <dd>
<t>The purpose of this Payload Type is to distinguish AcmeDelegation Method <t>The purpose of this Payload Type is to distinguish AcmeDelegation Method
MI objects (and any associated capability advertisement)</t> MI objects (and any associated capability advertisement)</t>
</dd> </dd>
<dt>Interface:</dt> <dt>Interface:</dt>
<dd> <dd>
skipping to change at line 474 skipping to change at line 474
<dd> <dd>
<t>See <xref target="acmedeleobj"/></t> <t>See <xref target="acmedeleobj"/></t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="sec"> <section anchor="sec">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The metadata object defined in this document does not introduce any new <t>The metadata object defined in this document does not introduce any new
security or privacy concerns over those already discussed in <xref target="RFC91 15"/>, security or privacy concerns over those already discussed in <xref target="RFC91 15"/>,
<xref target="RFC8006"/> and <xref target="RFC8008"/>.</t> <xref target="RFC8006"/>, and <xref target="RFC8008"/>.</t>
<t>The reader is expected to understand the ACME delegation trust model (< <t>The reader is expected to understand the ACME delegation trust model (<
xref section="7.1" sectionFormat="of" target="RFC9115"/>) and security goal (<xr xref section="7.1" sectionFormat="of" target="RFC9115"/>) and security goal (<xr
ef section="7.2" sectionFormat="of" target="RFC9115"/>), in particular ef section="7.2" sectionFormat="of" target="RFC9115"/>). In particular, the read
the criticality around the protection of the user account associated with the er is expected to understand that it is critical to protect the user account ass
delegation, which authorizes all the security relevant operations between dCDN ociated with the delegation; this account authorizes all the security-relevant o
and uCDN over the ACME channel. perations between a dCDN and a uCDN over the ACME channel.
The dCDN's ACME account is also relevant to the privacy of the entire scheme; The dCDN's ACME account is also relevant to the privacy of the entire scheme;
for example, the <tt>acme-delegation</tt> resource in the Metadata object is onl y for example, the <tt>acme-delegation</tt> resource in the Metadata object is onl y
accessible to the holder of the account key, who is allowed to fetch its accessible to the holder of the account key, who is allowed to fetch its
content exclusively via POST-as-GET (<xref section="2.3.1.2" sectionFormat="of" target="RFC9115"/>).</t> content exclusively via POST-as-GET (<xref section="2.3.1.2" sectionFormat="of" target="RFC9115"/>).</t>
<t>In addition, the Metadata interface authentication and confidentiality <t>In addition, the Metadata interface authentication and confidentiality
requirements defined in <xref section="8" sectionFormat="of" target="RFC8006"/> requirements defined in <xref section="8" sectionFormat="of" target="RFC8006"/>
MUST be followed.</t> <bcp14>MUST</bcp14> be followed.</t>
<t>Implementers MUST adhere to the security considerations defined in the <t>Implementers <bcp14>MUST</bcp14> adhere to the security considerations
CDNI Request Routing: Footprint and Capabilities Semantics, <xref section="7" se defined in <xref section="7" sectionFormat="of" target="RFC8008"/>, "Content Del
ctionFormat="of" target="RFC8008"/>.</t> ivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities
Semantics".</t>
<t>When TLS is used to achieve the above security objectives, the general TLS <t>When TLS is used to achieve the above security objectives, the general TLS
usage guidance in <xref target="RFC9325"/> MUST be followed.</t> usage guidance in <xref target="RFC9325"/> <bcp14>MUST</bcp14> be followed.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC8006"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
<front> 06.xml"/>
<title>Content Delivery Network Interconnection (CDNI) Metadata</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
le> 08.xml"/>
<author fullname="B. Niven-Jenkins" initials="B." surname="Niven-Jen <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87
kins"/> 39.xml"/>
<author fullname="R. Murray" initials="R." surname="Murray"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<author fullname="M. Caulfield" initials="M." surname="Caulfield"/> 15.xml"/>
<author fullname="K. Ma" initials="K." surname="Ma"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
<date month="December" year="2016"/> 25.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<t>The Content Delivery Network Interconnection (CDNI) Metadata in 19.xml"/>
terface enables interconnected Content Delivery Networks (CDNs) to exchange cont <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
ent distribution metadata in order to enable content acquisition and delivery. T 74.xml"/>
he CDNI Metadata associated with a piece of content provides a downstream CDN wi
th sufficient information for the downstream CDN to service content requests on
behalf of an upstream CDN. This document describes both a base set of CDNI Metad
ata 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">
<front>
<title>Content Delivery Network Interconnection (CDNI) Request Routi
ng: 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 Bra
ndenburg"/>
<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 Capabilities Advertisement" part of the Content Delivery Network Interconne
ction (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint"
and "Capabilities" in the CDNI context and what the "Footprint &amp; Capabiliti
es Advertisement interface (FCI)" offers within CDNI. The document also provides
guidelines for the CDNI FCI protocol. It further defines a Base Advertisement O
bject, the necessary registries for capabilities and footprints, and guidelines
on how 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="RFC8739">
<front>
<title>Support for Short-Term, Automatically Renewed (STAR) Certific
ates in the Automated Certificate Management Environment (ACME)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="D. Lopez" initials="D." surname="Lopez"/>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal
ez de Dios"/>
<author fullname="A. Pastor Perales" initials="A." surname="Pastor P
erales"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="March" year="2020"/>
<abstract>
<t>Public key certificates need to be revoked when they are compro
mised, that is, when the associated private key is exposed to an unauthorized en
tity. However, the revocation process is often unreliable. An alternative to rev
ocation is issuing a sequence of certificates, each with a short validity period
, and terminating the sequence upon compromise. This memo proposes an Automated
Certificate Management Environment (ACME) extension to enable the issuance of Sh
ort-Term, Automatically Renewed (STAR) X.509 certificates.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8739"/>
<seriesInfo name="DOI" value="10.17487/RFC8739"/>
</reference>
<reference anchor="RFC9115">
<front>
<title>An Automatic Certificate Management Environment (ACME) Profil
e for Generating Delegated Certificates</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="D. López" initials="D." surname="López"/>
<author fullname="A. Pastor Perales" initials="A." surname="Pastor P
erales"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="September" year="2021"/>
<abstract>
<t>This document defines a profile of the Automatic Certificate Ma
nagement Environment (ACME) protocol by which the holder of an identifier (e.g.,
a domain name) can allow a third party to obtain an X.509 certificate such that
the certificate subject is the delegated identifier while the certified public
key corresponds to a private key controlled by the third party. A primary use ca
se is that of a Content Delivery Network (CDN), the third party, terminating TLS
sessions on behalf of a content provider (the holder of a domain name). The pre
sented mechanism allows the holder of the identifier to retain control over the
delegation and revoke it at any time. Importantly, this mechanism does not requi
re any modification to the deployed TLS clients and servers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9115"/>
<seriesInfo name="DOI" value="10.17487/RFC9115"/>
</reference>
<reference anchor="RFC9325">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="November" year="2022"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Sec
urity (DTLS) are used to protect data exchanged over a wide range of application
protocols and can also form the basis for secure transport protocols. Over the
years, the industry has witnessed several serious attacks on TLS and DTLS, inclu
ding attacks on the most commonly used cipher suites and their modes of operatio
n. This document provides the latest recommendations for ensuring the security o
f deployed services that use TLS and DTLS. These recommendations are applicable
to the majority of use cases.</t>
<t>RFC 7525, an earlier version of the TLS recommendations, was pu
blished when the industry was transitioning to TLS 1.2. Years later, this transi
tion is largely complete, and TLS 1.3 is widely available. This document updates
the guidance given the new environment and obsoletes RFC 7525. In addition, thi
s document updates RFCs 5288 and 6066 in view of recent attacks.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="9325"/>
<seriesInfo name="DOI" value="10.17487/RFC9325"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE 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>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC7336"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.73
<front> 36.xml"/>
<title>Framework for Content Distribution Network Interconnection (C <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
DNI)</title> 60.xml"/>
<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" su
rname="van Brandenburg"/>
<date month="August" year="2014"/>
<abstract>
<t>This document presents a framework for Content Distribution Net
work Interconnection (CDNI). The purpose of the framework is to provide an overa
ll picture of the problem space of CDNI and to describe the relationships among
the various components necessary to interconnect CDNs. CDNI requires the specifi
cation of interfaces and mechanisms to address issues such as request routing, d
istribution metadata exchange, and logging information exchange across CDNs. The
intent of this document is to outline what each interface needs to accomplish a
nd to describe how these interfaces and mechanisms fit together, while leaving t
heir detailed specification to other documents. This document, in combination wi
th RFC 6707, obsoletes RFC 3466.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7336"/>
<seriesInfo name="DOI" value="10.17487/RFC7336"/>
</reference>
<reference anchor="RFC9460">
<front>
<title>Service Binding and Parameter Specification via the DNS (SVCB
and HTTPS Resource Records)</title>
<author fullname="B. Schwartz" initials="B." surname="Schwartz"/>
<author fullname="M. Bishop" initials="M." surname="Bishop"/>
<author fullname="E. Nygren" initials="E." surname="Nygren"/>
<date month="November" year="2023"/>
<abstract>
<t>This document specifies the "SVCB" ("Service Binding") and "HTT
PS" DNS resource record (RR) types to facilitate the lookup of information neede
d to make connections to network services, such as for HTTP origins. SVCB record
s allow a service to be provided from multiple alternative endpoints, each with
associated parameters (such as transport protocol configuration), and are extens
ible to support future uses (such as keys for encrypting the TLS ClientHello). T
hey also enable aliasing of apex domains, which is not possible with CNAME. The
HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics
"). By providing more information to the client before it attempts to establish
a connection, these records offer potential benefits to both performance and pri
vacy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9460"/>
<seriesInfo name="DOI" value="10.17487/RFC9460"/>
</reference>
</references> </references>
</references> </references>
<?line 321?>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>We would like to thank authors of the <xref target="RFC9115"/>, Antonio Augustin Pastor Perales, Diego Lopez, Thomas Fossati and Yaron Sheffer. Additio nally, our gratitude to Thomas Fossati who participated in the drafting, reviewi ng and giving his feedback in finalizing this document. We also thank CDNI co-ch air Kevin Ma for his continual review and feedback during the development of thi s document.</t> <t>We would like to thank authors of the <xref target="RFC9115"/>, <contac t fullname="Antonio Augustín Pastor Perales"/>, <contact fullname="Diego López"/ >, <contact fullname="Thomas Fossati"/>, and <contact fullname="Yaron Sheffer"/> . Additionally, our gratitude to <contact fullname="Thomas Fossati"/> who partic ipated in the drafting, reviewing, and giving his feedback in finalizing this do cument. We also thank CDNI co-chair <contact fullname="Kevin Ma"/> for his conti nual review and feedback during the development of this document.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA8072XbjNpbv+AqMfE6XnRJlWV6qSpNO4sj2xKe9jeVKJien
ZgKRkISYItgEKUdRVb6lX/s3un9s7r0AuEhyucons/ihQpHAxcXdtwRBwOZ9
vs9YrvJY9vng5OqcRzKWE5ErnfDCqGTCj4tcz0QuIz6QWa7GKoQf/FIkYiJn
Msn5aTJXmU7wmYnRKJPzR0ENLk9ZpMNEzOC4KBPjPFAyHwdhlKigWh6IcCaD
7gFjeNZEZ4s+N3nEQp0YmZjC9HmeFZKZYjRTxsCOfJECxPPTuzPGVJrRd5P3
ut033R4TmRR93jpO0xiRh+WGiyTit1LEwZ2ayRZ70Nn9JNNFCusGAA7vdSJj
NZfZgl/JHL8bfg4fMkAikSFCabF7uYAvUZ//9N3d3c2wXbtym27b5sO749t3
jJkcTvwvEesE8FxIw1IFu3IdtrnRWZ7JsYGnxQwfYLko8qnO+owH3BLrLPvn
36N//j1TIT9TUhSMc66zSZ9fZyKZSPxpAIrM+/ygGxy8bnMxl0khASMeC7hq
Woxi9deCVoYqB4oOpoBoDBjRKx3BKW96+72u/VkkOZL9DMCHtEnOhIr7fJzJ
SAIanTGi8Y2m4zuhnuGaTKMcyUjlOmMV8qczFUs+zGU6FclHMO+VWN8omWUo
ZdlvKqlQvhBJouoI93r73ScQlnh4x9jD6/hW+A1F8otY8Etlppko8fservmb
PcwjuLe/1+3ygY6L2UgJwPK+Rs+hikFc+DDNQNYrFC9PeA/E8KCB5dtEoUYN
c5Bvw/WYH8+QqKKGtyGkOjNC6pu5RcYiTjQC4eDPEFnOLfgW6tw3qH0duC2+
n6h8Wozgy5lj8ZnaJcV8gM8s0RlYAYCO596eDV53u0fV42v/+Gr/jXt8s7d3
6B/3e/DIVDJeAfJqfx+AMEAdKQjvhqcXZ4ABfMqnysCxQRBwMQL6izBn7A5e
cjAgBRmeSI5VAuSbyVxEIhc819wUaQr6VCoiWJ18ilrgCKPHjFQVWGFJNgJK
SZlwoBewnc80iJ2qEQ3t3qPU3QY7Z3Y6gHcqQzKNcbxoc8SdraEpHgW0yiWC
e77DL/3FCKGxCCXXo19gDd5UJmIUy7qRhbv9R+ew+4aHlaE2PJZwlJggJWpr
TTgF620cchGcwBzPOp55HC6jH0ydlMQoBdvg/AzlNIGNfFzEMdrmHNQfZdkR
3B+FpnYkOWFL++b6Hmicw4cFz8H80gqkGWi/VpFhCCCRgBUydArmm4NOzdHt
hNkizfUkE+kULCGYX46uKVMirhg5RQbONShjVCLcsZI0U1EUS8a2/vG3c0Q3
KojejHnOVHKCqmwlxfquunyEWqdAUyIJSgBHu24FLRX5FK7410JlYORD1CRA
AdCblQ4T7HxNWvjDFJA+uRoGI2EAY9gBW60YAEUKeAfydQ4cK8IpD2ENOAoB
HjVFoyRmiADfLuDfHaIZ8cZRH6lseIUEfROgQA+J27wd0UbQy1IhPAmAZMul
E4UPH0oprjEW9G6q8UBwJFZYADhiwuHjSE5FPPbi4IGnmZ4rMC5tejvVMTyX
IqNRoNqI40QmSF8Q9wTCghnKB1yZhJvVhNuePFIJIYFCZ9QkoVjFAiP7zh/A
sAFmIC1BKhSc94ASP1rYPYAvEPgMKDAuMniTAZgcTCSQOY0l0BtYMpYZA7SW
y6HjzB4iXREHEaw+Hnb2Or1Oc0nnMeNFkdJlzYLNBGgHsB23WwGskdwLuWBE
ZyIMXYFb6dFW/mcyBGenzMyLGmk4r/ETr2yvixLdZqiOUYRGao3BiBQCbRGq
N2IRaxHxO4i4TIufH18dA4EmCgTKisw4VIG3yECaFPQA7rsqOPa6KHcI+kzr
HN1mzv/EByIVIxVbO3MczZHdxkaalRncPhuco91dLmeN0+AOcJ6RxpGhdg4Q
JIpRY9eISvKB60s2nPuD4EZsa4vfAZlUomM9WfDlVl79+rDK1oLOri0fZ3pm
mTzOQBjJ3PvVxiq1MDZgZusrLMvQTTopo3UVHUpLYqPaEnB/Ra6qHQQQnbcF
yGhdRX8641M44OG8Jlk6RwNg9Obrs5redHpOLTBSWNOcvU1aI8nOY5xteOvy
7fCu1bb/5VfX9Hx7+u9vz29PT/B5+N3xxUX5wNyK4XfXby9Oqqdq5+D68vL0
6sRuhre88Yq1Lo9/bLUJy9b1zd359dXxRQtVKW9wHV0UaMnIhQ4g82iDBAQB
0oSZGln1+3Zw84+/7R3Aff8Fbtjb20MC2B+v914dwA/0BfY0nTjXQJZywUSa
SpEhFDC04AZSlQs0UQJkaAoGjYMmg7R++TWIuOTB0ddfoeSW3EO5P6kk/rKu
GCQB+RRCycmUg16BhDd02PLgGSJCSlqLMOoy44MLwch6oaOXZMwQgdBDBxMN
ZqYW9Fj/smZMC6/xTamvwXEgDMUK6jdLBtLNOlJIDkEelTyLCyaRjatOz0nm
WOM1kLoYvSRc/ipm4DW8S3MA0B85jxyVXrNCjjnk7OlED4VQ8Go+gMVkct00
Axa///77LwZCmCVEz62wxpYW5JeYTvAl/Vv/ugiQrC0M9QfnHU8uEPf1hXMR
F7jSA4GvXjDKA+zf7i6PwQvg1deuXSNcbUcLL1VJ5SUtaJUL3rmnDyVeYy+D
pnF2q5JNS0njgVgQHxg+fUBSUehHtPyoNiy3Zg0F+AFjNBfbeE6a1cTCORZI
VcZgkV2ohTtsAAkhHqThZXDHapa9XUYifFYYEmfYWw90RpA4lo5YZwrC+RfG
Rje5ZuBFQvB6GIcvOJYOUHBsgGR3gGoFADTj20ZKa6k3hSusNLw7KN/aagFs
tikNaI/d4WMXEsxwJld56LXtAYL0aWkDTdMfu7B6g2yvOJmGK9gkMlxgZcdm
JSMNvpwAYuGlUY8hbHwESpanJpyQqsdVDAUmNcsD9GPNXMpGkrYgBizOIEx9
gNh+uyJmr7NfujhHSjLokD8nwSMoreRZtTCPkgtLKMwwCCPWwGjl6P3m0TYg
U5MAU41gDMdQROYpwKdqMg0wQYz5XMmHKlqfjchmkzKgvbeVu7oyGwPpDB8T
5kB3Pcox3qYb1gWXTCxZ5trLY6puoVneHhzvNIXbZ2I3LlN4gVn2zQ7JujV3
Qpj5hHUgnws6fOVv49vNS91r9h717v3qx/fFhrfv+eCGry3F18f8PXsRvAyC
F6sfN759EcDbtaXuNePujH87vatUhvMNJz/+FvDh/GXg/n5CRr6zz199Nhj8
1Ot2+fVf2jV8ngNmWyVhhwQdM0IQzJ1ngPlyw6WCl8+51KdueAoMMqqmHM/m
1E+lJXz3XE55PtXReQYYy6jB8BaCeQhFQGmfzamVS/2fcerlRivwPIavm4tn
gAkzicYQkxsqS4CdfQ4YZNLDbi3AfB42FEt8yob/Bdqg3KxZx+dh84kbngRz
cw355nUGDmnveWD+MA1/bAPEVA8ii2pIfjaYz8HxmSSu6Nh7Hpg6jtRbc07t
j2b4J4JBUbXNOpdUmj8aGzzhQShIrI0psLdFB3z6249h81l/G8BsF0k93Yh2
yBWaXGRBPQhcA1MGJs/+e+pS9eO39p641JdPn/fE38unSdzprIeg69hgjrrs
861G0M5FRn2iQMRqkvy5FUrMkCjJpdb9n1unru5QbYFQfiXdwAoMBfRYMMKU
oke9oZj6j9WyFuS7y74wEHx/YF/xK53LPr9rtnRcftco7dTTkL2VRMSWs1ye
g7UeKlsuKCeeQfYG2Pg8Z3B1DJp9e2uAWsd8XORFJmuFnjSybZd6ayLURRxx
+Wtq+0ibMMVkHLNeCGviIpJ8+P3g213K113bZbn8GgEeHHUBoEeJ0iecRUCA
AKnWBqE83BYbqEdDKe1I6xxblbR7U2rLXEW9LOPzehnfN20iW+La2tqc7V7b
Ky236ph9JDt2JPAFN3skNYnwKjZjJlFBNDakqR3LfdjV9r0cA9zI1lt9bZA/
rA7YArCkr7aAN25kt7bzYjsDWCfEuteInnc80FasxhKbgy3MV1PQ5gXiIdC0
tZvbH9+BMhGrEFRkAYmLwLGPemq/2gLwAMo0uF6AqdorIq8O2PYip1OEI+IK
jUBEvxQmb3GR55kaFRBCd0CiNxAYTo9j+JDzqZjLRy+jkhVyY9/Zl3OoymON
gLH66H99vHTihENVneCyG+IOxsKKLTGPJEgQAPsCk3PCqc9pUqcm4GCTvuAn
VPEhisAK/vb2gqda2WImtgqTtZKPRaPNpaIOHBEIpMITC+vcRoeK4tsSQSqY
iZCGKnzni4SboBuZzX3F6wnr5NtQrvG3YyUe0aY2A5bjqF2Z56lxnfMOXfSO
xo6GuZv4+ALHosBA6WwR5DqwQwFApB+laVKN5ANscKQfNlDsezDzEVZHYLVC
Hq2JIwgSXDuLyMzUa3kHcL0D32GhJg+QjuOM0w902gZ+gzYKbnHhLXTdILKI
X9uZJf9JJpH90MFuNDaiSx9jrZpVSw+CWia0pyZH7iYOJBF3BDxLIBw0udbY
/UbXgBMi6C+smSWAQYRaiECxlkk/Nmjp3FGOUKSPDk2aKPCa9z+LLujxt3KM
YwLWnubHY7A2fKxkHJlNvKxJUsWoz5Embys2iBLah9KsNdw0qsFeoxdXwwP7
nxOZfRyJtvXqagxCsmrRnJ/DmrFvQG/G2VnJJ1B3q/7QG1xpdLFb/NRbzeVW
aTJXmzu+rYN2kPo8P28ypj/zRiMHaWKjC7Zi7lbbNjTuoMKy41C2Zy7POxt7
JO2Nu5q9mtaKaUZ4ZMH6u7v4qVOEUdJxN9ut1u3qyThzvaBWzVDVmkBOafp8
7+jo8GDv1cH+QdmjQR2yH45eHR3tH9gOjANXerU+3z84POp2V957n9nnvcM3
PZrs++AbN3eVh7Oe6PO4UWr/Sim780hsW7OQoNggtU0r27Cx/7/5+TBUh5/K
z8NX3Teve72N/LSMLjtqH2odNZoCGUBciBV7N4uw3FIiEWsDEjgbJU1ubaUb
HPHja/SupnU4K2nNLX5hGwdQ/OxJn7H3jW+Qjw3r0xGQXL2HTA1WPcIF2LBc
/gknECEkeM/YT/8J5mIkg0zO9FxG79bf9FEE+CmNu/araaE0tr0rD6sMWHB1
UsxGPnYGuuAr9BMWpH0HPkPa+N+2s883h271yzJ2U2SpNrLPbLKW2p/lOQ3K
KDskBnQDMhfKTDd28YDHcLRPcrbtENaiHonV+uuiPgOww1g5QYMIXZ7vng3O
GTtNQo0xC74bUljWSK5wYAFUrKDO0Jo0GRk6u1z2INbT0OZYRqQlURM7ijTs
J+kGiXxgxp8DxoGGC8MFJjbgl+EwGv4DEmAbNs6kiBZIrLAwZm2Oqs1WBmoa
gzEWX4QAAAEzyEfsSCmQ34URPoFYjYhpgN31JasmH3u1MiGzQ2eWt5noZjvy
1XozEvBPQdtVWMQio1FL8LlYv7F8zGwzzsb/uQPjVJNayD7g3hCRs3oq6Hqb
rjaG7UZIciie88hmsHouMHZPSz77zBhje4ZXs/OEliGOSjjblsi4w3xe+sLY
Dx41nMXApKg8wPUWPaPddbBsBWGaDej/laGfcObTxoY/r1jcnzHe00UWSp+L
Xa5IIhyMMRET1I9XbuJ1fdTRI3ovF0gobTEGs2dFA5whkE7lhvm5SflrGBfG
xplznDy/Ht4FwgRYbttezW56a01giIZFBGaKGNNAvOq11wp5fmqXenRudhTn
VNxc68zN820o/rxu+MUyZLY2XeK8yrmfbAHht99FhLNLnlCldIRNA9BQcjfo
c2t9Cb/VBVqy/seGlIY4Rgq3g7C1ph4VulZdadDj7mLoR2+pcBROlXR5uRih
la6MB7Ed2OJqEnZuNUYIrKAGOZjXCAuxldnY7x1upgw4Jz4S4T3NbYX3iX6I
ZTQhYrNlv0is55ARzqNAUkJFr1jdO8qJ5N4pW5lk1M0UP05ynSjNj4tJgXYf
PALkMBm/QYQR/xMlJ5pfgC7+1gYXomcQ9pxpY4D+RM0fwTQkfDiV47HMIAF1
8mQn3kEr+ARZlWN1DRBaAYAybq2OSslk+GIG/j9AwLo2joUrSW4fD5uoOT6i
NR9LGSFZaNJcJTi9ZatrNUvf4T+UdRAkBElHqAOwFCrjfwHQCWQBdgwUtqFW
qaQARtlT6cjynKjIqv9tADROp+RMvCctz2TsvwGAR1xQQjUAAA==
</rfc> </rfc>
 End of changes. 40 change blocks. 
417 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.48.