pEp Foundation

Oberer Graben 4 CH-8400 Winterthur Switzerland hernani.marques@pep.foundation https://pep.foundation/

The proposed pretty Easy privacy (pEp) protocols for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easily implementable and interoperable opportunistic encryption. The protocols range from key distribution, secret key synchronization between own devices, to mechanisms of metadata and content protection. The metadata and content protection 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 discussed within the scope of this document. The purpose of pEp for email is to simplify and automate operations in order to make usage of email encryption a viability for a wider range of Internet users, with the goal of achieving widespread implementation of data confidentiality and privacy practices in the real world. The proposed operations and formats are targeted towards to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp).

This document contains propositions for implementers of Mail User Agents (MUAs) seeking to support pretty Easy privacy (pEp) specifically for email . All the propositions of also apply to pEp for email. In this document, requirements are outlined for MUAs wanting to establish interoperability and/or to implement pEp for email. pEp for email builds upon the cryptographic security services offered by PGP/MIME . The primary goals of pEp for email are: (1) Maximization of email privacy for Internet actors deploying and using the pretty Easy privacy approach. (2) Compatibility with legacy or other automatic email encryption solutions in order to preserve privacy to the greatest extent possible. Interoperability with S/MIME is a also goal, but at this time there is no specification or running code that achieves this goal. Current tools and implementations have failed to provide a sufficient level of usability to ordinary Internet users, with the result that end-to-end email encryption is seldom used. While OpenPGP using PGP/MIME offers good encryption–for message contents at least–more work is needed to achieve the following three objectives of pretty Easy privacy (pEp): make email encryption as automatic as possible, protect as much metadata as possible, and provide an easy way to authenticate communication partners. A reference implementation of pEp for email is available for all major platforms and it has been ported to many programming languages (cf. for an overview).

This document describes the pEp for email protocols. While it specifies details particularly related to pEp for email, it basically inherits the structure of , which describes the general concepts of pEp on a higher level. For protocol details, constituent pEp mechanisms which also apply to email can be found in documents like ), which shows how trust between any two pEp users can be established, , which describes the privacy indications that can be helpful for regular Internet users or , which outlines pEp’s peer-to-peer protocol to synchronize secret key material which belongs to the same account and user across various end-devices.

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 .

The following terms are defined for the scope of this document: pEp Handshake: The process of one user contacting another over an independent channel in order to verify Trustwords (or fingerprints as a fallback). This can be done in-person or through established verbal communication channels, like a phone call. 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. Trust On First Use (TOFU): cf. , which states: “In a protocol, TOFU calls for accepting and storing a public key or credential associated with an asserted identity, without authenticating that assertion. Subsequent communication that is authenticated using the cached key or credential is secure against an MiTM attack, if such an attack did not succeed during the vulnerable initial communication.” Man-in-the-middle (MITM) attack: cf. , which states: “A form of active wiretapping attack in which the attacker intercepts and selectively modifies communicated data to masquerade as one or more of the entities involved in a communication association.” Note: Historically, MITM has stood for ‘Man-in-the-middle’. However, to indicate that the entity in the middle is not always a human attacker, MITM can also stand for ‘Machine-in-the-middle’ or ‘Meddler-in-the-middle’.

In addition to the Protocol’s Core Design Principles outlined in , the following sections on design principles are applicable to pEp for email applications.

The pEp formats and protocols aim to maximize privacy. Where privacy goals contradict with security goals, the privacy goals MUST take precedence. Examples: pEp implementers MUST NOT make queries to public key servers by default. The reason for this is to make it more resource-intensive 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 easier. Instead, key distribution MUST be handled in-band while communicating with other peers. Trust information MUST NOT be attached to the communication partners’ 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 external trust information MUST NOT be used to signal any trust level to the pEp user. 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 neither increase security nor privacy, so long as the corresponding public key is not authenticated.

Data Minimization includes data sparsity and hiding of all technically concealable information whenever possible.

Email metadata (i.e., headers) MUST either be omitted or encrypted whenever possible. The PGP/MIME specification as described in provides few facilities for metadata protection: while the email body receives protection, the header section remains unprotected. However, it is possible to also protect the information contained in the header field values by encapsulating the whole message into a MIME entity to be signed and encrypted. The S/MIME Message Specification defines a way to also protect the header section in addition to the content of a message: The sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to header fields.

Implementers of pEp SHOULD be liberal in accepting non-pEp formats to encrypt email contents and metadata. pEp implementations MUST use the strict and interoperable pEp Email Format 1.0 (cf. ) for any outgoing communication to non-pEp users. For communication between pEp users, more privacy-preserving formats (cf. ) MUST be used. pEp Email Formats 2.0 and newer SHOULD NOT be used between users who are not recognized as pEp users (cf. ), because for non-pEp users those formats are likely to produce unwanted visual artifacts.

For interpersonal messaging, an email endpoint in pEp is the MUA on a user’s end-device: that is, encryption and decryption of messages MUST be executed on a user’s end-device and MUST NOT depend on any third-party network infrastructure (i.e., any infrastructure outside a user’s direct control). [[ TODO: Add enterprise settings with Key Escrow / Extra Keys ]]

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 an 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. [[ TODO: Make clear there is a way that synchronizes trust in a peer-to-peer fashion, by using the Trust Sync mechanism. ]]

[[ TODO: Add here what is specific to email ]]

In pEp for email, a user is a person or group who 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. 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. In pEp’s reference implementation (cf. ), keys are held using the key store of the cryptographic library, while peer-specific state information, including trust information, is held in a simple relational database. [[ TODO: Check optimal order for the following sections. ]]

In pEp for email, the SMTP address (e.g., mailto:alice@example.org) constitutes the network address.

For now, a key in pEp for email is an OpenPGP key. Each identity has a default key attached for that identity. This is the public key to be used to encrypt communications to it.

A user in pEp for email is a specific person or group. A user has at least one identity, but can have more.

An identity in pEp for email is represented by an email URI, like mailto:alice@example.org. Identities are represented by email address URIs because a user may have multiple URIs. For example, if Alice uses mailto:alice@example.org for private purposes, but also wishes to have a public address, she may create another email address, such as anonymous@example.com. Because this is a new URI (mailto:anonymous@example.com), it is considered a new identity for Alice. By default, pEp-enabled MUAs MUST generate a new key pair during new account configuration, so that a user’s respective identities are not correlated to each other. However, if Alice wants her URIs to be handled as a single identity with one key, she may configure her respective identities as aliases. For other email URIs pointing to the same identity, see the alias (cf. ) concept.

Aliases share the same key and identity, e.g., the same key might be used for mailto:alice@example.org as well as for mailto:alice@example.net. That is, both addresses refer to the same identity.

The pEp Email Formats 1.0, 2.0 and 2.1 are restricted MIME-based email formats, which ensure messages to be signed and encrypted. In accordance with pEp’s privacy (and not security) focus, signed-only messages MUST NOT be produced (cf. ). pEp-enabled clients MUST be able to render all pEp Email Formats properly: for outgoing communications, the most privacy-preserving format available is to be used, taking interoperability (cf. ) into account. Since pEp Email Format 2.0, a compatibility format (i.e., pEp Email Format 1.0, cf. ) exists, which SHOULD be applied to non-pEp users, for which trustworthy public keys are available according to the local database. In case no trustworthy encryption key is available, an unencrypted, unsigned MIME email is sent out. As in all pEp formats, also this (unprotected) message MUST contain the sender’s public key, unless Passive Mode (cf. ) is active. All pEp Email Formats include a “pEpkey.asc” file attachment holding the sender’s OpenPGP public key in ASCII-armored format, which is suitable for manual key import by non-pEp users. Thus, a user of any OpenPGP-enabled MUA is able to manually import the public key and engage in end-to-end encryption with the pEp sender. MUA implementers of PGP-capable email clients, even when not fully supporting pEp’s protocols, are encouraged to automatically import the key such that the user can immediately engage in opportunistic encryption. In pEp’s reference implementation the subject is set to “pEp” (or alternatively to its UTF-8 representation as “=?utf-8?Q?p=E2=89=A1p?=”). However, the subject’s value of the outer message MUST be ignored. Therefore, the subject can be set to any value (e.g., “…” as used in other implementations).

This is the format to be used when unencrypted messages are sent out. The unencrypted pEp format is a “multipart/mixed” MIME format, which by default ensures the delivery of the sender’s public key as an attachment (“Content-Disposition: attachment”). A simple plaintext email looks like the following:

To: Bob Date: Tue, 31 Dec 2019 05:05:05 +0200 X-pEp-Version: 2.1 MIME-Version: 1.0 Subject: Saying Hello Content-Type: multipart/mixed; boundary="boundary" --boundary Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Bob If you reply to this email using a pEp-enabled client, I will be able to send you that sensitive material I talked to you about. Have a good day! Alice -- Sent with pEp for Android. --boundary Content-Type: application/pgp-keys; name="pEpkey.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pEpkey.asc"; size=2639 -----BEGIN PGP PUBLIC KEY BLOCK----- [...] -----END PGP PUBLIC KEY BLOCK----- --boundary-- ]]>

pEp Email Format 1.0 (PEF-1.0) is an encrypted and signed MIME format, which by default ensures: a signed and encrypted message, with subject encryption delivery of the sender’s public key PEF-1.0 has a “multipart/encrypted” MIME node on-the-wire format with an OpenPGP encrypted and signed filename “msg.asc”, and “Content-Disposition: inline” attribute.” The subject is the only header field that can be protected with PEF-1.0. To achieve this protection, the real subject value is added to the top for the content section for the very first MIME entity with media type “text/plain”, that is encrypted, e.g.: Subject: Credentials For example, an email with “Subject: Credentials” becomes “Subject: pEp” on-the-wire once encryption has taken place, with the true subject appended to the beginning of the message text once decrypted. Thus, legacy clients not aware of nor able to parse pEp’s subject encryption, still display the actual subject (in the above example: “Credentials”) to the user. Whenever the first encrypted “text/plain” MIME entity contains such a subject line, the MUAs implementing pEp MUST render it to the user. Note that also the lines starting with “subject:” or “SUBJECT:” are to be rendered (as with header fields, this is case-insensitive). A pEp-enabled MUA MUST add the “X-pEp-Version” header field with its highest value (preferably with value “2.1” as for pEp Email Format 2.1 ) when producing this format. Here, a pEp-enabled MUA declares its capability to receive and render more privacy-preserving formats. Upgrading both sides to the highest version of the pEp Email Format allows pEp-enabled MUAs for best possible protection of metadata. For non-pEp MUAs it is OPTIONAL to add the “X-pEp-Version: 1.0” header field. However, this format is implicitly assumed even if this header field is not present. Please note that for messages between pEp- and non-pEp clients the subject encryption MAY be disabled, sacrificing usability over privacy by avoiding artefacts for non-pEp recipients. PEF-1.0 is also considered pEp’s compatibility format towards non-pEp clients. A PEF-1.0 example looks as follows:

To: Bob Date: Wed, 1 Jan 2020 23:23:23 +0200 X-pEp-Version: 1.0 MIME-Version: 1.0 Subject: pEp Content-Type: multipart/encrypted; boundary="boundary1"; protocol="application/pgp-encrypted" --boundary1 Content-Type: application/pgp-encrypted Version: 1 --boundary1 Content-Type: application/octet-stream Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="msg.asc" -----BEGIN PGP MESSAGE----- [...] -----END PGP MESSAGE----- --boundary-- ]]>

Decrypting the enclosed “msg.msc” part yields the following:

Note that the user-intended subject value is encrypted in the first “text/plain” MIME entity under the “multipart/mixed” MIME node.

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 (1) a “text/plain” MIME entity with the PGP-encrypted content, and (2) the sender’s transferable public key at the very end. This variant MUST NOT be produced anymore. An example of this deprecated variant of PEF-1.0 looks as follows:

To: Bob Date: Wed, 1 Jan 2020 23:23:23 +0200 X-pEp-Version: 1.0 MIME-Version: 1.0 Subject: pEp Content-Type: multipart/mixed; boundary="boundary" --boundary Content-Type: application/pgp-encrypted Version: 1 --boundary Content-Type: text/plain; charset="utf8" Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- [...] -----END PGP MESSAGE----- --boundary Content-Type: application/pgp-keys; name="pEpkey.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- [...] -----END PGP PUBLIC KEY BLOCK----- --boundary-- ]]>

There, decrypting the PGP encrypted text/plain element yields a text like the following; most obviously, the intended subject line is now visible:

pEp Email Format 2.0 (PEF-2.0) is a strict MIME format, which by default ensures: a signed and encrypted message, with full email encapsulation delivery of the sender’s public key In PEF-2.0, 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, including a marker text “pEp-Message-Wrapped-Info: OUTER” (in its MIME content). This is used for proper displaying and mapping of the nested message and its encrypted header fields. Like with the PEF-1.0 (cf. ), the third (and last) part of the “multipart/mixed” MIME node MUST contain the sender’s public key. The “multipart/mixed” MIME node is encrypted inside yet another MIME node (“Content-Type: multipart/encrypted”, cf. / ), which is the body part of the outer message. Thus, the whole header section of the inner message can be fully preserved, not only encrypted, but also signed. In the outer message, however, when communicating with pEp users all header fields that are not needed MUST be omitted to the fullest extent possible. Once encrypted, only the outer message consisting of the (minimal) outer header section and the “multipart/encrypted” MIME entity as body with an application/octet-stream “Content-Type” with name “msg.asc” is visible on the wire. If the receiving side is not a known pEp-enabled MUA, but there is a trustworthy public key available, PEF-1.0 (cf. ) MUST be used to send the email. In any case, the “X-pEp-Version” header field MUST be set to version 2.0, as the highest version that the sender supports. The following example shows a PEF-2.0 multipart/encrypted email, signed and encrypted, as an 7bit octet stream with a filename “msg.asc”, with “Content-Disposition: inline”. Within that, the original email message is fully contained in encrypted form (like this, also the subject line gets encrypted). The support of version 2.0 is announced in the “X-pEp-Version” header field (in this example, 2.0 is the newest pEp Email Format the pEp-enabled MUA is able to produce and render):

To: Bob Date: Wed, 1 Jan 2020 23:23:23 +0200 X-pEp-Version: 2.0 MIME-Version: 1.0 Subject: pEp Content-Type: multipart/encrypted; boundary="boundary1"; protocol="application/pgp-encrypted" --boundary1 Content-Type: application/pgp-encrypted Version: 1 --boundary1 Content-Type: application/octet-stream Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="msg.asc" -----BEGIN PGP MESSAGE----- [...] -----END PGP MESSAGE----- --boundary-- ]]>

Decrypting “msg.asc” results in a multipart/mixed node, with three elements: (1) a text part indicating this is the encapsulated message (2) the original message encapsulated by a “message/rfc822” MIME entity, and (3) the transferable sender’s public key in ASCII-armored format. An unwrapped example looks like this:

Date: Wed, 1 Jan 2020 23:23:23 +0200 Subject: Credentials X-pEp-Version: 2.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="boundary3" --boundary3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable pEp-Wrapped-Message-Info: INNER Dear Bob Please use "bob" with the following password to access the wiki site: correcthorsebatterystaple Please reach out if there are any issues and have a good day! Alice --boundary3-- --boundary2 Content-Type: application/pgp-keys Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- [...] -----END PGP PUBLIC KEY BLOCK----- --boundary2-- ]]>

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. In normal interpersonal messaging those additional header fields are: (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. ) (2) “X-pEp-Sender-FPR” header field with the value set to sender’s full 160-bit public key fingerprint (e.g., “1234567890ABCDEF1234567890ABCDEF12345678”), and (3) the “X-pEp-Version” header field set to version “2.1”. As with PEF-2.0 , 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. ) and PEF 2.0 (cf. ), the third (and last) part of this “multipart/mixed” MIME node MUST contain the sender’s public key. This “multipart/mixed” MIME node is encrypted inside yet another MIME node (“Content-Type: multipart/encrypted”, cf. / ), which is the body part of the outer message. A caveat of PEF-2.1 is that message rendering varies considerably across different MUAs. This is relevant as it might happen that a non-pEp MUA encounters a PEF-2.1 message (e.g., if a pEp-enabled client was used in the past). No standard is currently available which enables MUAs to reliably determine whenever a nested “message/rfc822” MIME entity is meant to render the contained email message, or if it was effectively intended to be forwarded as an attachment, where a user needs to click on in order to see its content. To help unaware MUAs, a Content-Type header field parameter with name “forwarded” as per is added to the Content-Type header field. MUAs can use this to distinguish between a forwarded message and a nested message (i.e., using “forwarded=no”). When the receiving peer was registered as being only PEF-2.0-capable, the message must be sent in PEF-2.0 (cf. ). The reason for this is that pEp-enabled MUAs which are only PEF-2.0-capable rely on the plaintext “pEp-Message-Wrapped-Info: OUTER” and “pEp-Message-Wrapped-Info: INNER” markers to properly display and map the nested message and its encrypted header fields. As with PEF-1.0, if the receiving side is not a known pEp-enabled MUA, but there is a trustworthy public key available, PEF-1.0 (cf. ) MUST be used to send the email. In any case, the “X-pEp-Version” header field MUST be set to version 2.1, as the highest version that the sender supports. This is an example of what the format looks like between two PEF-2.1-capable clients:

To: Bob Date: Wed, 1 Jan 2020 23:23:23 +0200 X-pEp-Version: 2.1 MIME-Version: 1.0 Subject: pEp Content-Type: multipart/encrypted; boundary="boundary1"; protocol="application/pgp-encrypted" --boundary1 Content-Type: application/pgp-encrypted Version: 1 --boundary1 Content-Type: application/octet-stream Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="msg.asc" -----BEGIN PGP MESSAGE----- [...] -----END PGP MESSAGE----- --boundary1-- ]]>

Unwrapping the “multipart/encrypted” MIME node, yields this:

Date: Wed, 1 Jan 2020 23:23:23 +0200 Subject: Credentials X-pEp-Version: 2.1 X-pEp-Wrapped-Message-Info: INNER X-pEp-Sender-FPR: 1234567890ABCDEF1234567890ABCDEF12345678 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="boundary3" --boundary3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear Bob Please use "bob" with the following password to access the wiki site: correcthorsebatterystaple Please reach out if there are any issues and have a good day! Alice --boundary3-- --boundary2 Content-Type: application/pgp-keys Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- [...] -----END PGP PUBLIC KEY BLOCK----- --boundary2-- ]]>

[[ TODO: Clarify on the “raising message” term in the example. ]]

To be able to decide which email format to generate, the pEp-enabled MUA REQUIRES to record state on a per-identity basis. Once a “X-pEp-Version” header field is discovered, the user MUST be recorded as a pEp user and the corresponding pEp Version it supports (according to the highest value of the “X-pEp-Version” header field encountered).

In accordance with the Privacy by Default principle, messages sent or received in encrypted form MUST be saved with the identity’s respective public key. 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. Instead, message drafts MUST always be saved with the identity’s public key. Other messages sent and received MUST be saved encrypted by default: for most end-user scenarios, the servers users work with, are considered untrusted. 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.

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 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. If for an identity there’s an RSA key pair with less than 2048 bits, new keys MUST be generated.

[[ TODO: Add here what is specific to email ]]

[[ TODO: Add here what is specific to email ]]

[[ TODO: Add here what is specific to email ]]

By default, public keys MUST always be attached to any outgoing message as described in . If this is undesired, Passive Mode (cf. ) can be activated.

[[ TODO: Add here what is specific to email ]]

The following example roughly describes a pEp email scenario with a typical initial message flow to demonstrate key exchange and basic trust management: Alice – knowing nothing of Bob – sends an email to Bob. As Alice has no public key from Bob, this email is sent out unencrypted. However, Alice’s public key is automatically attached. Bob can just reply to Alice and – as he received her public key – his MUA is now able to encrypt the message. At this point, the rating for Alice changes to “encrypted” in Bob’s MUA, which (UX-wise) can be displayed using yellow color (cf. ). Alice receives Bob’s key. As of now Alice is also able to send secure emails to Bob. The rating for Bob changes to “encrypted” (with yellow color) in Alice’s MUA (cf. ). If Alice and Bob want to prevent man-in-the-middle (MITM) attacks, they can engage in a pEp Handshake comparing their so-called Trustwords (cf. ) and confirm this process if those match. After doing so, their identity rating changes to “encrypted and authenticated” (cf. ), which (UX-wise) can be displayed using a green color. As color code changes for an identity, this is also reflected to future messages to/from this identity. Past messages, however, MUST NOT be altered.

| | | | +-----------------------+ | | Privacy Status for A: | | | *Encrypted* | | +-----------------------+ | | | B sends message to A (Public Key | | attached) / signed and ENCRYPTED | |<------------------------------------------+ | | +-----------------------+ | | Privacy Status for B: | | | *Encrypted* | | +-----------------------+ | | | | A and B successfully compare their | | Trustwords over an alternative channel | | (e.g., phone line) | |<-- -- -- -- -- -- -- -- -- -- -- -- -- -->| | | +-----------------------+ +-----------------------+ | Privacy Status for B: | | Privacy Status for A: | | *Trusted* | | *Trusted* | +-----------------------+ +-----------------------+ | | ]]>

[[ TODO: Add more of what is specific to email ]]

[[ TODO: Add here what is specific to email ]]

[[ TODO: Add here what is specific to email ]]

[[ TODO: Add here what is specific to email ]]

As per : [[ TODO: Add here what is specific to email ]]

[[ TODO: Add here what is specific to email ]]

[[ TODO: Add here what is specific to email ]]

[[ TODO: Add here what is specific to email ]]

In email, Passive Mode primarily exists as an option to avoid potential usability issues in certain environments where Internet users might get confused by the exposure of public keys in email attachments. In principle, however, this “problem” can be mitigated either by training or by MUA implementers displaying public key material in a more symbolic way or even importing it automatically and then hiding this attachment altogether (as pEp implementers are supposed to do, such that regular Internet users do not have to bother about keys). Passive Mode has a negative impact on privacy: additional unencrypted message exchanges are needed until pEp’s by-default encryption can take place. Passive Mode MUST only affect unencrypted communications and MUST be inactive by default. By opting in to Passive Mode, the sender’s public key MUST NOT be attached when sending out unsecure emails. On the other hand, Passive Mode is without any effect when pEp is able to send out an encrypted message, because the necessary encryption key(s) are available. In this situation, opportunistic by-default encryption MUST take place: there, the sender’s public key is attached in encrypted form as constituent part of one of pEp’s PGP/MIME-based message format described in . Additionally, Passive Mode MUST be without effect, if a receiver learns that an MUA is actually pEp-capable, even if the sender involved is in Passive Mode, too: this MUST be recognized by the “X-pEp-Version” header field, as the only clear indicator to detect pEp users. That means that a pEp-enabled MUA is REQUIRED to attach its corresponding public key to another pEp user in any case, such that they can engage in opportunistic encryption. [[ TODO: Add message examples and a flow chart, if needed ]]

This is an opt-in mechanism to enforce that messages go out unprotected. Even if encryption keys for recipient(s) are available, this option MUST enforce that messages are sent in the format.

[[ TODO: Add here what is specific to email ]]

[[ TODO: Add here what is specific to email ]]

[[ TODO: Add here what is specific to email ]]

[[ TODO ]]

[[ TODO ]]

This document has no actions for IANA.

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 . 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. According to , “[…] 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.”

The following software implementations of the pEp protocols (to varying degrees) already exists: pEp for Outlook as add-on for Microsoft Outlook, release pEp for iOS (implemented in a new MUA), release pEp for Android (based on a fork of the K9 MUA), release pEp for Thunderbird as a new add-on for Thunderbird, beta Enigmail/pEp as add-on for Mozilla Thunderbird, release (will be discontinued late 2020/early 2021) pEp for Android, iOS, Outlook and Thunderbird are provided by pEp Security, a commercial entity specializing in end-user pEp implementations while Enigmail/pEp is pursued as community project, supported by the pEp Foundation. All software is available as Free and Open Source Software and published also in source form.

Special thanks go to Krista Bennett and Volker Birk for the reference implementation on pEp and the ideas leading to this draft. The author would like to thank the following people who provided substantial contributions, helpful comments or suggestions for this document: Berna Alp, Kelly Bristol, Bernie Hoeneisen, Claudio Luck and Lars Rohwedder. This work was initially created by the pEp Foundation, and was initially reviewed and extended with funding by the Internet Society’s Beyond the Net Programme on standardizing pEp.

This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. This memo defines an Experimental Protocol for the Internet community. 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] 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.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] 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. This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] This document defines the concept "Opportunistic Security" 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. This document defines a new Content-Type header field parameter named "forwarded" for "message/rfc822" and "message/global" media types, and its registration with IANA. The pretty Easy privacy (pEp) model and protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure, privacy-preserving end- to-end interpersonal messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer-to-peer synchronization of private keys and other user data across devices). Human Rights-enabling principles like Data Minimization, End-to-End and Interoperability are explicit design goals. For the goal of usable privacy, pEp introduces means to verify communication between 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. Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME with email), and are written with the intent to be interoperable with already widely- deployed systems in order to ease adoption and implementation. This document outlines the general design choices and principles of pEp. 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 authenticate their communication channel. The new method is targeted to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp). 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). 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. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. 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), which hexadecimal strings are mapped to. Such a mapping makes verification processes like fingerprint comparisons more practical, and less prone to misunderstandings. This document describes the pEp KeySync protocol, which is designed to perform secure peer-to-peer synchronization of private keys across devices belonging to the same user. Modern users of messaging systems typically have multiple devices for communicating, and attempting to use encryption on all of these devices often leads to situations where messages cannot be decrypted on a given device due to missing private key data. Current approaches to resolve key synchronicity issues are cumbersome and potentially insecure. The pEp KeySync protocol is designed to facilitate this personal key synchronization in a user-friendly manner. 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.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. pEp Foundation

[[ RFC Editor: This section is to be removed before publication ]] draft-pep-email-01: Minor language improvements draft-pep-email-00: Major restructure of the document Major fixes in the description of the various message formats Add many open questions and comments inline (TODO) Add IANA Considerations section Change authors and acknowledgment section Add internal references Describe Passive Mode Better explanation on how this document relates to other pEp documents draft-marques-pep-email-02: Add illustrations Minor fixes Add longer list of Open Issues (mainly by Bernie Hoeneisen) draft-marques-pep-email-01: Remove an artefact, fix typos and minor editorial changes; no changes in content draft-marques-pep-email-00: Initial version

[[ RFC Editor: This section should be empty and is to be removed before publication ]] Eventually move the many TODOs into this Open Issues section. Describe KeyImport to induce the import from secret keys from other devices Describe / Reference KeySync (and other sync, through IMAP) Add key pair revocation strategy 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. 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). Elaborate more on the X-EncStatus header field and for Trusted Server situations / mirrors and describe operations. Explain Key Mapping (between OpenPGP and S/MIME)