<metaname="dct.abstract"content="The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranges from key distribution, secret key synchronization between own devices to mechanims of metadata and content protection. This is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly in scope of this document. The goal of pEp for email is to automate 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. The proposed operations and formats are targeted to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp). " />
<metaname="description"content="The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranges from key distribution, secret key synchronization between own devices to mechanims of metadata and content protection. This is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly in scope of this document. The goal of pEp for email is to automate 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. The proposed operations and formats are targeted to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp). " />
<metaname="dct.abstract"content="The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranges from key distribution, secret key synchronization between own devices to mechanisms of metadata and content protection. This is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly in scope of this document. The goal of pEp for email is to automate 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. The proposed operations and formats are targeted to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp). " />
<metaname="description"content="The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranges from key distribution, secret key synchronization between own devices to mechanisms of metadata and content protection. This is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly in scope of this document. The goal of pEp for email is to automate 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. The proposed operations and formats are targeted to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp). " />
<p>The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranges from key distribution, secret key synchronization between own devices to mechanims of metadata and content protection. This is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly in scope of this document.</p>
<p>The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranges from key distribution, secret key synchronization between own devices to mechanisms of metadata and content protection. This is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly in scope of this document.</p>
<p>The goal of pEp for email is to automate 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>The proposed operations and formats are targeted to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp).</p>
<h1id="rfc.status"><ahref="#rfc.status">Status of This Memo</a></h1>
@ -633,7 +633,7 @@
<ol>
<li>make email encryption as automatic as possible,</li>
<li>protect as much metadata as possible, and</li>
<li>provide an easy way to authenticate communicaton partners.</li>
<li>provide an easy way to authenticate communication partners.</li>
</ol>
<pid="rfc.section.1.p.9">A reference implementation of pEp for email is available for all major platforms and it has been ported to many programming languages (cf. <ahref="#implementation-status"class="xref">Section 11</a> for an overview).</p>
<h1id="rfc.section.1.1">
@ -675,7 +675,7 @@
<ul>
<li>pEp implementers MUST NOT make queries to public key servers by default. The reason for this is to make it more expensive for centralized network actors to learn a user’s social graph. This is also problematic security-wise, as centralized cryptographic key subversion at-scale is made cheaper. Instead, key distribution MUST be handled in-band while communicating with other peers.</li>
<li>No trust information MUST be attached to the communication partner’s public keys. This is metadata which MUST be held locally and seperately from the keys. Trust is established between the peers directly (peer-to-peer) and no trust information is held centrally (no support for the Web of Trust): that is, while pEp MUST be able to work with OpenPGP keys which carry trust information, this trust information MUST not be used to signal any trust level.</li>
<li>No trust information MUST be attached to the communication partner’s public keys. This is metadata which MUST be held locally and separately from the keys. Trust is established between the peers directly (peer-to-peer) and no trust information is held centrally (no support for the Web of Trust): that is, while pEp MUST be able to work with OpenPGP keys which carry trust information, this trust information MUST not be used to signal any trust level.</li>
<li>pEp-enabled MUAs MUST either engage in a signed-and-encrypted communication or in unsigned plaintext communication. While the signatures attached to plaintext messages can be verified, signed-only messages per se do not increase security as long as the corresponding public key is not authenticated. Signed-only messages do not improve privacy either.</li>
<pid="rfc.section.2.6.p.1">All relevant pEp mechanisms and state information about other peers MUST be held locally, on a peer’s end-device. There MUST NOT be any reliance on a email server or even a centralized network component to hold relevant information for peers to be able to communicatate or to authenticate themselves. Email servers (like, SMTP or IMAP) are only used as transport infrastructure for messages, but MUST not be relevant to hold actual state between peers.</p>
<pid="rfc.section.2.6.p.1">All relevant pEp mechanisms and state information about other peers MUST be held locally, on a peer’s end-device. There MUST NOT be any reliance on a email server or even a centralized network component to hold relevant information for peers to be able to communicate or to authenticate themselves. Email servers (like, SMTP or IMAP) are only used as transport infrastructure for messages, but MUST not be relevant to hold actual state between peers.</p>
<pid="rfc.section.2.8.p.1">In pEp for email, a user is a person or group which can have one or more identities, each represented by email addresses. Every identity has an own key attached to it. An email address can also be an alias for an already existing identity, in which case the same key is attached to it.</p>
<pid="rfc.section.2.8.p.2">All information about communication partners, like identities, keys and aliases MUST be held on a user’s end-device as state information. This SHOULD be done using a structured format, to faciliate the synchronization of state information across various devices, taking into account multi-device scenarios, which are common today.</p>
<pid="rfc.section.2.8.p.2">All information about communication partners, like identities, keys and aliases MUST be held on a user’s end-device as state information. This SHOULD be done using a structured format, to facilitate the synchronization of state information across various devices, taking into account multi-device scenarios, which are common today.</p>
<pid="rfc.section.2.8.p.3">In pEp’s reference implementation (cf. <ahref="#implementation-status"class="xref">Section 11</a>), keys are hold using the key store of the cryptographic library used, while peer-specific state information, including trust information is held in a simple relational database.</p>
<pid="rfc.section.2.8.p.4">[[ <strong>TODO</strong>: Check optimal order the following sections. ]]</p>
<pid="rfc.section.2.9.2.1.p.1">An earlier variant of PEF-1.0 started with a “multipart/mixed” MIME node, which in case of a simple text-only email without attachments and other MIME entities has</p>
<pid="rfc.section.2.9.2.1.p.2">(1) a “text/plain” MIME entity with the PGP-encrypted content, and</p>
<pid="rfc.section.2.9.2.1.p.3">(2) the sender’s tranferable public key at the very end.</p>
<pid="rfc.section.2.9.2.1.p.3">(2) the sender’s transferable public key at the very end.</p>
<pid="rfc.section.2.9.2.1.p.4">This variant MUST NOT be produced anymore.</p>
<pid="rfc.section.2.9.2.1.p.5">An example of this deprecated variant of PEF-1.0 looks as follows:</p>
<ahref="#rfc.section.2.9.4">2.9.4.</a><ahref="#pef-2-1"id="pef-2-1">pEp Email Format 2.1</a>
</h1>
<pid="rfc.section.2.9.4.p.1">pEp Email Format 2.1 (PEF-2.1) introduces further pEp-specific header fields to the inner message, which help to determine the behaviour between pEp users.</p>
<pid="rfc.section.2.9.4.p.1">pEp Email Format 2.1 (PEF-2.1) introduces further pEp-specific header fields to the inner message, which help to determine the behavior between pEp users.</p>
<pid="rfc.section.2.9.4.p.2">In normal interpersonal messaging those additional header fields are:</p>
<pid="rfc.section.2.9.4.p.3">(1) “X-pEp-Wrapped-Message-Info: INNER” header field stating that the message carrying this is to be considered the most inner message containing the original email (this is particulary relevant for mixnet or other scenarios of nested messaging; cf. <ahref="#pEp.mixnet"class="xref">[pEp.mixnet]</a>)</p>
<pid="rfc.section.2.9.4.p.3">(1) “X-pEp-Wrapped-Message-Info: INNER” header field stating that the message carrying this is to be considered the most inner message containing the original email (this is particularly relevant for mixnet or other scenarios of nested messaging; cf. <ahref="#pEp.mixnet"class="xref">[pEp.mixnet]</a>)</p>
<pid="rfc.section.2.9.4.p.4">(2) “X-pEp-Sender-FPR” header field with the value set to sender’s full 160-bit public key fingerprint (e.g., “1234567890ABCDEF1234567890ABCDEF12345678”), and</p>
<pid="rfc.section.2.9.4.p.5">(3) the “X-pEp-Version” header field set to version “2.1”.</p>
<pid="rfc.section.2.9.4.p.6">As with PEF-2.0 <ahref="#pef-2-0"class="xref">Section 2.9.3</a>, in PEF-2.1 the actual email (inner message) is encapsulated by a MIME entity (“Content-Type: message/rfc822”), which is the second part of a “multipart/mixed” MIME node. The first part of this MIME node contains a “text/plain” MIME entity, which SHOULD be used to inform about the nature of this format (in case a non-pEp client encounters in the mailbox). It MAY be used to carry the intended subject of the inner message (which is not done in current reference implementations). Like with the PEF-1.0 (cf. <ahref="#pef-1-0"class="xref">Section 2.9.2</a>) and PEF 2.0 (cf. <ahref="#pef-2-0"class="xref">Section 2.9.3</a>), the third (and last) part of this “multipart/mixed” MIME node MUST contain the sender’s public key.</p>
<pid="rfc.section.2.9.6.p.2">Messages sent or received in unencrypted form, SHOULD NOT be saved in encrypted form on the email server: this reflects the Privacy Status the user encountered when sending or receiving the email and thus meets the user’s expectations.</p>
<pid="rfc.section.2.9.6.p.3">Instead, message drafts MUST always be saved with the identity’s public key.</p>
<pid="rfc.section.2.9.6.p.4">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>
<pid="rfc.section.2.9.6.p.5">For trusted environments (e.g., in organizations) and to conform to legally binding archivign regulations, pEp implementations MUST provide a “Trusted Server” option. With the user’s explicit consent (opt-in), unencrypted copies of the Messages MUST be held on the mail servers controlled by the organization.</p>
<pid="rfc.section.2.9.6.p.5">For trusted environments (e.g., in organizations) and to conform to legally binding archiving regulations, pEp implementations MUST provide a “Trusted Server” option. With the user’s explicit consent (opt-in), unencrypted copies of the Messages MUST be held on the mail servers controlled by the organization.</p>
<pid="rfc.section.3.1.p.1">A pEp-enabled Mail User Agent MUST consider every email account as an new identity: for each identity, a different key pair MUST be created automatically if no key material with sufficient length is available. By default, RSA-4096 key pairs for OpenPGP encryption <ahref="#RFC4880"class="xref">[RFC4880]</a> SHOULD be generated automatically for each email account. However, the key length MUST be at least 2048 bits. Elliptic curve keys with at least 256 bits MUST be supported, but SHOULD NOT yet be generated and announced by default for interoperability reasons.</p>
<pid="rfc.section.3.1.p.2">If for an identity there’s an RSA keypair with less than 2048 bits, new keys MUST be generated.</p>
<pid="rfc.section.3.1.p.2">If for an identity there’s an RSA keypair with less than 2048 bits, new keys MUST be generated.</p>
<li>Eventually move the many TODOs into this Open Issues section.</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>Add keypair revocation strategy</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’s general draft pieces to fill on both sides and how to reference them vice-versa (this is now pending on the reworked general draft to be published).</li>
<li>Elaborate more on the X-EncStatus header field and for Trusted Server situations / mirrors and describe operations.</li>
