pretty Easy privacy (pEp): Email Formats and ProtocolspEp FoundationOberer Graben 4CH-8400 WinterthurSwitzerlandhernani.marques@pep.foundationhttps://pep.foundation/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.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.This document defines basic operations of pEp’s approach towards email and
two PGP/MIME formats (pEp Email Format 1 and 2) to provide certain
security guarantees. The proposed operations and formats are targeted to Opportunistic
Security scenarios and are already implemented in several applications of
pretty Easy privacy (pEp).This document contains specific propositions to those parts of pretty Easy
privacy (pEp) that are specific to email .All changes required for the pEp propositions on email to work just
affect implementers of Mail User Agents (MUAs). pretty Easy privacy (pEp) for email is a proposition to both, implementers and
Internet users, to make end-to-end encryption of emails straightforward.
Whereas Pretty Good Privacy (PGP) and OpenPGP provide a
basis for good encryption, we still miss implementations that also
provide a sufficient level of usability for ordinary Internet users.Two users using pEp-enabled mail clients basically don’t need to do anything
else than just writing emails.
The following example roughly describes a typical pEp scenario:Alice – knowing nothing of Bob – just writes an email to Bob:
this mail is sent out unencrypted. However, Alice’s public key
is automatically attached.Bob can just reply to Alice and – as he got her public key – is
now able to encrypt a message at this point. Through a
color-rating (cf. Bob becomes aware of
his message now going out in a secure fashion.As Alice receives Bob’s key, as of now she is also able to send
secure messages to Bob.If Alice and Bob want to prevent man-in-the-middle (MITM) attacks,
they can engage in a Handshake ,
comparing their so-called Trustwords
and confirm this process if those match. After doing so, their
identity rating changes to “encrypted and authenticated”
, which (UX-wise) can be signaled, e.g.,
using a green color rating. This color rating is also applied to
messages (in- and outgoing).This workflow is implemented as running code already in various pEp-enabled
software, cf. .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) as to allow for onion routing of
email messages in a way metadata can be furtherly protected for
communication peers – achievable by message encapsulation. pEp’s
email message format 2 described below is already prepared for this
scenario.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 .Handshake: The process when Alice – e.g. in-person or via phone –
contacts Bob to verify Trustwords (or by fallback: fingerprints) is
called Handshake. 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. Man-in-the-middle attack (MITM): cf. 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 SHOULD be generated
automatically for each email account. However, the key length MUST be at
least RSA-2048.If for an identity there’s an RSA keypair with less than 2048 bits, new keys
MUST be generated.[[ TODO: Shouldn’t this go to general I-D ]]By default, public keys MUST always be attached to any outgoing message.In pEp, implementers MUST put privacy first: email metadata
(i.e., headers) MUST either be omitted or encrypted whenever
possible.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.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.If for a recipient there’s no public key available, a pEp message MUST
be sent out in plain text as MIME message version 1, with
“Content-Type: multipart/mixed” and the OpenPGP public key attached in
ASCII armored format, named “pEpkey.asc”.For a MUA implementer this fulfills two functions:It can be easily detected that the sender is a pEp user.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.The plain text messages SHOULD be sent out with the UTF-8 charset
Content-Type set.Please note that in the following examples the “pEpkey.asc” attachments
encoded in base64 format are only shown in its first and last line
(and otherwise shortened by three points).
pEp email format 1 is an encrypted and signed PGP/MIME format, which by
default ensures:correctly signed messagesdelivery of public keys (at least and automatically: the sender’s
public key)By default, when a public key for a peer is available,
pEp-capable MUAs are REQUIRED to send out email messages
according to and in PGP/MIME format
with the informational “Subject:” header field set to “pEp”,
as follows:Subject: pEpIn turn, the intended human-readable subject (in pEp called short message)
MUST be moved to the body of the message (in pEp called long
message) and appear as the first line there. pEp implementers are REQUIRED to
display the intended “Subject:” field as the real subject line in the
respective MUAs to help users to easily grasp the real subject.Alternatively, the “Subject:” header field can also be set to its
UTF-8 variant with “pEp” written with the equivalence symbol instead
of an “E”:Subject: =?utf-8?Q?p=E2=89=A1p?=Additionally, a header field “X-Pep-Version: 1.0” is added to
signal compatibility with pEp email format to pEp-enabled MUAs.
Example. Using the well-known example of , an email message sent out
with pEp in message format 1 looks like this:Using the UTF-8 variant of writing “pEp” with the equivalence symbol, and
an additional document attached (an example PDF attachment), an OpenPGP-signed
and -encrypted pEp email would look like the following:pEp email format 2 is a strict PGP/MIME format, which by default ensures:correctly signed messagesdelivery of public keys (at least: the sender’s public key)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).Headers of messages (received, to be forwarded etc.) can thus be preserved
in the inner message, which is OpenPGP-signed and -encrypted by the
application/pgp-encrypted “Content-Type”.In the outer message, unnecessary email headers MUST be omitted to the
fullest extent.In contrast to pEp email format 1, the public key and other files attached
cannot be seen in the MIME tree. The only part which can be seen is an
application/octet-stream “Content-Type” with name “msg.asc”.A pEp email format 2 message, with the “Subject:” header field set to
“pEp” looks like the following (please note that the inner message is
fully contained in the OpenPGP-signed and -encrypted file named “msg.asc”,
including possible attachments and with the sender’s public key as
“pEpkey.asc” attached at the very end):The inner message in a simple form without further nesting might look
like the following, when decrypted:It does not only carry the encrypted subject, which pEp implementers are
supposed to map (UX-wise) such as to replace the “pEp” subject in the
outer message, but also the actual message (as inline file named “msg.txt”
in case of plain text) as well as the sender’s public key.pEp-enabled clients MUST NOT blindly render messages. Special care MUST
be taken when rendering the pEp email formats, which provide certain
guarantees:For cases where messages appear unsigned, signed without a key or with a
bad signature, pEp’s privacy rating can be employed to signal issues to
a user in an easily understandable manner, cf. .[[TODO: This needs more work to be understandable. ]]For encryption of emails that contain Bcc recipients a simple
algorithm MAY be used.Recipients MUST be partitioned into three lists, one for each of three
possible outgoing messages:To and Cc recipients (without Bcc recipients)
Bcc recipients unable to encryptBcc recipients able to encryptIt’s RECOMMENDED that if the original message the user drafted is
saved in the user’s sent folder, that all recipient
fields (“To:”, “Cc:”, “Bcc:”) be preserved.To and Cc recipients MUST be split from the Bcc recipients.Bcc recipients MUST be split in two groups:First group of Bcc recipients who will receive clear text emails.Second group of Bcc recipients who are able to receive encrypted emails.The original email the user drafted SHOULD be sent out with the “Bcc:” field
removed.For the first Bcc group, a regular email message with only Bcc recipients is sent.For the second group, individual Bcc email messages are sent.[[TODO: This needs more work to make it better understandable. ]][[ TODO: Shouldn’t this go to general []In accordance to the Privacy by Default principle, messages sent
or received in encrypted form SHALL be saved with the peer’s
respective public key.Messages sent or received in unencrypted form, SHOULD NOT be saved
in encrypted form on the mail server: this reflects the Privacy Status
the user encountered when sending or receiving the email and thus meets
the user’s expectations.Instead, message drafts MUST always be saved with the user’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 regulations, pEp implementations MUST provide a “Trusted Server”
option. With the user’s explicit consent (opt-in), unencrypted copies of the
messages SHALL be held on the mail servers controlled by the organization.
This can also help end-users to archive their emails without needing access to
any key material.[[ TODO ]]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 implementing the pEp protocols (to varying
degrees) already exists:pEp for Outlook as add-on for Microsoft Outlook, release pEp for Android (based on a fork of the K9 MUA), release Enigmail/pEp as add-on for Mozilla Thunderbird, release pEp for iOS (implemented in a new MUA), beta 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.All software is available as Free Software and published also in source form.Special thanks go to Krista Bennet and Volker Birk for the reference
implementation on pEp and the ideas leading to this draft.This work was initially created by pEp Foundation, and will be reviewed and
extended with funding by the Internet Society’s Beyond the Net Programme on
standardizing pEp. Key words for use in RFCs to Indicate Requirement LevelsIn 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.MIME Security with OpenPGPThis 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]Internet Security Glossary, Version 2This 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.Internet Message FormatThis 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]Opportunistic Security: Some Protection Most of the TimeThis 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.pretty Easy privacy (pEp): Privacy by DefaultBuilding on already available security formats and message transports (like PGP/MIME for email), and with the intention to stay interoperable to systems widespreadly deployed, pretty Easy privacy (pEp) describes protocols to automatize operations (key management, key discovery, private key handling including peer-to-peer synchronization of private keys and other user data across devices) that have been seen to be barriers to deployment of end-to-end secure interpersonal messaging. pEp also relies on "Trustwords" (as a word mapping of of fingerprints) to verify communication peers and proposes a trust rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. In this document, the general design choices and principles of pEp are outlined.pretty Easy privacy (pEp): Contact and Channel Authentication through HandshakeIn interpersonal messaging end-to-end encryption means for public key distribution and verification of its authenticity are needed; the latter to prevent man-in-the-middle (MITM) attacks. This document proposes a new method to easily verify a public key is authentic by a Handshake process that allows users to easily verify their communication channel. The new method is targeted to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp).OpenPGP Message FormatThis 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]Simple Mail Transfer ProtocolThis document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]Improving Awareness of Running Code: The Implementation Status SectionThis 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.IANA Registration of Trustword Lists: Guide, Template and IANA ConsiderationsThis document specifies the IANA Registration Guidelines for Trustwords, describes corresponding registration procedures, and provides a guideline for creating Trustword list specifications. Trustwords are common words in a natural language (e.g., English) to which the hexadecimal strings are mapped to. This makes verification processes (e.g., comparison of fingerprints), more practical and less prone to misunderstandings.pretty Easy privacy (pEp): Mapping of Privacy RatingIn 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).Source code for pEp for AndroidSource code for pEp for iOSSource code for pEp for OutlookSource code for Enigmail/pEpBeyond the Net. 12 Innovative Projects Selected for Beyond the Net Funding. Implementing Privacy via Mass Encryption: Standardizing pretty Easy privacy’s protocols[[ RFC Editor: This section is to be removed before publication ]]draft-marques-pep-email-02:
Add illustrationsMinor fixesAdd 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 contentdraft-marques-pep-email-00:
Initial version[[ RFC Editor: This section should be empty and is to be removed
before publication ]]Ship better example of pEp Message Format 2Elaborate on omitting headers and better explain pEp Message Format 2Add notes on EFAILDescribe KeyImport to induce the import from secret keys from other devicesDescribe / Reference KeySync (and other sync, through IMAP)Add keypair revocation strategyBetter describe required MIME fields and parameters to set for the
pEp email formatsCreate 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.Add existence of internally exposed X-EncStatus header field after decrypt
and for Trusted Server situations / mirrors and describe operations.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)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.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?)