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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-dkg-openpgp-pgpmime-message-mangling-00" category="info">

  <front>
    <title>Common PGP/MIME Message Mangling</title>

    <author initials="D.K." surname="Gillmor" fullname="Daniel Kahn Gillmor">
      <organization abbrev="ACLU">American Civil Liberties Union</organization>
      <address>
        <postal>
          <street>125 Broad St.</street>
          <city>New York, NY</city>
          <code>10004</code>
          <country>USA</country>
        </postal>
        <email>dkg@fifthhorseman.net</email>
      </address>
    </author>

    <date year="2019" month="May" day="22"/>

    <area>int</area>
    <workgroup>openpgp</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>An e-mail message with OpenPGP encryption and/or signature has
standard form.  However, some mail transport agents damage those forms
in transit.  A user-friendly mail user agent that encounters such a
mangled message may wish to try to process it anyway, despite the
message’s non-standard structure.</t>

<t>This document aims to be a sort of bestiary of common message mangling
patterns, along with guidance for implementers for how to cope with
messages structured in these common ways.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<section anchor="requirements-language" title="Requirements Language">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and
“OPTIONAL” 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>

</section>
<section anchor="terminology" title="Terminology">

<t><list style="symbols">
  <t><spanx style="verb">Mail User Agent</spanx> (or <spanx style="verb">MUA</spanx>) refers to a program designed to send
and receive e-mail.  Common examples include Thunderbird, Outlook,
and Mail.app.  Webmail implementations, like Roundcube or the Gmail
interface can also be considered a MUA.</t>
  <t><spanx style="verb">Mail Transport Agent</spanx> (or <spanx style="verb">MTA</spanx>) refers to mail-handling software
within the network.  Common examples include Postfix and Exchange.</t>
  <t><spanx style="verb">PGP/MIME</spanx> is the message structure for OpenPGP
protections described in <xref target="RFC3156"/>.</t>
  <t><spanx style="verb">encrypted message</spanx> is used to mean any message where the outermost
PGP/MIME cryptographic feature of the message itself is encryption.
Some encrypted messages might be signed, but the inner signature
cannot typically be mangled by an <spanx style="verb">MTA</spanx> that can’t decrypt.</t>
  <t><spanx style="verb">clearsigned message</spanx> is used here to refer specifically to
messages that are not encrypted, but are signed with a PGP/MIME
signature.</t>
  <t><spanx style="verb">signed message</spanx> is used to refer to a message that has a valid
OpenPGP cryptographic signature applied by the message sender,
whether the message is encrypted or not.</t>
</list></t>

</section>
</section>
<section anchor="problem-statement" title="Problem Statement">

<t>Some MTAs modify message headers, bodies, and structure in transit.
Some of those modifications (“manglings”) can transform a message in
such a way that the end-to-end cryptographic properties of the message
are lost.</t>

<t>Clearsigned messages can become unverifiable, and encrypted messages
can become impossible to decrypt.  MUAs that receive these mangled
messages are unable to fulfil their users goals because of damage done
to the message by the mangling MTA.</t>

<t>In some cases, those manglings can take a regular enough form that a
clever MUA can “repair” them, restoring the cryptographic properties
of the message for the user.</t>

<t>This document aims to collect common manglings, and document how an
MUA can detect them and (if possible) repair them safely for the user.</t>

</section>
<section anchor="cryptographic-properties" title="Cryptographic Properties">

<t>TODO: describe message-wide cryptographic envelope vs. cryptographic
payload and their relevance to this draft.</t>

<t>TODO: we’re assuming a single layer of cryptographic protection.
These steps get more complicated if there are multiple nested layers
(encrypted and then signed?  signed and then encrypted?
triple-wrapped?).  Should this document address that situation?</t>

</section>
<section anchor="encrypted-messages" title="Encrypted Messages">

<t>This section aims to collect examples of repairable mangling known to
be performed by some currently-active MTA on encrypted messages.  Each
section offers a brief description of the mangling, a way to detect
it, and a proposed method of repair.</t>

<section anchor="mixed-up-encryption" title="“Mixed Up” Encryption">

<t>One common mangling takes an incoming multipart/encrypted e-mail and
transforms it into a multipart/mixed e-mail, shuffling body parts at
the same time.</t>

<t>An encrypted message typically has this clean structure C (see example
in <xref target="encrypted-message-sample"/>):</t>

<figure><artwork><![CDATA[
C   multipart/encrypted
C.1  application/pgp-encrypted
C.2  application/octet-stream
]]></artwork></figure>

<t>But after processing, it has mangled structure M (see example in
<xref target="mixup-message-sample"/>):</t>

<figure><artwork><![CDATA[
M   multipart/mixed
M.1  text/plain (0 bytes)
M.2  application/pgp-encrypted
M.3  application/octet-stream
]]></artwork></figure>

<t>Some versions of Microsoft Exchange are known to do this.</t>

<section anchor="detection-of-mixed-up-encryption" title="Detection of “Mixed Up” Encryption">

<t>Check that all of the following conditions hold:</t>

<t><list style="symbols">
  <t>The message itself (M) is Content-Type: multipart/mixed.</t>
  <t>The message has exactly three MIME subparts, all direct children of
the message itself.</t>
  <t>The first part (M.1) is Content-Type: text/plain, and has 0 bytes.</t>
  <t>The second part (M.2) is Content-Type: application/pgp-encrypted,
and contains (after removing any Content-Transfer-Encoding) exactly
the string “Version: 1”</t>
  <t>The third part (M.3) is Content-Type: application/octet-stream.</t>
  <t>After removing any Content-Transfer-Encoding, the decoded third
part (M.3) is an ASCII-armored OpenPGP block of type “PGP MESSAGE”
(see see section 6.2 of <xref target="RFC4880"/>)</t>
</list></t>

<t>Please see <xref target="detecting-mixed-up-python"/> for an example implementation.</t>

</section>
<section anchor="repair-of-mixed-up-encryption" title="Repair of “Mixed Up” Encryption">

<t>If the detection is successful, repair can be attempted with the
following steps:</t>

<t><list style="symbols">
  <t>Convert the message’s Content-Type: value to multipart/encrypted,
while leaving any other parameters untouched.</t>
  <t>Add (or reset) the parameter protocol=application/pgp-encrypted to
the Content-Type: header.</t>
  <t>Drop the first sub-part (M.1).</t>
</list></t>

<t>Please see <xref target="repairing-mixed-up-python"/> for an example implementation.</t>

</section>
</section>
</section>
<section anchor="clearsigned-messages" title="Clearsigned Messages">

<t>This section aims to collect examples of repairable mangling known to
be performed by some currently-active MTA on clearsigned messages.  Each
section offers a brief description of the mangling, a way to detect
it, and a proposed method of repair.</t>

<section anchor="extra-mime-footer" title="Extra MIME footer">

<t>TODO: describe the mailman case</t>

</section>
<section anchor="content-re-encoding" title="Content-Re-Encoding">

<t>TODO: despite the content of multipart/signed parts being ostensibly
invariant (see page 4 of <xref target="RFC1847"/>), some MTAs mangle them.
Describe some reversible manglings, like gratuitous application of
Content-Transfer-Encoding.</t>

</section>
</section>
<section anchor="performance-considerations" title="Performance Considerations">

<t>Trying multiple repair techniques can be expensive.  A
resource-constrained MUA may want to limit itself to detection of
possible mangling, rather than trying every possible repair it knows
of and indicating</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>There are several ways that attempting repair on a mangled message can
go dangerously wrong.</t>

<section anchor="only-repair-for-cryptographic-improvement" title="Only Repair for Cryptographic Improvement">

<t>If a message repair produces a seemingly-better-structured message,
but the repaired message still cannot be decrypted or verified, then
the MUA should abandon the repair and instead render the message in
its original form.  Additional message modification that does not
provide a cryptographic advantage over the received form of the
message offers no benefit to the user.</t>

<t>TODO: is a decryptable, unsigned message “better” than a verifiably
signed message?  What is “an improvement” isn’t necessarily clear here.</t>

</section>
<section anchor="avoiding-another-e-fail" title="Avoiding Another E-Fail">

<t>Promiscuous message repair may inject new vulnerabilities, or modify a
message beyond recognition.  An MUA attempting message repair should
use caution to avoid re-combining potentially malicious material with
material that has better cryptographic guarantees.</t>

<t>In particular, a responsible MUA should take care not to claim
cryptographic protections over material that does not have them.</t>

</section>
<section anchor="do-not-attempt-repair-inside-end-to-end-encryption" title="Do Not Attempt Repair Inside End-to-End Encryption">

<t>If a message or part of a message arrived end-to-end encrypted, none
of the recommendations in this draft should be read as encouraging
their application to any cleartext material within that end-to-end
encryption.  These techniques are specifically for recovering from
damage done by the MTA, which by design does not have access to the
cleartext of an end-to-end encrypted message.</t>

</section>
<section anchor="interactions-with-dkim-verification" title="Interactions with DKIM Verification">

<t>A mangling MTA may also add DKIM headers after mangling.  A subsequent
MTA that handles the message may verify the message by checking DKIM
headers, storing the results of that check in an
Authentication-Results header (see <xref target="RFC7601"/>). If the MUA performs
message repair, the repaired message might not pass DKIM check.  An
MUA that relies on Authentication-Results headers for any purpose on
such a repaired message should consider re-validating the DKIM header
itself directly after message repair (though this introduces new
problems for stored/old messages, as older DKIM signing keys may no
longer be published in the DNS).</t>

<t>Note that a repaired message may have cryptographic properties that
obviates the need for DKIM verification; an MUA that requires messages
to have a valid Authentication-Results: header might waive that
requirement for a signed message (whether any repair routine was
invoked or not).</t>

</section>
<section anchor="helpful-mta-mangling" title="“Helpful” MTA mangling">

<t>An MTA may intend to help the user by modifying the message.  For
example, in a clearsigned message, the MTA may modify a
potentially-malicious URL in the text, or it might change an
attachment name or MIME-type in an attachment.  If an MUA attempts
message repair in a way that reverses these modifications, it may
negate whatever security advantages the MTA hoped to offer.</t>

<t>It is not clear that this is a risk for repair of an encrypted
message, though, since the MTA by design cannot perform such a
modification on the cleartext of an encrypted message.</t>

</section>
</section>
<section anchor="privacy-considerations" title="Privacy Considerations">

<t>TODO: privacy considerations?</t>

</section>
<section anchor="user-considerations" title="User Considerations">

<t>Cryptographic properties of messages are only useful if the user
understands them.</t>

<section anchor="indications-of-mangling-can-be-confusing" title="Indications of Mangling Can Be Confusing">

<t><list style="symbols">
  <t>TODO: about how indicators of mangled messages can cause
user-experience confusion (e.g. parts of https://efail.de/ and
https://github.com/RUB-NDS/Johnny-You-Are-Fired )</t>
</list></t>

</section>
<section anchor="repair-indicators" title="Repair Indicators">

<t><list style="symbols">
  <t>TODO: how should a repairing MUA indicate that a repair has happened
(or is possible) to the user?</t>
</list></t>

</section>
<section anchor="undoing-repair" title="Undoing Repair">

<t><list style="symbols">
  <t>TODO: Should a repairing MUA allow the user to reverse the repair
and see the broken message?  If so, what else should happen if the
user takes this action (e.g., how is a subsequent “Reply” or
“Forward” action affected?)</t>
</list></t>

</section>
<section anchor="attempting-decryption-during-repair" title="Attempting Decryption During Repair">

<t>Attempting decryption may require access to secret key material, which
itself may cause interaction with the user.  If multiple repairs are
attempted, each attempt to decrypt may require multiple decryptions.
In some scenarios, multiple use of the secret key may be annoying to
the user.  It might be preferable to try to decrypt the apparent
underlying block of text exactly once, regardless of message structure
or repair, and if successful, either stash the session key, or store
the cleartext in memory, while manipulating exterior structure.</t>

</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document requires no actions from IANA.</t>

</section>
<section anchor="document-considerations" title="Document Considerations">

<t>[ RFC Editor: please remove this section before publication ]</t>

<t>This document is currently edited as markdown.  Minor editorial
changes can be suggested via merge requests at
https://gitlab.com/dkg/draft-openpgp-pgpmime-message-mangling or by
e-mail to the author.  Please direct all significant commentary to the
public IETF OpenPGP mailing list: openpgp@ietf.org</t>

</section>
<section anchor="example-messages" title="Example Messages">

<section anchor="encrypted-message-sample" title="Example Input Encrypted Message">

<figure><artwork><![CDATA[
From: Michael Elkins <elkins@aero.org>
To: Michael Elkins <elkins@aero.org>
Mime-Version: 1.0
Content-Type: multipart/encrypted; boundary=foo;
   protocol="application/pgp-encrypted"
   
--foo
Content-Type: application/pgp-encrypted

Version: 1

--foo
Content-Type: application/octet-stream

-----BEGIN PGP MESSAGE-----

hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
=zzaA
-----END PGP MESSAGE-----

--foo--
]]></artwork></figure>

</section>
<section anchor="mixup-message-sample" title="Input Message Mangled by “Mixed Up”">

<figure><artwork><![CDATA[
From: Michael Elkins <elkins@aero.org>
To: Michael Elkins <elkins@aero.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=foo

--foo
Content-Type: text/plain; charset="us-ascii"


--foo
Content-Type: application/pgp-encrypted

Version: 1

--foo
Content-Type: application/octet-stream

-----BEGIN PGP MESSAGE-----

hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
=zzaA
-----END PGP MESSAGE-----

--foo--
]]></artwork></figure>

</section>
</section>
<section anchor="example-implemenations" title="Example Implemenations">

<t>These examples use python3.  As Code Examples, they are licensed under
the Simplified BSD License as noted above.</t>

<section anchor="detecting-mixed-up-python" title="Example: Detecting “Mixed Up” Encryption">

<figure><artwork><![CDATA[
import email.message

def is_mixed_up(msg: email.message.Message) -> bool:
  if msg.get_content_type() == 'multipart/mixed':
    pts = msg.get_payload()
    if len(pts) == 3 and \
       pts[0].get_content_type() == 'text/plain' and \
       pts[0].get_payload(decode=True) == b'' and \
       pts[1].get_content_type() == 'application/pgp-encrypted' and \
       pts[1].get_payload(decode=True).strip() == b'Version: 1' and \
       pts[2].get_content_type() == 'application/octet-stream':
      encpart = pts[2].get_payload(decode=True)
      # FIXME: this is not a true check for RFC4880 ASCII armor:
      lines = encpart.replace(b'\r\n', b'\n').split(b'\n')
      if lines[0] == b'-----BEGIN PGP MESSAGE-----' and \
         lines[-1] == b'-----END PGP MESSAGE-----':
        return True
  return False
]]></artwork></figure>

</section>
<section anchor="repairing-mixed-up-python" title="Example: Repairing “Mixed Up” Encryption">

<figure><artwork><![CDATA[
import copy
import email.message
import typing

def un_mix_up(msg: email.message.Message) -> \
    typing.Optional[email.message.Message]:
  if is_mixed_up(msg):
    ret = copy.deepcopy(msg)
    ret.set_type('multipart/encrypted')
    ret.set_param('protocol', 'application/pgp-encrypted')
    ret.set_payload(msg.get_payload()[1:])
    return ret
  return None
]]></artwork></figure>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC1847" target='https://www.rfc-editor.org/info/rfc1847'>
<front>
<title>Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted</title>
<author initials='J.' surname='Galvin' fullname='J. Galvin'><organization /></author>
<author initials='S.' surname='Murphy' fullname='S. Murphy'><organization /></author>
<author initials='S.' surname='Crocker' fullname='S. Crocker'><organization /></author>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
<date year='1995' month='October' />
<abstract><t>This document defines a framework within which security services may be applied to MIME body parts.  [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail.  This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption.  This memo defines an Experimental Protocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='1847'/>
<seriesInfo name='DOI' value='10.17487/RFC1847'/>
</reference>



<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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="RFC3156" target='https://www.rfc-editor.org/info/rfc3156'>
<front>
<title>MIME Security with OpenPGP</title>
<author initials='M.' surname='Elkins' fullname='M. Elkins'><organization /></author>
<author initials='D.' surname='Del Torto' fullname='D. Del Torto'><organization /></author>
<author initials='R.' surname='Levien' fullname='R. Levien'><organization /></author>
<author initials='T.' surname='Roessler' fullname='T. Roessler'><organization /></author>
<date year='2001' month='August' />
<abstract><t>This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3156'/>
<seriesInfo name='DOI' value='10.17487/RFC3156'/>
</reference>



<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<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 title='Informative References'>





<reference  anchor="RFC4880" target='https://www.rfc-editor.org/info/rfc4880'>
<front>
<title>OpenPGP Message Format</title>
<author initials='J.' surname='Callas' fullname='J. Callas'><organization /></author>
<author initials='L.' surname='Donnerhacke' fullname='L. Donnerhacke'><organization /></author>
<author initials='H.' surname='Finney' fullname='H. Finney'><organization /></author>
<author initials='D.' surname='Shaw' fullname='D. Shaw'><organization /></author>
<author initials='R.' surname='Thayer' fullname='R. Thayer'><organization /></author>
<date year='2007' month='November' />
<abstract><t>This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format.  It is not a step-by-step cookbook for writing an application.  It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network.  It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.</t><t>OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage.  These services include confidentiality, key management, authentication, and digital signatures.  This document specifies the message formats used in OpenPGP.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4880'/>
<seriesInfo name='DOI' value='10.17487/RFC4880'/>
</reference>



<reference  anchor="RFC7601" target='https://www.rfc-editor.org/info/rfc7601'>
<front>
<title>Message Header Field for Indicating Message Authentication Status</title>
<author initials='M.' surname='Kucherawy' fullname='M. Kucherawy'><organization /></author>
<date year='2015' month='August' />
<abstract><t>This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts.  Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.</t></abstract>
</front>
<seriesInfo name='RFC' value='7601'/>
<seriesInfo name='DOI' value='10.17487/RFC7601'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIANT35FwAA+1bWVcbSbJ+r1+RR34A5iKxmPZCX6ZHIIzpRmCz2E0vpztV
lZKyKWWWaxHIPv7v94vIrEVCst3zMvdhOMeWqMolMtYvIpJ2ux3kOo/Vvjiy
k4k14s3Jm63+af9Y9FWWyZESfWlGsTajILKhkROMjFI5zNvR3ahtE2WSUdLG
v4meqPbEzWlP/Jz29nYQyRxzdrd3Xra3v2vv7gYhHoxsOtsX2gxtEOgk3Rd5
WmT57vb2y+3dQKZK0ss8uLfp3Si1RbIv/FbBnZrhabQvTk2uUqPydo/ICYIs
lyb6Q8bWYLuZyoJE74tfcxtuisymeaqGGb7NJvTl9yCQRT626X4g2oHAjzbZ
vuh1xE8dcaLjeGJTfuwO3JNGq1j8JMdm7q1NR/uiO1GpDqURR3qqY3GmByrN
tcrEjdHW8LgMu6t8X+zsficOUysjcZV3+E2oc/DhXN2LWxx1U5zfusc2wrY7
29vbe/73wuTEsZurLj+Qg0Gqptj86OyGH6iJ1DFEczf611AP8zHOluGZ6YBD
AfE5nchcTxUOfPnqaO/Fi2337fmz7Z39wMy/3nmx99x9293Zeem+Pd357pn7
9mLn+d5+0G63QQVOJkMwv2sESR3n9yog7nU+FhcQGhRKKBOmsyQHPwSEtGVT
kemRkXmRKjGWmZOdTCNBdHaEeG3v1VSlJLmJErwuNjJZAkEKrG7yTERyQvtA
ipnieRnO6YbpHGt0RZGptD1MtTJRPHOr0CO3ACbKnAgj1qo0E1kRjoUMWHVV
VJ1jImc4SzYWucXiM/pIUhvirdCgxczu5WxTRCpLdE7UqMDPXMuEsaZdHQ2s
KkI6cScIrscaB7BhMSFKpJ5ktO5ACcm6KuwQv2S5ltgQ30NnmjVJ3iITmZMN
QK9J7UeO56NCR9KEzBOhJ0msaBM6IT0Y23vaKoQ58fCS2qymLxLEx7ECW/3G
OGIGqknkEx1FsQoCWF9qI0wgHT9o/ATBpfpQ6JR3zcQZaC2wPk1+/EOcUAIm
LcimM9Hq31xdtzbdpzi/4O+Xx29vTi+Pe/T96nX37Kz64kYE+OXi5sy/p2/1
zKOLfv/4vOcm46lYeNTv3uIDEgpaF2+uTy/Ou2ctd/w5AUFNnXw0cTJJVQ4u
yYzEHqYweGJZcHj0RuzsiU+fvN18/uy+k73g+/1YGd5KWAN1dL+CzTMhk0TJ
lLaVcQz3CE2SMQkVQoG8jBgrpzUqnWhjYzuaBXNMFP8Qf/ZJvW9Ivbuk3n+K
dUj7z/5N988NAZdH8scRJCnvKJUTIh0mCMrxNIOFkBch4lIVKjgCb86wIx8X
1IMkXYLWmzAuIiWux4WJVDrQabQpLoo8tvZus1yFqOngXJj/Xg3Y9CpVlKQz
OF6s75S4hPlFYQHWglxwQ5zQ4IA9Mlg9lFBkcq5gCAsgxFSNbYn/AqdjN1oz
4LryEnNcuJ7nAm3RHoNOsiJY3DC/h4hpJTIJp/0CjpPCzxc48MZm+VA/8IGP
H0IsOIKYHDVlGP1TQJFoudJ4KzNjc/QOkraGYHLF9jSvV06JyP1+/lyu7v1p
7aZ4Gzg3FudEEcPMrPbFpEBMhS3A1Anoph2rUM+LkVokYx2KoXKOGY6nSbjO
MxUPaZ/amzP3r8hHP6Iog6sYjXOSmVO0TTEocl5RG6MaEYDWgIiNxdtZglAa
wzwG3s1hwQEsxDghOqeNwWs5eMQ7liwJY9iQV+lHTHHnt04FRJaoUA/9Rrml
/SuieQOydyKnOpSjnR77HdjTyoqDtER1nlolV5FTUcIWWTKYt0Y0xKOpjDVb
ZBlA5yVUB0+YWKwdj+aUTJFpsjVC9niTzosya8gLWoizwr28Se0AFgpsAoBG
hjrn171zZ2FDFBCvjfSw1rGxktgSZj3Ac5U5T1creyM0uzVYuyh08zoQhtP8
9VYZ3bLWBls+T6P43mAVvK0L1xSaHOPofDh1O7dtfCwwDLaVeFQ2r9WENUUM
e8D5jx5rUMYUDFRIFBcGkASkSnDJHe+x0geN8XB4Nss0RpOcS3UV5LW8npW+
1gVbr+91RCbaCiP9AsMiHhIOGiudMo7JxMjCLdJ2Er/TyTwmioCBA8IrDZmX
GuK5SzLsUBh3ECuUGcnMS6SUgOO/vCNckqpRESNKKWOL0ZgBlzeWAKYHztC5
eEIrVYnUaYv2m2xiYpbblLak/VfJJVjwNkMfDuigKwFTaOMYLrPCRyXdTjrV
cMI80gQlfZEiP8vU8bh1PRSlpChKEPHubSaHCi5igZajuSO8qY/wyFwqq7m+
6F3sV169PGT7HpFsgSMKShYTOJtmnflXQHuzmHIHotlpQarAecZ6LGxiEeVC
nXLDe7VGPiLLignxH+BSk4qJWM4gLwKWi9LwEahDuCyjYKUSqJnKYaUpw0G4
G8rfEJhYXrQ8/k2KONeIjQiaGb3kDbJgvTYQT7TxDvQHUXrS6kU19ocgT2mx
9n1KyCj6YQNGczW2RRwt4rIoSgmIsx7CtRTsRH4IguNq335pmEvFQqtl7siP
lKoK9+CTUwq2xMqA7gxBM4QPCBQaQAbhHLEzqCJNQWI8ayM/IhuHvQlrlrgM
HO5YhuOgpMMOGaZIMUDmMvRKk/hXcza8Wfo/63U60LlTfYZ50GneBkYd1YeA
crT6+gFvbpKWOK5C+SqAfmHUon2xS8goKAMJWVYtpwAyzbfqA/qEkMB15cM5
aQKy47hXzZkwPW48cr5xMRzyPgglM0EjsFke0NEz5OMi1xOCw90l3GwgCIqk
rC6EDEwjFB2J9UypUr4BI6xqoaqEkfHbz5839gNOsI8IJTw+pXvX2REuFLsw
tkU1kcUhu/NDbJirvE2VATkJgkOCF0NgszK5ZPFqhwdKIFQfoT93BAqHnz6B
iUWykvz+HPnMcPecSM/VQ76VxBKsWN+GCucq2/Bvd792sH7n6ZcOxrEe0SHj
6A4t7OswtQS5K8jMHqS0Jhg3Sw3yffLkieipvDILsVxvg6OxCu98LIrj0kiG
MGN7T1qElCHSDl2MbRztc750/RjZrvc3CBkdWSQeJm9fzxK1v8gzjzabs0lC
EESYE5gcpxALY+qsGLDmbjJRERJiClRjHcNl0WmIeY/hdWP9oU6znLUflHV2
ltBWi81ZPVHixddYB34FDKgW2l2y0EoJV/kclsixD/CZ01Kk93bKMQVpRrUY
W7lK25AOQJ0ZbZSMKQ8LraBJrXdOIfbFTqsmFGJPazqffoXOppr503b/Bmmc
ehMos5GK3NachM3tDrfRvTo6PW3LlOJfVMHxQWyhcqRpoEu06FH/+Oqqe3Lc
olXYON0/p7zPYEcYzZkc1d5gl5wkvIFrytzQT5+cD6eqKataG9aczOC8zefP
DEGkqQ1+Lpf2tnLpkMtqQzkd+kOXNqW56kXuBuBys4Q+DsIKqi1N2LdyskOV
rdqmGBg4SwKLYd95U5nXFgWHfKZgkLLEg/osRRMuUbKSnOWsBUPh8bl6VSBq
APNXNtiNIs7ugQBUvsHbV6MZylhE8oOVqu0TP5o2T6tLZPwmPYRR507YGmHU
7doiKWdqCtDx798TYDP5+AJm+Q+hliXJ9X8Atxw/AEc47zq0gKrpY8zyCGq7
fXWMvTnJAae9tC9V5QyWYZ/GSmVll70g4U4QVSuyZ4uDKQNFTEY+qQzlEzOg
i6lMtcQkdgoJufq9yhdQoR2+wNe5XVrNwZ7zj07QK4/B71PFgbQpz7KMBgif
FxoGkjWdJIWZlR6QtNcpAGcQR76w5vLwlbkMK2A6qzFfrKqUSYVjoz8UVdYM
ZUyID1NF5fgAhmqLNFRtquFBkpp1HUkZl9iJRVCIWE8IIbqIXCmIP0uVT9ea
BHpddYMrBUwXcWlWZXQldViVdJ8TTVI1DVBAXIL0gysFxdf57BuZwFVrn/lk
tJuMuUTuMYjzm0SJ35rMVCz2FcCiYITzEQJKITcqCaeWxXJB9WHvzclvzCec
pxPYyNQVaJZi9uU4Hs6/rp94whIu4ROUJw9GQB6WP1DUVGg32gF+1mZQFvDc
9MZhslwD5Pgi3kCVxQ5XXXJVEyqiUZ7HMJ6knrmMTg4gDWsa63rxwIYklaOp
kjWPlAz8BRxcqkfagPW+Z4R4wChP1j2oZmnJCSeyitoyeUA8pOxbLuTAMkJC
ndNkO/X7+iqNa055X1YWaUqvZ6g4bdRQ58LXXcrCBTsRwhIlU1z5qDDz7lS0
HN9bTpWlqGpNs2B+JFLn93QUrNmiFKxWhxaeUWXUKArpcDtQI/bcZQOhO7Wa
TF90jQuvx+1XVG1fqTRvUqR3WViQX1nQHTJabf6imGPUvZgWsYEhDHSscy7/
QfC+QigrZg3UzLoWgx0ZFhbJzbA6NMxmYSenKAGVuEJZOFkif6SzYAi8yWSg
Dc1LLHk6zdnfRMIJaqZbgq2aTJTbXeVvVbXV8X1BDUYFoAQcJyFpKpKRd9ch
FcA2uRaWJdY499JQZa6UhWXxmIIysPkkWFVkyZyKzVNUKihIm5ZRIOhZcY5H
Xcei0jWcsq8CwuOi5zE1Ib6Szf8dF2FTB4Zt86FMU7aERqG1USM3VHb0sZ5k
PIFSRr6uW/XUqEBVMmxA4yR30rgRm8oR+WNX3GrGMZK38cpMWc+8ULUpm7kl
VUGjRSGEq2U1whM77mYTYMg4MiR5kCINofZBo5ZaFk8RoDcJqoZjeuI6aAsS
kwynvRMIaoI56izlW8lcVjScSnrlYNTd++m0L96xK3Cs+BbBwtDn6rxsq9xA
k8DMvKSv1vuaQzmYu+bAuJkCmxBeaK63ExPFar6RRYuyk5pvPYAxISXktDdt
FVSNgWYZGBYE9OCr8dTS4RyeOqAm6BYUJ3J/YOA0N9St42AUgye6ugDw1BE+
ryFL9JA2C+Z9yObysOU6VCS7REJozBmmhN0SF4x9nT7m1gHSwS/RlnmUD/BR
pIRiMaPsUzwOmc4Eyn4meTLu+jAkYXIbggo8IHJlBCisl9u8o1wHYqbaPBua
9g16Uk51T/GOmjuORJKEirZsXKN57jbjAVblfUm1OV9Qs4xFbWxAdwzwnjKH
YhDrbFxdFRC98ytKh+ClfB9ryYlpFbaRlb0ZmhnYwVTDujPfhHVx1xE1bRjC
92RPDQnxnYMqSmXU/nAG6ZppKyRXpnteFe6la8eAjLS+xeDEKhYC9nrZWSOB
ewkAyEF8CuvQZZSpvav6a8Sd1msVJ8i0W94o/S2OlUZsKuOlXrjhvuEYS1T4
gozNBdlSZ0pfIsQrmwY+Gdxkw1qWxG2Wbo13qeJ1I5C260B6c3lWiptcGod4
4B3HubKUZwIEcqSFzDe6PUWjKGVrc6mELVzUQ0Do6bCUpIcAi8brqK8afS4L
cvqx2D7kkimOEhg1gg7BV+N/CrJZifArfJdVRx9D/5i3jOXIDTO4Irfg0JPv
L5JREY5LdXbnI0ZZcJGNUnTQ4C2Z4yZ1XUJVbVdHDo+Xvc+qLiA1QasHxo/j
yOPg8QahWYbfmMOUwDTxk8K5ST8EAd8k+fpSi92w+UbrXCeTb71Aa2EAvnnE
OhzwLRK+JZWVeOfU52ZlybiMZUc4+iGnqsMiW206y4zpH8IdWA5gotwR9Amg
TR2p8+mZS2G5rxoId5GMklm6SxZyHYAIgHDWVQdR0+X+WGWc50m2v7WlhnT/
JVJb3P0Q1fMRYnox6AAabV3eHLbPe1dbP9qxMbP2rS3aXcSAV+wyN+gWlQd5
JZXLih3lqeg8ZT4lqjIUG5U/5oJbZuQ7pvaa4To+FdKg3HUbtJHFkDYgRaMF
HVHBKjKulpMgqWpYOy2+/cA23IjKgaszU3Cnh4MUvtM0Uh54icxuskELFWdV
/HRn8ArlReX7U2yxDk05OW06uXO6W4Ec0cKh4llL8J3OFtzmvUyjVjlRwieE
1JSESLp1itJT1YXGXpGuZM0qz14vFNULkQv2UacBI+G5UpXzHbkS9HoMWoIC
muduAOgaP1ZFW5eIMgMXCjZslkFV5t0USpID8klGfWVhjrBqjZpwpEjlNYIs
VAZ5p4Ujrgb6qwm5a0XUZ+E7PuQBXfCyQZPYvL49lPBVmfIWhL+CWZJGc6AB
kqqWzpPEvFxdoCenWbZnLIyXytwjSDgm/tY+qm6uBZVndzVJqFazSK40B304
rGzsD5WxK8CpOCQyuArmvbYmVZ7YdLbpK91wNzpBOsk6gBGQK0+tr4ieds+7
3+SA569GVEDIWFFmEpTOCFqPU0k/8FtLXb/9Snd+xXGkcS4EDFfw5iaLciZW
FoAHakiXBBgb+vD1+yJ51I4ta8xCYU13j3Ii07vI3lOy1tcGnFC8HXQ9cMCi
KilmxWjk7hgAJYKpKcMEyupck7jhaWPpPG10N9pyV9a/dl2dxDeYBb5x7V2g
uygOynyt37fyqKvHIJlitXF3UKie7/STnJFjhDg9vn5VNY5oYdoI6Dmv7rT/
S6t82LHpKKAat2sQrOwB1ENOTYJQ9uiqg/j0ZGU3+2vuKXDN4ldQmH3q1I6l
isVxfEedv/9V/PkvqVJLxP6Th17bbxzYJ4bXfb/OtmuLr2i2Vif4XgzohijY
ejC09nue5C9Lcn+ntbLB03LX8PDTbmPqku2+3Njm/2qC62ffstxcE7wxEz+H
xyen56LRMnScrwaNT+97t093x7cnR8cv+neH3a37i+J5tPedvHl4tfd2+/Kn
H5O093T63S8vf9q5DS9/3B1O1YvncT/uxQ97F3+5Pwd4v3fSiw6HZ4Mfj5+/
u0mSnafnOy9Pzl6ore6HwWz21+vXe/Jq+9Ze3+1sv3370pjL6V+3L8wvZ0/7
b36++oUXGb18d/L24ZU6+fBxdvdxMru7edbdfda/6quHy71uotTF+bOHj7+8
H9r/2Z5dfOh+eBYP9p7dZ9M4+uXls1v3lwrd7uHr5y/Gs5+f3/68V1zv5OdH
749PTw/thw/TI3XaT5LnN293Tz8epj+Pnp3kxd3Vi/OHQXF3Bs59ePf+KS+y
M8t3d3q3F38VZx/D/rna+vE8672c9t4dTS8uTp5eHOkXBzzw4ONH2a15fXze
+wKnWZCs9M6U5v7ixXXFGp3UT0+W3rD4toj//8OquC05b1FfV+v6lsH3lOUB
tuUHrSJryyzUulXP/6+p/dfUvm5qVfDyDfCvZamc41dNbcKSrqX+lEp0dM2A
KuD+dfnnFHSlVwOJUhuZMSGjsSvquXMjShxe9cSZG0HoA0k4wZABEE2nonC/
vHtE91WW3aeAQ1h9Y+NvZKbEHroqnObuj7g65dXkinmRomv3f/AefxTJ+iQb
7c+P7XjXtSHa/4R523jfB0qAV4zujFT+h29e/0F1mPUNcXAg1hY8w1o5C/EV
aOqgmupvnq5vVO+xbqzMOobxSk8ZKf9WvXYr/Lr9+6qda6ey9sWp5c7uos7B
dVooXmCwtmLezsotV7qgL6+0jIIO3WNK1j0lteNasdLuN9HU9GMNSQgq9nAn
5qC52DKyGnOeiFenP/eP96uyFRWaJP2VpfK1dipg+dtI7pKT4EtOzY2BVBWp
gSegg6wolqFaH6z9lv5m1jZxdnyAGzhEvu5+aUwnHaEVIEvHqC/45CWc8/v/
2t5pTl/mZua4JZAOIIUyglgSzD15JWO6AFIZ+GVVpVhl4Ktv9Px7Bh7aZPZl
g/cv6BqrGc27gMKQC/gGB1Cz0S3TuUhcY/zXpXN+bziLBTezUXOWEvcDPkAn
UiqhLzyiOaADbODUe20JlF97PJYvbK2vlWgeKvUFM1023RnBIz/1687+73PD
Sfz4mNeHc+pX/h+zYVXZAj0AAA==

-->

</rfc>

