<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.5 (Ruby 3.2.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-netconf-over-tls13-04" number="9918" category="std" consensus="true" submissionType="IETF" updates="7589" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.19.1 --> version="3" xml:lang="en">

<front>

    <title abbrev="NETCONF over TLS">Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-over-tls13-04"/> name="RFC" value="9918"/>
    <author initials="S." surname="Turner" fullname="Sean Turner">
      <organization>sn3rd</organization>
      <address>
        <email>sean@sn3rd.com</email>
      </address>
    </author>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <postal>
          <street>516 Dranesville Road</street>
          <city>Herndon, VA</city>
          <city>Herndon</city>
	  <region>VA</region>
          <code>20170</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <date year="2024" month="January" day="18"/>
    <area>Operations and Management</area>
    <workgroup>Network Configuration</workgroup> year="2026" month="January"/>

    <area>OPS</area>
    <workgroup>netconf</workgroup>

    <keyword>NETCONF</keyword>
    <keyword>TLS 1.3</keyword>
    <keyword>TLS 1.2</keyword>
    <keyword>Early Data</keyword>
    <abstract>
      <?line 43?>

<t>RFC 7589 defines how to protect NETCONF Network Configuration Protocol (NETCONF) messages with TLS 1.2. This
document updates RFC 7589 to update support requirements for TLS 1.2
and add TLS 1.3 support requirements, including restrictions on the
use of TLS 1.3's early data.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://netconf-wg.github.io/netconf-over-tls13/draft-ietf-netconf-over-tls13.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-netconf-over-tls13/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Network Configuration Working Group mailing list (<eref target="mailto:netconf@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/netconf/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/netconf/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/netconf-wg/netconf-over-tls13"/>.</t>
    </note>

  </front>
  <middle>
    <?line 50?>

    <section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="RFC7589"/> defines how to protect NETCONF messages <xref target="RFC6241"/> with
TLS 1.2 <xref target="RFC5246"/>. This document updates <xref target="RFC7589"/> to update
support requirements for TLS 1.2 <xref target="RFC5246"/> and to add TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/> target="RFC9846"/>
support requirements, including restrictions on the use of TLS 1.3's early data data, which is also known as 0-RTT data.
It also updates "netconf-tls", the "netconf-tls" IANA Registered Port Number entry IANA-registered port number entry, to
refer to this document. All other provisions set forth in <xref target="RFC7589"/>
are unchanged, including connection initiation, message framing,
connection closure, certificate validation, server identity, and client
      identity.</t>
<aside>
        <t>NOTE: Implementations that support TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/> target="RFC9846"/> should
  refer to TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/> in Sections <xref target="RFC7589" section="4" sectionFormat="bare"/> and <xref target="RFC7589" section="5" sectionFormat="bare"/> of <xref target="RFC7589"/>.</t>
      </aside>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The
      <name>Conventions</name>
        <t>
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>
      <?line -18?> here.
        </t>
    </section>
    <section anchor="early-data">
      <name>Early Data</name>
      <t>Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3
<xref target="I-D.ietf-tls-rfc8446bis"/> target="RFC9846"/> that allows a client to send data ("early data")
as part of the first flight of messages to a server. Note that TLS 1.3 can
be used without early data as per <xref section="F.5" sectionFormat="of" target="I-D.ietf-tls-rfc8446bis"/>. target="RFC9846"/>.
In fact, early data is permitted by TLS 1.3 only when the client and server
share a Pre-Shared Key (PSK), either obtained externally or via a previous
handshake. The client uses the PSK to authenticate the server and to encrypt
the early data.</t>
      <t>As noted in <xref section="2.3" sectionFormat="of" target="I-D.ietf-tls-rfc8446bis"/>, target="RFC9846"/>, the security
properties for early data are weaker than those for subsequent TLS-protected
data. In particular, early data is not forward secret, and there is no
protection against the replay of early data between connections.
<xref section="E.5" section="F.5" sectionFormat="of" target="I-D.ietf-tls-rfc8446bis"/> target="RFC9846"/> requires applications not
use early data without a profile that defines its use. This document
specifies that NETCONF implementations that support TLS 1.3 <bcp14>MUST NOT</bcp14> use early
data.</t>
    </section>
    <section anchor="cipher-suites">
      <name>Cipher Suites</name>
      <t>Implementations <bcp14>MUST</bcp14> support mutually authenticated TLS 1.2 <xref target="RFC5246"/> target="RFC5246"/>, and
they are, as specified in <xref target="RFC9325"/>, recommended to support the cipher
suites found in <xref section="4.2" sectionFormat="of" target="RFC9325"/>.</t>
      <t>Implementations <bcp14>MAY</bcp14> implement additional TLS 1.2 cipher suites that provide
mutual authentication <xref target="RFC5246"/> and confidentiality confidentiality, as required by
NETCONF <xref target="RFC6241"/>.</t>
      <t>Implementations <bcp14>SHOULD</bcp14> support mutually authenticated TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/> target="RFC9846"/> and,
if implemented, <bcp14>MUST</bcp14> prefer to negotiate TLS 1.3 over earlier versions
of TLS.</t>
      <t>Implementations that support TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/> target="RFC9846"/> are
<bcp14>REQUIRED</bcp14> to support the mandatory-to-implement cipher suites listed in
<xref section="9.1" sectionFormat="of" target="I-D.ietf-tls-rfc8446bis"/>.</t> target="RFC9846"/>.</t>
      <t>Implementations that support TLS 1.3 <bcp14>MAY</bcp14> implement additional TLS cipher
suites that provide mutual authentication and confidentiality, which are
required for NETCONF <xref target="RFC6241"/>.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The Security Considerations security considerations of <xref target="RFC6241"/>, <xref target="RFC7589"/>, and <xref target="RFC9325"/>
apply here as well.</t>
      <t>NETCONF implementations <bcp14>SHOULD</bcp14> follow the TLS recommendations given in
<xref target="RFC9325"/>.</t>
      <t>For implementations that support TLS 1.3, the Security Considerations security considerations of
TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/> target="RFC9846"/> apply.</t>
      <t>As specified in <xref target="RFC7589"/>, NETCONF over TLS requires mutual authentication.</t>
      <t>For implementations that support TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/>:</t>
      <ul empty="true">
        <li>
          <t>TLS target="RFC9846"/>:</t>

      <t indent="3">TLS 1.3 mutual authentication is used
to ensure that only authorized users and systems are able to view the
NETCONF server's configuration and state or to modify the NETCONF
server's configuration. To this end, neither the client nor the server
should establish a NETCONF over TLS 1.3 connection with an unknown,
unexpected, or incorrectly identified peer; see <xref section="7" sectionFormat="of" target="RFC7589"/>. If
deployments make use of a trusted list of Certification Authority (CA)
certificates <xref target="RFC5280"/>, then the listed CAs should only issue certificates
to parties that are authorized to access the NETCONF servers. Doing otherwise
will allow certificates that were issued for other purposes to be
inappropriately accepted by a NETCONF server.</t>
        </li>
      </ul>

      <t>The Security Considerations security considerations of <xref target="RFC9525"/> apply to all implementations
when the client checks the identity of the server, as is required in
<xref section="6" sectionFormat="of" target="RFC7589"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to add has added a reference to this document in the
"netconf-tls" entry in the "Service Name and Transport Protocol Port
Number Registry". The updated registry entry would appear appears as follows:</t>
      <artwork><![CDATA[
 Service Name:           netconf-tls
 Transport Protocol(s):  TCP
 Assignee:               IESG <iesg@ietf.org>
 Contact:                IETF Chair <chair@ietf.org>
 Description:            NETCONF
<dl spacing="compact" newline="false">
  <dt>Service Name:</dt><dd>netconf-tls</dd>
  <dt>Port Number:</dt><dd>6513</dd>
  <dt>Transport Protocol:</dt><dd>tcp</dd>
  <dt>Description:</dt><dd>NETCONF over TLS
 Reference:              RFC TLS</dd>
  <dt>Assignee:</dt><dd>IESG &lt;iesg@ietf.org&gt;</dd>
  <dt>Contact:</dt><dd>IETF Chair &lt;chair@ietf.org&gt;</dd>
  <dt>Reference:</dt><dd>RFC 7589, [THIS RFC]
 Port Number:            6513
]]></artwork> RFC 9918</dd>
</dl>
    </section>
  </middle>
  <back>

    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC7589">
        <front>
          <title>Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication</title>
          <author fullname="M. Badra" initials="M." surname="Badra"/>
          <author fullname="A. Luchuk" initials="A." surname="Luchuk"/>
          <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/>
          <date month="June" year="2015"/>
          <abstract>
            <t>The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7589"/>
        <seriesInfo name="DOI" value="10.17487/RFC7589"/>
      </reference>
      <reference anchor="RFC6241">
        <front>
          <title>Network Configuration Protocol (NETCONF)</title>
          <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
          <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
          <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
          <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
          <date month="June" year="2011"/>
          <abstract>
            <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7589.xml"/>
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
<!-- [I-D.ietf-tls-rfc8446bis] -> [RFC9846]
draft-ietf-tls-rfc8446bis-14
companion doc RFC 4741. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6241"/>
        <seriesInfo name="DOI" value="10.17487/RFC6241"/>
      </reference>
      <reference anchor="RFC5246">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
          <author fullname="T. Dierks" initials="T." surname="Dierks"/>
          <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
          <date month="August" year="2008"/>
          <abstract>
            <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate 9846 in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5246"/>
        <seriesInfo name="DOI" value="10.17487/RFC5246"/>
      </reference> AUTH48
-->
<reference anchor="I-D.ietf-tls-rfc8446bis"> anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846">
  <front>
      <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
      <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
            <organization>Windy Hill Systems, LLC</organization> surname="Rescorla" fullname="Eric Rescorla">
         <organization>Independent</organization>
      </author>
    <date day="7" month="July" year="2023"/>
          <abstract>
            <t>   This document specifies version 1.3 of the Transport Layer Security
   (TLS) protocol.  TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.

   This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes
   RFCs 5077, 5246, 6961, and 8446.  This document also specifies new
   requirements for TLS 1.2 implementations.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-09"/>
      </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>
      <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="RFC5280">
        <front>
          <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
          <author fullname="D. Cooper" initials="D." surname="Cooper"/>
          <author fullname="S. Santesson" initials="S." surname="Santesson"/>
          <author fullname="S. Farrell" initials="S." surname="Farrell"/>
          <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
          <author fullname="R. Housley" initials="R." surname="Housley"/>
          <author fullname="W. Polk" initials="W." surname="Polk"/>
          <date month="May" year="2008"/>
          <abstract>
            <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5280"/>
        <seriesInfo name="DOI" value="10.17487/RFC5280"/>
      </reference>
      <reference anchor="RFC9525">
        <front>
          <title>Service Identity in TLS</title>
          <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
          <author fullname="R. Salz" initials="R." surname="Salz"/>
          <date month="November" year="2023"/>
          <abstract>
            <t>Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions.</t>
            <t>This document obsoletes RFC 6125.</t>
          </abstract> month="January" year="2026"/>
  </front>
  <seriesInfo name="RFC" value="9525"/> value="9846"/>
  <seriesInfo name="DOI" value="10.17487/RFC9525"/> value="10.17487/RFC9846"/>
</reference>
       <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"/>
       <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.5280.xml"/>
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9525.xml"/>
    </references>
    <?line 180?>

    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We would like to thank Per Andersson, Jürgen Schönwälder, Jeff
Hartley, Rob Wilton, and Qin Wu <contact fullname="Per Andersson"/>, <contact fullname="Jürgen Schönwälder"/>, <contact fullname="Jeff
Hartley"/>, <contact fullname="Rob Wilton"/>, and <contact fullname="Qin Wu"/> for their reviews.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA5VZy3YbNxLd4yswzGKsOSQl6mWbozhhJDlSoldEKh6fnCzA
bpDEUbO7B0CTZnz0L7OYb5jVrMY/NrcAdLNJUbLijdjoRqEet6puwa1Wi1ll
E9nld3ksrDTcZvzOqHTM7UTyq9PB8fXVe36jM5tFWcKzmdR8oEVq8kxbfiEW
eO7LqNDKLvirwUV/i8+VnfDLwhYi4f9oH+y85b0CwlKrImFVljIxHGo561bS
vdCLPsN7Oc70osuNjRmLsygVU+gWazGyLSXtqJVKG2XpqEV7WjYxnb3Wzj4z
xXCqjIFwu8ix4fx08J7hOyNTU5gut7qQDCfuscKb2eWvD968ZUJL0eWN61xq
p5rhIo35pUjFWE6hcYPNM30/1lmR47MraemRH0MBNS78lga7lwssx13GW6VJ
9BMG8U57b/lzl36eCp0s+Imwgs1kWkjs4l+Rz7k3qvEBLykyP9L3tD4VKsF6
8Mn35KB2psf0SuhoglcTa3PT3d6mL2lJzWS7/GybFraHOpsbuR1kbNPeMQJY
DJeCW/Px9mO/05cJ+dLWzlnuaHspbZVt2Lv9bETbEztNGowJwCbT5FccxblK
EbZ+mw8KnUrtljw8+lKk9VXYJlL1h3MfoJTu6ditS+8vg8+/d6vtKJuW0r2o
28IYfpYVJpGLUlaX/6rGKqlg3uQXF8fuZQnk1ffulbFaSnjmoHPIT5Av0sxU
kkh+mwmvTIQvu/xM6jTO0ib/tedXsxha7O50Xu+E5yK1lBB3/boJE6/h9zM6
2MjIGcJYq9WCTjhaRJax2/fHDuU8liMFBbBrTumdI5llZKv0m0pjgHfjEzdg
FW6eKEMpWFAi8JA3vBIKQX6NmyJ3xUDLfxZKu7wxfJTpCvaUUyKOy4zYuKGJ
8EZJERO+NTClVeQTMkupErHCSJ6NShF/NVy6RIICou0Nn6o4TiRj3/BzuCyL
CyeAsc+f/wKlSeeHhxe7wm863N3vYBP5hQVjwpuD3f3DhwfvJP7ISZ8/L0+s
/MS+5ie/zUt2dQhb627DyeetE5e+lCctPYre7O8fDpV5eNgo/Cs+5c/4lM8n
KppwGCcSk/H7NJunXBi+07odDILXz61/WVpNIquSAQUb/Lx31eO3cqyMlVrG
/IY0vCqmQ9R7SbiGiUzLER5hq637ss17CdoNZGqK0kwZp7mRllwGnKq07maq
5LxIo4lIxzKuGw5tUunsxqKyylWFZhlpPtJiis+arPZdlGSm0LLJI6mtGlHb
knwmEhWHzUZqalkqpqZGBYGiFSUKj6xcBCqPhMETqrS+j+G/bxvDJIvuG++Q
yVfXg1O0qWmeuFCF5mMnwlbZsQz7k1HnBoUgoXpSOfElYPG+68uAhn2n/gFB
ofJnmx1tO+3fMcoodKQZmVV2yBNKI+WeGRsg7uiBnJqg4Y3Lu/6g0fR/yU76
fXv6y9357ekJ/e6f9S4uqh8sfNE/u767OFn+Wu48vr68PL068ZuxyleWWOOy
97HhI9C4vhmcX1/1Lhpk4QqcOOED7hlKvAIYcy0tAClQ4aSJtBriAXt+OL75
3786+yHJdzsdymD/8Kbzep9qAYiMPy1LkSv+EShdMJHnyB+SIoDcSOTKIj2a
lDUIE9IHUJZAxd9+I8/83uVHwyjv7L8LC2TwymLps5VF57PHK482eyduWNpw
TOXNlfU1T6/q2/u48lz6vbZ49F2CQstbnTffeQjViA87XdaZV+Je1KrKlis5
yE7KZGWmoWC74JSE6rmEcBkE/4PTQIxPSYo7iGAcDmwsq1xjiyE6uUC2AfxU
v0ZKG1SYRI0nbq1qCFSLQ963+RW6hj+qTLdIpGzoKmrs2kVW2Ho1pVOQn1XS
8fdtl29PGoLqmvIR2nizLkY5MVNlCbvDRXV6BUVnQ7CaMOoVZmZC8Beg8bLV
p98x/xkJ++qm//MWDlCuymZDK5yr5SckSAonLsB++ExBfZRgOVMgHQxhiSHu
XlLvq86C3b7+Q6Jz1ZLwS7ceKmboajKN9CK3jN6s9PGe4WlmfbiXztolE59x
VjMcEegX2kVOhVv67loPA7wwl1BeU/TIWxlaIH2EAcKgc5ItcGor8AIZM6cY
GIVDiYoKsOj1kEBjkjEXmhweobL4AkFelf4DFgSSNWIMNwNkpLOWeSIWZFxN
5BBjgEQslx3JtAH6HupLGqtP/PQr2Ck5ADIgz5MwdDk1HYuqN/mAVIpvNlJJ
AHVJkhT4CXassRxmchmhK8rQr0rupF7SzMpKxytNWAg9mozKCYf9QoFNMLbe
HN3WUt7UjZewo460+CkmRUBbUPR9NQ76B5RRcX+7t3tAONISRBpnxtLhtDzN
ZZXTDjyLtEO8i3QNpfs417dQL629wYTex6WbiNu5FooxudTbH8LDIc6DjvzE
knmL6/bSoeuUkbiXZyCgK5jIYW5AAxUMVsbKbfPsdoOaoVO8yNfP8xOo1GRq
tDSauJkLZF4xlhQjP9EyuSxnVCoIHAp/8dtRP+aZ6gZ1/zRrAhBY2V3XwzyF
ysJmetGyWWsZq9XAJERoKfxsGf637c5XKvrLFH8WI6sgrOODb8bHBkw0A7cn
L1TYoBq4GRzfLK93wAKJEoarEk/8nnhJrqjJada5uq+ObsFnClEnwMuVSwB2
LpMEBz9VVwI6Rxl1eRcz8kyVueGrsQJh9RGqZ+R72PmSQuVbytPGsRfhjMzy
XW2t5tR8sX4JtqzeGyP6J2x4TrcuY++q7zZDR7nij9pJ/ZrmIX+I4xr+Zkb9
AXvwjfZDgVkgK6bGdVkxTBzfninpYlRF0xMBzJpR/ZLL77dUBDJXFKZZrEaL
+h0k27wTzSlMjoh9E8XEk5kaD0ozXaMgzI9MHOMwdFQGefA4BI7RLedBdy8C
ulCkbg5usiKVn3LHD5qkL4bNTAOAFp7xieYinUup/45jZa1JvF6dsvj5CANI
nmQLfxswBTcpx3JBt5auzlC5oZXjahwlUT0fA7p2Pe5tsdqsaqpLijc7gR15
Zhjq1nHPhMnRR1MZU8j6sGso6I7wlFXGxXQZdKJ4UQRuvHJL7D1s2vwko8nb
De9zZSSbK0xEjpWvnOJFzz1Lggq+DIWZv9B5ZjzxHkqmUiQTeJ2mRkEAxOl5
YMFiTYH2CyqTa/oHVBR8ljqLoORaXrF1Uh1NZHTvrS4H/XJ08Ic7hqFqXXel
SRyuDdl0WUV3JOuV1S0GKdLFLNwFCT/pg0DLR1cmfuiVbPUOxt+z+FcYrqGk
wt4rMZUu6ZZ3+dUdP93SsHBL4y9v9KLh6b6/6omhhF8O0ucOS2EAFibUZoMi
Q3eWvH5oly//1fT0Hz5W5pXZwo7B8Y3/oGeMGqdyRQr9Oz/t/8iPgNZxdQn+
zu+AZy3GqPUN7n8I+PFEKM2PIvqzvvHE3Qvk/g659u/Rf1q41dsyKmsHldel
Tf7b4Oy8T8+/+x21u7CVPYcHnb1wlTsU0T1BpBdR3UlkPHZVgn3upm6fjL9t
jERiZOOBsQ8yhCFR9wEbIr3nN9CyBz6rjaGbq5++/FePAel+NPnyn3T+5d9J
TJj9SY5G7AwJn0jwg9tsyD+oxGbhpuMXoOdD4ZITIILHaBiUc0wl/wf3IVnT
QBoAAA==

-->
</rfc>