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.
 
 
 

1166 lines
55 KiB

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>pretty Easy privacy (pEp): Email Formats and Protocols</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
<link href="#rfc.section.2" rel="Chapter" title="2 Terms">
<link href="#rfc.section.3" rel="Chapter" title="3 Opportunistic Security with pEp for email">
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Automatic keypair generation">
<link href="#rfc.section.3.2" rel="Chapter" title="3.2 Key Distribution">
<link href="#rfc.section.4" rel="Chapter" title="4 Encryption of email header fields and interoperability">
<link href="#rfc.section.5" rel="Chapter" title="5 pEp message formats for email">
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Unencrypted plain text message with public key attached">
<link href="#rfc.section.5.1.1" rel="Chapter" title="5.1.1 Example">
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 pEp email format version 1">
<link href="#rfc.section.5.2.1" rel="Chapter" title="5.2.1 Example 1">
<link href="#rfc.section.5.2.2" rel="Chapter" title="5.2.2 Example 2">
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 pEp email format version 2">
<link href="#rfc.section.5.3.1" rel="Chapter" title="5.3.1 Example (Outer and Inner Message)">
<link href="#rfc.section.6" rel="Chapter" title="6 Rendering Incoming Messages and Message Rating">
<link href="#rfc.section.7" rel="Chapter" title="7 Encryption to Bcc recipients">
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 Algorithm">
<link href="#rfc.section.7.1.1" rel="Chapter" title="7.1.1 Split To and Cc recipients from Bcc recipients">
<link href="#rfc.section.7.1.2" rel="Chapter" title="7.1.2 Split Bcc recipients in two groups">
<link href="#rfc.section.7.1.3" rel="Chapter" title="7.1.3 Send one email with only To/Cc recipients">
<link href="#rfc.section.7.1.4" rel="Chapter" title="7.1.4 Send one Bcc email for the first Bcc group">
<link href="#rfc.section.7.1.5" rel="Chapter" title="7.1.5 Send individual Bcc emails for the second group">
<link href="#rfc.section.8" rel="Chapter" title="8 Saving messages">
<link href="#rfc.section.9" rel="Chapter" title="9 Security Considerations">
<link href="#rfc.section.10" rel="Chapter" title="10 Implementation Status">
<link href="#rfc.section.10.1" rel="Chapter" title="10.1 Introduction">
<link href="#rfc.section.10.2" rel="Chapter" title="10.2 Current software implementing pEp">
<link href="#rfc.section.11" rel="Chapter" title="11 Acknowledgements">
<link href="#rfc.references" rel="Chapter" title="12 References">
<link href="#rfc.references.1" rel="Chapter" title="12.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="12.2 Informative References">
<link href="#rfc.appendix.A" rel="Chapter" title="A Document Changelog">
<link href="#rfc.appendix.B" rel="Chapter" title="B Open Issues">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.9.8 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Marques, H." />
<meta name="dct.identifier" content="urn:ietf:id:draft-marques-pep-email-02" />
<meta name="dct.issued" scheme="ISO8601" content="2018-10-24" />
<meta name="dct.abstract" content="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." />
<meta name="description" content="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." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">H. Marques</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">pEp Foundation</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">October 24, 2018</td>
</tr>
<tr>
<td class="left">Expires: April 27, 2019</td>
<td class="right"></td>
</tr>
</tbody>
</table>
<p class="title">pretty Easy privacy (pEp): Email Formats and Protocols<br />
<span class="filename">draft-marques-pep-email-02</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>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.</p>
<p>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.</p>
<p>This document defines basic operations of pEp&#8217;s approach towards email and two PGP/MIME formats (pEp Email Format 1 and 2) to provide certain security guarantees. </p>
<p>The proposed operations and formats are targeted to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp).</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on April 27, 2019.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a>
</li>
<li>2. <a href="#rfc.section.2">Terms</a>
</li>
<li>3. <a href="#rfc.section.3">Opportunistic Security with pEp for email</a>
</li>
<ul><li>3.1. <a href="#rfc.section.3.1">Automatic keypair generation</a>
</li>
<li>3.2. <a href="#rfc.section.3.2">Key Distribution</a>
</li>
</ul><li>4. <a href="#rfc.section.4">Encryption of email header fields and interoperability</a>
</li>
<li>5. <a href="#rfc.section.5">pEp message formats for email</a>
</li>
<ul><li>5.1. <a href="#rfc.section.5.1">Unencrypted plain text message with public key attached</a>
</li>
<ul><li>5.1.1. <a href="#rfc.section.5.1.1">Example</a>
</li>
</ul><li>5.2. <a href="#rfc.section.5.2">pEp email format version 1</a>
</li>
<ul><li>5.2.1. <a href="#rfc.section.5.2.1">Example 1</a>
</li>
<li>5.2.2. <a href="#rfc.section.5.2.2">Example 2</a>
</li>
</ul><li>5.3. <a href="#rfc.section.5.3">pEp email format version 2</a>
</li>
<ul><li>5.3.1. <a href="#rfc.section.5.3.1">Example (Outer and Inner Message)</a>
</li>
</ul></ul><li>6. <a href="#rfc.section.6">Rendering Incoming Messages and Message Rating</a>
</li>
<li>7. <a href="#rfc.section.7">Encryption to Bcc recipients</a>
</li>
<ul><li>7.1. <a href="#rfc.section.7.1">Algorithm</a>
</li>
<ul><li>7.1.1. <a href="#rfc.section.7.1.1">Split To and Cc recipients from Bcc recipients</a>
</li>
<li>7.1.2. <a href="#rfc.section.7.1.2">Split Bcc recipients in two groups</a>
</li>
<li>7.1.3. <a href="#rfc.section.7.1.3">Send one email with only To/Cc recipients</a>
</li>
<li>7.1.4. <a href="#rfc.section.7.1.4">Send one Bcc email for the first Bcc group</a>
</li>
<li>7.1.5. <a href="#rfc.section.7.1.5">Send individual Bcc emails for the second group</a>
</li>
</ul></ul><li>8. <a href="#rfc.section.8">Saving messages</a>
</li>
<li>9. <a href="#rfc.section.9">Security Considerations</a>
</li>
<li>10. <a href="#rfc.section.10">Implementation Status</a>
</li>
<ul><li>10.1. <a href="#rfc.section.10.1">Introduction</a>
</li>
<li>10.2. <a href="#rfc.section.10.2">Current software implementing pEp</a>
</li>
</ul><li>11. <a href="#rfc.section.11">Acknowledgements</a>
</li>
<li>12. <a href="#rfc.references">References</a>
</li>
<ul><li>12.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>12.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Document Changelog</a>
</li>
<li>Appendix B. <a href="#rfc.appendix.B">Open Issues</a>
</li>
<li><a href="#rfc.authors">Author's Address</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
</h1>
<p id="rfc.section.1.p.1">This document contains specific propositions to those parts of pretty Easy privacy (pEp) <a href="#I-D.birk-pep" class="xref">[I-D.birk-pep]</a> that are specific to email <a href="#RFC5322" class="xref">[RFC5322]</a>.</p>
<p id="rfc.section.1.p.2">All changes required for the pEp propositions on email to work just affect implementers of Mail User Agents (MUAs). </p>
<p id="rfc.section.1.p.3">pretty Easy privacy (pEp) for email is a proposition to both, implementers and Internet users, to make end-to-end encryption of emails straightforward. </p>
<p id="rfc.section.1.p.4">Whereas Pretty Good Privacy (PGP) and OpenPGP <a href="#RFC4880" class="xref">[RFC4880]</a> provide a basis for good encryption, we still miss implementations that also provide a sufficient level of usability for ordinary Internet users.</p>
<p id="rfc.section.1.p.5">Two users using pEp-enabled mail clients basically don&#8217;t need to do anything else than just writing emails. </p>
<p id="rfc.section.1.p.6">The following example roughly describes a typical pEp scenario:</p>
<p></p>
<ol>
<li>Alice &#8211; knowing nothing of Bob &#8211; just writes an email to Bob: this mail is sent out unencrypted. However, Alice&#8217;s public key is automatically attached.</li>
<li>Bob can just reply to Alice and &#8211; as he got her public key &#8211; is now able to encrypt a message at this point. Through a color-rating (cf. <a href="#I-D.marques-pep-rating" class="xref">[I-D.marques-pep-rating]</a> Bob becomes aware of his message now going out in a secure fashion.</li>
<li>As Alice receives Bob&#8217;s key, as of now she is also able to send secure messages to Bob.</li>
<li>If Alice and Bob want to prevent man-in-the-middle (MITM) attacks, they can engage in a Handshake <a href="#I-D.marques-pep-handshake" class="xref">[I-D.marques-pep-handshake]</a>, comparing their so-called Trustwords <a href="#I-D.birk-pep-trustwords" class="xref">[I-D.birk-pep-trustwords]</a> and confirm this process if those match. After doing so, their identity rating changes to &#8220;encrypted and authenticated&#8221; <a href="#I-D.marques-pep-rating" class="xref">[I-D.marques-pep-rating]</a>, which (UX-wise) can be signaled, e.g., using a green color rating. This color rating is also applied to messages (in- and outgoing).</li>
</ol>
<pre>
----- -----
| 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 |
+------------------------------------------&gt;|
| |
| +-----------------------+
| | Privacy Status for A: |
| | *Encrypted* |
| +-----------------------+
| |
| B sends message to A (Public Key |
| attached) / signed and ENCRYPTED |
|&lt;------------------------------------------+
| |
+-----------------------+ |
| Privacy Status for B: | |
| *Encrypted* | |
+-----------------------+ |
| |
| A and B sucessfully compare their |
| Trustwords over an alternative channel |
| (e.g. phone line) |
|&lt;-- -- -- -- -- -- -- -- -- -- -- -- -- --&gt;|
| |
+-----------------------+ +-----------------------+
| Privacy Status for B: | | Privacy Status for A: |
| *Trusted* | | *Trusted* |
+-----------------------+ +-----------------------+
| |
</pre>
<p id="rfc.section.1.p.8">This workflow is implemented as running code already in various pEp-enabled software, cf. <a href="#implementation-status" class="xref">Section 10</a>.</p>
<p id="rfc.section.1.p.9">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) <a href="#RFC5321" class="xref">[RFC5321]</a> as to allow for onion routing of email messages in a way metadata can be furtherly protected for communication peers &#8211; achievable by message encapsulation. pEp&#8217;s email message format 2 described below is already prepared for this scenario.</p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#terms" id="terms">Terms</a>
</h1>
<p id="rfc.section.2.p.1">The key words &#8220;MUST&#8221;, &#8220;MUST NOT&#8221;, &#8220;REQUIRED&#8221;, &#8220;SHALL&#8221;, &#8220;SHALL NOT&#8221;, &#8220;SHOULD&#8221;, &#8220;SHOULD NOT&#8221;, &#8220;RECOMMENDED&#8221;, &#8220;MAY&#8221;, and &#8220;OPTIONAL&#8221; in this document are to be interpreted as described in <a href="#RFC2119" class="xref">[RFC2119]</a>.</p>
<p></p>
<ul>
<li>Handshake: The process when Alice &#8211; e.g. in-person or via phone &#8211; contacts Bob to verify Trustwords (or by fallback: fingerprints) is called Handshake. <a href="#I-D.marques-pep-handshake" class="xref">[I-D.marques-pep-handshake]</a>
</li>
<li>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. <a href="#I-D.birk-pep-trustwords" class="xref">[I-D.birk-pep-trustwords]</a>
</li>
<li>Trust on First Use (TOFU): cf. <a href="#RFC7435" class="xref">[RFC7435]</a>
</li>
<li>Man-in-the-middle attack (MITM): cf. <a href="#RFC4949" class="xref">[RFC4949]</a>
</li>
</ul>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#opportunistic-security-with-pep-for-email" id="opportunistic-security-with-pep-for-email">Opportunistic Security with pEp for email</a>
</h1>
<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> <a href="#automatic-keypair-generation" id="automatic-keypair-generation">Automatic keypair generation</a>
</h1>
<p id="rfc.section.3.1.p.1">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 <a href="#RFC4880" class="xref">[RFC4880]</a> SHOULD be generated automatically for each email account. However, the key length MUST be at least RSA-2048.</p>
<p id="rfc.section.3.1.p.2">If for an identity there&#8217;s an RSA keypair with less than 2048 bits, new keys MUST be generated.</p>
<p id="rfc.section.3.1.p.3">[[ TODO: Shouldn&#8217;t this go to general I-D ]]</p>
<h1 id="rfc.section.3.2">
<a href="#rfc.section.3.2">3.2.</a> <a href="#key-distribution" id="key-distribution">Key Distribution</a>
</h1>
<p id="rfc.section.3.2.p.1">By default, public keys MUST always be attached to any outgoing message.</p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#encryption-of-email-header-fields-and-interoperability" id="encryption-of-email-header-fields-and-interoperability">Encryption of email header fields and interoperability</a>
</h1>
<p id="rfc.section.4.p.1">In pEp, implementers MUST put privacy first: email metadata (i.e., headers) MUST either be omitted or encrypted whenever possible.</p>
<p id="rfc.section.4.p.2">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.</p>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#pep-message-formats-for-email" id="pep-message-formats-for-email">pEp message formats for email</a>
</h1>
<p id="rfc.section.5.p.1">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.</p>
<h1 id="rfc.section.5.1">
<a href="#rfc.section.5.1">5.1.</a> <a href="#unencrypted-plain-text-message-with-public-key-attached" id="unencrypted-plain-text-message-with-public-key-attached">Unencrypted plain text message with public key attached</a>
</h1>
<p id="rfc.section.5.1.p.1">If for a recipient there&#8217;s no public key available, a pEp message MUST be sent out in plain text as MIME message version 1, with &#8220;Content-Type: multipart/mixed&#8221; and the OpenPGP public key attached in ASCII armored format, named &#8220;pEpkey.asc&#8221;.</p>
<p id="rfc.section.5.1.p.2">For a MUA implementer this fulfills two functions:</p>
<p></p>
<ol>
<li>It can be easily detected that the sender is a pEp user.</li>
<li>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.</li>
</ol>
<p id="rfc.section.5.1.p.4">The plain text messages SHOULD be sent out with the UTF-8 charset Content-Type set.</p>
<h1 id="rfc.section.5.1.1">
<a href="#rfc.section.5.1.1">5.1.1.</a> <a href="#example" id="example">Example</a>
</h1>
<p id="rfc.section.5.1.1.p.1">Please note that in the following examples the &#8220;pEpkey.asc&#8221; attachments encoded in base64 format are only shown in its first and last line (and otherwise shortened by three points). </p>
<pre>
From: John Doe &lt;jdoe@machine.example&gt;
To: Mary Smith &lt;mary@example.net&gt;
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--
</pre>
<h1 id="rfc.section.5.2">
<a href="#rfc.section.5.2">5.2.</a> <a href="#pep-email-format-version-1" id="pep-email-format-version-1">pEp email format version 1</a>
</h1>
<p id="rfc.section.5.2.p.1">pEp email format 1 is an encrypted and signed PGP/MIME format, which by default ensures:</p>
<p></p>
<ul>
<li>correctly signed messages</li>
<li>delivery of public keys (at least and automatically: the sender&#8217;s public key)</li>
</ul>
<p id="rfc.section.5.2.p.3">By default, when a public key for a peer is available, pEp-capable MUAs are REQUIRED to send out email messages according to <a href="#RFC5322" class="xref">[RFC5322]</a> and in PGP/MIME format <a href="#RFC3156" class="xref">[RFC3156]</a> with the informational &#8220;Subject:&#8221; header field set to &#8220;pEp&#8221;, as follows:</p>
<p></p>
<ul class="empty"><li>Subject: pEp</li></ul>
<p id="rfc.section.5.2.p.5">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 &#8220;Subject:&#8221; field as the real subject line in the respective MUAs to help users to easily grasp the real subject.</p>
<p id="rfc.section.5.2.p.6">Alternatively, the &#8220;Subject:&#8221; header field can also be set to its UTF-8 variant with &#8220;pEp&#8221; written with the equivalence symbol instead of an &#8220;E&#8221;:</p>
<p></p>
<ul class="empty"><li>Subject: =?utf-8?Q?p=E2=89=A1p?=</li></ul>
<p id="rfc.section.5.2.p.8">Additionally, a header field &#8220;X-Pep-Version: 1.0&#8221; is added to signal compatibility with pEp email format to pEp-enabled MUAs. </p>
<h1 id="rfc.section.5.2.1">
<a href="#rfc.section.5.2.1">5.2.1.</a> <a href="#example-1" id="example-1">Example 1</a>
</h1>
<p id="rfc.section.5.2.1.p.1">Example. Using the well-known example of <a href="#RFC5322" class="xref">[RFC5322]</a>, an email message sent out with pEp in message format 1 looks like this:</p>
<pre>
From: John Doe &lt;jdoe@machine.example&gt;
Sender: Michael Jones &lt;mjones@machine.example&gt;
To: Mary Smith &lt;mary@example.net&gt;
Subject: pEp
Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: &lt;1234@local.machine.example&gt;
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--
</pre>
<h1 id="rfc.section.5.2.2">
<a href="#rfc.section.5.2.2">5.2.2.</a> <a href="#example-2" id="example-2">Example 2</a>
</h1>
<p id="rfc.section.5.2.2.p.1">Using the UTF-8 variant of writing &#8220;pEp&#8221; 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:</p>
<pre>
From: John Doe &lt;jdoe@machine.example&gt;
Sender: Michael Jones &lt;mjones@machine.example&gt;
To: Mary Smith &lt;mary@example.net&gt;
Subject: =?utf-8?Q?p=E2=89=A1p?=
Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: &lt;1234@local.machine.example&gt;
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--
</pre>
<h1 id="rfc.section.5.3">
<a href="#rfc.section.5.3">5.3.</a> <a href="#pep-email-format-version-2" id="pep-email-format-version-2">pEp email format version 2</a>
</h1>
<p id="rfc.section.5.3.p.1">pEp email format 2 is a strict PGP/MIME format, which by default ensures:</p>
<p></p>
<ul>
<li>correctly signed messages</li>
<li>delivery of public keys (at least: the sender&#8217;s public key)</li>
</ul>
<p id="rfc.section.5.3.p.3">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).</p>
<p id="rfc.section.5.3.p.4">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 &#8220;Content-Type&#8221;.</p>
<p id="rfc.section.5.3.p.5">In the outer message, unnecessary email headers MUST be omitted to the fullest extent.</p>
<p id="rfc.section.5.3.p.6">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 &#8220;Content-Type&#8221; with name &#8220;msg.asc&#8221;.</p>
<h1 id="rfc.section.5.3.1">
<a href="#rfc.section.5.3.1">5.3.1.</a> <a href="#example-outer-and-inner-message" id="example-outer-and-inner-message">Example (Outer and Inner Message)</a>
</h1>
<p id="rfc.section.5.3.1.p.1">A pEp email format 2 message, with the &#8220;Subject:&#8221; header field set to &#8220;pEp&#8221; looks like the following (please note that the inner message is fully contained in the OpenPGP-signed and -encrypted file named &#8220;msg.asc&#8221;, including possible attachments and with the sender&#8217;s public key as &#8220;pEpkey.asc&#8221; attached at the very end):</p>
<pre>
From: John Doe &lt;jdoe@machine.example&gt;
Sender: Michael Jones &lt;mjones@machine.example&gt;
To: Mary Smith &lt;mary@example.net&gt;
Subject: =?utf-8?Q?p=E2=89=A1p?=
Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: &lt;1234@local.machine.example&gt;
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--
</pre>
<p id="rfc.section.5.3.1.p.2">The inner message in a simple form without further nesting might look like the following, when decrypted:</p>
<pre>
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-----
</pre>
<p id="rfc.section.5.3.1.p.3">It does not only carry the encrypted subject, which pEp implementers are supposed to map (UX-wise) such as to replace the &#8220;pEp&#8221; subject in the outer message, but also the actual message (as inline file named &#8220;msg.txt&#8221; in case of plain text) as well as the sender&#8217;s public key.</p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#rendering-incoming-messages-and-message-rating" id="rendering-incoming-messages-and-message-rating">Rendering Incoming Messages and Message Rating</a>
</h1>
<p id="rfc.section.6.p.1">pEp-enabled clients MUST NOT blindly render messages. Special care MUST be taken when rendering the pEp email formats, which provide certain guarantees:</p>
<pre>
+--------------+----------------+--------+--------------------------+
| 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 |
+--------------+----------------+--------+--------------------------+
</pre>
<p id="rfc.section.6.p.2">For cases where messages appear unsigned, signed without a key or with a bad signature, pEp&#8217;s privacy rating can be employed to signal issues to a user in an easily understandable manner, cf. <a href="#I-D.marques-pep-rating" class="xref">[I-D.marques-pep-rating]</a>.</p>
<p id="rfc.section.6.p.3">[[TODO: This needs more work to be understandable. ]]</p>
<h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#encryption-to-bcc-recipients" id="encryption-to-bcc-recipients">Encryption to Bcc recipients</a>
</h1>
<h1 id="rfc.section.7.1">
<a href="#rfc.section.7.1">7.1.</a> <a href="#algorithm" id="algorithm">Algorithm</a>
</h1>
<p id="rfc.section.7.1.p.1">For encryption of emails that contain Bcc recipients a simple algorithm MAY be used.</p>
<p id="rfc.section.7.1.p.2">Recipients MUST be partitioned into three lists, one for each of three possible outgoing messages:</p>
<p></p>
<ol>
<li>To and Cc recipients (without Bcc recipients) </li>
<li>Bcc recipients unable to encrypt</li>
<li>Bcc recipients able to encrypt</li>
</ol>
<p id="rfc.section.7.1.p.4">It&#8217;s RECOMMENDED that if the original message the user drafted is saved in the user&#8217;s sent folder, that all recipient fields (&#8220;To:&#8221;, &#8220;Cc:&#8221;, &#8220;Bcc:&#8221;) be preserved.</p>
<h1 id="rfc.section.7.1.1">
<a href="#rfc.section.7.1.1">7.1.1.</a> <a href="#split-to-and-cc-recipients-from-bcc-recipients" id="split-to-and-cc-recipients-from-bcc-recipients">Split To and Cc recipients from Bcc recipients</a>
</h1>
<p id="rfc.section.7.1.1.p.1">To and Cc recipients MUST be split from the Bcc recipients.</p>
<h1 id="rfc.section.7.1.2">
<a href="#rfc.section.7.1.2">7.1.2.</a> <a href="#split-bcc-recipients-in-two-groups" id="split-bcc-recipients-in-two-groups">Split Bcc recipients in two groups</a>
</h1>
<p id="rfc.section.7.1.2.p.1">Bcc recipients MUST be split in two groups:</p>
<p></p>
<ul>
<li>First group of Bcc recipients who will receive clear text emails.</li>
<li>Second group of Bcc recipients who are able to receive encrypted emails.</li>
</ul>
<h1 id="rfc.section.7.1.3">
<a href="#rfc.section.7.1.3">7.1.3.</a> <a href="#send-one-email-with-only-tocc-recipients" id="send-one-email-with-only-tocc-recipients">Send one email with only To/Cc recipients</a>
</h1>
<p id="rfc.section.7.1.3.p.1">The original email the user drafted SHOULD be sent out with the &#8220;Bcc:&#8221; field removed.</p>
<h1 id="rfc.section.7.1.4">
<a href="#rfc.section.7.1.4">7.1.4.</a> <a href="#send-one-bcc-email-for-the-first-bcc-group" id="send-one-bcc-email-for-the-first-bcc-group">Send one Bcc email for the first Bcc group</a>
</h1>
<p id="rfc.section.7.1.4.p.1">For the first Bcc group, a regular email message with only Bcc recipients is sent.</p>
<h1 id="rfc.section.7.1.5">
<a href="#rfc.section.7.1.5">7.1.5.</a> <a href="#send-individual-bcc-emails-for-the-second-group" id="send-individual-bcc-emails-for-the-second-group">Send individual Bcc emails for the second group</a>
</h1>
<p id="rfc.section.7.1.5.p.1">For the second group, individual Bcc email messages are sent.</p>
<p id="rfc.section.7.1.5.p.2">[[TODO: This needs more work to make it better understandable. ]]</p>
<h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#saving-messages" id="saving-messages">Saving messages</a>
</h1>
<p id="rfc.section.8.p.1">[[ TODO: Shouldn&#8217;t this go to general []</p>
<p id="rfc.section.8.p.2">In accordance to the Privacy by Default principle, messages sent or received in encrypted form SHALL be saved with the peer&#8217;s respective public key.</p>
<p id="rfc.section.8.p.3">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&#8217;s expectations.</p>
<p id="rfc.section.8.p.4">Instead, message drafts MUST always be saved with the user&#8217;s public key.</p>
<p id="rfc.section.8.p.5">Other messages sent and received MUST be saved encrypted by default: for most end-user scenarios, the servers users work with, are considered untrusted.</p>
<p id="rfc.section.8.p.6">For trusted environments (e.g., in organizations) and to conform to legally binding regulations, pEp implementations MUST provide a &#8220;Trusted Server&#8221; option. With the user&#8217;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.</p>
<h1 id="rfc.section.9">
<a href="#rfc.section.9">9.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
</h1>
<p id="rfc.section.9.p.1">[[ TODO ]]</p>
<h1 id="rfc.section.10">
<a href="#rfc.section.10">10.</a> <a href="#implementation-status" id="implementation-status">Implementation Status</a>
</h1>
<h1 id="rfc.section.10.1">
<a href="#rfc.section.10.1">10.1.</a> <a href="#introduction-1" id="introduction-1">Introduction</a>
</h1>
<p id="rfc.section.10.1.p.1">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 <a href="#RFC7942" class="xref">[RFC7942]</a>. 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.</p>
<p id="rfc.section.10.1.p.2">According to <a href="#RFC7942" class="xref">[RFC7942]</a>, &#8220;[&#8230;] 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.&#8221;</p>
<h1 id="rfc.section.10.2">
<a href="#rfc.section.10.2">10.2.</a> <a href="#current-software-implementing-pep" id="current-software-implementing-pep">Current software implementing pEp</a>
</h1>
<p id="rfc.section.10.2.p.1">The following software implementing the pEp protocols (to varying degrees) already exists:</p>
<p></p>
<ul>
<li>pEp for Outlook as add-on for Microsoft Outlook, release <a href="#SRC.pepforoutlook" class="xref">[SRC.pepforoutlook]</a>
</li>
<li>pEp for Android (based on a fork of the K9 MUA), release <a href="#SRC.pepforandroid" class="xref">[SRC.pepforandroid]</a>
</li>
<li>Enigmail/pEp as add-on for Mozilla Thunderbird, release <a href="#SRC.enigmailpep" class="xref">[SRC.enigmailpep]</a>
</li>
<li>pEp for iOS (implemented in a new MUA), beta <a href="#SRC.pepforios" class="xref">[SRC.pepforios]</a>
</li>
</ul>
<p id="rfc.section.10.2.p.3">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.</p>
<p id="rfc.section.10.2.p.4">All software is available as Free Software and published also in source form.</p>
<h1 id="rfc.section.11">
<a href="#rfc.section.11">11.</a> <a href="#acknowledgements" id="acknowledgements">Acknowledgements</a>
</h1>
<p id="rfc.section.11.p.1">Special thanks go to Krista Bennet and Volker Birk for the reference implementation on pEp and the ideas leading to this draft.</p>
<p id="rfc.section.11.p.2">This work was initially created by pEp Foundation, and will be reviewed and extended with funding by the Internet Society&#8217;s Beyond the Net Programme on standardizing pEp. <a href="#ISOC.bnet" class="xref">[ISOC.bnet]</a></p>
<h1 id="rfc.references">
<a href="#rfc.references">12.</a> References</h1>
<h1 id="rfc.references.1">
<a href="#rfc.references.1">12.1.</a> Normative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="I-D.birk-pep">[I-D.birk-pep]</b></td>
<td class="top">
<a>Birk, V.</a>, <a>Marques, H.</a> and <a>S. Shelburn</a>, "<a href="https://tools.ietf.org/html/draft-birk-pep-02">pretty Easy privacy (pEp): Privacy by Default</a>", Internet-Draft draft-birk-pep-02, June 2018.</td>
</tr>
<tr>
<td class="reference"><b id="I-D.marques-pep-handshake">[I-D.marques-pep-handshake]</b></td>
<td class="top">
<a>Marques, H.</a> and <a>B. Hoeneisen</a>, "<a href="https://tools.ietf.org/html/draft-marques-pep-handshake-00">pretty Easy privacy (pEp): Contact and Channel Authentication through Handshake</a>", Internet-Draft draft-marques-pep-handshake-00, June 2018.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
<td class="top">
<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
<tr>
<td class="reference"><b id="RFC3156">[RFC3156]</b></td>
<td class="top">
<a>Elkins, M.</a>, <a>Del Torto, D.</a>, <a>Levien, R.</a> and <a>T. Roessler</a>, "<a href="https://tools.ietf.org/html/rfc3156">MIME Security with OpenPGP</a>", RFC 3156, DOI 10.17487/RFC3156, August 2001.</td>
</tr>
<tr>
<td class="reference"><b id="RFC4949">[RFC4949]</b></td>
<td class="top">
<a>Shirey, R.</a>, "<a href="https://tools.ietf.org/html/rfc4949">Internet Security Glossary, Version 2</a>", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007.</td>
</tr>
<tr>
<td class="reference"><b id="RFC5322">[RFC5322]</b></td>
<td class="top">
<a>Resnick, P.</a>, "<a href="https://tools.ietf.org/html/rfc5322">Internet Message Format</a>", RFC 5322, DOI 10.17487/RFC5322, October 2008.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7435">[RFC7435]</b></td>
<td class="top">
<a>Dukhovni, V.</a>, "<a href="https://tools.ietf.org/html/rfc7435">Opportunistic Security: Some Protection Most of the Time</a>", RFC 7435, DOI 10.17487/RFC7435, December 2014.</td>
</tr>
</tbody></table>
<h1 id="rfc.references.2">
<a href="#rfc.references.2">12.2.</a> Informative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="I-D.birk-pep-trustwords">[I-D.birk-pep-trustwords]</b></td>
<td class="top">
<a>Birk, V.</a>, <a>Marques, H.</a> and <a>B. Hoeneisen</a>, "<a href="https://tools.ietf.org/html/draft-birk-pep-trustwords-02">IANA Registration of Trustword Lists: Guide, Template and IANA Considerations</a>", Internet-Draft draft-birk-pep-trustwords-02, June 2018.</td>
</tr>
<tr>
<td class="reference"><b id="I-D.marques-pep-rating">[I-D.marques-pep-rating]</b></td>
<td class="top">
<a>Marques, H.</a> and <a>B. Hoeneisen</a>, "<a href="https://tools.ietf.org/html/draft-marques-pep-rating-00">pretty Easy privacy (pEp): Mapping of Privacy Rating</a>", Internet-Draft draft-marques-pep-rating-00, July 2018.</td>
</tr>
<tr>
<td class="reference"><b id="ISOC.bnet">[ISOC.bnet]</b></td>
<td class="top">
<a>Simao, I.</a>, "<a href="https://www.internetsociety.org/blog/2017/06/12-innovative-projects-selected-for-beyond-the-net-funding/">Beyond the Net. 12 Innovative Projects Selected for Beyond the Net Funding. Implementing Privacy via Mass Encryption: Standardizing pretty Easy privacy&#8217;s protocols</a>", June 2017.</td>
</tr>
<tr>
<td class="reference"><b id="RFC4880">[RFC4880]</b></td>
<td class="top">
<a>Callas, J.</a>, <a>Donnerhacke, L.</a>, <a>Finney, H.</a>, <a>Shaw, D.</a> and <a>R. Thayer</a>, "<a href="https://tools.ietf.org/html/rfc4880">OpenPGP Message Format</a>", RFC 4880, DOI 10.17487/RFC4880, November 2007.</td>
</tr>
<tr>
<td class="reference"><b id="RFC5321">[RFC5321]</b></td>
<td class="top">
<a>Klensin, J.</a>, "<a href="https://tools.ietf.org/html/rfc5321">Simple Mail Transfer Protocol</a>", RFC 5321, DOI 10.17487/RFC5321, October 2008.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7942">[RFC7942]</b></td>
<td class="top">
<a>Sheffer, Y.</a> and <a>A. Farrel</a>, "<a href="https://tools.ietf.org/html/rfc7942">Improving Awareness of Running Code: The Implementation Status Section</a>", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016.</td>
</tr>
<tr>
<td class="reference"><b id="SRC.enigmailpep">[SRC.enigmailpep]</b></td>
<td class="top">"<a href="https://enigmail.net/index.php/en/download/source-code">Source code for Enigmail/pEp</a>", July 2018.</td>
</tr>
<tr>
<td class="reference"><b id="SRC.pepforandroid">[SRC.pepforandroid]</b></td>
<td class="top">"<a href="https://pep-security.lu/gitlab/android/pep">Source code for pEp for Android</a>", July 2018.</td>
</tr>
<tr>
<td class="reference"><b id="SRC.pepforios">[SRC.pepforios]</b></td>
<td class="top">"<a href="https://pep-security.ch/dev/repos/pEp_for_iOS/">Source code for pEp for iOS</a>", July 2018.</td>
</tr>
<tr>
<td class="reference"><b id="SRC.pepforoutlook">[SRC.pepforoutlook]</b></td>
<td class="top">"<a href="https://pep-security.lu/dev/repos/pEp_for_Outlook/">Source code for pEp for Outlook</a>", July 2018.</td>
</tr>
</tbody></table>
<h1 id="rfc.appendix.A">
<a href="#rfc.appendix.A">Appendix A.</a> <a href="#document-changelog" id="document-changelog">Document Changelog</a>
</h1>
<p id="rfc.section.A.p.1">[[ RFC Editor: This section is to be removed before publication ]]</p>
<p></p>
<ul>
<li>draft-marques-pep-email-02: <ul>
<li>Add illustrations</li>
<li>Minor fixes</li>
<li>Add longer list of Open Issues (mainly by Bernie Hoeneisen)</li>
</ul>
</li>
<li>draft-marques-pep-email-01: <ul><li>Remove an artefact, fix typos and minor editorial changes; no changes in content</li></ul>
</li>
<li>draft-marques-pep-email-00: <ul><li>Initial version</li></ul>
</li>
</ul>
<h1 id="rfc.appendix.B">
<a href="#rfc.appendix.B">Appendix B.</a> <a href="#open-issues" id="open-issues">Open Issues</a>
</h1>
<p id="rfc.section.B.p.1">[[ RFC Editor: This section should be empty and is to be removed before publication ]]</p>
<p></p>
<ul>
<li>Ship better example of pEp Message Format 2</li>
<li>Elaborate on omitting headers and better explain pEp Message Format 2</li>
<li>Add notes on EFAIL</li>
<li>Describe KeyImport to induce the import from secret keys from other devices</li>
<li>Describe / Reference KeySync (and other sync, through IMAP)</li>
<li>Add keypair revocation strategy</li>
<li>Better describe required MIME fields and parameters to set for the pEp email formats</li>
<li>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.</li>
<li>Make document more coherent: check with pEp&#8217;s general draft pieces to fill on both sides and how to reference them vice-versa.</li>
<li>Add existence of internally exposed X-EncStatus header field after decrypt and for Trusted Server situations / mirrors and describe operations.</li>
<li>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)</li>
<li>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.</li>
<li>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?)</li>
</ul>
<h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Hernani Marques</span>
<span class="n hidden">
<span class="family-name">Marques</span>
</span>
</span>
<span class="org vcardline">pEp Foundation</span>
<span class="adr">
<span class="vcardline">Oberer Graben 4</span>
<span class="vcardline">
<span class="locality">CH-8400 Winterthur</span>,
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline">Switzerland</span>
</span>
<span class="vcardline">EMail: <a href="mailto:hernani.marques@pep.foundation">hernani.marques@pep.foundation</a></span>
<span class="vcardline">URI: <a href="https://pep.foundation/">https://pep.foundation/</a></span>
</address>
</div>
</body>
</html>