p≡p I-Ds (IETF Internet-Drafts)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 

1329 lines
61 KiB

<?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 comments="yes"?>
<rfc docName="draft-marques-pep-email-02" category="std">
<front>
<title abbrev="pretty Easy privacy (pEp) Email">pretty Easy privacy (pEp): Email Formats and Protocols</title>
<author initials="H." surname="Marques" fullname="Hernani Marques">
<organization>pEp Foundation</organization>
<address>
<postal>
<street>Oberer Graben 4</street>
<city>CH-8400 Winterthur</city>
<country>Switzerland</country>
</postal>
<email>hernani.marques@pep.foundation</email>
<uri>https://pep.foundation/</uri>
</address>
</author>
<date year="2018" month="October" day="24"/>
<abstract>
<t>The pretty Easy privacy (pEp) propositions for email are based upon already
existing email and encryption formats (i.e., PGP/MIME) and designed to allow
for easy implementable and interoperable opportunistic encryption: this ranging
from key distribution to mechanisms of subject encryption.</t>
<t>The goal of pEp for email is to automatize operations in order to make
email encryption usable by a wider range of Internet users, to achieve
wide application of confidentiality and privacy practices in the real
world.</t>
<t>This document defines basic operations of pEp’s approach towards email and
two PGP/MIME formats (pEp Email Format 1 and 2) to provide certain
security guarantees. <!-- TODO-02: Furthermore: Bcc and message storage... --></t>
<t>The proposed operations and formats are targeted to Opportunistic
Security scenarios and are already implemented in several applications of
pretty Easy privacy (pEp).</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>This document contains specific propositions to those parts of pretty Easy
privacy (pEp) <xref target="I-D.birk-pep"/> that are specific to email <xref target="RFC5322"/>.</t>
<t>All changes required for the pEp propositions on email to work just
affect implementers of Mail User Agents (MUAs). <!-- TODO-02: i.e. those
work without changes to MTAs... --></t>
<t>pretty Easy privacy (pEp) for email is a proposition to both, implementers and
Internet users, to make end-to-end encryption of emails straightforward.
<!-- TODO-02: Needs more explanation, why to implementers ? --></t>
<t>Whereas Pretty Good Privacy (PGP) and OpenPGP <xref target="RFC4880"/> provide a
basis for good encryption, we still miss implementations that also
provide a sufficient level of usability for ordinary Internet users.</t>
<t>Two users using pEp-enabled mail clients basically don’t need to do anything
else than just writing emails.
<!-- TODO-02: explain more, what users have to do in pre-pEp world --></t>
<t>The following example roughly describes a typical pEp scenario:</t>
<t><list style="numbers">
<t>Alice – knowing nothing of Bob – just writes an email to Bob:
this mail is sent out unencrypted. However, Alice’s public key
is automatically attached.</t>
<t>Bob can just reply to Alice and – as he got her public key – is
now able to encrypt a message at this point. Through a
color-rating (cf. <xref target="I-D.marques-pep-rating"/> Bob becomes aware of
his message now going out in a secure fashion.</t>
<t>As Alice receives Bob’s key, as of now she is also able to send
secure messages to Bob.</t>
<t>If Alice and Bob want to prevent man-in-the-middle (MITM) attacks,
they can engage in a Handshake <xref target="I-D.marques-pep-handshake"/>,
comparing their so-called Trustwords <xref target="I-D.birk-pep-trustwords"/>
and confirm this process if those match. After doing so, their
identity rating changes to “encrypted and authenticated”
<xref target="I-D.marques-pep-rating"/>, which (UX-wise) can be signaled, e.g.,
using a green color rating. This color rating is also applied to
messages (in- and outgoing).</t>
</list></t>
<figure><artwork><![CDATA[
----- -----
| A | | B |
----- -----
| |
+------------------------+ +------------------------+
| auto-generate key pair | | auto-generate key pair |
| (if no key yet) | | (if no key yet) |
+------------------------+ +------------------------+
| |
+-----------------------+ +-----------------------+
| Privacy Status for B: | | Privacy Status for A: |
| *Unencrypted* | | *Unencrypted* |
+-----------------------+ +-----------------------+
| |
| A sends message to B (Public Key |
| attached) / optionally signed, but |
| NOT ENCRYPTED |
+------------------------------------------>|
| |
| +-----------------------+
| | Privacy Status for A: |
| | *Encrypted* |
| +-----------------------+
| |
| B sends message to A (Public Key |
| attached) / signed and ENCRYPTED |
|<------------------------------------------+
| |
+-----------------------+ |
| Privacy Status for B: | |
| *Encrypted* | |
+-----------------------+ |
| |
| A and B sucessfully compare their |
| Trustwords over an alternative channel |
| (e.g. phone line) |
|<-- -- -- -- -- -- -- -- -- -- -- -- -- -->|
| |
+-----------------------+ +-----------------------+
| Privacy Status for B: | | Privacy Status for A: |
| *Trusted* | | *Trusted* |
+-----------------------+ +-----------------------+
| |
]]></artwork></figure>
<t>This workflow is implemented as running code already in various pEp-enabled
software, cf. <xref target="implementation-status"/>.</t>
<t>Note: No propositions are made at this point in time that would
require implementers to change the behavior or feature set of email
servers. Another Internet-Draft may propose changes to the Simple Mail
Transfer Protocol (SMTP) <xref target="RFC5321"/> as to allow for onion routing of
email messages in a way metadata can be furtherly protected for
communication peers – achievable by message encapsulation. pEp’s
email message format 2 described below is already prepared for this
scenario.</t>
</section>
<section anchor="terms" title="Terms">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in <xref target="RFC2119"/>.</t>
<t><list style="symbols">
<t>Handshake: The process when Alice – e.g. in-person or via phone –
contacts Bob to verify Trustwords (or by fallback: fingerprints) is
called Handshake. <xref target="I-D.marques-pep-handshake"/></t>
<t>Trustwords: A scalar-to-word representation of 16-bit numbers (0 to
65535) to natural language words. When doing a Handshake, peers are
shown combined Trustwords of both public keys involved to ease the
comparison. <xref target="I-D.birk-pep-trustwords"/></t>
<t>Trust on First Use (TOFU): cf. <xref target="RFC7435"/></t>
<t>Man-in-the-middle attack (MITM): cf. <xref target="RFC4949"/></t>
</list></t>
</section>
<section anchor="opportunistic-security-with-pep-for-email" title="Opportunistic Security with pEp for email">
<section anchor="automatic-keypair-generation" title="Automatic keypair generation">
<t>For every email account a user has in a pEp-enabled Mail User Agent (MUA),
a different keypair SHOULD be used by default. If there are no keys whatsoever,
RSA-4096 keypairs for OpenPGP encryption <xref target="RFC4880"/> SHOULD be generated
automatically for each email account. However, the key length MUST be at
least RSA-2048.</t>
<t>If for an identity there’s an RSA keypair with less than 2048 bits, new keys
MUST be generated.</t>
<t>[[ TODO: Shouldn’t this go to general I-D ]]</t>
</section>
<section anchor="key-distribution" title="Key Distribution">
<t>By default, public keys MUST always be attached to any outgoing message.</t>
</section>
</section>
<section anchor="encryption-of-email-header-fields-and-interoperability" title="Encryption of email header fields and interoperability">
<t>In pEp, implementers MUST put privacy first: email metadata
(i.e., headers) MUST either be omitted or encrypted whenever
possible.</t>
<t>In case of email header encryption: implementers of pEp SHOULD
be liberal in accepting other approaches to encrypt email headers, but
MUST use the strict and interoperable pEp formats for any outgoing
communication.</t>
</section>
<section anchor="pep-message-formats-for-email" title="pEp message formats for email">
<t>The pEp message formats 1 and 2 (as described in the following) are
email security formats used for sending signed and encrypted emails
whenever public key(s) for the recipient(s) exist.</t>
<section anchor="unencrypted-plain-text-message-with-public-key-attached" title="Unencrypted plain text message with public key attached">
<t>If for a recipient there’s no public key available, a pEp message MUST
be sent out in plain text as MIME message version 1, with
“Content-Type: multipart/mixed” and the OpenPGP public key attached in
ASCII armored format, named “pEpkey.asc”.</t>
<t>For a MUA implementer this fulfills two functions:</t>
<t><list style="numbers">
<t>It can be easily detected that the sender is a pEp user.</t>
<t>The MUA (if at least OpenPGP-enabled) can enable the
receiving user to import the public key to engage in
end-to-end encryption with the sender; a MUA implementer
can also decide to automatically import the key such that
the user can immediately engage in opportunistic encryption.</t>
</list></t>
<t>The plain text messages SHOULD be sent out with the UTF-8 charset
Content-Type set.</t>
<section anchor="example" title="Example">
<t>Please note that in the following examples the “pEpkey.asc” attachments
encoded in base64 format are only shown in its first and last line
(and otherwise shortened by three points).
<!-- TODO-02: Move up, as it covers all examples; applies also
to other attachment types --></t>
<figure><artwork><![CDATA[
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Test
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----3YNFBU8B6LV244ZJNQZL12LVUAPGG6"
Content-Transfer-Encoding: 7bit
------3YNFBU8B6LV244ZJNQZL12LVUAPGG6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=UTF-8
Test
------3YNFBU8B6LV244ZJNQZL12LVUAPGG6
Content-Type: application/pgp-keys;
name="pEpkey.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="pEpkey.asc";
size=3813
LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkZxNWlkd
...
SUXFhQT09Cj1adlFnCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0K
------3YNFBU8B6LV244ZJNQZL12LVUAPGG6--
]]></artwork></figure>
</section>
</section>
<section anchor="pep-email-format-version-1" title="pEp email format version 1">
<t>pEp email format 1 is an encrypted and signed PGP/MIME format, which by
default ensures:</t>
<t><list style="symbols">
<t>correctly signed messages</t>
<t>delivery of public keys (at least and automatically: the sender’s
public key)</t>
</list></t>
<t>By default, when a public key for a peer is available,
pEp-capable MUAs are REQUIRED to send out email messages
according to <xref target="RFC5322"/> and in PGP/MIME format <xref target="RFC3156"/>
with the informational “Subject:” header field set to “pEp”,
as follows:</t>
<t><list style='empty'>
<t>Subject: pEp</t>
</list></t>
<t>In turn, the intended human-readable subject (in pEp called short message)
MUST be moved to the body of the message (in pEp called long
message) and appear as the first line there. pEp implementers are REQUIRED to
display the intended “Subject:” field as the real subject line in the
respective MUAs to help users to easily grasp the real subject.</t>
<t>Alternatively, the “Subject:” header field can also be set to its
UTF-8 variant with “pEp” written with the equivalence symbol instead
of an “E”:</t>
<t><list style='empty'>
<t>Subject: =?utf-8?Q?p=E2=89=A1p?=</t>
</list></t>
<t>Additionally, a header field “X-Pep-Version: 1.0” is added to
signal compatibility with pEp email format to pEp-enabled MUAs.
<!-- TODO-02: Same for X-Pep-Version: 2.0 further below --></t>
<section anchor="example-1" title="Example 1">
<t>Example. Using the well-known example of <xref target="RFC5322"/>, an email message sent out
with pEp in message format 1 looks like this:</t>
<figure><artwork><![CDATA[
From: John Doe <jdoe@machine.example>
Sender: Michael Jones <mjones@machine.example>
To: Mary Smith <mary@example.net>
Subject: pEp
Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: <1234@local.machine.example>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0016_01D0E64A.33EC31B"
Content-Language: en-us
X-Pep-Version: 1.0
This is a multipart message in MIME format.
------=_NextPart_000_0016_01D0E64A.33EC31B
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
-----BEGIN PGP MESSAGE-----
hQIMAwusnBHN80H+AQ//cJLQLOl+6hOofKEkQJeu0wedmwt+TkzPx/sCUQ80dzLv
...
j/ES8ndDBftM5mZLzFQ2VatqB9G9cqCgiOVFs6jfTI13nPfLit9IPWRavcVIMdwt
Xd9bdvHx/ReenAk/
=7WaL
-----END PGP MESSAGE-----
------=_NextPart_000_0060_01D0EAEF.2D54F450
Content-Type: application/pgp-keys; name="pEpkey.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="pEpkey.asc"
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBFQRqIcBEACpsz3mK1zqPdqDlxU6Yws/Xz14LJpszDLlKJckpa7hSc9jfZ4Q
...
Ag7IIk/Gj628hYTdCpNCUc9b1vS6xMAkxJWYgNVwLFS2goikEHCiyzDe
=MicJ
-----END PGP PUBLIC KEY BLOCK-----
------=_NextPart_000_0060_01D0EAEF.2D54F450--
]]></artwork></figure>
</section>
<section anchor="example-2" title="Example 2">
<t>Using the UTF-8 variant of writing “pEp” with the equivalence symbol, and
an additional document attached (an example PDF attachment), an OpenPGP-signed
and -encrypted pEp email would look like the following:</t>
<figure><artwork><![CDATA[
From: John Doe <jdoe@machine.example>
Sender: Michael Jones <mjones@machine.example>
To: Mary Smith <mary@example.net>
Subject: =?utf-8?Q?p=E2=89=A1p?=
Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: <1234@local.machine.example>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0016_01D0E64A.33EC31B"
Content-Language: en-us
X-Pep-Version: 1.0
This is a multipart message in MIME format.
------=_NextPart_000_0016_01D0E64A.33EC31B
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
-----BEGIN PGP MESSAGE-----
hQIMAwusnBHN80H+AQ//cJLQLOl+6hOofKEkQJeu0wedmwt+TkzPx/sCUQ80dzLv
...
j/ES8ndDBftM5mZLzFQ2VatqB9G9cqCgiOVFs6jfTI13nPfLit9IPWRavcVIMdwt
Xd9bdvHx/ReenAk/
=7WaL
-----END PGP MESSAGE-----
------=_NextPart_000_003A_01D10CF6.2DA15150
Content-Type: application/octet-stream; name="example.pdf.pgp"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="example.pdf.pgp"
-----BEGIN PGP MESSAGE-----
hQIMA/bohV/mG7k7ARAAyy+sdpZYZBhUH/p0gJ+wIlEGTTG2rjLpLuixBrm5Cuj3
...
oAXrQJJgD0F3Ung24Kkundua2gSa9cyeYvUXtA2mbXT7YyN7RdxrMFNfdVFqXZEc
pXqIjL2uKBbyjpS44fc3GmOZNih3bI6q8nl/
=Mvna
------=_NextPart_000_0060_01D0EAEF.2D54F450
Content-Type: application/pgp-keys; name="pEpkey.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="pEpkey.asc"
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBFQRqIcBEACpsz3mK1zqPdqDlxU6Yws/Xz14LJpszDLlKJckpa7hSc9jfZ4Q
...
Ag7IIk/Gj628hYTdCpNCUc9b1vS6xMAkxJWYgNVwLFS2goikEHCiyzDe
=MicJ
-----END PGP PUBLIC KEY BLOCK-----
------=_NextPart_000_0060_01D0EAEF.2D54F450--
]]></artwork></figure>
</section>
</section>
<section anchor="pep-email-format-version-2" title="pEp email format version 2">
<t>pEp email format 2 is a strict PGP/MIME format, which by default ensures:</t>
<t><list style="symbols">
<t>correctly signed messages</t>
<t>delivery of public keys (at least: the sender’s public key)</t>
</list></t>
<t>In pEp email format 2 the actual email is encapsulated by an outside
multipart/encrypted message (i.e., the actual email is sent like a forwarded
message).</t>
<t>Headers of messages (received, to be forwarded etc.) can thus be preserved
in the inner message, which is OpenPGP-signed and -encrypted by the
application/pgp-encrypted “Content-Type”.</t>
<t>In the outer message, unnecessary email headers MUST be omitted to the
fullest extent.</t>
<t>In contrast to pEp email format 1, the public key and other files attached
cannot be seen in the MIME tree. The only part which can be seen is an
application/octet-stream “Content-Type” with name “msg.asc”.</t>
<!-- TODO: not a sentence / sth is missing here
or the sender's public key is considered as modification and shown as
attack.
-->
<section anchor="example-outer-and-inner-message" title="Example (Outer and Inner Message)">
<t>A pEp email format 2 message, with the “Subject:” header field set to
“pEp” looks like the following (please note that the inner message is
fully contained in the OpenPGP-signed and -encrypted file named “msg.asc”,
including possible attachments and with the sender’s public key as
“pEpkey.asc” attached at the very end):</t>
<figure><artwork><![CDATA[
From: John Doe <jdoe@machine.example>
Sender: Michael Jones <mjones@machine.example>
To: Mary Smith <mary@example.net>
Subject: =?utf-8?Q?p=E2=89=A1p?=
Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: <1234@local.machine.example>
MIME-Version: 1.0
Subject: pEp
X-Pep-Version: 2.0
Content-Type: multipart/encrypted;
boundary="261a304d18692673570d913f7e24b8cb";
protocol="application/pgp-encrypted"
--261a304d18692673570d913f7e24b8cb
Content-Type: application/pgp-encrypted
Version: 1
--261a304d18692673570d913f7e24b8cb
Content-Type: application/octet-stream
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="msg.asc"
-----BEGIN PGP MESSAGE-----
hQGMAzDKu5MiiyCzAQv9Edg8ulxgxyQfiZRxOpThL0aMFkK7JZH7AJfgdxunLAJk
...
a2jDdzNxotItZk8tWW2h/REdKtRMyXg633DyFLbsIx+cCMnMR1NDChCzvyzUjAw6
XeCGXnY3LB1K
=sdgE
-----END PGP MESSAGE-----
--261a304d18692673570d913f7e24b8cb--
]]></artwork></figure>
<t>The inner message in a simple form without further nesting might look
like the following, when decrypted:</t>
<figure><artwork><![CDATA[
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="17d3c87b380049a821c764604aaf9272"
--17d3c87b380049a821c764604aaf9272
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; filename="msg.txt"
Subject: The real encrypted subject
Hello, there!
--17d3c87b380049a821c764604aaf9272
Content-Type: application/pgp-keys
Content-Disposition: attachment; filename="pEpkey.asc"
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQGNBFmwE70BDACyR/yQ48QSaQAZyvyUgp7f/4WXxiX1OS9vC/UuewdGLosvl3G+
...
A0KQ6HDwLFuLzneg6Nse4pX0hNWGbLNCouYKdL3vfUHokqp/MTzxyPQlOadDHrDV
H9RC4kMrB/ONGe5yn+u4zjrgq9gWCbdJ43fMoiU3lfMIKy5sZ2NPzh9l
=p5bZ
-----END PGP PUBLIC KEY BLOCK-----
]]></artwork></figure>
<t>It does not only carry the encrypted subject, which pEp implementers are
supposed to map (UX-wise) such as to replace the “pEp” subject in the
outer message, but also the actual message (as inline file named “msg.txt”
in case of plain text) as well as the sender’s public key.</t>
</section>
</section>
</section>
<section anchor="rendering-incoming-messages-and-message-rating" title="Rendering Incoming Messages and Message Rating">
<t>pEp-enabled clients MUST NOT blindly render messages. Special care MUST
be taken when rendering the pEp email formats, which provide certain
guarantees:</t>
<!-- ORIGINAL
| Message Format | Error State | Render | Status Code |
| PGP/MIME | Unsigned | Yes | DECRYPTED_BUT_UNSIGNED |
| | Signed, no key | Yes | NO_KEY_FOR_SIGNER |
| | Bad signature | No | SIGNATURE_DOES_NOT_MATCH |
| pEp Email 1.0 | Unsigned | No | DECRYPTED_BUT_UNSIGNED |
| | Signed, no key | No | NO_KEY_FOR_SIGNER |
| | Bad signature | No | SIGNATURE_DOES_NOT_MATCH |
| pEp Email 2.0 | Unsigned | No | MODIFICATION_DETECTED |
| | Signed, no key | No | MODIFICATION_DETECTED |
| | Bad signature | No | SIGNATURE_DOES_NOT_MATCH |
-->
<figure><artwork><![CDATA[
+--------------+----------------+--------+--------------------------+
| Message | Error State | Render | Status Code |
| Format | | | |
+--------------+----------------+--------+--------------------------+
| PGP/MIME | Unsigned | Yes | DECRYPTED_BUT_UNSIGNED |
| | Signed, no key | Yes | NO_KEY_FOR_SIGNER |
| | Bad signature | No | SIGNATURE_DOES_NOT_MATCH |
+--------------+----------------+--------+--------------------------+
| pEp Email | Unsigned | No | DECRYPTED_BUT_UNSIGNED |
| 1.0 | Signed, no key | No | NO_KEY_FOR_SIGNER |
| | Bad signature | No | SIGNATURE_DOES_NOT_MATCH |
+--------------+----------------+--------+--------------------------+
| pEp Email | Unsigned | No | MODIFICATION_DETECTED |
| 2.0 | Signed, no key | No | MODIFICATION_DETECTED |
| | Bad signature | No | SIGNATURE_DOES_NOT_MATCH |
+--------------+----------------+--------+--------------------------+
]]></artwork></figure>
<t>For cases where messages appear unsigned, signed without a key or with a
bad signature, pEp’s privacy rating can be employed to signal issues to
a user in an easily understandable manner, cf. <xref target="I-D.marques-pep-rating"/>.</t>
<t>[[TODO: This needs more work to be understandable. ]]</t>
</section>
<section anchor="encryption-to-bcc-recipients" title="Encryption to Bcc recipients">
<!-- TODO-02: Describe Problem you are trying to solve! -->
<section anchor="algorithm" title="Algorithm">
<t>For encryption of emails that contain Bcc recipients a simple
algorithm MAY be used.</t>
<t>Recipients MUST be partitioned into three lists, one for each of three
possible outgoing messages:</t>
<t><list style="numbers">
<t>To and Cc recipients (without Bcc recipients)
<!-- TODO-02: why is there no such difference in To/CC?--></t>
<t>Bcc recipients unable to encrypt</t>
<t>Bcc recipients able to encrypt</t>
</list></t>
<t>It’s RECOMMENDED that if the original message the user drafted is
saved in the user’s sent folder, that all recipient
fields (“To:”, “Cc:”, “Bcc:”) be preserved.</t>
<section anchor="split-to-and-cc-recipients-from-bcc-recipients" title="Split To and Cc recipients from Bcc recipients">
<t>To and Cc recipients MUST be split from the Bcc recipients.</t>
</section>
<section anchor="split-bcc-recipients-in-two-groups" title="Split Bcc recipients in two groups">
<t>Bcc recipients MUST be split in two groups:</t>
<t><list style="symbols">
<t>First group of Bcc recipients who will receive clear text emails.</t>
<t>Second group of Bcc recipients who are able to receive encrypted emails.</t>
</list></t>
</section>
<section anchor="send-one-email-with-only-tocc-recipients" title="Send one email with only To/Cc recipients">
<t>The original email the user drafted SHOULD be sent out with the “Bcc:” field
removed.</t>
</section>
<section anchor="send-one-bcc-email-for-the-first-bcc-group" title="Send one Bcc email for the first Bcc group">
<t>For the first Bcc group, a regular email message with only Bcc recipients is sent.</t>
</section>
<section anchor="send-individual-bcc-emails-for-the-second-group" title="Send individual Bcc emails for the second group">
<t>For the second group, individual Bcc email messages are sent.</t>
<t>[[TODO: This needs more work to make it better understandable. ]]</t>
</section>
</section>
</section>
<section anchor="saving-messages" title="Saving messages">
<t>[[ TODO: Shouldn’t this go to general []</t>
<t>In accordance to the Privacy by Default principle, messages sent
or received in encrypted form SHALL be saved with the peer’s
respective public key.</t>
<t>Messages sent or received in unencrypted form, SHOULD NOT be saved
in encrypted form on the mail server: this reflects the Privacy Status
the user encountered when sending or receiving the email and thus meets
the user’s expectations.</t>
<t>Instead, message drafts MUST always be saved with the user’s public key.</t>
<t>Other messages sent and received MUST be saved encrypted by default: for
most end-user scenarios, the servers users work with, are considered
untrusted.</t>
<t>For trusted environments (e.g., in organizations) and to conform to legally
binding regulations, pEp implementations MUST provide a “Trusted Server”
option. With the user’s explicit consent (opt-in), unencrypted copies of the
messages SHALL be held on the mail servers controlled by the organization.
This can also help end-users to archive their emails without needing access to
any key material.</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>[[ TODO ]]</t>
</section>
<section anchor="implementation-status" title="Implementation Status">
<section anchor="introduction-1" title="Introduction">
<t>This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in <xref target="RFC7942"/>.
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.</t>
<t>According to <xref target="RFC7942"/>, “[…] this will allow reviewers and
working groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this
information as they see fit.”</t>
</section>
<section anchor="current-software-implementing-pep" title="Current software implementing pEp">
<t>The following software implementing the pEp protocols (to varying
degrees) already exists:</t>
<t><list style="symbols">
<t>pEp for Outlook as add-on for Microsoft Outlook, release <xref target="SRC.pepforoutlook"/></t>
<t>pEp for Android (based on a fork of the K9 MUA), release <xref target="SRC.pepforandroid"/></t>
<t>Enigmail/pEp as add-on for Mozilla Thunderbird, release <xref target="SRC.enigmailpep"/></t>
<t>pEp for iOS (implemented in a new MUA), beta <xref target="SRC.pepforios"/></t>
</list></t>
<t>pEp for Android, iOS and Outlook are provided by pEp Security, a commercial
entity specializing in end-user software implementing pEp while Enigmail/pEp
is pursued as community project, supported by the pEp Foundation.</t>
<t>All software is available as Free Software and published also in source form.</t>
</section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>Special thanks go to Krista Bennet and Volker Birk for the reference
implementation on pEp and the ideas leading to this draft.</t>
<t>This work was initially created by pEp Foundation, and will be reviewed and
extended with funding by the Internet Society’s Beyond the Net Programme on
standardizing pEp. <xref target="ISOC.bnet"/></t>
</section>
</middle>
<back>
<references title='Normative References'>
<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="RFC4949" target='https://www.rfc-editor.org/info/rfc4949'>
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials='R.' surname='Shirey' fullname='R. Shirey'><organization /></author>
<date year='2007' month='August' />
<abstract><t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='FYI' value='36'/>
<seriesInfo name='RFC' value='4949'/>
<seriesInfo name='DOI' value='10.17487/RFC4949'/>
</reference>
<reference anchor="RFC5322" target='https://www.rfc-editor.org/info/rfc5322'>
<front>
<title>Internet Message Format</title>
<author initials='P.' surname='Resnick' fullname='P. Resnick' role='editor'><organization /></author>
<date year='2008' month='October' />
<abstract><t>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of &quot;electronic mail&quot; messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, &quot;Standard for the Format of ARPA Internet Text Messages&quot;, updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5322'/>
<seriesInfo name='DOI' value='10.17487/RFC5322'/>
</reference>
<reference anchor="RFC7435" target='https://www.rfc-editor.org/info/rfc7435'>
<front>
<title>Opportunistic Security: Some Protection Most of the Time</title>
<author initials='V.' surname='Dukhovni' fullname='V. Dukhovni'><organization /></author>
<date year='2014' month='December' />
<abstract><t>This document defines the concept &quot;Opportunistic Security&quot; in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.</t></abstract>
</front>
<seriesInfo name='RFC' value='7435'/>
<seriesInfo name='DOI' value='10.17487/RFC7435'/>
</reference>
<reference anchor="I-D.birk-pep">
<front>
<title>pretty Easy privacy (pEp): Privacy by Default</title>
<author initials='V' surname='Birk' fullname='Volker Birk'>
<organization />
</author>
<author initials='H' surname='Marques' fullname='Hernani Marques'>
<organization />
</author>
<author initials='S' surname='Shelburn' fullname='Shelburn'>
<organization />
</author>
<date month='June' day='26' year='2018' />
<abstract><t>Building on already available security formats and message transports (like PGP/MIME for email), and with the intention to stay interoperable to systems widespreadly deployed, pretty Easy privacy (pEp) describes protocols to automatize operations (key management, key discovery, private key handling including peer-to-peer synchronization of private keys and other user data across devices) that have been seen to be barriers to deployment of end-to-end secure interpersonal messaging. pEp also relies on "Trustwords" (as a word mapping of of fingerprints) to verify communication peers and proposes a trust rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. In this document, the general design choices and principles of pEp are outlined.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-birk-pep-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-birk-pep-02.txt' />
</reference>
<reference anchor="I-D.marques-pep-handshake">
<front>
<title>pretty Easy privacy (pEp): Contact and Channel Authentication through Handshake</title>
<author initials='H' surname='Marques' fullname='Hernani Marques'>
<organization />
</author>
<author initials='B' surname='Hoeneisen' fullname='Bernie Hoeneisen'>
<organization />
</author>
<date month='June' day='29' year='2018' />
<abstract><t>In interpersonal messaging end-to-end encryption means for public key distribution and verification of its authenticity are needed; the latter to prevent man-in-the-middle (MITM) attacks. This document proposes a new method to easily verify a public key is authentic by a Handshake process that allows users to easily verify their communication channel. The new method is targeted to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp).</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-marques-pep-handshake-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-marques-pep-handshake-00.txt' />
</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="RFC5321" target='https://www.rfc-editor.org/info/rfc5321'>
<front>
<title>Simple Mail Transfer Protocol</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
<date year='2008' month='October' />
<abstract><t>This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a &quot;mail submission&quot; protocol for &quot;split-UA&quot; (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5321'/>
<seriesInfo name='DOI' value='10.17487/RFC5321'/>
</reference>
<reference anchor="RFC7942" target='https://www.rfc-editor.org/info/rfc7942'>
<front>
<title>Improving Awareness of Running Code: The Implementation Status Section</title>
<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></author>
<author initials='A.' surname='Farrel' fullname='A. Farrel'><organization /></author>
<date year='2016' month='July' />
<abstract><t>This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.</t><t>This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='205'/>
<seriesInfo name='RFC' value='7942'/>
<seriesInfo name='DOI' value='10.17487/RFC7942'/>
</reference>
<reference anchor="I-D.birk-pep-trustwords">
<front>
<title>IANA Registration of Trustword Lists: Guide, Template and IANA Considerations</title>
<author initials='V' surname='Birk' fullname='Volker Birk'>
<organization />
</author>
<author initials='H' surname='Marques' fullname='Hernani Marques'>
<organization />
</author>
<author initials='B' surname='Hoeneisen' fullname='Bernie Hoeneisen'>
<organization />
</author>
<date month='June' day='26' year='2018' />
<abstract><t>This document specifies the IANA Registration Guidelines for Trustwords, describes corresponding registration procedures, and provides a guideline for creating Trustword list specifications. Trustwords are common words in a natural language (e.g., English) to which the hexadecimal strings are mapped to. This makes verification processes (e.g., comparison of fingerprints), more practical and less prone to misunderstandings.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-birk-pep-trustwords-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-birk-pep-trustwords-02.txt' />
</reference>
<reference anchor="I-D.marques-pep-rating">
<front>
<title>pretty Easy privacy (pEp): Mapping of Privacy Rating</title>
<author initials='H' surname='Marques' fullname='Hernani Marques'>
<organization />
</author>
<author initials='B' surname='Hoeneisen' fullname='Bernie Hoeneisen'>
<organization />
</author>
<date month='July' day='2' year='2018' />
<abstract><t>In many Opportunistic Security scenarios end-to-end encryption is automatized for Internet users. In addition, it is often required to provide the users with easy means to carry out authentication. Depending on several factors, each communication channel to different peers may have a different Privacy Status, e.g., unencrypted, encrypted and encrypted as well as authenticated. Even each message from/to a single peer may have a different Privacy Status. To display the actual Privacy Status to the user, this document defines a Privacy Rating scheme and its mapping to a traffic-light semantics. A Privacy Status is defined on a per-message basis as well as on a per-identity basis. The traffic-light semantics (as color rating) allows for a clear and easily understandable presentation to the user in order to optimize the User Experience (UX). This rating system is most beneficial to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp).</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-marques-pep-rating-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-marques-pep-rating-00.txt' />
</reference>
<reference anchor="SRC.pepforandroid" target="https://pep-security.lu/gitlab/android/pep">
<front>
<title>Source code for pEp for Android</title>
<author >
<organization></organization>
</author>
<date year="2018" month="July"/>
</front>
</reference>
<reference anchor="SRC.pepforios" target="https://pep-security.ch/dev/repos/pEp_for_iOS/">
<front>
<title>Source code for pEp for iOS</title>
<author >
<organization></organization>
</author>
<date year="2018" month="July"/>
</front>
</reference>
<reference anchor="SRC.pepforoutlook" target="https://pep-security.lu/dev/repos/pEp_for_Outlook/">
<front>
<title>Source code for pEp for Outlook</title>
<author >
<organization></organization>
</author>
<date year="2018" month="July"/>
</front>
</reference>
<reference anchor="SRC.enigmailpep" target="https://enigmail.net/index.php/en/download/source-code">
<front>
<title>Source code for Enigmail/pEp</title>
<author >
<organization></organization>
</author>
<date year="2018" month="July"/>
</front>
</reference>
<reference anchor="ISOC.bnet" target="https://www.internetsociety.org/blog/2017/06/12-innovative-projects-selected-for-beyond-the-net-funding/">
<front>
<title>Beyond the Net. 12 Innovative Projects Selected for Beyond the Net Funding. Implementing Privacy via Mass Encryption: Standardizing pretty Easy privacy’s protocols</title>
<author initials="I." surname="Simao" fullname="Ilda Simao">
<organization></organization>
</author>
<date year="2017" month="June"/>
</front>
</reference>
</references>
<section anchor="document-changelog" title="Document Changelog">
<t>[[ RFC Editor: This section is to be removed before publication ]]</t>
<t><list style="symbols">
<t>draft-marques-pep-email-02:
<list style="symbols">
<t>Add illustrations</t>
<t>Minor fixes</t>
<t>Add longer list of Open Issues (mainly by Bernie Hoeneisen)</t>
</list></t>
<t>draft-marques-pep-email-01:
<list style="symbols">
<t>Remove an artefact, fix typos and minor editorial changes;
no changes in content</t>
</list></t>
<t>draft-marques-pep-email-00:
<list style="symbols">
<t>Initial version</t>
</list></t>
</list></t>
</section>
<section anchor="open-issues" title="Open Issues">
<t>[[ RFC Editor: This section should be empty and is to be removed
before publication ]]</t>
<t><list style="symbols">
<t>Ship better example of pEp Message Format 2</t>
<t>Elaborate on omitting headers and better explain pEp Message Format 2</t>
<t>Add notes on EFAIL</t>
<t>Describe KeyImport to induce the import from secret keys from other devices</t>
<t>Describe / Reference KeySync (and other sync, through IMAP)</t>
<t>Add keypair revocation strategy</t>
<t>Better describe required MIME fields and parameters to set for the
pEp email formats</t>
<t>Create clearer relations to the pEp rating draft (draft-marques-pep-rating),
as this plays an important role in how messages are rendered and how they
need to be presented (after rating) for a user to have awareness about his
privacy status in any given situation.</t>
<t>Make document more coherent: check with pEp’s general draft pieces to fill on
both sides and how to reference them vice-versa.</t>
<t>Add existence of internally exposed X-EncStatus header field after decrypt
and for Trusted Server situations / mirrors and describe operations.</t>
<t>Add references to
https://www.ietf.org/archive/id/draft-melnikov-smime-header-signing-05.txt
and https://tools.ietf.org/html/draft-schaad-rfc5751-bis, as well as
align text with those (e.g. forwarded=no)</t>
<t>Fix wrong stuff around pEp Message Format 2, especially considering the
encryption of the whole inner message (including To, Cc, and other fields)
when dealing with pEp users.</t>
<t>Add pEp Message Format 2.1 (additonal MIME container with preview of
all headers and some of the initial body text; special case: how to treat
HTML; e.g., show a text-only snippet?)</t>
</list></t>
</section>
</back>
<!-- ##markdown-source:
H4sIAPunz1sAA+196XbiSNLofz1FjudH213s3umu6cEY29jgDahtuk8dISWg
spBUSgHGXfWd+xr39e6T3IjITG2Ayz1TM9+cOcOZ6cIol8jIyNgzVCwWDcu3
HW9cZ7NoVDwyjMiJXF5nW0HIo2jJWqZYsiB05qa1ZNtBK9ips9bUdFx25odT
MxLM9Gx2G/qRb/mu2DLM4TDk8zrb2F92N2zf8swpzGSH5igqTs3w84yLYsCD
IscGxUrNsMyIj/1wWWcisg1DRDDXR9P1Pei25MIInDr7G0xcYMIPo5CPBHxb
TuUXy59OuReJ3wzDnEUTP6wbf2asiP9hzPFEnb0psRMnfJC/SGDe+O4DD1M/
+yGgBsCG5c4824wc35MPBMzHozq7GfIQepyH5pB7bE8+tJwIgG5eFI/2KhX2
1vEiHkaTWaiewlARrqq3cKInHrqwLPmEVl5nc4KiNAQo/goIKY1yc89CWPgk
igJRL5ezDcoGrjFe4kWJdSVmjWSRFzz0TM/JPFm3zueW+ewqNy4ytcaJBKKk
Nj6/zm8u0/CI/pw5r0Pj+7NmrVo9Vl93q/sH6uve8Z7+dX+3VlNfD/d29/Fr
u3hKWEayqzP1Q5oUJwC1mJgPMInheKPclHtHR5Vk8CoRGA1f2z/SMx3v1eTv
+aElHnJAFKNwJqKFH9qivgacEGaHs4rjtdK9HvhSLD1LTsQiMxzjnm1Anc3n
5ZAHvijTjnk8KtIZFOWR4/Jy5ATl1JhleT7zUxWvr0vRY6Qm/DbPuOJL1oN+
k9D3nCcCJOYaW3KU1CnFT1F/2Xg21x/kNT3zBJ/tnToj9ADQBH1qlepRsXKg
QPM8YHtm6C4lu8Jfe/fNEiDE8kP+crxn8NWErsC5ZqHF4bjYnFgpMC84aR78
5EwDlyMLk9jyR3Q+t7k3djzZ1rTNAHZQ7KwCfmjEEALVQuPQd+y6sQHMouAW
nLZoWXJn5TFAZw7Lqg8+NlJA91LwwsgEE/7bkM2N5wFxfPECIKxJikhhgo/Q
86Nz0yu/BBBo9w0g/Fnk+v7Dy7CxCsiN7P4iYFTbjQBxzxkjH0D+sxYc3aAE
xxTOq80fS8EkgJ/Ltr/wXN+0y5KCijj3cyC11Ei4jrXwtHs3zdIQ5lkPyWKx
KGmGIXzL4YAfkBrloeuPyzDKYblyUK7Wio7n+XPiksUg9D9xKxKAUBf+5XYR
ACkO+dL37GI04UXkPSM4IMDUMujcOqE2DNqwax6VWLXG2vG4yDhoXNZT49IC
s33YmRy3xNr6HMFf0FWypbljwqkXAtBihcsATxigDBUMM7SdJ2y6hpv9v//z
fwV8j5WdNNtK8Zu2a5us50xN30jYTLuU+inG/SHyGKNYLDJzCLLWtCLD6MMK
NqtPMD1Qo4MQC1o3CRJmAi8ZmgJwMQuAW5huyE17afBHR9DCVStAEI9XzEZK
h9t2SrxUYLfnt+Vuu9vaoXY2F87YgwEjH4Zz/YVBsyFECWsaupIVEWX4AQ/p
Fz8IQCGbeTi3lZqwDrvjCAb8CHjY2BiF/pSBQGE2NAyd4YyAgumm3ALJ64ip
QLYnZkPc7tQ4JYmksW+6mi8mmIAJEOJZ5KOwfkJoeGhKfDnAR0MbpAhOAmLd
kF1SKJkJWsFwyUy2cLApQstxmraifmgDTLdAs1gTh8+5gS2ZGQSuY8Xc2vK9
EfwMdGe6wEwITXorA9xpx+IEEVIs7JZrgNx3bVobrAEU5BmiGPZhBAxf4O4C
MlOLkSv/QeDEoQ+gAEQLIF+RbLYBukS8rcl2I8LSWjyrEnS1HVwTjDXH5Vig
zZmOZ2huyMYzE3ARcS5K7Oc/Acn2b05vQE+vw1kDxY+HU5SF7MSyaLQpF8IE
zIkIBNCYl0olViz+RZM3EjHQVmo52EdDiNQsGZCkv5sMQRk9DZKwuGeiVJHy
EHopwk9IlCNxMgG7FAK1pPaIEGhsPGgleSynjm273AAJC9sf+vbMIv00t0ew
14grwUTALWcEMGaOKawAmISAdZthJDcumdbInu/ff08rhF+/Qk/YIFxaPDYM
J3f499+VXvv1K4DbcF2G52YMxBLyzzMnVJwRCQy3PAMTEKkcBEYDwntgn0Dz
NMzRCI9agr2QwO1iwwGQPWuM0ahi291BQ+zk6QDZiFypQUOC6j8BaRtDBVN1
+w0Rk8JmLpc5zmYachxk6EeTQhZIJPY1BxQPORxvEDd+kWeZHyyLZhBo5JjO
eBLBpHh+SkZ2Vdecw5lC4mb8MQBDhsinwBaTJU6RAeMXubC3cBqAU4K4oQWe
+74di55tOI+Sw94E3IM/5DaiMQG7rU+faeB5lxx+jN0TyGFmPFUObPfUARGW
VRSFIhhX+EY8GPDQEVCOg7TqwlEgtomsziHWhJMAX3TgLC1zbA7ZEfAQ+g7/
JcHYAuvFQzYJhxy3yHIdIgriUCAqgKH73g8R87g8vTYwSm8JrB94PnfhGACE
HtEbW8AxjsUT8JUc6gnfcHwR+YhwU0HFJiboAXJoeAx0VEQCJwaacJmRj2KL
hn80EUkMdL/xBOHjwgKBw5G2omWAUNMJ0fwEzL1qiTWAVXAYjj14chjPp0Ug
8k78IT6JF4FDpU4UPCaVgOSdpmOB6MfzMPPUbnK7xC78BTKngpwO2HkwG8I3
FIw4AtK/kmUSt2YUAa/nKCgARoTD0tgERdUlmpSQI42hZgHoQmEZodGdGh2f
OWT+w/IYiT3kLBIyQIxm4IB0Wkbgg5Qvsf6EsAgUSma+CyqdtEvZtjUqKf61
arUCbSOsQ275U0TWAlmaP8JBCEdqMgRl7BOSAVGwt0C7yO1hN00xIdkvbTfa
IKFWGnKLg2YocArAICyugMuGfcLxBCwf0QhHIl4m7AUZK2pwNb1Qeydx2x6l
EInAL0D8SREJOwZfp6YH+i6pslJOAF9s97s7co8eREGSAKAatwgsN1whrelC
OxbW4Ct2Onz9WpA4noLcQJTAUE4IJmMRKQHOVj/2FuTERsqP8PWrQRasLRWS
cKo2M/RB/QDmMVKiCQjMmgBKR3D64VjhdMIvyCmJDkmVAWahNjvF07diapZi
GDRibIvuO5uU5M00gYfaAc1le/CuuHAE3yFMDYG/ge5pwhoLjJfGJcKD5D4m
G4ece5LyFDBIlLCm9E/JhqPEJz6EY8T7vA37RtACmRG9ocD/H/gYLP4U8cNe
9qG2qb5fWAP+/7LPF3bCvnynedmLZ6W2xqvihs+rlcabmxpfiEcVQTdAdY4T
dwlMoNVVYDY3NajxtoOHln5e8mhnw5I2N/1OK/r+GF2dfjMAiFGtL4BVGs2k
InBSXwvL2raNusYo+3GQyJsfN65oY9vvtKLVuV72+bLSs0HcO5EZyLNBrZKC
DT2NG3tq2bnDymB6oLpEIlUaugUGFuimnunP9U2fta6b9+9v+63TZ6HdSGCr
n788P+dznz/W8/vs0Gaa+2Oj0OfHVpbk/ldWlGm7rufJKtk1Vshubc802Smn
CoqeLA3lev78ctL5V3GrbM8/wqHyPemzuuv/RGgzf32j9fM9G1IdBJMKFajR
DBmIVNG4UtA29Uypaz5o/GgwmC4aW9KtiRqVB6bZmp7bqASxYOJ7nLmOx3de
Bi3QEHvZ//4h7vPvJ/GAuAjZMWk9I/HWtP1fl3hKFZVeJnSljMCQRZU27dYC
AyeceR4p4xQ+0q4vj83RiAW0pEx1Q/ijCI2uApNmWtZtUBSESHIkXfvonb72
sw4jpO+paefsQXJgOlMuvQ4Lf+bahnI+ZT0jwC2lyUDuqCEHC94htwMbcZgZ
/Vs8ip0yBlj5c3Q/sAYa3XBYtFuieIoROIBkqb2IaVMEx+7RvOSzMvqh6YkR
dNfBRrbd6/Zvd2LXWRXsUlPEPm7pCvHQP4RxImnsKy9xbDuQBbcAAKY8Mm0z
MrXRMpJ+UJdAi+LQhIG5CDNP+4YDjvhAw5y8x9rfrMUKqF9mIGYuNS5JF28W
AuUmZbXYj2HD7IpCNBWAjYosSXsAwdDXzo0SejP7PJwK6SZB/Vlypa3uoNff
Ksh/Uc3B7/etu0H7vnWK33sXjU4n/iJbGPDHzaCjnuO3pGfzptttXZ/Kzt3G
e/gHmefWzW2/fXPd6GxJ/zcAF7tSiY36iE2KKaCLUNJ6slboQ9uHIX8i2B8T
e7rOlH+ZrNsFGKKJG4eYKNh9AeAfHYAhhYEkVyUjity4GFhCYx+AAAp0Rss0
396GTrBXIyCWIVj4dTYCEkEoAVixI90pyjiPQVrnE0nZ+Ah+MkMdtVsYwQzR
ZYk/oVcn5CIdCK4eFIdOxLzZdIiktF2R1u3B/v7uPvnwPTxRpstcOBgzpBga
u8TeIj6kcZ/yQRQUSQLqYRQx8RdoXk+Hjpf1McDM6HlNuZDwLMx9dy79fNwk
3x43Yp+FQAp+zjWh147u6DMnhC8DGGO7f3M22KkrRqUSNmTr7orLRfpalOcl
1QdTP7DPn3PRgzh4gN7pbOwIGv+ZNbS3DRdIlqmyVcnvf4ZtgS6WOshiUaYL
oBMdk2xiKvaQdpLmvOfkPN8pGCaznRFF+6N4KnWAgPpnGB4ZoqtyZM7ciLxR
yFw4nRBp9gpyiQqf/IfGfa9R3KscH+jBpFTUTuaU5zvtb04m1Ba5bWT9jTLq
Z02yC075LSPFQ1zujQGjxDuGuC+GCxQRMYSrVtk7goMKa8DhgFvG7iRa0w/k
PYWGMSJoc1w8w+Qsxv4MaF4UmMcXtHZDTxQDDhP8+rdf/0bu4zrrTVAYoR+a
pNXYRxKVbV3MrGG//vbrb7TjqLufpkKQhnES472QoXaa0nSB9wu5RKnXk/jw
lrEvSTNq4rSt1ZADmwCLBnIYOdy1RT6ASj55wJWHRJQLcxAAAZipOlwywkNT
Z1o+SHlkqICunAb4EnXjDglSgNufOhFyVdzZ2HWHvBI3lBkgVIUDlFsiICw8
1XnI0zHdfLAIj5QkK2OI6uqQMI6nwrJ4IGUqQaLjllJ0a8dzeh5BNrnc6Zlk
LhitcaxoTdRZHWUKIEoqS+1IVgbTxmD7rEQVaVbQV1GzfBMVK2XbeZkUpUMO
O8RN5VriCKoegs42ToUGJXlaE6Mw2RAZEzHifUkIcVvsxIG9kFtOgPEX/JHC
/SUi6pQfh8kgSsQfo3g1kvklsQBNyskZTUaOzyhwnXSXOcCHmC9IfhePjduF
Wx/HOzBEk4AAeKNwtG6Oeh6ejmqBoDK2miCGoWuxvwxAnk/hFDoYOC1PnUdu
bxGWcOWas61ZBcxoNHrNdht2AWNHOrJcoAwNUEAAXGhfMoW1VZJM3QSwG2la
lmwD7LuR47pAoQsf/vAo/CtkfKgdacUP+JxDYSWl9JEyTMQKGwxDySAmoAiF
hAwuIHnhjOjENDEqh6xSLUlLjh0VN5BBC+iAJoWMdSDVkMSREUiQbzLMm+CC
jpSOOGDH9WFQIoQE1J/WIIKCEGSsCh/WaGFIMZViIcVECgicHazjCaFBhUAk
sDiKM4UdcIBfQ6cEwE0pIyrVY5WCRUp0xYQWL2bQPyseoWEQolVhpCkK7Qw6
IsCaZVjQMG5d0l3A1FCGTP446wiioJ/T5KNojnKNDYAbLDHiBpiMc7CnVXUK
dnnoaiTtCp47yG1I40F6dnH30bI3tikogScO4yHYPgTQpS4QTULOpd0ldvJh
6q4/BywHFPhyMCVhTjqd68aw/6SCISoyYsAeKkYcLwGjoVzIEGocDTkL/Wmd
XfoTj536nP38yfb5X6dovXi8pAb/C7Xs+3VMpgSzfIo78TOovMu/qhaYwiZb
9WRCD6jqXBB9ED8ovpF8oM6qpQr9+iwf+MlYNZyHlG0ZLl9voQG++/767GRw
dHLQeVPb2/tweX33oVOtdd4MGrfn5wdb2SmUnVhseToh/hDUDYMaSXv++eG+
NdrnmY8JcGQo4HFes0Ck7jIRulybot7XRMsSEkLY3wkTzZHKfykHY5nO+1OS
u/Y6TdnfWpKk8Ewr0KK0w6Ceoio1A+YXr8yingnnib/eParu0p/0n06vEnV6
1eb9wL7sOyd399XGeHD2ptlvuaftVnT2tncC349Pe0tsV4ma4yAaDNybu4cP
j9dv3QeZjFoqyYhxb/DubHLXrxw3P1VN2z3zmo7sdj/Yb7XPTi4GzZO7N4PL
bm/QHfcqbz60W5fdfuW6I8GoXCWAvQT3YE9KF86fpaIhNQHFDWKJZxgrz6ok
LDyWjakqBSGXyqWjp8AaDKWvQj8xA3OxjsaS5YcgLaI4whHzTnhmc9chOwY1
tpSKux0LIxXLTXh8PSUnfkBLN+m3k9WZye4209JIqhRoZ9L6YtUBEVC0zIBE
HCYVEavUPgcdqSfmnvPCGGiJhKQ+QatUKpRSDfPIkk3wbgA0MWJJEaf1YyyI
bWnetJXR0ck3hZFugHYLLDehJAOi+S8JP8PUWlSZwfj2Cmr0CNFls8kMkwXQ
NUMr1TmN2w5p+dpnQNxeL3EntnCmvrKwyXXm27Rp+F2rULlhXN8bG3oUuY9B
wM2QPF0o1kjuoLiRqh15mXL5VLldMGw42q65zK4qhS6JJzUBpjPGa6R5lEA1
gDQD+BH93bTbMPSEu4FK65FOBFSlxqEpgpWxKMst9pi7S4nkTZsW6yxDrjcQ
pK4hdQN0kWI6BxEC7Svl8cDCEi0C/Zhz06V0fLGcDn00Y0QEcxiwATD6Vmsr
SwGvf6F7VL/c/RK8btVeHx2/blSDX14D2Lbt6Hgj6ssZQLfeFW95kBGAW3RM
bFtmLshsCOlViRyVtRX7LzL8A9NT0r4HQHJeU+gBD6YDmZu2VqpoF6byJ5Ie
kNKUkGOpryU2EConhS246xYxScqLM60AP6kjWUiSo+K0UKWzGfEyMM8r6+Cs
MsyeF0BBD5zU8frfpZX0iGOBZgK80uQu9MF82p+nn/Df76LI6Jz6U8rrPgud
AtutsMuZR/n1rHJc39+vVw7Yq0qtInWbrlxpsX1aZz9Xa7t7f3V9OL2ltdD8
U9Sj1x+vQeG4hR4fK5UK/L968LFSPa20DvYapd3dFrDKk6wO0FHexDoImeJM
XhxbpdxETlL0gkyfGLh4h2GzU7y5lFZqXgLY8+pTrDpt0Wn8o6reSeu8fY3i
g3VbvV7jvEW/0vPJXbvbWMyEd3JxfVS5eNW4K5ety85d58Z9dTC58UdXrYe7
Sz6rLLg9XUSv+g9Pt49l0RzcHVXsp848o5J8Krd6R559ejKKuvvTD52ns7va
GzP6fHJ8fmx9bo6dmzdn4uDTqN+u7nq3o44THbdv396bc+tNu2svpOr8zj4e
2vOLx/I9515DXUt5ffjW7CQLal2fri7nOYwfVCTGG62zUu10f+9sb38dza3V
Jv+4Iknof4kauV6DXLtzt4OTTrvJrlrv2UnnpnmVbOH0rn19cnZ3/7ltnbQa
zUA87U6vqk+fb+3Pp+7j4OD9QpTfPVX3Opfw6LTjXl1aD4F5OOlZx59GH/bu
MlvYGB+22w/l808HtaPJ+77dDK6bA+t4WJ33Dh67jYfHy7fvx9dvFp2zXm3s
Ow+ti6azfDqV6v9rYEiXq7u0FnT2h/cLt1iroAkDrxlGwrezkhBYtk7HVfJw
sxykOI6B8jWWa0k2fOyF2TYTgXB7epbayh2SCNrdobRTgxJWU26rWLZRXJGE
gZYFKdv831UobNIF/iso/iso/lMExW4DMV6tNM8OgPE0qvvVbwoK34p4VMSL
5eZUCwt9iAJ7VAJB8k+RGCtzvHwfy0N/8qY8PT98OGzcNxrL5SthBx/efziZ
DC7KQWV8+WrRdlvn/f55LfzUCToz5/EknO43Z592M/voN96Fd5eX49PK2e7A
G9f2rh7goM3M2rhnHltL/n4+eBc1atPhu/7h++X14b39GHbPrkf2m7PP7z60
LBokePe5/alTm12dDJefgt7e3sjaPZ/efLh2JrvD9sHnI89Ve9ude+Z/xfx/
vpj/tqOptsbRVJMcV4XTNnuWvrtjKetGyjqRZNAzDyi2N61oBkpGfCksSZOR
vnFQJ8CaFI7NjUTCJbpE4imhyOi6EckiJfXCZOoqGCol2o8CoudCBiVxZclF
AnX3xC6otJWkK4+skgzhRJMZBYwpkSOExobyhzieB8a2GkwjHWDJaUY5xYhC
AdzIn8ukQSaEtiXjuDgdYCg93QxmxzwZM05nUGHXOIivI8XS92RgtiMXQAuP
OLqKD8NUIfoLpech580s5MNScXiDTrlIAo+AJ8+PpK+Ge9phRDSJRUhkxIxi
KKQfSFTp2yLUA/2mxiZRk8OJVG6RybCtqRjrSGDsKKljMIguH2En0HvLcFJo
a/DOHerI6DgzDBWFXUPNjG6keEiRocxgmgIjHOksMPLqUjDIRF8mJbHQndOc
x2X7hvYMm7eJWLraO2g01p2VhJa09v68T9OQun7G0ZIOfG0H+djYCt1i2pPO
g6V7sEk8/Hk6RgrQEVm9CQU4GpY7I7+uTkRIx9hojFzQMot3UxhrAnQ4u4Rd
Zu949s5/DYdvGA4r/q1Vh+GzBka80z+xZ62M2kHV3K3s2dWjg+PaweHu/mHF
Pq7ujg55bW94ZA231vbXhRheb21khLHS8K0ZXqD1xIPKMRNkfZ8p0rzqH9Ok
HA897mktSp+tb6u8Suc97zaeTq9m+13HWTafGnfz45Y9Ppq5j+PH5d3I+XD/
eBP0J52K2T17uDq8/HBx2Lgcje3HmddpXD5kVCez9unUfrp+9KN29OHhKHr7
tjYp37fsq+i+u3w3PtjdPV2edYai/fjKana97n31+rQ5aT7Nl0+DT42FDGK+
483zd9773c5JVcbhXgt73HqZ3fKtfYkVqP4qX6PrpzKdGBlsfKFde8nhxJO/
ZIrXx6V/wljloSoeZnNFQGm+890t9uqhvWsdHQ53jyqVvWPzqFa1Dg/2Dip7
pjk6rh3WYiL4VsPvazk/G/9+AflGj5GCPMke0MGhRKCoMJFseMEB/wUZ4frT
P7DqdebPv9KOOQc7ZrpoHVZOThvN5X15ebd3dNcz7xoflvPlYBwcjsp7b989
Ou+qN73jebM8mPGFfd7xxdzdPX+VtWMqV3cHF6dgp8w6Tx4fH1wLvhe8q0yu
354PO9dNf/b+yu7szkeDC//hc1Du9p8el7d37o1pn16Ep28kXo/vm3sP3fCk
fHN9zveX3qvZ3tOncPz5ePy2ObQv93ZHXd8Z7LqjbvtquS8+1K5vnybHrjy4
wf7wwwuNIXUu2xEDYSxIISP9zzLDUAYiV3Zeq9Dr4pmGmAWy6ggVhghSl44p
W0leA8A79KbF4zyfrTiOKVUaI6dD451BCjKmTIrY2KBsYIp/5lUdomcnya5M
Epx2EBCMqOlg6hodh/IX7+l3ZD9tOGZT/NLVVgkqSeoPdk8XoskCjMOCumSD
TvRnMLJnA25DmbCmzZsS62HVEYw9YkRYZ/ZF5gPGSZGrhTEUusxIWiEV8Ybk
qsokxWTqSuu+uW/DaWh0jC8x5Ko6zRfWCkNQtPGuD0fS+aLWDl/U/Z8mXoDJ
fOiCmjZq1U9s4ClFVP/wHnBFX05b6i7ex5NB/+Pgutc+v6aLeV+YsXJ3B6ZV
N0bV9ePUQNc3H4GKP57d3H+kMe7TAK2Mc2LK3A55Awa7+3oG6NzoD+5bH09v
Wr2PsEcfu41+84LGSQr4gMRYu7B4nM0Le9G64nH+xeuqfWtd3ZvT9lm72cCL
JB9PW/1WU12k/IPr+mPj/F3rSrLpcnfFVq6Ovdr4JNUmdUDU3JuPR+aTPiu4
OnW89Cgri930JNXmu60oc1TX7Ls6YAjLBope2a81u54ahT6rRL1mlJU9Z3LX
n93z74WX5ERswIuG5Vm8EJd4Di/JKP95eNlwxHFFtT+Al82j/PvgRSpMmM6O
egXdf0sXt1FZYDNPFzxQSNNmjUnL9tXtGyxBlVpJQVWb0zdPdB0YlQEPypa/
lLqVylZyhJjR1Q5DXY5Cc8rTCV4z5FBU0pkS4qZ49zmUd1OfqRejrvhIDx2F
Db2kOhfVHJNO2OzoJX3XJ30ZB6tGWFZyy0EYuTSpU3W5A++OwiBTtvRn8npi
uFRZhwLvvv2J6Twp1nDHfgi4m6qLYuuqjZEPTTnKchDE1qZh6oFYt/FeXweD
xd8nbbWLFg1Dsj3I60aOWswSdx2B2hfebYxvcFHWIDyMb/is3FhSNxv6PmmQ
zQxw25pMskDv5NCGZdEcoe6qwUki3VrfdLPIqO775WbzF0IalrDK4mDm5UpR
rWu00qQdAWmmLpyqNH6ZJgmoHDteSjGPLyRQOV9EnDCEOU/8lvjwBxUSADve
lvfcqK6am7oYY6gbXNtbfb+Od1ybFv0D0Na3djIef3XloAe2ZLQev1QOM0+S
a1vqrRc0GPVDoLN9MxPm0IerXPhsHPqzACbJPc0On2lL0R95UZN+oFJo2d6L
iQ/8Q6KJU10DF5kO3d1QZd5gjB63sFrrc4NQOUe1z3qs/O0ovUjKEfa4ThdB
9kWmIlJaDqFpelD12vLU8NzNErm30oVuhJxSc/NQ4GJiKyiVcYu/04ole1jz
oED3rsYz1wxz+ZLJmvJ7Kck0DQOYcg5YW2iKxqCIGBaRQn0CSPrXwtoRUnIk
5HrOb3NjKsHoYGAnQsN5E2fumfM0H3rxTU5o9xvFoWQ6uIksRmVK6xoRwyXw
chnERP8TYA7vrMWrwZVgHEcH8pDiUzEK9PvJ6+5ID8QkYmLAfPYfRDqpOWOj
d9NTsNwUqSKANEmBJbfn46mMVVh8yaHUzUKskqDL6vKRS2WR02uXOr8Rkzje
UJqhS0Td+IyvIMbQaVM+qRhM0csp51EyDvBG/ohrljUnKRJIidExXuVhWrky
m0OgGiuDtRtyrWa2R5VGV8iL+RONlQmLqmB1ncouTH0MVXp2kVYe14otKHqn
AhMq8TwuV1og4k7F7Qx8jwGVB1EXBdVfMPDcCX1PBqWoQEtB1hcem7rEvZDJ
91j6wqdrBvjV5WNMAjeGjkS8PO7UvJD1W6l6nvLOb1zKc0tVK4GjjivYMmQh
qxJ7m0MqFs90LLoK5hESt6Fl0fF2Chnas/wAr4SpGwVGjPeY5icYLFylOiEj
vz7dOJAR6cziS7J6SZyET2n+ejdkxY3QmuCZkVVzFJfSSgZyEqpTYFElB7yC
gBd6UUEFo5WHjumSFyy+zt9UeyaxlroKHrOYdgax+mig3ramtq/g9BdSHRU/
kFePyYAGVMlk9/xOSRwaOjClSjcr7DhJdWAVAZbhSKqegh5AX6h6I7IiRrbg
iSyc4QhV5Nv34qq4mHm5UhoD3zuB2jJKO/k0VkPzQKsKHPGCMRVP3+9A3R00
RSEhbbf6Z/rqIl4DpdQSVWpDlkWBP8bADCk+rs4/DAHwiBJbuWOJQ7pOvGjc
3ZTYyYJpkDYZu4HxIcVw/VBQI02ACGIpXY+ajDk+gsMXGVicYYiZArAPspCn
KvCRuwfEVL0NvLbDQ13axhTkQKZikjAbIYNOAFYN8LFUTZzHSCBqHJpC7t0U
y1zAE/Sf4okEPiLNpSFdoAaiMF1fYkLfjlolsFAV5FQ1c2DSe5WxQdqSPXeU
fztBs0y2yI80NVVxeLxSs3KRSpIPKLK//q1UKv36m6QQ0upkmZyQzx2+0IWX
kXtid6kj0tEWaAQye5bwUlNbXTpPWJlCspQvHJshSPSRQ3nI6bpG2oOMFX+I
86BfnCMzRFEPjeemO6OQEkqk0EkOOFUUBzaClVpSc1ERI9ryVDGluKq/QcrL
lNBLV7xh4aCiKpUiRaCri5YVCuDopmlJOvERdFT2otIWMZzmLKS6H7ooUwKL
qrCcr2C8vqF2ucfQs22kapMMVMPmWCoVhZCqCUQbLnX43BsqEEzTtovypQCY
2xD6OKV+XoAdl+f3999X3qTx9WtqQPUiELadYlQjlK5KwFwdMyp/snZA9dIR
GjD9woo8eP4TkKIJ5420yaET2vnxUm/WyIDn3PTYdq44vEk1RSRUoKWaGZBA
YcAqMrnlFWggKuKtERhyLaSJP1AVDCWb6Hzj+6hCDKUYqvKJkJEV+bYJ0vO0
prKJKPAkAFfIvMoDC3HNQjGTKUaqykVEFahkQIyiXmGSNpZ7zZMqHJ/Mmbqd
iSOeoTOhp5/SSwxQWROUUINyHavry3eNINGTTG5YKB9BLxhzeS/e0FEkLOby
oFX4qxDI0WQn3MNy4zh06h0/qQIXynNg5N+II3MFdTkIQDyACzSgORnxLJJC
pVQlNWTkALODr2XAWCKcjCjZsQQvBZVoBLgZcs3vKIPJoOw3W6ux6gUmsQTS
5dN78iUpoIjl3kxyi0LSnKLU9+RLzZJ3jrQCqpekX8WClFcsFhlyMETsqb5i
0aSSZyAvlJ4DPJu1bAfkkDLEUtJcesSUqQpfR8jgpMYtESn1ox+feRUb1jL/
kTVsOC6uO8N6+VLJwl+7jodF3JxHLuJWeAEV9hGlO557zAJjbekO3IYh0YoF
dJ0AohzOLnxg/CC3vJ1ngahKIO5pHVQ7EYh6ZCKJw+RYuEC9BmJKAHHCBkUu
ZXk4mTbh+XG5OEfmLqL199y8FTlvW5KMTqmVdaXiZX1rGwSZsMpRql4Gkt8a
mdbxzP70Jk6gzejUPUuk21zEtIb8E46wTyWW8axgHqfMWlTqgmcnQ8ng84Zx
cD9Rm6BXRrTOGu0O/Bj7Rq/4sq0qfyArAB06lq34I/mmAAkhj2QWMP0gVRIb
zpRFKcPxaGXYXu0nhJHxjWEsKYjB8M1jaL3JAvTtbuN2RwGoy0bBOfUV1ohK
+XgJLU7kQrWanLwdQ2Y8J1WYAhMOJtf1CjFBUnEh2JuV0DYM3CTuIT1c+KoY
7up3MPgxq1V+cqIvtr1KZvL5DpY4J10BGbqL1jLVSkEs4uUssLPIdToB5Svj
h5Hxd5VbiU9R24Cx9MsXtA+ShN22SeXd1ZTqUr4uI0PKEdXl99DiAuoBM2xC
Je20z18ZQOTIX7IxGG+AZyeaKUmC5dkeeHIRjFQpy59QjbM6HDxuPcTXloEx
ah+OxA2YoZYsBYUVdxi9BZDqzaH6KJL1+amXpMFipwzJqIjn0iwpciBFR+uH
8q1VxO2B1CkB5B1mJqlwaCYnVuJHZWph0qF6Kw3LGt3JogXQ7NTB+KvQb02S
NJa82UYDFUMtZLm+zJu1eDSi12kpm7js2OrNe1Pues6DPy+KKai2RQkt5dPC
FhYr+/QaPgmnHjDyQRNMhpxEU1cNJoD3mXYxHFn7h/vV4tARhVS2CQ7jotpO
vlrlo8ECm7L8bJzY/trzd8gN/MgWoY/KaTQbgdkSovBcy0YKjCttRyYJk0Gg
FFiD5eIkdKN8Iuk9nY23nSQG9/0Ca1qFTDI5HuId3DKVbAdLgZbx7XL1NhO5
FetgLFXheOBtRrrMSJxBpzOrgFggtQD51goMBKSZqfClGS+tBCkrqFQDIvMn
rexRXK6u6RiTPYnKLvrdzk/yTQeUFI6vJYFuRVkyyHOCgEe/7Bj/HzkjFtCw
dQAA
-->
</rfc>