<?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.5) --> 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-sha1-10" number="9905" category="std" consensus="true" submissionType="IETF" updates="4034, 5155" obsoletes="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" version="3">

  <front>

    <title abbrev="MUST NOT abbrev="Deprecating SHA-1 in DNSSEC with SHA-1">Deprecating Signature Algorithms">Deprecating the use Use of SHA-1 in DNSSEC signature algorithms</title> Signature Algorithms</title>
    <seriesInfo name="RFC" value="9905"/>
    <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="September" day="10"/> month="October"/>
    <area>OPS</area>
    <workgroup>dnsop</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

<abstract>

<?line 48?>
<t>This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1
algorithms for the creation of DNS Public Key (DNSKEY) and Resource
Record Signature (RRSIG) records.</t>
      <t>It updates RFC4034 RFCs 4034 and RFC5155 5155 as it deprecates the use of these algorithms.</t>
    </abstract>
  </front>
  <middle>

<?line 56?>

<section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t>The security of the protection provided by the SHA-1 algorithm <xref target="RFC3174"/> has been slowly diminishing
over time as various forms of attacks have weakened its cryptographic
underpinning.  DNSSEC <xref target="RFC9364"/> originally (originally defined in <xref target="RFC3110"/> target="RFC3110"/>) made extensive use
of SHA-1, for example example, as a
cryptographic hash algorithm in RRSIG Resource Record Signature (RRSIG) and Delegation Signer (DS)
records. Since then, multiple other algorithms with
stronger cryptographic strength have become widely available for DS records
and for Resource Record Signature (DNSKEY) RRSIG and DNS Public Key (RRSIG) (DNSKEY) records <xref target="RFC4034"/>.

<!--[rfced] Should the names of the IANA registries be included here
for clarity?

Original:
   Operators are encouraged to consider switching to one of the
   recommended algorithms listed in the [DNSKEY-IANA] and [DS-IANA]
   tables, respectively.

Perhaps:
   Operators are encouraged to consider switching to one of the
   recommended algorithms listed in the "DNS Security Algorithm
   Numbers" [DNSKEY-IANA] and "Digest Algorithms" [DS-IANA]
   registries, respectively.
-->

Operators are encouraged to consider switching to one of the recommended algorithms
listed in the "DNS Security Algorithm
   Numbers" <xref target="DNSKEY-IANA"/> and "DNS Security Algorithm
   Numbers" <xref target="DS-IANA"/> tables, registries, respectively.
Further, support for validating SHA-1 based SHA-1-based signatures has been
removed from some systems. As a result, SHA-1 as part of a signature algorithm
is no longer fully interoperable
in the context of DNSSEC. As adequate alternatives exist, the use of SHA-1 is
no longer advisable.</t>
      <t>This document thus further deprecates the use of RSASHA1 and
RSASHA1-NSEC3-SHA1 for DNS Security Algorithms.</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 BCP&nbsp;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-sha-1-from-dnssec-signatures-and-delegation-rrs"><name>Deprecating anchor="deprecating-sha-1-from-dnssec-signatures-and-delegation-rrs">
      <name>Deprecating SHA-1 from DNSSEC Signatures and Delegation RRs</name>
      <t>The RSASHA1 <xref target="RFC4034"></xref> target="RFC4034"/> and RSASHA1-NSEC3-SHA1 <xref target="RFC5155"></xref> target="RFC5155"/> algorithms MUST NOT <bcp14>MUST NOT</bcp14>
be used when creating DS records.  Operators of validating resolvers MUST <bcp14>MUST</bcp14> treat RSASHA1
and RSASHA1-NSEC3-SHA1 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 RSASHA1 <xref target="RFC4034"></xref> target="RFC4034"/> and RSASHA1-NSEC3-SHA1 <xref target="RFC5155"></xref> target="RFC5155"/> algorithms MUST NOT <bcp14>MUST NOT</bcp14> be
used when creating DNSKEY and RRSIG records.  Validating resolver implementations
(<xref target="RFC9499"></xref> section 10) MUST target="RFC9499" sectionFormat="comma" section="10"/>) <bcp14>MUST</bcp14> continue to support validation using these
algorithms as they are diminishing in use but still actively in use for some
domains as of this publication. Operators of validating resolvers MUST <bcp14>MUST</bcp14> treat DNSSEC signing algorithms RSASHA1 and RSASHA1-NSEC3-SHA1 as unsupported, rendering responses insecure if they cannot be validated by other supported signing algorithms.</t>

</section> algorithms.</t></section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1 for
DNSSEC Delegation delegation and DNSSEC signing since these algorithms are no
longer considered to be secure.</t>
    </section>
    <section anchor="operational-considerations"><name>Operational anchor="operational-considerations">
      <name>Operational Considerations</name>

      <t>Zone owners currently making use of SHA-1 based SHA-1-based algorithms should
immediately roll switch to algorithms with stronger cryptographic algorithms,
such as the recommended algorithms in the IANA registries <xref target="DNSKEY-IANA"></xref> and target="DNSKEY-IANA"/> <xref target="DS-IANA"></xref> tables.</t> target="DS-IANA"/>.</t>
      <t>Operators should take care when deploying software packages and
operating systems that may have already removed support for the SHA-1
algorithm.  In these situations situations, software may need to be manually built
and deployed by an operator to continue supporting the required levels
indicated by the "Use for DNSSEC Validation" and "Implement for DNSSEC
Validation" columns, which this document is not changing.</t>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>

<t>[Note to IANA, to be removed by the RFC Editor: the registry fields
listed above will be created by draft-ietf-dnsop-rfc8624-bis.]</t>

<t>IANA is requested to set has updated the "Use for DNSSEC Delegation" field of SHA-1 (1) entry in the "Digest Algorithms" registry <xref target="DS-IANA"/> <xref target="I-D.ietf-dnsop-rfc8624-bis"/> target="RFC9904"/> as follows and has added this document as a reference for SHA-1 (1) to MUST NOT.</t>

<t>IANA is requested to set the "Use entry:</t>

<dl spacing="compact">
 <dt>Value:</dt><dd> 1</dd>
 <dt> Description:</dt><dd> SHA-1</dd>
 <dt> Use for DNSSEC Signing" column of the
DNS Security Algorithm Numbers registry <xref target="DNSKEY-IANA"/>
<xref target="I-D.ietf-dnsop-rfc8624-bis"/> to MUST NOT Delegation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
 <dt> Use for DNSSEC Validation:</dt><dd><bcp14>RECOMMENDED</bcp14></dd>
 <dt> Implement for DNSSEC Delegation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
 <dt> Implement for DNSSEC Validation:</dt><dd><bcp14>MUST</bcp14></dd>
</dl>

<t>  IANA has updated the RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) algorithms.</t>

<t>All other columns should remain as currently specified.</t>

</section>

  </middle>

  <back>

    <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
  algorithm entries in the specification. These words are often capitalized. This document defines these words "DNS Security Algorithm Numbers" registry
  <xref target="DNSKEY-IANA"/> <xref target="RFC9904"/> as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, follows 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="RFC3110">
  <front>
    <title>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</title>
    <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
    <date month="May" year="2001"/>
    <abstract>
      <t>This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3110"/>
  <seriesInfo name="DOI" value="10.17487/RFC3110"/>
</reference>
<reference anchor="RFC3174">
  <front>
    <title>US Secure Hash Algorithm 1 (SHA1)</title>
    <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
    <author fullname="P. Jones" initials="P." surname="Jones"/>
    <date month="September" year="2001"/>
    <abstract>
      <t>The purpose of has added this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information as a
  reference for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3174"/>
  <seriesInfo name="DOI" value="10.17487/RFC3174"/>
</reference>
<reference anchor="RFC4034">
  <front>
    <title>Resource Records entries:
</t>

<dl spacing="compact">
  <dt> Number:</dt><dd> 5</dd>
   <dt>Description:</dt><dd> RSA/SHA-1</dd>
   <dt>Mnemonic:</dt><dd> RSASHA1</dd>
   <dt>Zone Signing:</dt><dd> Y</dd>
   <dt>Trans. Sec.:</dt><dd> Y</dd>
   <dt>Use for the DNS Security Extensions</title>
    <author fullname="R. Arends" initials="R." surname="Arends"/>
    <author fullname="R. Austein" initials="R." surname="Austein"/>
    <author fullname="M. Larson" initials="M." surname="Larson"/>
    <author fullname="D. Massey" initials="D." surname="Massey"/>
    <author fullname="S. Rose" initials="S." surname="Rose"/>
    <date month="March" year="2005"/>
    <abstract>
      <t>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication DNSSEC Signing:</dt><dd><bcp14> MUST NOT</bcp14></dd>
   <dt>Use for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.</t>
      <t>This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4034"/>
  <seriesInfo name="DOI" value="10.17487/RFC4034"/>
</reference>
<reference anchor="RFC5155">
  <front>
    <title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>
    <author fullname="B. Laurie" initials="B." surname="Laurie"/>
    <author fullname="G. Sisson" initials="G." surname="Sisson"/>
    <author fullname="R. Arends" initials="R." surname="Arends"/>
    <author fullname="D. Blacka" initials="D." surname="Blacka"/>
    <date month="March" year="2008"/>
    <abstract>
      <t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) DNSSEC Validation:</dt><dd><bcp14> RECOMMENDED</bcp14></dd>
   <dt>Implement for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5155"/>
  <seriesInfo name="DOI" value="10.17487/RFC5155"/>
</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="RFC9499">
  <front>
    <title>DNS Terminology</title>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
    <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
    <date month="March" year="2024"/>
    <abstract>
      <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions DNSSEC Signing:</dt><dd><bcp14> NOT RECOMMENDED</bcp14></dd>
   <dt>Implement for many of the terms used in the DNS in a single document.</t>
      <t>This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="219"/>
  <seriesInfo name="RFC" value="9499"/>
  <seriesInfo name="DOI" value="10.17487/RFC9499"/>
</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 Validation:</dt><dd><bcp14> MUST</bcp14></dd>
</dl>

<dl spacing="compact">
   <dt>Number:</dt><dd> 7</dd>
  <dt> Description:</dt><dd> RSASHA1-NSEC3-SHA1</dd>
   <dt>Mnemonic:</dt><dd> RSASHA1-NSEC3-SHA1</dd>
   <dt>Zone Signing: </dt><dd>Y</dd>
   <dt>Trans. Sec.:</dt><dd> Y</dd>
   <dt>Use for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference DNSSEC Signing:</dt><dd><bcp14> MUST NOT</bcp14></dd>
   <dt>Use 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> DNSSEC Validation:</dt><dd><bcp14> RECOMMENDED</bcp14></dd>
   <dt>Implement for DNSSEC Signing:</dt><dd><bcp14> NOT RECOMMENDED</bcp14></dd>
   <dt>Implement for DNSSEC Validation:</dt><dd><bcp14> MUST</bcp14></dd>
</dl>

    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <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.3110.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.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.9499.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 Security (DNSSEC) Algorithm Numbers</title>
          <author initials="" surname="IANA" fullname="IANA">
      <organization></organization>
            <organization/>
          </author>
    <date year="n.d."/>
        </front>
      </reference>
      <reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-rr-types">
        <front>
    <title>Delegation
          <title>DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms</title>
          <author initials="" surname="IANA" fullname="IANA">
      <organization></organization>
            <organization/>
          </author>
    <date year="n.d."/>
        </front>
      </reference>

<!--
draft-ietf-dnsop-rfc8624-bis-13
companion doc RFC 9904
in AUTH48 as of 10/30/25
-->
      <reference anchor="I-D.ietf-dnsop-rfc8624-bis"> anchor="RFC9904" target="https://www.rfc-editor.org/info/rfc9904">
        <front>
          <title>DNSSEC Cryptographic Algorithm Recommendation Update Process</title>
          <author fullname="Wes Hardaker" initials="W." surname="Hardaker"> surname="Hardaker" fullname="Wes Hardaker">
            <organization>USC/ISI</organization>
          </author>
          <author fullname="Warren Kumari" initials="W." surname="Kumari"> surname="Kumari" fullname="Warren Kumari">
            <organization>Google</organization>
          </author>
          <date day="4" month="June" year="2025"/>
      <abstract>
	 <t>   The DNSSEC protocol makes use of various cryptographic algorithms to
   provide authentication of DNS data and proof of non-existence.  To
   ensure interoperability between DNS resolvers and DNS authoritative
   servers, it is necessary to specify both a set of algorithm
   implementation requirements and usage guidelines to ensure that there
   is at least one algorithm that all implementations support.  This
   document replaces and obsoletes RFC8624 and moves the canonical
   source of algorithm implementation requirements and usage guidance
   for DNSSEC from RFC8624 to an IANA registry.  This is done both to
   allow the list of requirements to be more easily updated, and to
   allow the list to be more easily referenced.  Future extensions to
   this registry can be made under new, incremental update RFCs.  This
   document also incorporates the revised IANA DNSSEC considerations
   from RFC9157.

   The document does not change the status (MUST, MAY, RECOMMENDED,
   etc.) of the algorithms listed in RFC8624; that is the work of future
   documents.

	 </t>
      </abstract> month='November' year='2025'/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-rfc8624-bis-13"/> name="RFC" value="9904"/>
        <seriesInfo name="DOI" value="10.17487/RFC9904"/>
      </reference>
    </references>

<?line 140?>

    <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, Peter Dickson, Thomas Graf, Paul Hoffman, Russ Housley, Shumon
Huque, Barry Leiba, S Moonesamy, Yoav Nir, Florian Obser, Peter
Thomassen, Stefan Ubbink, Paul Wouters, Tim Wicinski, <contact
      fullname="Mark Andrews"/>, <contact fullname="Steve Crocker"/>, <contact
      fullname="Peter Dickson"/>, <contact fullname="Thomas Graf"/>, <contact
      fullname="Paul Hoffman"/>, <contact fullname="Russ Housley"/>, <contact
      fullname="Shumon Huque"/>, <contact fullname="Barry Leiba"/>, <contact
      fullname="S. Moonesamy"/>, <contact fullname="Yoav Nir"/>, <contact
      fullname="Florian Obser"/>, <contact fullname="Peter Thomassen"/>,
      <contact fullname="Stefan Ubbink"/>, <contact fullname="Paul Wouters"/>,
      <contact fullname="Tim Wicinski"/>, 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-sha1</t>

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

<!-- ##markdown-source:
H4sIAAAAAAAAA61YbW/bOBL+zl8xl35JANtN+rK7NQ6H9SZpE7RNelbaolcU
B0oaSzxTpMqh7BqB//thSMpWmnT39u4+haFocl6eeeYhx+Ox8MprnMLBGbYO
C+mVqcDXCB0h2AVkF7PxCSgDZ1dZdn4KpCojfecQpK6sU75u6EDIPHe4msLb
99kNXF3f9KvXytdxC1HawsgGp1A6ufBjhX4xLg3Zdtx05MfG+jHV8mR8ciwK
6bGybjMF8qVQrZuCdx35J8fHL46fCPIOZTOFy/Obl6JrS+mRpvDs+OmzETw/
ef5cCPLSlP+U2hqcwgZJtGoKn70tRkDWeYcLGgFtmjgobdHItlWm+iKE7Hxt
3VQAjAUAgDI0hY8TuJCulEt0YTI68hHp7rR11RTeZ6ePL7PLMIGNVHoK7Ouv
dVpJE4P+3vavu0Y6NdxcOodmOB92f2VtpXG4+Tos/HUZFoa9hbGukV6tkN2Y
vzx9cnLyIg2fnpwc74Y/P0tDjl0acgDT8Jf9ghfPXvQ7vHj6U5g9u8pen38a
X86uZtNgzz5yey/4a5jw0lXop3BQe9/S9PHj9Xo9UdLIiXXVY0kMqwaNp8el
oTFhMZa6GpuuydE9ODf5VvtGH8TNI4TPbCOVgSvZIGQb8thAhkXnlN/AYQTk
Ecx61MJV3Ihdyf4rN37XCxo7N/abFumujaixkl5ZA5mqDDo4PMuOYI5kO1cg
zLGwroTD+fwIbjYtwpmqkPzebBJCmcU+wUKMx2OQOXknCy/ETa2IEd2xHVCm
okYa1jQP59ksu5idgDRlPx5fZeenT8c8FPvihoV14ReFw2i4XXDy4V2Xa1XA
a4zRfX3+6SjulnwRyZdsxxiH83l2+eoIXPhAEyEuPaQC7mEYt4g4BEmgfscJ
GpLQJEaiUWWpUYhHcGm8s2VXsM0cFwTq0ZBi0DrrMXzn4UqVWEK+CZ8i7e12
h9vbVDHbLdSSIEc0QNqu9QZK1SijqFamEnaFDrxqkG1fSadsFyLYEB8qvZfF
kqCWK4Q1yiUaLEF5gsJtWm8rJ9taFaIzJbpWGaNMNYGeTIMNXH7bLVinKmWk
1pvetJPj7RYaWSLgN4+G1CqESvQcPgqJxG+yaXWwToo7h7Jb9cBjZSCkKyTk
YdiKPpEAmTIFcuTMCJpOe8WHWF+jG6QotAOmb2sqdHd9BmZ1U/k6BifHwjYI
a1Wi3oBcSaVlrjH4cJb1CALBxvHc9wU0AN0Qm9/j9i4gYygZhdvtBMR1i056
6wikQ0BT2M7JCkvwFgprSJXogNbKF3Vomhas2dUXb9k0aBhTgwgIrchzzk1Y
dXs7oNHtNth4e5v4aLsFz07TCBxSy0hdod5MxMvOcWRHQF3bWudDBFZSqzK2
7wjeXBKW+35NO9wKh41dYQkLZxsgjjMFuqQJzAgkn9ZpP+qLgKCVzgf8PtT+
QSgCY0HHrC46BqUyHp3lAOYaRfK2sMbjN58IJDs/jeeV+LWTnnf06EzgNQL8
psiPHlAiJPZnyXKliE+YfE98vua6i3H6AYEMGFDcZ8CItKts30JmQ6p59Ajm
+LVTDgPfg7FeRqIBAOaaJW5gHUB1wKLoYBT/sjji8fz87+8v5+dnPM4uZm/e
7AZxBW9zkF1cv3+TlvBo/+PT67dvz6/O4u9Zb3039Xb2Ke7BgDq4fndzeX01
e3MQYTeMEyPbW8gxZqx1yOiUBCVS4VSOpQgqBX47fQcnz2KFsJ7YbuP4l8iJ
61D5fJo1epP+9TVuQLYtSpd2kVpDIVvlpaYRH0O1XRuo0XEKH8FQhMZ8B4wm
Asz2WP6OlOZzihTfJ/VzKuQvP2hwYQH3mC/D6uwzJPKAkjL4kRqfqQbEMwHY
s4NdDIvPIVm9Qpd2Y63q/whrA0bjlmdCo8IJwOWCKyvy6GCRXQhZFNhyru6y
6MAZTu2OOGMlMZ77PXLUds2zotzHsbXK+Gh4jtH2CIedTf/PMEOO4qEwB0qM
O4YOtA/6h/txBsUNjcEcXCBx+DkJ1i/c8INbJ8dH8VBmIGW6gPmePPvcWQMd
pdsP4VABSUpQdjhs9gxo5pK880BeaQ0yUXT/hTmE+VWUQZqGnUJ/UARtaEPh
3MmfApMY3MR4zcDQ3xd1IEl0JrmNJXcV1hnpnNYawn2iQS2i04U0xnqGQ7IL
S5FvEiZ3mz1gzURwRe/o8zR1zJSl/0io/oE/C+v6YAy4IPX5YYioVyd3FGPI
p7EiNZO+pccGnye5GHkp5kdZI/U9R/4Ruv7acJaKji9jXm+gkUs++U7vih15
YADVttOlUE2DpZKekeOs1nz+d6oJfqCa9stGgrqiTlj9kfxIjfjzQHXE0v2c
NMeXJDkmYiB/opng5RKh4KCFei2x1XYTwmsXfs3zrSyWsor0LGyMGX+P6gJ8
LT00chMlntQOZbmBXo0MxcxOgu/LkNnQpByS8l0M//5s3tfgLnmNNF2Qx3mn
tA86MRocNb40YJN/Sc5FXkhG9I8gLvb4EjSuUJNQpuSa3d8TDt6nMk+I+7Aj
k4PYey97dhqsEsNVhdVdY2gE61oV9XftOSgrD0UtTcV3gXCvmV3N7oHw85X1
gdX46yjFoI9ssnX+8hTOS+Utv6cE5ypF3m1goVCX1EtTmVu+nTCf5enWF/e4
93DjFsUvPz15Ns4VTb4IEQxTFIKGYStmWfQPBmpfsAfx/CScxcG9G+/B3tKh
Nr69/cvl+GzysD3bLQg+LRbe4ckR29L3ncmftDWLNNLnqrf0YXXYvyvcMXoo
8sUfGT6wVPTF0DPh4fOjH7Hh4c9Hd9l3pnWi6YSxvpAdhocSOeQrvl+ohcIy
3aNzWSwZbbNiaexaY1kFoRvbf3wjIdZ2DgtmrqTvm6iG2ULqKs5jKNIg4njF
wmpt13xR5se7cK9QhWol/0ixDtT8DMe38bILjD0ohim8lW4JM1M6XNNIZB5X
CKfOFku+C71DzyJJFUuyZgQ3tW0kwSsnFyN4JzsNF3axaKQZwbwjggvbkcbN
CLK6a6wRF93XDkfwm3RuA29Q5XIEGby11iDJZjOCT1au4Eq5EbzU1ilp4Dqn
3cEinkcsezOPC2ngfZ4rs0yHf7SdR0cjuFENfFSFMrRUUTBzXBppNqLBCJx0
gzy7yq7f8R0iNJLK2a6NDFoqKjriVhLjw2UZm+1pTOfgbtaRrLBnr5C7vjVy
X0+x/hcWngv8g1oyH551y9qujArW3XnkrFVVa1XVPjaZhJ5ErIGwgnyJrx6D
tmMDcYv+7Y+89DQpDfGbnrdWU3g/gzXmpDx33L8OuarVKAmBZapPmOiFXdey
aN0rqb9xFF4pX3c5fEBH6bnqDo6E+FgrjfeZNry6QMmxsi1Pjvj1qZAmiB+F
a9ZM/My2xHIkFkyQfHGZip1jVTh5Utjmcf/c+ziyZv/vQ0/e/4u7/waxDAzO
whcAAA==

-->
</rfc>