<?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.26 (Ruby 3.3.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-jose-deprecate-none-rsa15-01" category="std" consensus="true" submissionType="IETF" updates="7518" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.0 -->
  <front>
    <title>JOSE: Deprecate 'none' and 'RSA1_5'</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-jose-deprecate-none-rsa15-01"/>
    <author fullname="Neil Madden">
      <organization>Teya</organization>
      <address>
        <email>neil.e.madden@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="March" day="20"/>
    <area>Security</area>
    <workgroup>Javascript Object Signing and Encryption</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 56?>

<t>This document updates <xref target="RFC7518"/> to deprecate the JWS algorithm "none" and the JWE algorithm
"RSA1_5". These algorithms have known security weaknesses. It also updates the Review
Instructions for Designated Experts to establish baseline security requirements that future
algorithm registrations should meet.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://NeilMadden.github.io/jose-deprecate-none-rsa1_5/draft-ietf-jose-deprecate-none-rsa15.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Javascript Object Signing and Encryption Working Group mailing list (<eref target="mailto:jose@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/jose/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/jose/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/NeilMadden/jose-deprecate-none-rsa1_5"/>.</t>
    </note>
  </front>
  <middle>
    <?line 63?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>JSON Web Algorithms (JWA, <xref target="RFC7518"/>) introduced several standard algorithms for both JSON Web
Signature (JWS) and JSON Web Encryption (JWE). Many of these algorithms have stood the test of time
and are still in widespread use. However, some algorithms have proved to be difficult to implement
correctly leading to exploitable vulnerabilities. This document deprecates two such algorithms:</t>
      <ul spacing="normal">
        <li>
          <t>The JWS "none" algorithm, which indicates that no security is applied to the message at all.</t>
        </li>
        <li>
          <t>The JWE "RSA1_5" algorithm, which indicates RSA encryption with PKCS#1 version 1.5 padding.</t>
        </li>
      </ul>
      <t>Note that RSA signatures using PKCS#1 version 1.5 padding (<tt>RS256</tt>, <tt>RS384</tt>, and <tt>RS512</tt>) are
unchanged by this specification and can still be used.</t>
      <t>Additionally, this document also updates the Review Instructions for the JOSE Designated Experts,
to establish baseline security requirements for future JOSE algorithm registrations. Only algorithms
that are reasonably believed to satisfy these requirements should be registered in future.</t>
      <section anchor="the-none-algorithm">
        <name>The 'none' algorithm</name>
        <t>The "none" algorithm creates an Unsecured JWS, whose contents are completely unsecured as the name
implies. Despite strong guidance in the original RFC around not accepting Unsecured JWS by default,
many implementations have had serious bugs due to accepting this algorithm. In some cases, this has
led to a complete loss of security as authenticity and integrity checking can be disabled by an
adversary simply by changing the algorithm ("alg") header in the JWS. The website <xref target="howmanydays"/>
tracks public vulnerabilities due to implementations mistakenly accepting the "none" algorithm. It
currently lists 12 reports, many of which have high impact ratings. The following is a partial list
of issues known to have been caused by misuse of the "none" algorithm, with a Common Vulnerability
Enumeration <xref target="CVE"/> identifier, and a Common Vulnerability Scoring System <xref target="CVSS"/> score
indicating the severity of the impact:</t>
        <ul spacing="normal">
          <li>
            <t><eref target="https://nvd.nist.gov/vuln/detail/CVE-2018-1000531">CVE-2018-1000531</eref> - CVSS: 7.5 (High)</t>
          </li>
          <li>
            <t><eref target="https://nvd.nist.gov/vuln/detail/CVE-2017-10862">CVE-2017-10862</eref> - CVSS: 5.3 (Medium)</t>
          </li>
          <li>
            <t><eref target="https://nvd.nist.gov/vuln/detail/CVE-2022-23540">CVE-2022-23540</eref> - CVSS: 7.6 (High)</t>
          </li>
          <li>
            <t><eref target="https://nvd.nist.gov/vuln/detail/CVE-2020-15957">CVE-2020-15957</eref> - CVSS: 7.5 (High)</t>
          </li>
          <li>
            <t><eref target="https://nvd.nist.gov/vuln/detail/CVE-2021-29500">CVE-2021-29500</eref> - CVSS: 7.5 (High)</t>
          </li>
          <li>
            <t><eref target="https://nvd.nist.gov/vuln/detail/CVE-2021-29451">CVE-2021-29451</eref> - CVSS: 9.1 (Critical)</t>
          </li>
          <li>
            <t><eref target="https://nvd.nist.gov/vuln/detail/CVE-2021-29455">CVE-2021-29455</eref> - CVSS: 7.5 (High)</t>
          </li>
          <li>
            <t><eref target="https://nvd.nist.gov/vuln/detail/CVE-2021-22160">CVE-2021-22160</eref> - CVSS: 9.8 (Critical)</t>
          </li>
          <li>
            <t><eref target="https://nvd.nist.gov/vuln/detail/CVE-2021-32631">CVE-2021-32631</eref> - CVSS: 6.5 (Medium)</t>
          </li>
          <li>
            <t><eref target="https://nvd.nist.gov/vuln/detail/CVE-2023-29357">CVE-2023-29357</eref> - CVSS: 9.8 (Critical)</t>
          </li>
        </ul>
        <t>Many other vulnerabilities have been reported without an accompanying CVE, which we do not list here.</t>
        <t>Although there are some legitimate use-cases for Unsecured JWS, these are relatively few in number
and can easily be satisfied by alternative means. The small risk of breaking
some of these use-cases is far outweighed by the improvement in security for the majority of
JWS users who may be impacted by accidental acceptance of the "none" algorithm.</t>
      </section>
      <section anchor="the-rsa15-algorithm">
        <name>The 'RSA1_5' algorithm</name>
        <t>The "RSA1_5" algorithm implements RSA encryption using PKCS#1 version 1.5 padding <xref target="RFC8017"/>. This
padding mode has long been known to have security issues, since at least Bleichenbacher's attack in
1998. It was supported in JWE due to the wide deployment of this algorithm, especially in legacy
hardware. However, more secure replacements such as OAEP <xref target="RFC8017"/> or elliptic curve encryption
algorithms are now widely available. NIST has disallowed the use of this encryption mode for federal
use since the end of 2023 <xref target="NIST.SP800-131Ar2"/> and a CFRG draft <xref target="I-D.irtf-cfrg-rsa-guidance"/> also deprecates
this encryption mode for IETF protocols. This document therefore also deprecates this algorithm for
JWE.</t>
      </section>
      <section anchor="guidance-on-deprecation">
        <name>Guidance on deprecation</name>
        <t>Both of the algorithms listed above are deprecated for use in JWS and JWE. JOSE library developers
<bcp14>SHOULD</bcp14> deprecate support for these algorithms and commit to a timeline for removal. Application
developers <bcp14>SHOULD</bcp14> disable support for these algorithms by default. New specifications building on
top of JOSE <bcp14>MUST NOT</bcp14> allow the use of either algorithm.</t>
        <t>The IANA algorithm registry distinguishes between algorithms that are "Deprecated" and those that are
"Prohibited". The algorithms identified in this document are to be marked as Deprecated only. Existing
specifications and applictions that make use of these algorithms can continue to do so, but should
consider adopting alternatives in future updates.</t>
      </section>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>No security issues are introduced by this specification.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="jose-algorithm-deprecations">
        <name>JOSE Algorithm Deprecations</name>
        <t>The following changes are to be made to the IANA JOSE Web Signature and Encryption Algorithms registry:</t>
        <ul spacing="normal">
          <li>
            <t>For the entry with Algorithm Name "none", update the JOSE Implementation Requirements to "Deprecated".</t>
          </li>
          <li>
            <t>For the entry with Algorithm Name "RSA1_5", update the JOSE Implementation Requirements to "Deprecated".</t>
          </li>
        </ul>
      </section>
      <section anchor="updated-review-instructions-for-designated-experts">
        <name>Updated Review Instructions for Designated Experts</name>
        <t>The review instructions for the designated experts for the IANA "JSON Web Signature and Encryption Algorithms"
registry <xref target="IANA.jose"/> in Section 7.1 of <xref target="RFC7518"/> are updated to add these additional review criteria:</t>
        <ul spacing="normal">
          <li>
            <t>For JWS signature algorithms, only algorithms that are reasonably conjectured to meet the standard security goal
of existential unforgeability under a chosen message attack (EUF-CMA) should be considered for approval.</t>
          </li>
          <li>
            <t>For JWE key management algorithms (specified with the "alg" header), only algorithms that are reasonably
conjectured to meet the standard security goal of indistinguishability under an adaptive chosen ciphertext
attack (IND-CCA2) should be considered for approval.</t>
          </li>
          <li>
            <t>For JWE content encryption methods (specified with the "enc" header), only algorithms that are reasonably
conjectured to meet the standard security goal of authenticated encryption with associated data (AEAD) should
be considered for approval.</t>
          </li>
        </ul>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC7518">
          <front>
            <title>JSON Web Algorithms (JWA)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7518"/>
          <seriesInfo name="DOI" value="10.17487/RFC7518"/>
        </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>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="howmanydays" target="https://github.com/zofrex/howmanydayssinceajwtalgnonevuln/blob/deploy/data/vulns.yml">
          <front>
            <title>How Many Days Has It Been Since a JWT alg:none Vulnerability?</title>
            <author fullname="James Sanderson">
              <organization/>
            </author>
            <date year="2023" month="September" day="25"/>
          </front>
        </reference>
        <reference anchor="RFC8017">
          <front>
            <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
            <author fullname="K. Moriarty" initials="K." role="editor" surname="Moriarty"/>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
            <author fullname="A. Rusch" initials="A." surname="Rusch"/>
            <date month="November" year="2016"/>
            <abstract>
              <t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t>
              <t>This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.</t>
              <t>This document also obsoletes RFC 3447.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8017"/>
          <seriesInfo name="DOI" value="10.17487/RFC8017"/>
        </reference>
        <reference anchor="I-D.irtf-cfrg-rsa-guidance">
          <front>
            <title>Implementation Guidance for the PKCS #1 RSA Cryptography Specification</title>
            <author fullname="Alicja Kario" initials="A." surname="Kario">
              <organization>Red Hat, Inc.</organization>
            </author>
            <date day="20" month="February" year="2025"/>
            <abstract>
              <t>   This document specifies additions and amendments to RFC 8017.
   Specifically, it provides guidance to implementers of the standard to
   protect against side-channel attacks.  It also deprecates the RSAES-
   PKCS-v1_5 encryption scheme, but provides an alternative depadding
   algorithm that protects against side-channel attacks raising from
   users of vulnerable APIs.  The purpose of this specification is to
   increase security of RSA implementations.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-rsa-guidance-03"/>
        </reference>
        <reference anchor="NIST.SP800-131Ar2">
          <front>
            <title>Transitioning the use of cryptographic algorithms and key lengths</title>
            <author fullname="Elaine Barker" initials="E." surname="Barker">
              <organization/>
            </author>
            <author fullname="Allen Roginsky" initials="A." surname="Roginsky">
              <organization/>
            </author>
            <date month="March" year="2019"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.sp.800-131ar2"/>
          <refcontent>National Institute of Standards and Technology</refcontent>
        </reference>
        <reference anchor="CVE" target="https://cve.mitre.org">
          <front>
            <title>Common Vulnerability Enumeration Database</title>
            <author>
              <organization>MITRE</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="CVSS" target="https://www.first.org/cvss/">
          <front>
            <title>Common Vulnerability Scoring System</title>
            <author>
              <organization>FIRST</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="IANA.jose" target="https://www.iana.org/assignments/jose">
          <front>
            <title>JSON Object Signing and Encryption (JOSE)</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
      </references>
    </references>
    <?line 185?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA71Z23IbNxJ9x1dg6QdLW+LwItOWWNkktETH8lqSV5TjSqVS
CTgDkrBmBgwwQ5px+V/2W/bL9jQwN1KSLdVW7YvEuaDRON19+jLtdptlKovl
kLfeXE7GQ34ql0aGIpP8aapT+ZSLNOJPryaj3u+Dpy1GT+babIbcZhFTSzPk
mclt1u92j7t9xiIdpiKBuMiIWdZWMpu1P2or21Ept01i28aK3qDd7TGbTxNl
rdJptlli3dn4+hXnT7iIrYZSKsVCiT9p1jrgLRmpTBslYro4G73EP23w6+r6
VYvlywjy7ZC/GPSOWJonU2mGjO4NWahTK1ObW6evZKshP2TCSIE9JjLMjco2
LbbW5mZudL4kOMRK2NCoZcYvpx9lmPGJmqcqnTtExmloNssMarfYjdxgYTRk
vM3P0kyaVGbtUzo/W8k0x+6cP14q5x6Q1gcoRS/8RCLofiJUjPsE648EcKDN
nO4LEy5wf5FlSzvsdOg1uqVWMihf69CNztTotZUdEtChhXOVLfIpll5IFZ+L
CGh37jPa7wNaERPQWWOzemXgpQVKf0VG5yHuESyyJG4xJvJsoQ3Bi505n+Vx
7H2MNuV+V/cEBxSp+ksQgEN+LTfC3ZYesBRvBzJI3Ps/zulmEOqEsVSbBGtW
zlBXr07IfYaMqXTWfLDQ60Skm0hsLF3ySqttnd7gr+UTWFMaq51ezgN5v9s/
bHeP2/0B3SuD7rVe4wTphp9CLn8tLD/L+EspU/hFGkou+JsP1wiG+ZBw4T/n
cSqNmKoY/vpDy0kSZi5hitISBfw4WecvPTPyU6ehuSWh4uM6g0QSuIK8zjTW
0w4MEOtNB7qKDt21wSaJPR5H3d4LOudZ+zRQBhYLZ2ZOJmrPcxUJSKSnF2eT
62Dy7qjbbfcOeyPTB5dcngW9bvC82z/qFI+D+jnWnPw89gAWcJzoJNHp9ikR
FHmCKzIqUMrEVFjpFm1ZYMf452fXV2MvegefEOGQqMxIigenw2TybSUmIWgH
QTjZ2Ewm39z+1dnV5PrO7dfrdTBTxmYuHMOVtR2CdnQxCigQ4HftdpuLqc2M
CDPGrhfKcrAqMEgzXlAc//y58NMvX3imeRU9PFtIeMyEPAYKZ4uEt8jOLUcv
/uG4fshanthbAb9eSCvrJ5YvxErym1SvU24LguRrKW5Saa20AfkpcXSlEgm/
kisl1+wshfZ5SFBYjiBCUrFgObwGivu0lCazpDUYRExjZRecTBor+He1k5F/
5spIOjSJFhlCLMuNZPXBjJwrQslvYxc6jyOeSJkFHsNERVEsGXtCpGx05BVi
7M3k8oJ/kFM+qg+79+bD6KCJ6j5XxSLobOUKnhAj5QFFYaImTHS8qc4WvBTL
Ju6o0JWkTvYd8tWeNcPT0/F+4KNfzwi/OwxgM6294Yhw3XsqAQqQieyFxyqO
oSpfq0haOIGIeG5lwMErpPQBtzq5LXVp9Arngg2mkkdqNlNhHmd0rZJl7FBH
xjTwqSze8BhSyffJZJ/AEorMJvmqESCKPGLbVSufhP3Wmts8XDT0gJ8jW14X
3lr6aPn4gK8XCu8j+6tCBLlAqmsHwVZiuYyVPwYBBN61Yo7DkmPGQS1/zEs3
/9oOeIXL2jprvMXf/fNk8qTHASQVKLwXDPgS6QNgwMcutIs3bEdLbWl1CwMQ
Wvev5Xt/XE36g+d/HHD8ODx6hh9kUFwMev0/9smyLE/DhUjnON50g11wXLuU
oZqRtiSPFoQiLTwAZoTZI2g1whb0AiDYHPiFlUnuiVd+K14dUaAcvCNwD9hj
IpeE+cD18u6J3oBfpnC02j2Yw5U8HC6NNIrdNjgkzF34rcVCO9sUUbO1Z8EE
U1nsIQ2WIES8HoDoyRPnGGV9W5Eho7u7rshDaEB4Aev3qTslxMFpyYNA2ByV
Zeb2JW2RdRE/mYS2efWy8GBTfcAovlywANmlyiiCjYZLlJmUFKWXsflcwYiU
fyFZ5zB3qgFJGEo4KFZsKUNOEsmZQBQfMEr2dSAX/OjifiGIzIzSueXTfA7X
yCWhWUt1DlMdHiyfegYJYWdb+NNCWBZ7M4jqxDzW1hI/VY6AY1OKhAoqdNcp
mQHtg3saLmToylpyYsdClljFubtImYgocITZILCwwYZuu4DwSjYoje+18Lu1
zxegKWlKAAGKS2rIWVNLQH/+3KiDvnxhlF9vLF/mcORwl8xKYHZRRKuSiRvp
nLWB2W23ofzIAITBWqJQrLO814dLLjVFEU8K2vc05K2j5gvaEXmfU2Ckc+uP
MNNxrNe0FRkHNGIytEBOKIMItE85VPa5Gko7YVOqIUNBrEDYQXH8LPLMXXxL
dCfurH1YswD7/Bk1G4oORR0Z2IhSjEtGDymb3OrJBMst7iMYPPmWGLo0S6sK
LT0UPlP8im3b/W7vqN3rdruDw95ve2VFla6iIAUUwVyvXOmKWjZDcd/ZXbIP
Oa7a4y9AxnuvAfd+U/YLvHj0vP9wycWCWu4gOOR752hS86Qpud9v9w8Hz7oP
llwuaGr8/LbGfZTSg+PBi4fLLRZ8A4l+r90/HnQfoW+x4CFynw0ebrtyQS33
OOjxvRN4CRwnvkP24LGyBw/Qud97/jgsaEFT56N7dT7sP3+EL5cLatnPSec7
PO4Qhzt8jGcUC+7Vmvk6FXFpbpFlTTie3kA5xCc6zyhrgiiRI7Ca4hy7laXX
GqSvXVIjIgN9u+Q8imkhiJB2kr7IpQQUI5ej9KUeB0TWdvnIlRc7Sbkoo13l
ELvmHfQ7Q5GDvOBHQqwsnVBZKFdWFNWEKrJPTCMctxQ1pUgLErYJSipulL0h
fpqiKqD0xZxyVfleqwamngnDgcFawqXKOs6xGlXfriBTjd6qrLsS8VEXLMgo
s0OksVRr4IlT1tNioWsYOiZGNvD5yNUQ97B8o/Qp5nm3ip9bdXKdAW9VyN8s
c107RcODL198c8DKJ4mOqBixKBpw5TxnO3s1ynzKbWhj/DQko2YEzvIylnAh
mU4F/pqnyIpZhnQOQFnv+PjIdadryLf5snBIQE2dQJHXCR5qmbgfezhjONSa
1c8B6lyquamUpvVwQRFu2AId4BoO1miyEm0KncntlrEIy1rUdT2WX47G75p4
0NRSxrECkiHHMhy5RpY12jVyZCDjlKWiY0VDPdRJgZu3OAypcqL6QPo+sUrz
OErDWg5yV47LiJpZRu95VGmVRExgFREB9Lw1y4HGRZZ/dfWTn+3itfsHQvQ+
NRt1E8juVchNfBETmQ51fKuNdDQwI3x3BO4Yi0QhXsbeyX8qy2lsVC5xzf9L
atWL+GjATAxElfoUkekwr/aJnI4ElvOgiW/nsY9vaGI1NVSlRnCEWKNDsmzy
+vL929PGTKZwwjLCt7t8R0YonVTm62lq711DRW+jpdErEQd8RK1ucYZ6K15u
5Wvnr29UdwjwHfDhVjtJ7YCKXWxih0wvCSN3wPP3cLOLS5pBwseaHiaVSwZN
eiEOoVHW7T5vQ0pSpZeja4TxphK8iLBvKFi1fK3qG0RUzq2o0Sqfs9Y7oxdq
qui55+aGlKowjXwnsNX/GlnMPBJhbnxnVu+Fk8ebAH2uV5TtAOT835nBXzt1
EjQDdcTtIE45hrpDlXrSQbaz+gBIZ0WP6r5KKGpaRKR9L9FIPrZuWsumnZwb
hXa6ojOWSp3KmUpdz2+9BW7khtMHCctbZD36VFJakX5fjf/1/uxqfEq/J69H
b99WP1jxhner+le98uTy/Hx8ceoXk1ds3WKt89EvLd8QtC7fXZ9dXozetr5m
B+oHDQzggs/CtenbyNTb7uXJu//8u/cMPPM38Ga/1zsGq/iLo96LZ7hYIwP4
3ch0xSXMsGEwlBSuF6SkHQq02qCPAzI4oEeiKaqNv/9KyPw25N9Nw2Xv2ffF
DTrw1s0Ss62bDrPbd24t9iDeceuObSo0t+7vIL2t7+iXresS98bN735wjNLu
Hf3wPSMXKr94kS85BxSF+1zo3dTrjNWYhd45jXJ+6QJ/VyC42NFINWutAq72
17q99SMvuxWoUZWw3QZOGk1S6zHr9pez5li3JB/fQ74qKiy4IPjIdby1Whci
KSumgyLc6jHY2dYYgF9tDaf1FmEFD9ypqLT+x70I3/dOQHTvMO/2DM/Dbvz7
6q7hX1SvkcXAvnzkrNCqBtoPMEOLVUkANUP5pYOGCCl5onv7Bfo6cGjzu4ao
eM+PmqKopNhqxFmeAaQBHlGitjNlalurVuly4KnirrTTmDSCl+nbrOsqsDV9
VPATivIDQBUkcy3oK5nLh5Q4iJihV07fDueyHIPkqSN5+DcOnjYm1a5o3Ru/
f9U+OR/tN0aXZWYo6g/wmXGVQH2+seP5RKSQVEx3688ZRXQWjZjvBmhKVgzJ
9h8EA53rcUgQDDTUqTL9DgCg40gsXWdVQBGqJag4k58y9021AOTs4rR9cjLq
PxaRYha7VWZKVA/RPZDgvf8HJNUY1AfUzkcGYa1Gk0GP6Osr3xuNR6flyWnD
rx3efelCF3RDDDwKqYuKZTR3dME+D33HK6N/tGbIf7L1hf0XlzTJMfIhAAA=

-->

</rfc>
