<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.2) --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<?rfc docmapping="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dnsop-must-not-ecc-gost-07" number="9906" updates="" obsoletes="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" version="3">

  <front>
    <title abbrev="MUST NOT DNSSEC with ECC-GOST">Deprecate usage Usage of ECC-GOST within DNSSEC</title>
    <seriesInfo name="RFC" value="9906"/>
    <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
      <organization>USC/ISI</organization>
      <address>
        <email>ietf@hardakers.net</email>
      </address>
    </author>
    <author initials="W." surname="Kumari" fullname="Warren Kumari">
      <organization>Google</organization>
      <address>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <date year="2025" month="June" day="03"/> month="November"/>
    <area>OPS</area>
    <workgroup>dnsop</workgroup>

<abstract>

<?line 53?>
      <t>This document retires the use of GOST R 34.10-2001 (mnemonic
      "ECC-GOST") and GOST R 34.11-94 within DNSSEC.</t>

<t>RFC5933 (now historic)
      <t>RFC 5933 (Historic) defined the use of GOST R 34.10-2001 and GOST R 34.11-94
      algorithms with DNS Security Extensions (DNSSEC).
      This document updates RFC5933 RFC 5933
by deprecating the use of ECC-GOST.</t>
    </abstract>
  </front>
  <middle>

<?line 62?>

<section anchor="introduction"><name>Introduction</name> anchor="introduction">
  <name>Introduction</name>
      <t>The use of the GOST R 34.10-2001 and GOST R 34.11-94 algorithms are documented in <xref target="RFC5933"/> and their use with
the DNS Security Extensions (DNSSEC) <xref target="RFC9364"></xref> was documented is further described in <xref target="RFC5933"/>. target="RFC9364"/>. These two algorithms were deprecated by the Orders of the
Federal Agency for Technical Regulation and Metrology of Russia
(Rosstandart) in August 2012, 2012 and were superseded by GOST 34.10-2012
and GOST 34.11-2012 34.11-2012, respectively. The use of these newer two newer
algorithms in DNSSEC is documented in <xref target="RFC9558"/> target="RFC9558"/>, and their associated
requirement levels are not changed by this document.</t>
      <t>Thus, the use of GOST R 34.10-2001 (mnemonic GOST-ECC) "ECC-GOST") and GOST R 34.11-94
is no longer recommended for use in DNSSEC <xref target="RFC9364"/>.</t>
      <section anchor="requirements-notation"><name>Requirements notation</name>

<t>The anchor="requirements-notation">
        <name>Requirements Notation</name>
        <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 in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="deprecating-ecc-gost-algorithms-in-dnssec"><name>Deprecating anchor="deprecating-ecc-gost-algorithms-in-dnssec">
      <name>Deprecating ECC-GOST algorithms Algorithms in DNSSEC</name>
      <t>The GOST R 34.11-94 algorithm <xref target="RFC5933"/> algorithm MUST NOT <bcp14>MUST NOT</bcp14> be used when
creating DS Delegation Signer (DS) records.  Validating resolvers MUST <bcp14>MUST</bcp14> treat GOST R 34.11-94
DS records as insecure.  If no other DS records of accepted
cryptographic algorithms are available, the DNS records below the
      delegation point MUST <bcp14>MUST</bcp14> be treated as insecure.</t>

<t>The ECC-GOST GOST R 34.10-2001 algorithm <xref target="RFC5933"/> algorithm MUST NOT (mnemonic "ECC-GOST") <bcp14>MUST NOT</bcp14> be used when creating
DNSKEY DNS Public Key (DNSKEY) and RRSIG Resource Record Signature (RRSIG) records.  Validating resolvers MUST <bcp14>MUST</bcp14> treat
RRSIG records created from DNSKEY records using these algorithms as an
unsupported algorithm. algorithms. If no other RRSIG records of accepted cryptographic
algorithms are available, the validating resolver MUST <bcp14>MUST</bcp14> consider the
associated resource records as insecure.</t>
    </section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document potentially increases the security of the DNSSEC ecosystem by
deprecating algorithms that are no longer recommended for use.</t>
    </section>
    <section anchor="operational-considerations"><name>Operational anchor="operational-considerations">
      <name>Operational Considerations</name>
      <t>This document removes support for ECC-GOST. Zone operators currently making use
of ECC-GOST based ECC-GOST-based algorithms should switch to algorithms that remain supported.
DNS registries should prohibit their clients from uploading and publishing
ECC-GOST based
ECC-GOST-based DS records to ensure that they are using algorithms which that are
supported by DNSSEC validators, validators and so thus can be DNSSEC validated.</t>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>

<t>[Note to IANA,

<!--IANA Action: add "DEPRECATED" to be removed by "GOST R 34.11-94" -->

 <t>  IANA has updated the RFC Editor: GOST R 34.10-2001 (12) entry in the "DNS
   Security Algorithm Numbers" registry fields
listed above will be created by draft-ietf-dnsop-rfc8624-bis.]</t>

<t>IANA is requested to set the "Use <xref target="DNSKEY-IANA"/> <xref target="RFC9904"/> as
   follows: </t>

<dl spacing="compact">
  <dt>Number:</dt><dd> 12</dd>
  <dt>Description:</dt><dd> GOST R 34.10-2001 (DEPRECATED)</dd>
  <dt>Mnemonic:</dt><dd> ECC-GOST </dd>
  <dt>Zone Signing:</dt><dd> Y 	</dd>
  <dt>Trans. Sec.:</dt><dd> * </dd>
  <dt>Use for DNSSEC Signing", "Use Signing:</dt><dd><bcp14>MUST NOT</bcp14></dd>
  <dt>Use for DNSSEC
Validation", "Implement Validation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
  <dt>Implement for DNSSEC Signing", and "Implement Signing:</dt><dd><bcp14>MUST NOT</bcp14></dd>
  <dt>Implement for DNSSEC
Validation" columns Validation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
  <dt>Reference:</dt><dd><xref target="RFC5933"/>, <eref target="https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/">Change the status of GOST
       Signature Algorithms in DNSSEC in the DNS Security Algorithm Numbers registry
<xref target="DNSKEY-IANA"/> <xref target="draft-ietf-dnsop-rfc8624-bis"/> for ECC-GOST (12) IETF stream to MUST NOT.  Note that previously
the
       Historic</eref>, and RFC 9906</dd>
</dl>
<t>
   Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC
   Delegation" columns were already MUST NOT.</t>

<t>IANA is requested to set to <bcp14>MUST NOT</bcp14>.
</t>
<t>
   IANA has updated the "Use GOST R 34.11-94 (3) entry in the "Digest Algorithms"
   registry <xref target="DS-IANA"/> as follows:
</t>
<dl spacing="compact">
  <dt>Value:</dt><dd> 3</dd>
  <dt>Description:</dt><dd> GOST R 34.11-94 (DEPRECATED)</dd>
  <dt>Use for DNSSEC Delegation", "Use Delegation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
  <dt>Use for DNSSEC
Validation", "Implement Validation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
  <dt>Implement for DNSSEC Delegation", and "Implement Delegation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
  <dt>Implement for DNSSEC
Validation" columns of Validation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
  <dt>Reference:</dt><dd><xref target="RFC5933"/>, <eref target="https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/">Change the "Digest Algorithms" registry <xref target="DS-IANA"/>
for status of GOST R 34.11-94 (3) to MUST NOT.  Note that previously
       Signature Algorithms in DNSSEC in the IETF stream to
       Historic</eref>, and RFC 9906</dd>
</dl>
<t>
   Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation"
   columns were already MUST NOT.</t> set to <bcp14>MUST NOT</bcp14>.
</t>
    </section>
  </middle>
  <back>
    <references title='References' anchor="sec-combined-references">
      <name>References</name>
      <references title='Normative References' anchor="sec-normative-references">

<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="RFC5933">
  <front>
    <title>Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC</title>
    <author fullname="V. Dolmatov" initials="V." role="editor" surname="Dolmatov"/>
    <author fullname="A. Chuprina" initials="A." surname="Chuprina"/>
    <author fullname="I. Ustinov" initials="I." surname="Ustinov"/>
    <date month="July" year="2010"/>
    <abstract>
      <t>This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC).</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5933"/>
  <seriesInfo name="DOI" value="10.17487/RFC5933"/>
</reference>
<reference anchor="RFC9364">
  <front>
    <title>DNS Security Extensions (DNSSEC)</title>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
    <date month="February" year="2023"/>
    <abstract>
      <t>This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="237"/>
  <seriesInfo name="RFC" value="9364"/>
  <seriesInfo name="DOI" value="10.17487/RFC9364"/>
</reference>
        <name>Normative References</name>
        <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.5933.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.9364.xml"/>

        <reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml"> target="https://www.iana.org/assignments/dns-sec-alg-numbers">
          <front>
    <title>Domain Name System
            <title>DNS Security (DNSSEC) Algorithm Numbers</title>
    <author initials="" surname="IANA" fullname="IANA">
      <organization></organization>
            <author>
              <organization>IANA</organization>
            </author>
    <date year="n.d."/>
          </front>
        </reference>
        <reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-rr-types">
          <front>
    <title>Delegation Signer (DS) Resource Record (RR) Type Digest
            <title>Digest Algorithms</title>
    <author initials="" surname="IANA" fullname="IANA">
      <organization></organization>
            <author>
              <organization>IANA</organization>
            </author>
    <date year="n.d."/>
          </front>
        </reference>

<!--
draft-ietf-dnsop-rfc8624-bis-13
companion doc RFC 9904
AUTH48 as of 10/30/25
-->
        <reference anchor="draft-ietf-dnsop-rfc8624-bis" target="https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8624-bis"> anchor="RFC9904" target="https://www.rfc-editor.org/info/rfc9904">
          <front>
    <title>DNS Security
            <title>DNSSEC Cryptographic Algorithm Numbers</title> Recommendation Update Process</title>
            <author initials="K." surname="W." fullname="Kumari, W.">
      <organization></organization> initials="W." surname="Hardaker" fullname="Wes Hardaker">
              <organization>USC/ISI</organization>
            </author>
    <date year="n.d."/>
  </front>
</reference>

    </references>

    <references title='Informative References' anchor="sec-informative-references">

<reference anchor="RFC9558">
  <front>
    <title>Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC</title>
            <author fullname="B. Makarenko" initials="B." surname="Makarenko"/>
    <author fullname="V. Dolmatov" initials="V." role="editor" surname="Dolmatov"/>
    <date month="April" year="2024"/>
    <abstract>
      <t>This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC).</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9558"/>
  <seriesInfo name="DOI" value="10.17487/RFC9558"/>
</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"/> initials="W." surname="Kumari" fullname="Warren Kumari">
              <organization>Google</organization>
            </author>
            <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> month='November' year='2025'/>
          </front>
          <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/> value="9904"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/> value="10.17487/RFC9904"/>
        </reference>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9558.xml"/>
      </references>
    </references>

<?line 135?>

<section anchor="acknowledgments"><name>Acknowledgments</name> anchor="acknowledgments" numbered="false">
  <name>Acknowledgments</name>
      <t>The authors appreciate the comments and suggestions from the
      following IETF participants in helping produce this document: Mark Andrews, Steve Crocker,
Brian Dickson, Thomas Graf, Russ Housely, Shumon Huque, Paul Hoffman, S Moonesamy, Peter
Dickson, Peter Thomassen, Stefan Ubbink, Paul Wouters, Tim Wicinski, <contact
      fullname="Mark Andrews"/>, <contact fullname="Steve Crocker"/>, <contact
      fullname="Brian Dickson"/>, <contact fullname="Peter Dickson"/>, <contact fullname="Thomas Graf"/>,  <contact fullname="Paul Hoffman"/>, <contact
      fullname="Russ Housely"/>, <contact fullname="Shumon Huque"/>, <contact fullname="S. Moonesamy"/>, <contact fullname="Peter Thomassen"/>,
      <contact fullname="Stefan Ubbink"/>,
      <contact fullname="Tim Wicinski"/>, <contact fullname="Paul Wouters"/>, and the many members of the DNSOP working group
      Working Group that discussed this draft.</t>

</section>
<section anchor="current-algorithm-usage-levels"><name>Current algorithm usage levels</name>

<t>The DNSSEC scanning project by Viktor Dukhovni and Wes Hardaker
highlights the current deployment of various algorithms on the
https://stats.dnssec-tools.org/ website.</t>

<t>&lt;RFC Editor: please delete this section upon publication&gt;</t>

</section>
<section anchor="github-version-of-this-document"><name>Github Version of this document</name>

<t>While this document is under development, it can be viewed, tracked,
fill here:</t>

<t>https://github.com/hardaker/draft-hardaker-dnsop-must-not-gost</t>

<t>&lt;RFC Editor: please delete this section upon publication&gt;</t> specification.</t>
    </section>

  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA81YbW/jNhL+zl8xcL8kgOW8bPqyxuGuqZPdDbpJ9uxsF72i
ONDUWOKZIlUOZVcI/N+LIWVbzubSl/tynyxT5GieZx7ODJllmQg6GBzD4Apr
j0oGhIZkgeAWcD2ZZG/vZw+w1qHUFq7uZrPryUDI+dzjagy3H2cPcHf/0L2I
03aLRO6UlRWOIfdyETKNYZHlllydVQ2FzLqQoVJZ4Shkp18L/nThfDsGCrnQ
tR9D8A2F89PT16fngoJHWY3h5vrhjRCCgrT5v6VxFsfQIolaj+Gn4NQQyPng
cUFDoLZKD7lTlaxrbYufhZBNKJ0fC4BMAABoS2P4NIJ30udyiT4OJs8/IR0O
O1+M4eNscnIzu4kDWEltxsDgvi27mTSyGD4z/31TSa/7xqX3aPvj0fpb5wqD
fePrOPHbZZwYbQvrfCWDXiHDmL6ZnJ+dve4ev3z96lX3+PrVVxdjIYDj8/31
j9nN5d3lOFrec7D3h9/GgSB9gWEMgzKEmsYnJ+v1eqSllSPnixNJpAtboQ10
klvKCFUmTZHZppqjf3Zs9GsZKjNIxpPcrlwltYU7WSHMWgpYwQxV43Vo4SjJ
6RguTeG8DmUFd8kQQ5n9JRgvoqDM+yy0NdKhj2iwkEE7CzNdWPRwdDU7himS
a7xCmKJyPoej6fQYHtoa4UoXSGHvNjH3n6nfL9Q3X51fZHNNByjgAMZWdkP4
NDp4kfSyG96i3MYql0EGL9US/Yg/GtHmTp1wCE5ecuYA+t1sH4/nwgAghLaL
JzJ8/eWX34yFEFmWgZwT+xGEeCg18RZsmG7wGLRHglBypol5JuaYKby6GJ2d
Zuenp2dwVFmsnNVKDLb5ZHB8mIZGQnRqhyPr1lBqCs5rdQw5LrTF/OUvSJv3
R8+y1xdC7gKXUtkBC9e/BrSknaWdQEdwCK2pcxmQtrtQzFvIu6yqbdH3Zwtq
lLiqdJ4bFOILuLHBu7xRrDpmbreCF/8hFPAEheCVv4cEfurSxc+wlntEmIO2
4vGxA7TZMGIkhLB2B99BjzuomMO8jf7e+xw9dd6LN5ijlwYuC7SqhYXz8ICq
tFpJA1MsGpP2GmO6xeCdcUXLi6cNkZbiaOoopn3pwzFoC5dN0VCA89Oz82Fc
Fd2gpkZPmCc3Ijlbws7OxY6wRBePgUeqUbGMTRsB9jgnBItr9Iy4r4+dDEE/
oQsiXbwTNpvoVShRe5BETmlmR3j8pdEeo2QMrtAQSI9gXQBVSltsCexZHrEW
Ghr+wV0T32XXk8nxszrXBNaBcbZADx6Vqyq0TBjHhK3v0SUwr7662GxGQogv
voDp3ns2E2SSKkBkboktrJ3PCQbcHQyG6Ze7BH6eXv/z4830+oqfZ+8u37/f
PaQZbGYwe3f/8X03hZ/2iyf3t7fXd1dpPTceT4ZuL39MNhj14P7Dw8393eX7
AeM5oDPyHRzMGWpAX3vk4LHykZTXc8xFLN3w3eQDnF0kGrjIbjbw+PiP6ZvJ
N2dfX2w2sC7RJvE5a9rubyixBVnXKH1nRhoDStY6SEND/g6Vbm2hRI8j3vZX
vTSx67qek1vKCU+3fG+H7lft27N51EwevRPKY/rO1SzG3uc0AvhBGp2ncY/k
zIo3bjTAfVf4TEL7xYxGW+LkgiOAmwVry4USfe8LrFepFNasf+XbOrjCy7rU
qo+SoyJXUhs5N5i0zolra2OOxq1jKsn3lbl22obk6RyTsymSO58SZTtW/wRX
sOVKpAYqxnk6nd28/ePMiYP5ySLvNO+qri3bvWuoqxKEB6wQSCsaS01dOx/R
bV+ODug+/FKPcThgXLzM+OpzPAmOcpZ0zqmwRLFPZ3FW7IeeEwSLe1d4Jp2F
GDl62hjULqANWhrTgrZMFHVtAm0NdHWwy02oHKXWcd6KfqHtAQylDF12fSHh
RTfv684zaX7HU4+VWyFBF5FoZVfR4V/OIrhozHkC1XD3HkwLlVyydw2h6B+u
5pL6MY25oTE50FoHVXKaeorHY2yed4IYibRNCk3Ba9xZqL0r9VyHrgQpo2PS
jtprauNkHtmyOdTN3GgqWepP/Ort4eAALTWcOtmLlOU8drrttwOlViW/EnvN
zttt2DqBOU8pcZIDJS1vvMMJjIs7osu7y8/i8dOdCzGD89thl8pTWHbdx/TN
BK5zHbi15v8dPy0sNJqchNEUN9PcrRDW2hi2sd2f3Lq90CuPfhYiOqYJuJxj
NBUcEEZiYPCRMOqiw8QHCG0LLlKHb8Q2fzjLL2+q2qTO4NnFsa49N6dvBpQz
TWWpt11eaOZ3vIjHx945MRa6lyjYbA50D0dn58cggtul0hFAihKLpfa40q4h
04qX6PnvAHunsYHYAowNnzQeZd7uv/snQ9Mz/Jeic7D+LwVo8NnBcbBX6+Nj
d+TdbASbe1r7j14dw/8H63ySmUu15F17qZbWrQ3mRWwUUw1OB13i1shjrB4R
fkrHgVI2aArmIp5OYqLiGQtnjFtzlonXP7X0QStdS16kuY0yfLfD+S5vFB72
emO4lX4Jlzb3uKYhzAKuECbe8RF5KL7zWlq40mpJzg7hoXSVJHjr5WIYDx7w
zjWEph3CrGwqZ+Fd80uDQ/ggGwPv3GJRSTuEGdw6Z5Fk1Q7hAwb0Ymcy/u0M
E7eHs4ALaeHjfK7tsrP0yTUBOSM+6Ao+aaUtLfUQtgcIUUnbQoVpx+739f0H
7rZjWSm8a+oU9lyTaojiEZiZ4F0cc+kk1aJe35Pu+tIpJAWpCzwpaW1H6n9Q
Bc6IP+hlYGk0y9KtrI7OHVyRlboojS7KkOp2V/r4ZGhcG6XlFrCSnjXZLxjO
RpDbOwwKMtAot8T3SME5Q/EWA9Y4Jx24Wv+tn9xrw60CcFMYuuATxhM0NDW3
iFzcVBTx35mFtzqUzRx+QM+H4MRmTzBCfCq1eaIiziaN5e4nZ65czYND0GFb
u1Ya15gPId295EOx4IrCDf5Y7IAV8csj5aqT7WVhdyWz/fv0hpRvR/8XuL8B
elkXheIVAAA=

-->
</rfc>