<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?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" number="9538" docName="draft-ietf-cdni-delegation-acme-04" 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 --> <front> <title abbrev="CDNIdelegation using ACME">CDNI delegation usingDelegation Using ACME">Content Delivery Network Interconnection (CDNI) Delegation Using the Automated Certificate Management Environment</title> <seriesInfoname="Internet-Draft" value="draft-ietf-cdni-delegation-acme-04"/>name="RFC" value="9538"/> <author initials="F." surname="Fieau" fullname="Frédéric Fieau" role="editor"> <organization>Orange</organization> <address> <postal> <street>40-48, avenue de laRepublique</street> <city>Chatillon</city>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="S." surname="Mishra" fullname="Sanjay Mishra"> <organization>Verizon</organization> <address> <postal> <street>13100 Columbia Pike</street> <city>Silver Spring</city><code>MD 20904</code><region>MD</region><code>20904</code> <country>United States of America</country> </postal> <email>sanjay.mishra@verizon.com</email> </address> </author> <dateyear="2023" month="December" day="07"/> <area>Applications and Real-Time</area> <workgroup>Content Delivery Networks Interconnection</workgroup>year="2024" month="February"/> <area>art</area> <workgroup>cdni</workgroup> <keyword>HTTPS</keyword> <keyword>delegation</keyword> <keyword>ACME</keyword> <keyword>STAR</keyword><abstract> <?line 64?> <t>This<abstract><t>This document defines metadata to support delegating the delivery of HTTPS content between two or more interconnected Content Delivery Networks (CDNs). Specifically, this document defines a Content Delivery Network Interconnection (CDNI) Metadata interface object to enable delegation of X.509 certificates leveraging delegation schemes defined inRFC9115. RFC9115 allowsRFC 9115. Per RFC 9115, delegating entitiestocan remain in full control of the delegation andbe able tocan revoke it at anytime and thistime. This avoids the need to share private cryptographic key material between the involved entities.</t> </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 (<eref target="mailto:cdni@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/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> <middle><?line 74?><section anchor="introduction"><name> Introduction</name><name>Introduction</name> <t>Content delivery over HTTPS using two or more cooperating CDNs along the 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 CDN (dCDN) for content delivery.</t> <t><xref target="RFC9115"/> defines delegation methods that allow a uCDN on behalf of the content provider, the holder of the domain, to generate on-demand an X.509 certificate that binds the designated domain name with akey-pairkey pair owned by the dCDN. For further details, please refer to Sections <xref section="1"sectionFormat="of"sectionFormat="bare" target="RFC9115"/> and <xref section="5.1.2.1"sectionFormat="of"sectionFormat="bare" target="RFC9115"/> of <xref target="RFC9115"/>.</t> <t>This document defines CDNI Metadata to make use of HTTPS delegation between a uCDN and a dCDN based on the mechanism specified in <xref target="RFC9115"/>. Furthermore, it adds a delegation method to the "CDNI Payload Types" IANA registry.</t> <t><xref target="fci-metadata"/> presents delegation metadata for the Footprint & Capabilities Advertisement interface (FCI). <xref target="mi-metadata"/> addresses the metadata for handling HTTPS delegation with the MetadataInterface.</t>interface.</t> <section anchor="terminology"> <name>Terminology</name> <t>This document uses terminology from CDNI framework documents such as: CDNI framework document <xref target="RFC7336"/> and CDNI interface specifications documents: CDNI Metadata interface <xref target="RFC8006"/> and 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" sectionFormat="of"target="RFC9115"/>.</t>target="RFC9115"/>, including Short-Term, Automatically Renewed (STAR), as applied to X.509 certificates.</t> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.<?line -6?></t> </section> </section> <section anchor="fci-metadata"> <name>Advertising Delegation Metadata for CDNI through FCI</name> <t>The Footprintand& Capabilities Advertisement interface (FCI) defined in <xref target="RFC8008"/> allows a dCDN to send a FCI capability type object to a uCDN.</t> <t>This document uses the CDNI Metadata capability object serialization from <xref target="RFC8008"/> for a CDN that supports delegation methods.</t> <t>The following is an example of the supported delegated methods capability object for a dCDN implementing the ACME delegation method.</t> <sourcecode type="json"><![CDATA[ { "capabilities": [ { "capability-type": "FCI.Metadata", "capability-value": { "metadata": [ // list of supported delegation methods "ACMEDelegationMethod" ] }, "footprints": [ "Footprint objects" ] } ] } ]]></sourcecode> </section> <section anchor="mi-metadata"><name> ACME<name>ACME Delegation Metadata for CDNI</name> <t>When a uCDN delegates the delivery of HTTPS traffic to a dCDN using DNSRedirectionredirection <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" sectionFormat="of" target="RFC9115"/>).</t> <t>To that end, this section defines the AcmeDelegationMethodobjectobject, which describes metadata for using the ACME delegation interface <xref target="RFC9115"/>.</t> <t>The ACMEDelegationMethod applies to both ACME STAR delegation, which provides a 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 certificates (<xref section="2.3.3" sectionFormat="of" target="RFC9115"/>).</t> <t><xref target="fig-call-flow"/> provides a high-level view of the combined CDNI and ACME delegation message flows to obtain a STAR certificate from theCertificateCertification Authority (CA) bound to the Content Provider's (CP) name.</t> <figure anchor="fig-call-flow"> <name>Examplecall-flowCall Flow of STARdelegationDelegation in CDNIshowing 2 levelsShowing Two Levels ofdelegation</name>Delegation</name> <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"> <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 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,352 L 64,368" 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 224,32 L 224,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 392,32 L 392,64" fill="none" stroke="black"/> <path d="M 536,32 L 536,64" fill="none" stroke="black"/> <path d="M 560,64 L 560,640" fill="none" stroke="black"/> <path d="M 576,32 L 576,64" fill="none" stroke="black"/> <path d="M 8,32 L 48,32" fill="none" stroke="black"/> <path d="M 184,32 L 224,32" fill="none" stroke="black"/> <path d="M 352,32 L 392,32" fill="none" stroke="black"/> <path d="M 536,32 L 576,32" fill="none" stroke="black"/> <path d="M 8,64 L 48,64" fill="none" stroke="black"/> <path d="M 184,64 L 224,64" fill="none" stroke="black"/> <path d="M 352,64 L 392,64" fill="none" stroke="black"/> <path d="M 536,64 L 576,64" fill="none" stroke="black"/> <path d="M 24,96 L 88,96" fill="none" stroke="black"/> <path d="M 144,96 L 192,96" fill="none" stroke="black"/> <path d="M 32,144 L 88,144" fill="none" stroke="black"/> <path d="M 144,144 L 200,144" fill="none" stroke="black"/> <path d="M 24,192 L 64,192" fill="none" stroke="black"/> <path d="M 160,192 L 192,192" fill="none" stroke="black"/> <path d="M 32,240 L 64,240" fill="none" stroke="black"/> <path d="M 160,240 L 200,240" fill="none" stroke="black"/> <path d="M 24,272 L 64,272" fill="none" stroke="black"/> <path d="M 32,368 L 64,368" fill="none" stroke="black"/> <path d="M 24,416 L 64,416" fill="none" stroke="black"/> <path d="M 160,416 L 192,416" fill="none" stroke="black"/> <path d="M 200,448 L 240,448" fill="none" stroke="black"/> <path d="M 336,448 L 368,448" fill="none" stroke="black"/> <path d="M 376,480 L 416,480" fill="none" stroke="black"/> <path d="M 512,480 L 552,480" fill="none" stroke="black"/> <path d="M 384,512 L 408,512" fill="none" stroke="black"/> <path d="M 528,512 L 552,512" fill="none" stroke="black"/> <path d="M 32,544 L 56,544" fill="none" stroke="black"/> <path d="M 168,544 L 192,544" fill="none" stroke="black"/> <path d="M 208,544 L 232,544" fill="none" stroke="black"/> <path d="M 344,544 L 368,544" fill="none" stroke="black"/> <path d="M 384,544 L 408,544" fill="none" stroke="black"/> <path d="M 520,544 L 552,544" fill="none" stroke="black"/> <path d="M 24,592 L 552,592" fill="none" stroke="black"/> <path d="M 32,624 L 560,624" fill="none" stroke="black"/> <polygon class="arrowhead" points="560,592 548,586.4 548,597.6" fill="black" transform="rotate(0,552,592)"/> <polygon class="arrowhead" points="560,544 548,538.4 548,549.6" fill="black" transform="rotate(0,552,544)"/> <polygon class="arrowhead" points="560,512 548,506.4 548,517.6" fill="black" transform="rotate(0,552,512)"/> <polygon class="arrowhead" points="560,480 548,474.4 548,485.6" fill="black" transform="rotate(0,552,480)"/> <polygon class="arrowhead" points="392,544 380,538.4 380,549.6" fill="black" transform="rotate(180,384,544)"/> <polygon class="arrowhead" points="392,512 380,506.4 380,517.6" fill="black" transform="rotate(180,384,512)"/> <polygon class="arrowhead" points="376,544 364,538.4 364,549.6" fill="black" transform="rotate(0,368,544)"/> <polygon class="arrowhead" points="376,448 364,442.4 364,453.6" fill="black" transform="rotate(0,368,448)"/> <polygon class="arrowhead" points="216,544 204,538.4 204,549.6" fill="black" transform="rotate(180,208,544)"/> <polygon class="arrowhead" points="200,544 188,538.4 188,549.6" fill="black" transform="rotate(0,192,544)"/> <polygon class="arrowhead" points="200,416 188,410.4 188,421.6" fill="black" transform="rotate(0,192,416)"/> <polygon class="arrowhead" points="200,192 188,186.4 188,197.6" fill="black" transform="rotate(0,192,192)"/> <polygon class="arrowhead" points="200,96 188,90.4 188,101.6" fill="black" transform="rotate(0,192,96)"/> <polygon class="arrowhead" points="40,624 28,618.4 28,629.6" fill="black" transform="rotate(180,32,624)"/> <polygon class="arrowhead" points="40,544 28,538.4 28,549.6" fill="black" transform="rotate(180,32,544)"/> <polygon class="arrowhead" points="40,368 28,362.4 28,373.6" fill="black" transform="rotate(180,32,368)"/> <polygon class="arrowhead" points="40,240 28,234.4 28,245.6" fill="black" transform="rotate(180,32,240)"/> <polygon class="arrowhead" points="40,144 28,138.4 28,149.6" fill="black" transform="rotate(180,32,144)"/> <g class="text"> <text x="28" y="52">dCDN</text> <text x="204" y="52">uCDN</text> <text x="372" y="52">CP</text> <text x="556" y="52">CA</text> <text x="80" y="84">GET</text> <text x="132" y="84">metadata</text> <text x="116" y="100">[CDNI]</text> <text x="64" y="116">200</text> <text x="96" y="116">OK,</text> <text x="148" y="116">metadata</text> <text x="64" y="132">(inc.</text> <text x="108" y="132">dele</text> <text x="160" y="132">config)</text> <text x="116" y="148">[CDNI]</text> <text x="72" y="180">GET</text> <text x="132" y="180">delegation</text> <text x="88" y="196">[ACME</text> <text x="136" y="196">dele]</text> <text x="48" y="212">200</text> <text x="80" y="212">OK,</text> <text x="140" y="212">delegation</text> <text x="56" y="228">(inc.</text> <text x="96" y="228">CSR</text> <text x="152" y="228">template)</text> <text x="88" y="244">[ACME</text> <text x="136" y="244">dele]</text> <text x="68" y="308">create</text> <text x="112" y="308">key</text> <text x="148" y="308">pair</text> <text x="184" y="308">and</text> <text x="56" y="324">CSR</text> <text x="84" y="324">w/</text> <text x="136" y="324">delegated</text> <text x="60" y="340">name</text> <text x="84" y="404">POST</text> <text x="132" y="404">Order1</text> <text x="88" y="420">[ACME</text> <text x="136" y="420">dele]</text> <text x="256" y="436">forward</text> <text x="316" y="436">Order1</text> <text x="264" y="452">[ACME</text> <text x="312" y="452">dele]</text> <text x="436" y="468">POST</text> <text x="484" y="468">Order2</text> <text x="440" y="484">[ACME</text> <text x="488" y="484">STAR]</text> <text x="468" y="516">authorizations</text> <text x="76" y="548">wait</text> <text x="132" y="548">issuance</text> <text x="252" y="548">wait</text> <text x="308" y="548">issuance</text> <text x="428" y="548">wait</text> <text x="484" y="548">issuance</text> <text x="208" y="580">(unauthenticated)</text> <text x="296" y="580">GET</text> <text x="380" y="580">star-certificate</text> <text x="280" y="612">certificate</text> <text x="340" y="612">#1</text> <text x="280" y="644">...</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .----. .----. .----. .----. |dCDN| |uCDN| | CP | | CA | '-+--' '-+--' '--+-' '--+-' | GET metadata | | | +--------[CDNI]------>| | | | 200 OK, metadata | | | | (inc. dele config) | | | |<-------[CDNI]-------+ | | | | | | | GET delegation | | | +-----[ACME dele]---->| | | | 200 OK, delegation | | | | (inc. CSR template) | | | |<----[ACME dele]-----+ | | | | | | +----. | | | | | | | | | create key pair and| | | | CSR w/ delegated | | | | name | | | | | | | | |<---' | | | | | | | | POST Order1 | | | +-----[ACME dele]---->| | | | | forward Order1 | | | +-----[ACME dele]---->| | | | | POST Order2 | | | +-----[ACME STAR]----->| | | | | | | |<---authorizations--->| | | | | |<---wait issuance--->|<---wait issuance--->|<---wait issuance---->| | | | (unauthenticated) GET star-certificate | +----------------------------------------------------------------->| | certificate #1 | |<-----------------------------------------------------------------+ | ... | ]]></artwork> </artset> </figure> <aside> <t>Note: The delegation object defined in <xref section="2.3.1.3" sectionFormat="of" target="RFC9115"/> only allowsto specifyDNS mappings to be specified using CNAME RRs. A future document updating <xref target="RFC9115"/> could expand the delegation object to also include SVCB/HTTPS-based mappings <xreftarget="RFC9460"/> mappings.</t>target="RFC9460"/>.</t> </aside> <t><xref target="acmedeleobj"/> defines the objects used for bootstrapping the ACME delegation method between a uCDN and a delegate dCDN.</t> <section anchor="acmedeleobj"> <name>ACMEDelegationMethod Object</name> <t>The ACMEDelegationMethod object allows a uCDN to define both STAR and non-STARdelegation.delegations. The dCDN, the consumer of the delegation, can determine the type of delegation by the presence (or absence) of the "lifetime" property. That is, the presence of the "lifetime" property explicitly means a short-term delegation with lifetime of the certificate based on that property (and the optional "lifetime-adjust" attribute). A non-STAR delegation will not have the "lifetime" 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> <ul spacing="normal"> <li> <t>Property: acme-delegation </t> <ul spacing="normal"> <li> <t>Description:aA URL pointing at an ACME delegation object, either 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 details). The URLMUST<bcp14>MUST</bcp14> use the https scheme.</t> </li> <li> <t>Type: String</t> </li> <li> <t>Mandatory-to-Specify: Yes</t> </li> </ul> </li> <li> <t>Property: time-window </t> <ul spacing="normal"> <li> <t>Description: Validity period of the certificate. According to <xref section="4.3.4" sectionFormat="of" target="RFC8006"/>, a TimeWindow object is defined by a window "start"time,time and a window "end" time. In the case of a STAR method, the "start" and "end" properties of the windowMUST<bcp14>MUST</bcp14> be understood respectively as the start-date and end-date of the certificate validity. In the case ofthea non-STAR method, the "start" and "end" properties of the windowMUST<bcp14>MUST</bcp14> beunderstood respectivelyunderstood, respectively, as the notBefore and notAfter fields of the certificate.</t> </li> <li> <t>Type: TimeWindow</t> </li> <li> <t>Mandatory-to-Specify: Yes</t> </li> </ul> </li> <li> <t>Property: lifetime </t> <ul spacing="normal"> <li> <t>Description: See lifetime in <xref section="3.1.1" sectionFormat="of" target="RFC8739"/></t> </li> <li> <t>Type: Integer</t> </li> <li> <t>Mandatory-to-Specify: Yes, only if a STAR delegation method is specified</t> </li> </ul> </li> <li> <t>Property: lifetime-adjust </t> <ul spacing="normal"> <li> <t>Description: See lifetime-adjust in <xref section="3.1.1" sectionFormat="of" target="RFC8739"/></t> </li> <li> <t>Type: Integer</t> </li> <li> <t>Mandatory-to-Specify: No</t> </li> </ul> </li> </ul> <section anchor="examples"> <name>Examples</name> <t>The following example shows an <tt>ACMEDelegationMethod</tt> object for a STAR-based ACME delegation.</t> <sourcecode type="json"><![CDATA[ { "generic-metadata-type": "MI.ACMEDelegationMethod", "generic-metadata-value": { "acme-delegation": "https://acme.ucdn.example/delegation/ogfr", "time-window": { "start": 1665417434, "end": 1665676634 }, "lifetime": 345600, "lifetime-adjust": 259200 } } ]]></sourcecode> <t>The example below shows an <tt>ACMEDelegationMethod</tt> object for a non-STAR ACME delegation. The delegation object is defined as per <xref section="4.3" sectionFormat="of" target="RFC8006"/>.</t> <sourcecode type="json"><![CDATA[ { "generic-metadata-type": "MI.ACMEDelegationMethod", "generic-metadata-value": { "acme-delegation": "https://acme.ucdn.example/delegation/wSi5", "time-window": { "start": 1570982234, "end": 1665417434 } } } ]]></sourcecode> </section> </section> </section> <section anchor="iana"><name> IANA<name>IANA Considerations</name><t>This document requests the registration of<t>Per this document, the followingentry undertype has been registered in the "CDNI Payload Types" registry:</t> <table> <thead> <tr> <th align="left">Payload Type</th> <thalign="left">Specification</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">MI.ACMEDelegationMethod</td> <tdalign="left">RFCthis</td>align="left">RFC 9538</td> </tr> </tbody> </table><t><cref anchor="to-be-removed">RFC Editor: please replace RFCthis with the RFC number of this RFC and remove this note.</cref></t><section anchor="cdni-mi-acmedelegationmethod-payload-type"> <name>CDNI MI ACMEDelegationMethod Payload Type</name> <dl> <dt>Purpose:</dt> <dd> <t>The purpose of this Payload Type is to distinguish AcmeDelegationMethod MI objects (and any associated capability advertisement)</t> </dd> <dt>Interface:</dt> <dd> <t>MI/FCI</t> </dd> <dt>Encoding:</dt> <dd> <t>See <xref target="acmedeleobj"/></t> </dd> </dl> </section> </section> <section anchor="sec"> <name>Security Considerations</name> <t>The metadata object defined in this document does not introduce any new security or privacy concerns over those already discussed in <xref target="RFC9115"/>, <xreftarget="RFC8006"/>target="RFC8006"/>, and <xref target="RFC8008"/>.</t> <t>The reader is expected to understand the ACME delegation trust model (<xref section="7.1" sectionFormat="of" target="RFC9115"/>) and security goal (<xref section="7.2" sectionFormat="of"target="RFC9115"/>), in particular the criticality aroundtarget="RFC9115"/>). In particular, theprotection ofreader is expected to understand that it is critical to protect the user account associated with thedelegation, whichdelegation; this account authorizes all thesecurity relevantsecurity-relevant operations 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; for example, the <tt>acme-delegation</tt> resource in the Metadata object is only 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> <t>In addition, the Metadata interface authentication and confidentiality requirements defined in <xref section="8" sectionFormat="of" target="RFC8006"/>MUST<bcp14>MUST</bcp14> be followed.</t> <t>ImplementersMUST<bcp14>MUST</bcp14> adhere to the security considerations defined inthe CDNI<xref section="7" sectionFormat="of" target="RFC8008"/>, "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and CapabilitiesSemantics, <xref section="7" sectionFormat="of" target="RFC8008"/>.</t>Semantics".</t> <t>When TLS is used to achieve the above security objectives, the general TLS usage guidance in <xref target="RFC9325"/>MUST<bcp14>MUST</bcp14> be followed.</t> </section> </middle> <back> <references> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="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 interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with 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 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"> <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 Brandenburg"/> <author fullname="K. Ma" initials="K." surname="Ma"/> <date month="December" year="2016"/> <abstract> <t><p>This document captures the semantics of the "Footprint and Capabilities 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 & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.</p></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) Certificates 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="Gonzalez de Dios"/> <author fullname="A. Pastor Perales" initials="A." surname="Pastor Perales"/> <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 compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation 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 Short-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) Profile 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 Perales"/> <author fullname="T. Fossati" initials="T." surname="Fossati"/> <date month="September" year="2021"/> <abstract> <t>This document defines a profile of the Automatic Certificate Management 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 case 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 presented mechanism allows the holder of the identifier to retain control over the delegation and revoke it at any time. Importantly, this mechanism does not require 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 (TLS) 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 Security (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, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of 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 published when the industry was transitioning to TLS 1.2. Years later, this transition 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, this 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</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 the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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</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 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8006.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8008.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8739.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9115.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="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" surname="van Brandenburg"/> <date month="August" year="2014"/> <abstract> <t>This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their 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="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 "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They 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 privacy.</t> </abstract> </front> <seriesInfo name="RFC" value="9460"/> <seriesInfo name="DOI" value="10.17487/RFC9460"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7336.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/> </references> </references><?line 321?><section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>We would like to thank authors of the <xref target="RFC9115"/>,Antonio Augustin<contact fullname="Antonio Augustín PastorPerales, Diego Lopez, Thomas Fossati and Yaron Sheffer.Perales"/>, <contact fullname="Diego López"/>, <contact fullname="Thomas Fossati"/>, and <contact fullname="Yaron Sheffer"/>. Additionally, our gratitude toThomas Fossati<contact fullname="Thomas Fossati"/> who participated in the drafting,reviewingreviewing, and giving his feedback in finalizing this document. We also thank CDNI co-chairKevin Ma<contact fullname="Kevin Ma"/> for his continual review and feedback during the development of this document.</t> </section> </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>