wdiff rfc8933xml2.original.xml rfc8933.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3161 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3161.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC5652 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml">
<!ENTITY RFC6211 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6211.xml">
<!ENTITY RFC5083 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5083.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC6210 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6210.xml">
<!ENTITY RFC8017 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-cms-update-alg-id-protect-05" number="8933" updates="5652" obsoletes="" submissionType="IETF" category="std" updates="5652"> consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="CMS Algorithm Identifier Protection">Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection</title>
    <seriesInfo name="RFC" value="8933"/>
    <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="2020" month="August" day="27"/> month="October"/>
    <area>Security</area>

    <keyword>Internet-Draft</keyword>
    <workgroup>LAMPS</workgroup>

<keyword>digitally sign</keyword>
<keyword>authenticate</keyword>
<keyword>algorithm identifier integrity</keyword>

    <abstract>
      <t>This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed-data and authenticated-data content types are adequately protected.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document updates the Cryptographic Message Syntax (CMS) <xref target="RFC5652"/> target="RFC5652" format="default"/> to ensure that algorithm identifiers in signed-data and authenticated-data content types are adequately protected.</t>
      <t>The CMS signed-data Content Type content type <xref target="RFC5652"/>, target="RFC5652" format="default"/>, unlike X.509 certificates <xref target="RFC5280"/>, target="RFC5280" format="default"/>, can be vulnerable to algorithm substitution attacks.  In an algorithm substitution attack, the attacker changes either the algorithm identifier or the parameters associated with the algorithm identifier to change the verification process used by the recipient.  The X.509 certificate structure protects the algorithm identifier and the associated parameters by signing them.</t>
      <t>In an algorithm substitution attack, the attacker looks for a different algorithm that produces the same result as the algorithm used by the originator.  As an example, if the signer of a message used SHA-256 <xref target="SHS"/> target="SHS" format="default"/> as the digest algorithm to hash the message content, then the attacker looks for a weaker hash algorithm that produces a result that is of the same length.  The attacker’s attacker's goal is to find a different message that results in the same hash value, which is called a cross-algorithm collision.  Today, there are many hash functions that produce 256-bit results.  One of them may be found to be weak in the future.</t>
      <t>Further, when a digest algorithm produces a larger result than is
      needed by a digital signature algorithm, the digest value is reduced to
      the size needed by the signature algorithm.  This can be done both by
      truncation and modulo operations, with the simplest being
      straightforward truncation.  In this situation, the attacker needs to
      find a collision with the reduced digest value.  As an example, if the
      message signer uses SHA-512 <xref target="SHS"/> target="SHS" format="default"/> as the
      digest algorithm and ECDSA the Elliptic Curve Digital Signature Algorithm (ECDSA)
      with the P-256 curve <xref target="DSS"/> target="DSS" format="default"/> as the
      signature algorithm, then the attacker needs to find a collision with
      the first half of the digest.</t>
      <t>Similar attacks can be mounted against parameterized algorithm
      identifiers.

When looking at randomized hash functions, functions are employed, such as the example in <xref target="RFC6210"/>, target="RFC6210" format="default"/>, the algorithm identifier parameter includes a random value that can be manipulated by an attacker looking for collisions.  Some other algorithm identifiers include complex parameter structures, and each value provides another opportunity for manipulation by an attacker.</t>
      <t>This document makes two updates to CMS to provide protection for the
      algorithm identifier.  First, it mandates a convention followed by many
      implementations by requiring the originator to use the same hash
      algorithm to compute the digest of the message content and the digest of
      signed attributes.  Second, it recommends that the originator include
      the CMSAlgorithmProtection attribute <xref target="RFC6211"/>.</t> target="RFC6211"
      format="default"/>.</t>
    </section>
    <section anchor="terms" title="Terminology">

<t>The numbered="true" toc="default">
      <name>Terminology</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 anchor="required-use-the-same-hash-algorithm" title="Required use numbered="true"
	     toc="default">
      <name>Required Use of the same hash algorithm"> Same Hash Algorithm</name>
      <t>This section updates <xref target="RFC5652"/> target="RFC5652" format="default"/> to require the originator to use the same hash algorithm to compute the digest of the message content and the digest of signed attributes.</t>
      <section anchor="rfc-5652-section-53" title="RFC numbered="true" toc="default">
        <name>RFC 5652, Section 5.3"> 5.3</name>
        <t>Change the paragraph describing the digestAlgorithm as follows:</t>
        <t>OLD:</t>

<t><list style='empty'>

  <t>digestAlgorithm
<blockquote>
          digestAlgorithm identifies the message digest algorithm, and any
   associated parameters, used by the signer.  The message digest is
   computed on either the content being signed or the content
   together with the signed attributes using the process described in Section 5.4. <xref target="RFC5652" sectionFormat="bare" section="5.4"/>.  The message digest algorithm SHOULD <bcp14>SHOULD</bcp14> be among those
   listed in the digestAlgorithms field of the associated SignerData.
   Implementations MAY <bcp14>MAY</bcp14> fail to validate signatures that use a digest
   algorithm that is not included in the SignedData digestAlgorithms
   set.</t>
</list></t>
   set.</blockquote>

        <t>NEW:</t>

<t><list style='empty'>

  <t>digestAlgorithm
          <blockquote>digestAlgorithm identifies the message digest algorithm, and any
   associated parameters, used by the signer.  The message digest is
   computed on either the content being signed or the content
   together with the signedAttrs using the process described in Section 5.4. <xref target="RFC5652" sectionFormat="bare" section="5.4"/>.  The message digest algorithm SHOULD <bcp14>SHOULD</bcp14> be among those
   listed in the digestAlgorithms field of the associated SignerData.
   If the signedAttrs field is present in the SignerInfo, then the same
   digest algorithm MUST <bcp14>MUST</bcp14> be used to compute both the digest of the
   SignedData encapContentInfo eContent, which is carried in the
   message-digest attribute, and the digest of the DER-encoded
   signedAttrs, which is passed to the signature algorithm.
   Implementations MAY <bcp14>MAY</bcp14> fail to validate signatures that use a
   digest algorithm that is not included in the SignedData
   digestAlgorithms set.</t>
</list></t> set.</blockquote>

      </section>
      <section anchor="rfc-5652-section-54" title="RFC numbered="true" toc="default">
        <name>RFC 5652, Section 5.4"> 5.4</name>
        <t>Add the following paragraph as the second paragraph in Section 5.4:</t> <xref target="RFC5652" sectionFormat="bare" section="5.4"/>.</t>
        <t>ADD:</t>

<t><list style='empty'>

  <t>When
          <blockquote>When the signedAttrs field is present, the same digest algorithm
   MUST
   <bcp14>MUST</bcp14> be used to compute the digest of the encapContentInfo
   eContent OCTET STRING, which is carried in the message-digest
   attribute,
   attribute and the digest of the collection of attributes that
   are signed.</t>
</list></t> signed.</blockquote>
      </section>
      <section anchor="rfc-5652-section-56" title="RFC numbered="true" toc="default">
        <name>RFC 5652, Section 5.6"> 5.6</name>
        <t>Change the paragraph discussing the signed attributes as follows:</t>
        <t>OLD:</t>

<t><list style='empty'>

  <t>The
          <blockquote>The recipient MUST NOT <bcp14>MUST NOT</bcp14> rely on any message digest values computed
   by the originator.  If the SignedData signerInfo includes
   signedAttributes, then the content message digest MUST <bcp14>MUST</bcp14> be
   calculated as described in Section 5.4. <xref target="RFC5652" sectionFormat="bare" section="5.4"/>.  For the signature to be
   valid, the message digest value calculated by the recipient MUST <bcp14>MUST</bcp14>
   be the same as the value of the messageDigest attribute included
   in the signedAttributes of the SignedData signerInfo.</t>
</list></t> signerInfo.</blockquote>
        <t>NEW:</t>

<t><list style='empty'>

  <t>The
          <blockquote>The recipient MUST NOT <bcp14>MUST NOT</bcp14> rely on any message digest values computed
   by the originator.  If the SignedData signerInfo includes the
   signedAttrs field, then the content message digest MUST <bcp14>MUST</bcp14> be
   calculated as described in Section 5.4, <xref target="RFC5652" sectionFormat="bare" section="5.4"/> using the same digest
   algorithm to compute the digest of the encapContentInfo eContent
   OCTET STRING and the message-digest attribute.  For the signature
   to be valid, the message digest value calculated by the recipient
   MUST
   <bcp14>MUST</bcp14> be the same as the value of the messageDigest attribute
   included in the signedAttrs field of the SignedData signerInfo.</t>
</list></t> signerInfo.</blockquote>
      </section>
      <section anchor="backward-compatibility-considerations" title="Backward numbered="true" toc="default">
        <name>Backward Compatibility Considerations"> Considerations</name>
        <t>The new requirement introduced above might lead to incompatibility with an implementation that allowed different digest algorithms to be used to compute the digest of the message content and the digest of signed attributes.  The signatures produced by such an implementation when two different digest algorithms are used will be considered invalid by an implementation that follows this specification.  However, most, if not all, implementations already require the originator to use the same digest algorithm for both operations.</t>
      </section>
      <section anchor="timestamp-compatibility-considerations" title="Timestamp numbered="true" toc="default">
        <name>Timestamp Compatibility Considerations"> Considerations</name>
        <t>The new requirement introduced above might lead to compatibility
	issues for timestamping systems when the originator does not wish to
	share the message content with the Time Stamp Stamping Authority (TSA) <xref target="RFC3161"/>.
	target="RFC3161" format="default"/>.  In this situation, the
	originator sends a TimeStampReq to the TSA that includes a
	MessageImprint, which consists of a digest algorithm identifier and a
	digest value, then the value. The TSA then uses the originator-provided digest in the MessageImprint.</t>
        <t>When producing the TimeStampToken, the TSA MUST <bcp14>MUST</bcp14> use the same digest algorithm to compute the digest of the encapContentInfo eContent, which is an OCTET STRING that contains the TSTInfo, and the message-digest attribute within the SignerInfo.</t>
        <t>To ensure that TimeStampToken values that were generated before this update remain valid, no requirement is placed on a TSA to ensure that the digest algorithm for the TimeStampToken matches the digest algorithm for the MessageImprint embedded within the TSTInfo.</t>
      </section>
    </section>
    <section anchor="recommended-inclusion-of-the-cmsalgorithmprotection-attribute" title="Recommended inclusion numbered="true" toc="default">
      <name>Recommended Inclusion of the CMSAlgorithmProtection attribute"> Attribute</name>
      <t>This section updates <xref target="RFC5652"/> target="RFC5652" format="default"/> to recommend that the originator include the CMSAlgorithmProtection attribute <xref target="RFC6211"/> target="RFC6211" format="default"/> whenever signed attributes or authenticated attributes are present.</t>
      <section anchor="rfc-5652-section-14" title="RFC numbered="true" toc="default">
        <name>RFC 5652, Section 14"> 14</name>
        <t>Add the following paragraph as the eighth paragraph in Section 14:</t> <xref target="RFC5652" sectionFormat="bare" section="14"/>:</t>
        <t>ADD:</t>

<t><list style='empty'>

  <t>While
          <blockquote>While there are no known algorithm substitution attacks today,
   the inclusion of the algorithm identifiers used by the originator
   as a signed attribute or an authenticated attribute makes such an
   attack significantly more difficult.  Therefore, the originator
   of a signed-data content type that includes signed attributes
   SHOULD
   <bcp14>SHOULD</bcp14> include the CMSAlgorithmProtection attribute <xref target="RFC6211"></xref> target="RFC6211" format="default"/> as
   one of the signed attributes.  Likewise, the originator of an
   authenticated-data content type that includes authenticated
   attributes SHOULD <bcp14>SHOULD</bcp14> include the CMSAlgorithmProtection attribute
   <xref target="RFC6211"></xref> target="RFC6211" format="default"/> as one of the authenticated attributes.</t>
</list></t> attributes.</blockquote>

      </section>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document makes has no requests of the IANA.</t> IANA actions.</t>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security properties of the CMS <xref target="RFC5652"/> target="RFC5652" format="default"/> signed-data and
authenticated-data content types are updated to offer protection for
algorithm identifiers, which makes algorithm substitution attacks
significantly more difficult.</t>
      <t>For the signed-data content type, the improvements specified in this
document force an attacker to mount a hash algorithm substitution attack
on the overall signature, not just on the message digest of the
encapContentInfo eContent.</t>
      <t>Some digital signature algorithms have prevented hash function
      substitutions by including a digest algorithm identifier as an input to
      the signature algorithm.  As discussed in <xref target="HASHID"/>, target="HASHID"
      format="default"/>, such a “firewall” "firewall" may not be effective or even
      possible with newer signature algorithms.  For example,
      RSASSA-PKCS1-v1_5 <xref target="RFC8017"/> target="RFC8017" format="default"/> protects the
      digest algorithm identifier, but RSASSA-PSS <xref target="RFC8017"/> target="RFC8017"
      format="default"/> does not.  Therefore, it remains important that a
      signer have a way to signal to a recipient which digest algorithms are
      allowed to be used in conjunction with the verification of an overall
      signature.  This signaling can be done as part of the specification of
      the signature algorithm, algorithm in an X.509v3 certificate extension <xref target="RFC5280"/>,
      target="RFC5280" format="default"/> or some other means.  The Digital
      Signature Standard (DSS) <xref target="DSS"/> target="DSS" format="default"/> takes the
      first approach by requiring the use of an “approved” "approved" one-way hash
      algorithm.</t>
      <t>For the authenticated-data content type, the improvements specified in
this document force an attacker to mount a MAC algorithm substitution
attack, which is difficult because the attacker does not know the
authentication key.</t>
      <t>The CMSAlgorithmProtection attribute <xref target="RFC6211"/> target="RFC6211" format="default"/> offers protection for the algorithm identifiers used in the signed-data and authenticated-data content types.  However, no protection is provided for the algorithm identifiers in the enveloped-data, digested-data, or encrypted-data content types.  Likewise, The the CMSAlgorithmProtection attribute provides no protection for the algorithm identifiers used in the authenticated-enveloped-data content type defined in <xref target="RFC5083"/>. target="RFC5083" format="default"/>.  A mechanism for algorithm identifier protection for these content types is work for the future.</t>
    </section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they motivated me to write this document.  Thanks to Roman Danyliw, Ben Kaduk, and Peter Yee for their careful review and editorial suggestions.</t>

</section>
  </middle>
  <back>

    <references title='Normative References'>

&RFC2119;
&RFC3161;
&RFC8174;
&RFC5652;
&RFC6211;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3161.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6211.xml"/>
      </references>

    <references title='Informative References'>

&RFC5083;
&RFC5280;
&RFC6210;
&RFC8017;
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5083.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6210.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>

        <reference anchor="SHS" > anchor="SHS">
          <front>
            <title>Secure Hash Standard</title>
    <author > Standard (SHS)</title>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
            <seriesInfo name="FIPS Publication" name="FIPS" value="180-4"/>
	    <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>

        <reference anchor="DSS" > anchor="DSS">
          <front>
            <title>Digital Signature Standard (DSS)</title>
    <author >
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2013" month="July"/>
          </front>
            <seriesInfo name="FIPS Publication" name="FIPS" value="186-4"/>
	    <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
        </reference>

        <reference anchor="HASHID" > anchor="HASHID">
          <front>
            <title>On Hash Function Firewalls in Signature Schemes</title>
            <author initials="B." surname="Kaliski" fullname="Burton S. Kaliski, Jr.">
      <organization></organization>
              <organization/>
            </author>
            <date year="2002" month="February" day="08"/> month="February"/>
          </front>
            <seriesInfo name="DOI" value="10.1007/3-540-45760-7_1"/>
            <seriesInfo name="Lecture Notes in Computer Science," value="Volume 2271"/>
  <seriesInfo name="DOI" value="10.1007/3-540-45760-7_1"/>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Many thanks to <contact fullname="Jim Schaad"/> and <contact
      fullname="Peter Gutmann"/>; without knowing it, they motivated me to
      write this document.  Thanks to <contact fullname="Roman Danyliw"/>,
      <contact fullname="Ben Kaduk"/>, and <contact fullname="Peter Yee"/> for
      their careful review and editorial suggestions.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAFTFR18AA+Vae2/jNhL/X5+CSIC7LWDl7Owm2brA4bzJbpM2r4u97RVF
UdASbbORRFWU7HUX+e43MyQlSraT7LZFcbhDD6vI4nCev3mQYRgGpSwTMWTv
85iXgpWKlQvBTot1Xqp5wfOFjNiV0JrPBRuvs5J/YC9Or8ZfsJkq2CiZq0KW
i5RdxCIr5UyKgt0WqhRRKVUW8Om0EMshgwVPfhurKOMpcBIXfFaGUpSzMOFp
rsMo1WFF7IU8mYcyDnOzLOwfBfh6yA77h/2w/zo8PAkieAE7rYdMl3Fg1ukh
Ozo+OgwCmRdDVhaVLg/7/S/7hwEvBB+ysYgq4G0d3Iv1ShXxkF1kpSgyUYZn
yE0Q6JJn8c88URnslqkgl0P2Y6miHtOqKAsx0/C0TvHhpyDgVblQxTBgYcDg
fzIDBu4O2LmqdCLW9M7Ieldp3XqtivmQfSfnMqmZ6rHLy1P60amz/Tv9pIEH
UYKYg2MGLGdCL2WSCHaneEwfRPDlkJ2DULHKeuy7kXmrYtLe4KRv/66yEnX3
fkx/i5TLZMgWhsN/LXFjLaKDSKVBkKki5aVcChCU3b07PRwMvrSPLwfHA/v4
enDyyj6iDezjMXw8BHtksw6Ro/7rl+7x8HW/+dw9vgZm8XF8Ph4Sj9aB90gf
gp1zvWBjNBcv4j2jN2cOVqv4mqPT8QQMrYFABa6vZvUyzeBfNhHRIlOJmq/Z
i+uL8eQLIuAcbnAEDmd0LwopNIritth7d3E7ZrfVNJERbbQ3ZIPX/fAV/H42
bvN9BjotgZGxnGe8RAkcF+wFfPvFnyjBy7B/8kkSHJME56Px+cVZS4ibzOj9
XZVRNLN3shArniQanN8XLVqIVOgWG/3DEP97vUVQCpw3B+xbnkh9L+1bEzpv
qqKEjcb1rz32TXGwS5xLgAtk4BqAg3g6VWkOOiuAJSmySPRAwO9UUqWCHR6e
DOy6s5sLkLt/MOj3T/7xMjx6BTY8Ojnuhyc/D4IgDEOISQg9HgFETBZSM0Ax
IJGVzALPc9FU5yJCSIyRN/BywitEY5Fp5Ltc8JLxGkJlDaEkjAYFiziEHTnZ
HbWIHyAW2teRAkQDvsp1DlwB7DEei18r+CBZM4unIj4wQqUyjhMRBPsAg4WK
K2PTj/sS/3z4naJ+/Gih4OHhLxFwgmxCQvJpntrFE1jsM9hjVZbIe8H+c3DU
/5JFokCmIhLXfAYYhZ9FPGNTwZZVkomCTxPKpI04upqaIEU98rLk0b0+YBC6
IM3jn/VIreYZvDVa8GwOmwv4Hv6k37YoDSCCfst5AcFSoha51iqSqC+2gq93
LwXGzS70yRJiaWYxANUYgUlZpYHKdE0fFOC4OYRQCfKgajc0hbmpMtFnzaB3
b47GpR8bbj0ZYEu0mszm+FEKxvx0DSZK3WuqXjiL5WwmCjR8Q4EcMSevtz6t
YXsQU1cJfNfl3VcFvJpLQDpVgC5GCMFMfIASJhE9JmeGFjpdgUjNWWqjg0iM
z0fh4dExeBUkNogMu1Eswdot9hRbINLij46AdX0SNNst7UpwfEXLd8nLnaD0
GqJczRodJCKblwtrZ7fF3zWbK0hD8C3wNpMYnZ5iHY9Ez9CmiK6JEjtLnlSg
pBWAxgIpRZA6BBKKCqV12HAbqQTAHoyLXKiYr0loDHb4f8qztaE3s3lIt8Rj
oOBwKms+gMZNJqyIKSxfYwzPoAaKURZ4RpU5bmcV+jD43DvIPLAnsgvq5ps2
8rSZ8GIOOm+UmqF4mRCxcRtaTflf10myJtTzXYBUhIsLgcRjV6pr+ZvwCDon
65Aio5FiCaegBhRsqgAGcEkB2jIBjuGXAvOJYioHICMd9hrA0BK9GbiZCgxC
TH1yvijBv1ZYsDSUDLiVuKWGcKR3nUBEnn2fqU3bbOdE9VWwM7Scp9kQg6jS
FFVHg8Mnowrlfnt6Nh41e99SOEJJucSMAJVYs3yXqbJPFnAmC+BjwZOZCzTD
GnjZWKYSvMdlC2e5FCt0DI05h+qobNAR3CDenkBBY98jc4gFaDUMRBBYpbSk
HS/QxVQQglZQq2KMAMp2WIZjttsJ3zU3sCRKqtggCm1mHZji0cnCM5lXCaE8
xkLWxi3kFZGr1htKMlaAGYqS365qgTaGVcj6B4+lOg+BlGhwwSOLPBixS0nc
Zoa2ynPo66oMuibioWYVzdfm9aBbD6UAs6C/lWoqI0UVB/xjN3KZEKnN1O48
DgK/QxcBJ0e6mSFHxc4Sv6HlSaJWRoMEgBSiyIiJXnxfQCEkC5s2vTSFHEGc
dMC4lWwiUyf7YaPa8eYKL5e6m69MhYWKKuQUiJD9BHwfkzxQOagUGI0tSnd4
c4YsTb1Wzw+amUFDuXbPwcMD2GN/IopU2s7n4z4YP9UPpvKDDp9hi6/Z3tX7
8WSvZ/5l1zf0fPf23+8v7t6e4TOAx+Vl/eC+GJ/fvL88a56alac3V1dvr8/M
YnjLOq+uRj/sGc/bu7mdXNxcjy73THIB72ncBzOZyT4ShxB5ISjewcGEjkBc
0yO8Ob39WzbV+VeDV0Z47L4BougZe254xvxkNlQZFMHmT1AnuG+eC44qBmMn
EI45piAMC4DrhVplDHMqKvKOPAe2fMRNrP9raxTn9J063/ig+Ks9EGTad/1V
D72ReD46eBkEp03Vi6BBTYxTuosdQ7qZZXFtA1APg+DmErri4J/YO3a/q0Na
tzjvJiJjLYhipLG1Bu61Kk6T62xF1iEqqc222kMX8JsGpzKbx42aVOs3XA2t
nKA1XgXQ0Sjw45Tj2gPfUZFKo+VX21lt7G1jCpyfp4rIKi2QBmSA0nj+FjOA
EaRIYucXnuLGpKAz6PFoNHDRwUYISTbjMkE/g0wgaQZap3eLS+ifrsoju7Rr
Z6znVOngqmaRdo5x5w1uA5pRYJK/fvv9/4nHjMBh/sd8ZbbBvlkJBgdQ1qgM
39bFRTZTXh2IcNYY1uOb8s3U9n0ewFE9voFypJTGlwQU2LkdV+CGTJy67s/r
nopC1gpAAlaHoePFRW9vC2biX2dv70LYSYE/k7M2OvC2yUF3fh+y2XT8vpDb
qrznhdyWgNI25LbD/6sgGMVGEwbP0U+bLOAKfypevPc43GxoQCiPzuoU8H3t
CI94UK/JfF1RkcYuV9m0WNcvcLVzDXZzOnk7YePJ3cX11zv9pOMkhCdP+QmW
5lZ+HGk0SQHNRBQKJ/9O1R/vyrxSR5WuAWMz8ezKvRN/KsVcdQevoAaiHnfd
xRRqAnSNfEhk20jHIoIXjboO/LrhaceLYdVDBQejHQ6soQl/eRLZpqhb9LXB
8Z1F3ybyqGxEGhRYvW2Jw/Q73h7dMR6xQhrwqjLr/2Zxu/o660BKHZUBDfA7
EWBNpx7RZDst/rXGdPi5EcJ/gkV7Xnb0AKFTcXwKBtQAgDR8DKijeVde2OZd
JrvTlPvzvcsHtc/xLuNUbdjfxNcn3Gt//w107jSxwmMgSExTmWCnD+rSUHfZ
uZdpGDOxcr1LalK+ORJBY07VEjjFCRhLBCeEBuZaJKkMwqlfKw0ye9xhOvdm
WtrNAdpq/Gn8/7xufLJo5d7cSYaDdpoDbTBOM0+cbTzGNKI+sbyS0F5OiStS
LBmN3McOUbapxYK6nR6ag7F6qngOGlvi8DVVNBaZUSUAmuxtDD54UoBR1s/t
PDdKDRzMUE3WjELJeSYSlF3yNP/jvaftO1JrRDIaELk9qfheQ30Lal45CPKk
ipUwxdFK4imBgn6eW9m7LlJX6CgQnhyDRCM6f8XNX0zGI3tYh6f5Dw+7R7re
9prGOZxIEsU78aurEIGgLd+a2aA9IYQisZBNDUvuokttzkk2DNM5L+It9PGQ
GTekMXCbydAO4eq5ssWRNi9gaqrgTEw4YK7lmqh7O02hbQjTHnenz4Nur1yD
cGmBuBmlwmc4CbacTEwT8hS+k+03mhecZLYPZNviutRKP63w1GUu8LiTgF6A
mwrjHmYCBH6fAmcuW2SqHQiANgmPTJvJjW+09/aU1I7JTTuwlJfRQuwY7rs1
bfsykUIOju1xqMx8BZrJl51OEmaBw2pb5T5nHvnckZjd4g+dfxIsIEZuKZnx
HNA/Om+V03RAS13Jjlp98LwuSSCkLbZ3SYONJkkmJKI9wgMvuc9wAPn42Tlo
D8/+qCRZiE37bD8a2H5WawYnjG+oi7SV7VKYHfPbNGm7JeDNnFBjxspKqFFT
jArMlRJKIntGXlCsdLETSRDe+RcT/FsNHfDcsC5NCsxM5JN850frOj+BGoiJ
+kx0a81wKe8FJJcN/ol5o4jHb2d0k4D/davr1J8jDlLwJfLF2eX76O8Xo+vR
lhS+ebBjgUzY/IR0cS3ScFfytpYC2v0IGSXH6xFNH4SHQz42dK67BM+67mJA
hsoIhaVZ54wp2BoTLr0Y0R4PuuBRzw4Cv2PYxqZxGKjSIP1SEtDta0+YO4Ja
2cByJFpngiAYnX5CiHROCbZwGyhbGgEQ4hlHXeX2qDr6pcLc25p7dMZuOzMy
ns0qk+B3HdxrYHBJaIqndN1D1ha7OgBAMv5NZ7OPVztUBMgMioiNsVtjX3NC
bscnRrUfP5pLe3h4axCL7c3sFb09uviASoFCXYDnRHgdMwBjIvcsV1pLvNBE
5SLUszaxdEW2LaM7lQ/uxqPxeBTefns6HoTLwc9H9miqPzgBD2/dBHpE5B6D
AK1pjcctIq7WbaMqnSymVBOBr6mi5Jm9zsIDezeArMPZCuTGChmloXkk90YN
Ji629za2cQu85gyUDL7+izNxXVu37k8RQm66pL2cERhG0A38axocJ61FXSm2
GiIfp7s3EgJJd6PoPtbyZetGlvgAjkz5snWJDev35ng9FTyzPWLw1CXV+oZE
ac6+F+5qA8/B0njO7p9CB/g7FstGH3v00VLEe4jVIVqlHd8etjyBhE9ATFC2
8PxRiLkane5AmMDdK6sr8xoFwWgRd21ATbXuybC0IXDxxEAr3It1czHx+YUe
wbx+7l0CXTtqF6Sfc6PSb70z5e9Jw2zbUD2+v91aZEuRQAo02/RsjNV/Iohk
Ed4j3cVIU4E8S2X15Y4238/XVVs3bfbblU0sZjJzkGtvs1PnPIJwwluVUpt+
ZPvtmQ3mtOgkelD2ShX3NfP1pbT9UYTelYh4bhw/CK5wOIpXzqheZt/IFO9f
cx6TwW/pTszXVZnyLPuKAEtVxkURgWRprwqkCtIBFRYpDZhXwLbt81wgEUi4
be4UEGRnsHciVz32BlLItzyu7nverj8I4SSQBR5DiFmVAD4spViZqzmxhIpS
Ynat5ugddviCl5OnmN3/C5s5uji6MgAA

-->
</rfc>