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.

36 KiB


title: "pretty Easy privacy (pEp): Email Formats and Protocols" abbrev: pretty Easy privacy (pEp) Email docname: draft-pep-email-00 category: std

stand_alone: yes pi: [toc, sortrefs, symrefs, comments]

author: {::include ../shared/author_tags/hernani_marques.mkd} #{::include ../shared/author_tags/claudio_luck.mkd} #{::include ../shared/author_tags/bernie_hoeneisen.mkd}



RFC3156: # PGP/MIME # RFC4880: # OpenPGP # RFC4949: RFC5322: # STMP # RFC7435: # Opportunistic Security # I-D.melnikov-iana-reg-forwarded: I-D.birk-pep: I-D.marques-pep-handshake: I-D.marques-pep-rating:

informative: RFC8551: # S/MIME #




RFC5490: # SIEVE






I-D.birk-pep-trustwords: I-D.pep-keysync:


target: https://www.usenix.org/legacy/publications/library/proceedings/usenix01/full_papers/davis/davis_html/index.html

title: "Defective Sign Encrypt in S/MIME, PKCS7, MOSS, PEM, PGP, and XML. 65-78"



ins: Don Davis

name: Don Davis

date: 2001

{::include ../shared/references/isoc-btn.mkd} {::include ../shared/references/implementation-status.mkd}

--- abstract

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 protection (like subject encryption) by moving actual payload data into the PGP/MIME encrypted part. Despite such naive forms of metadata protection, the modern message formats propsed allow for sending email messages through a mixnet. Such work is in scope of this document to be treated in a future revision.

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.

This document defines specific operations of pEp's approach towards email and using PGP/MIME formats to provide certain privacy and 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).

--- middle


This document contains propositions for implementers of Mail User Agents (MUAs) seeking to support pretty Easy privacy (pEp) specifically for email {{RFC5322}}. All the propositions of {{I-D.birk-pep}} 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 {{RFC3156}} for now. The most important goal is (1) to maximize privacy in the email context, at least for those Internet actors deploying and using the pretty Easy privacy approach, and (2) to provide ways to stay compatible to legacy or other approaches in automatic email encryption to any privacy-preserving extent possible.

Interoperability with S/MIME {{RFC8551}} is a goal, but there's no specification or Running Code so far.

Current (decade-old) tools and implementations have failed to provide a sufficient level of usability to ordinary Internet users, such that end-to-end email encryption is seldomly used.

Whereas with OpenPGP {{RFC4880}} using PGP/MIME {{RFC3156}} formats good encryption, for message contents at least, can be achieved, more work is needed for the goal to achieve three objectives:

  1. make email encryption (of the payloads) as automatic as possible.
  2. protect metadata as much as possible; and
  3. provide an easy way to authenticate communicaton partners.

pEp for email (for now producing PGP/MIME-based formats) is actively being implemented and already available for all major platforms and has been ported to many programming languages (cf. {{implementation-status}} for an overview).

Relationship to other pEp documents

This document describes the pEp for email protocols. While it specifies details particularly related to pEp for email, it basically inherits the structure of {{I-D.birk-pep}}, which describes the general concepts of pEp on a higher level.

For protocol details, constituent pEp mechanisms also applying for email can be found in documents like {{I-D.marques-pep-handshake}}) showing how trust between any two pEp users can be established, {{I-D.marques-pep-rating}} describing privacy indications which can be helpful for regular Internet users or {{I-D.pep-keysync}} outlining pEp's peer-to-peer protocol to synchronize secret key material belonging to the same account and user across various (very different) end-devices.

{::include ../shared/text-blocks/key-words-rfc2119.mkd}

{::include ../shared/text-blocks/terms-intro.mkd}

{::include ../shared/text-blocks/handshake.mkd} {::include ../shared/text-blocks/trustwords.mkd} {::include ../shared/text-blocks/tofu.mkd} {::include ../shared/text-blocks/mitm.mkd}

Opportunistic Security and Privacy for Email

In addition to the Protocol's Core Design Principles outlined in {{I-D.birk-pep}}, the following sections on design principles are applicable to pEp for email applications.

Privacy by Default

The pEp formats and protocols aim to maximize privacy. Where privacy goals contradict with security goals, the privacy goals SHALL have precedence.


  • pEp implementers SHALL NOT make queries to public key servers by default, in order to make it more expensive for centralized network actors to learn a user's social graph. This is also problematic security-wise, as centralized cryptgraphic key subversion at-scale is made cheaper.
  • Instead, key distribution SHALL be handled in-band while communicating with other peers.
  • No trust information SHALL be attached to the communication partner's public keys. This is metadata which SHALL be held locally and seperately from the keys. Trust is established between the peers directly (peer-to-peer) and no transitive trust information is held centrally: that is, while pEp MUST be able to work with OpenPGP keys which carry trust information, this trust information SHALL not be used to signal any trust level.
  • pEp-enabled MUAs SHALL either engage in a signed-and-encrypted communication or in unsigned plaintext communication. While the signatures attached to plaintext messages can be verified, this cannot enhance the perceived quality of the message in the user interface, while an invalid signature degrades the perception: signed-only messages per se do not increase security, if no authentication was done and are -- as sole measure -- without positive influence on privacy.

Data Minimization

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

Metadata Protection

Email metadata (i.e., headers) MUST either be omitted or encrypted whenever possible.

The PGP/MIME specification {{RFC3156}} provides no facility for metadata protection. However, it is possible to protect the information contained in header field values by encapsulating the whole message into a new message body to be singed and encrypted.

The S/MIME Message Specification {{RFC8551}}, on the other hand, defines a way to protect also 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.

Support for multiple formats

What concerns any kind of email (metadata) encryption: implementers of pEp SHOULD be liberal in accepting other approaches to encrypt email headers, but MUST use the strict and interoperable pEp format (cf. {{pef-1-0}}) for any outgoing communication.


While pEp implementers SHALL make sure that any communication between pEp users is maximized for privacy, interoperability between other approches to encrypt payloads and hide metadata SHOULD be supported to the widest extent. To mitigate artefacts in the presentation of messages sent from non-pEp to pEp implementions (and vice versa).


An email endpoint in pEp is the MUA on a user's end-device: that is, encryption and decryption of messages SHALL be end-device-based and MUST NOT happen on a server infrastructure.

[[ TODO: Add enterprise settings with Key Escrow / Extra Keys ]]


All relevant pEp mechanisms and state information about other peers SHALL be held locally, on a peer's end-device. There SHALL 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 SHALL not be relevant to hold actual state between peers.

User Experience (UX)

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

Identity System

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.

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.

In pEp's reference implementation (cf. {{implementation-status}}), 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.

[[ TODO: Check optimal order 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 to it. 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 and device owner which can have one or more identities.

Each user has at last one identity.


An identity in pEp for email is represented by an email address, like mailto:alice@example.org.

This can be Alice with her real name, using this identity for private purposes. Should Alice create another address, like mailto:anonymous@example.com, this is considered a second identity. By default, pEp-enabled MUAs SHALL create a new key pair when a new email account is being configured, such as to not allow correlation by using the same key. If in turn, Alice wants different addresses of her to be collapsed into one single identity with one single key, then the user has to configure them as aliases.

If various email addresses represent the same identity, this is called an alias (cf. {{elements-alias}}).


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.com. That is, both addresses refer to the same identity.

pEp Email Formats

The pEp Email Formats 1.0, 2.0 and 2.1 are restricted PGP/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 SHALL NOT be supported. While pEp-enabled clients MUST be able to render all pEp Email Formats properly, it's RECOMMENDED to use pEp Email Format 2.1.

Since pEp Email Format 2.0, a compatibility format (i.e., pEp Email Format 1.0, cf. {{pef-1-0}}) exists, which SHOULD be applied towards non-pEp users, for which trustworthy public keys are available according to the local database.

In case no suitable encryption key is available, an unencrypted, unsigned MIME email is sent out. This message SHALL contain the sender's public key, unless Passive Mode (cf. {{passive-mode}}) is active.

Unencrypted pEp Format

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 disposed as an attachment.

In its simplest form, such an email looks like the following:

{::include ../shared/fence-line.mkd}

{::include examples/pef-0.mkd}

{::include ../shared/fence-line.mkd}

The "pEpkey.asc" file attachment holds 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.

The plain text messages MUST be sent out with the UTF-8 charset Content-Type set.

pEp Email Format 1.0

pEp Message Format 1.0 is an encrypted and signed PGP/MIME format, which by default ensures:

  • a signed and encrypted message, with subject encryption
  • delivery of the sender's public key

In its initial version, which SHALL NOT be produced anymore by pEp-enabled clients, it starts with multipart/mixed MIME node, which in case of a simple text-only email without attachments and other Content-Types has (1) a text/plain Content-Type with the PGP-encrypted content and (2) the sender's tranferable public key at the very end.

The modern version of PEF-1.0 instead, has a multipart/encrypted MIME node on the wire format with an OpenPGP encrypted and signed filename "msg.asc" to be disposed inline.

By default, the subject SHALL be set to "pEp" or alternatively to its UTF-8 representation as =?utf-8?Q?p=E2=89=A1p?=. This is the only header field which can be protected in this format. To achieve its protection, the real subject value is added to the top of the content section of the very first MIME entity with media type "text/plain", that is encrypted, e.g.:

Subject: Credentials

Thus, legacy clients not aware of 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, pEp-implementing MUAs MUST render it to the user. Note that this mechanism inherits the case-insensitiveness, e.g. also "subject:" or "SUBJECT:" are to be rendered.

Clients not (fully) implementing pEp, but still aim to stay as interoperable as possible with pEp-enabled MUAs, it is OPTIONAL to add the header "X-pEp-Version: 1.0" when using this format: this is considered implicitly the case. The reason for that is that pEp implementers are only REQUIRED to hold users exposing "X-pEp-Version: 2.0" or higher as actual pEp users. Very ancient pEp users and not pEp users are served with this compatibiltiy format.

A modern pEp-enabled MUA, however, SHALL add the X-pEp-Version header with its highest value (preferly with value "2.1" as for pEp Email Format 2.1 {{pef-2-1}}) when producing this format, in order to announce oneself as a pEp MUA with the capability to receive and render more privacy-preserving formats. That is, upgrading both sides to modern pEp-enabled MUAs, allows them to upgrade to more privacy-enhancing formats, also protecting (more) metadata.

Please note that between pEp- and non-pEp clients subject encryption MAY be disabled, sacrificing usability (avoiding artefacts for receiving non-pEp clients) over privacy.

An example of a pEp Email Format 1.0 in its old form, which is NOT RECOMMENDED to be used anymore, looks the following:

{::include ../shared/fence-line.mkd}

{::include examples/pef-1-0_old.mkd}

{::include ../shared/fence-line.mkd}

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

{::include ../shared/fence-line.mkd}

{::include examples/pef-1-0-text-payload.mkd}

{::include ../shared/fence-line.mkd}

The newer PEF-1.0 format, which is also considered pEp's compatibility format towards non-pEp clients, looks the following:

{::include ../shared/fence-line.mkd}

{::include examples/pef-1-0_old.mkd}

{::include ../shared/fence-line.mkd}

Decrypting the enclosed "msg.msc" part yields the following:

{::include ../shared/fence-line.mkd}

{::include examples/msg-part-decrypted-compat.mkd}

{::include ../shared/fence-line.mkd}

Note that in either case, the actual subject's value is encrypted in the very first text/plain MIME entity under a multipart/mixed MIME node.

pEp Email Format 2.0

pEp Email Format 2.0 (PEF-2.0) is a strict PGP/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 is fully encapsulated by a multipart/encrypted email message. It is contained as the second node of a multipart/mixed structure.

Additional email headers can thus be fully preserved, not only encrypted, but also signed. In the outer message, however, when communicating with pEp users unneeded headers SHALL be omitted to the fullest extent possible.

Equally to PEF-1.0 (except its older version), 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".


Example PEF-2.0: pEp to pEp

pEp Message Format 2.0 is a multipart/encrypted email, signed and encrypted, as an 7bit octet stream with a filename "msg.asc", to be disposed inline. The subject is encrypted and in the "X-pEp-Version" header field version "2.0" SHALL be announced, if this is the newest pEp Email Format the pEp-enabled MUA is able to produce and render:

{::include ../shared/fence-line.mkd}

{::include examples/pef-2-0.mkd}

{::include ../shared/fence-line.mkd}

Decrypting "msg.asc" SHALL yield a multipart/mixed structure, with three elements: (1) a text part indicating this is the encapsulated message, (2) the actual RFC/822 message (with varying complexity) and (3) the transferable sender's public key in ASCII-armored format.

An unwrapped example looks like this:

{::include ../shared/fence-line.mkd}

{::include examples/msg-part-decrypted-pef-2-0.mkd}

{::include ../shared/fence-line.mkd}

Example PEF-2.0: pEp to non-pEp

From the outside, the exactly same wire format is visible as in {{pef-2-0-ex1}}, that is:

{::include ../shared/fence-line.mkd}

{::include examples/pef-2-0.mkd}

{::include ../shared/fence-line.mkd}

The decrypted "msg.asc" octet stream also is a multipart/mixed Content-Type, but immediately exposes the MIME content part(s), with the transferable sender's public key at the very end. There's no full email encapsulation, such that only the Subject header field gets protected by default.

Concretly, that "msg.asc" element, when decrypted, looks like the following:

{::include ../shared/fence-line.mkd}

{::include examples/msg-part-decrypted-compat.mkd}

{::include ../shared/fence-line.mkd}

pEp Email Format 2.1

pEp Email Format 2.1 introduces further pEp-specific header fields to the inner message, which help to determine the behaviour between pEp users.

In normal interpersonal messaging those fields are (1) an
"X-pEp-Wrapped-Message-Info: INNER" header field stating that the message carrying this is to be considered the most inner message containing the actual payload (this is particulary rellevant thinking of mixnet or other scenarios of nested messaging), X-pEp-Sender-FPR with the value set to sender's full 160-bit public key fingerprint (e.g., "1234567890ABCDEF1234567890ABCDEF12345678") and the the X-pEp-Version header field set to version "2.1".

While the message/rfc822 entity with encapsulated SHALL be the second element of a fully encrypted multipart/mixed structure (like in PEF-2.0), the first node is text/plain element, 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 at least the intended subject of the inner message, even if this is not done in current reference implementations. Like with the PEF-1.0 and PEF 2.0, the last element of the encrypted container contains the sender's public key.

An addtional caveat of the design is that the MUA display of messages with message/rfc822 entities varies considerably across different mail user agents. This is relevant in possible case a non-pEp MUA encounters a PEF-2.1 message (this is most probable to happen 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 entity is meant to blend the containing 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. As of pEp-Message-Format-2.1, a steering parameter as described in {{I-D.melnikov-iana-reg-forwarded}} is used. In chapter 3.2 a new Content-Type header field parameter with name "forwarded", for the MUA to distinguish between a forwarded message and a nested message for the purpose of header protection (i.e., using "forwarded=no").


Example PEF-2.1: pEp to pEp

This is an example of what the format looks like between two PEF-2.1-capable clients:

{::include ../shared/fence-line.mkd}

{::include examples/pef-2-1.mkd}

{::include ../shared/fence-line.mkd}

Unwrapping the "msg.asc" multipart/encrypted MIME part, yields this:

{::include ../shared/fence-line.mkd}

{::include examples/msg-part-decrypted-pef-2-1.mkd}

{::include ../shared/fence-line.mkd}

Example PEF-2.1: pEp to pEp (support version 2.0)

Please note that when the receiving peer was registered as being only PEF-2.0-capable, that a special PEF-2.1 format SHALL be sent, which in its essence is a PEF-2.0 format.

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.

On the wire, no difference is visble to example {{pef-2-1-ex1}} above:

{::include ../shared/fence-line.mkd}

{::include examples/pef-2-1.mkd}

{::include ../shared/fence-line.mkd}

The "msg.asc" part, on the other hand, looks like this:

{::include ../shared/fence-line.mkd}

{::include examples/msg-part-decrypted-pef-2-1_compat-2-0.mkd}

{::include ../shared/fence-line.mkd}

Please note that this basically is a PEF-2.0 format, but with the additional pEp-specific headers for the wrapped RFC 822 message.

This ensures interoperablity with clients which are only capable of rendering PEF-2.0.

Example PEF-2.1: pEp to non-pEp

On the wire, PEF-2.1 is identical to {{pef-2-0}} except X-pEp-Version being set to version 2.1 instead of 2.0.

{::include ../shared/fence-line.mkd}

{::include examples/pef-2-1.mkd}

{::include ../shared/fence-line.mkd}

The "msg.asc", when decrypted, looks exactly the same as in {{pef-2-0-ex1-compat}}:

{::include ../shared/fence-line.mkd}

{::include examples/msg-part-decrypted-compat.mkd}

{::include ../shared/fence-line.mkd}

Protocol Negotiation for Format Selection

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 SHALL be recorded as a pEp user.

Saving Messages

In accordance to the Privacy by Default principle, messages sent or received in encrypted form SHALL 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 archivign 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.

Key Management

Key Generation

A pEp-enabled Mail User Agent SHALL consider every email account as an new identity: for each identity, a different key pair SHALL be created automatically if no key material with sufficient length is available. By default, RSA-4096 key pairs for OpenPGP encryption {{RFC4880}} 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 keypair with less than 2048 bits, new keys MUST be generated.

Private Keys

TODO: Add here what is specific to email


TODO: Add here what is specific to email


TODO: Add here what is specific to email

Private Key Export / Import

Public Key Distribution

By default, public keys MUST always be attached to any outgoing message as described in {{pep-email-formats}}.

Key Reset

TODO: Add here what is specific to email

Trust Management

The following example roughly describes a pEp Email scenario with a typical initial message flow to demonstrate key exchange and basic trust management:

  1. Alice -- knowing nothing of Bob -- sends a 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.

  2. 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. {{trust-rating}}).

  3. 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. {{trust-rating}}).

  4. 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. {{handshake}}) and confirm this process if those match. After doing so, their identity rating changes to "encrypted and authenticated" (cf. {{trust-rating}}), 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, SHALL NOT be altered.

{::include ../shared/fence-line.mkd}

{::include ../shared/ascii-arts/basic-msg-flow.mkd}

{::include ../shared/fence-line.mkd}

TODO: Add more of what is specific to email

Privacy Status

TODO: Add here what is specific to email


TODO: Add here what is specific to email

Trust Rating

TODO: Add here what is specific to email


As per {{I-D.pep-keysync}}:

TODO: Add here what is specific to email

Private Key Synchronization

TODO: Add here what is specific to email

Trust Synchronization

TODO: Add here what is specific to email


TODO: Add here what is specific to email

Options in pEp

Option "Passive Mode"

In email, Passive Mode primarily exists as an option to avoid potential usability artefacts 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 user don't 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 SHALL only affect unencrypted communications and 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 {{pep-email-formats}}.

Additionally, Passive Mode MUST be without effect, if a receiver learns a MUA is actually pEp-capable, even if the sender involved is in Passive Mode, too: this SHALL 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

Option "Disable Protection"

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

Option "Extra Keys"

TODO: Add here what is specific to email

Option "Blacklist Keys"

TODO: Add here what is specific to email

Option "Trusted Server"

TODO: Add here what is specific to email

Security Considerations


Privacy Considerations


IANA Considerations

This document has no actions for IANA.

{::include ../shared/text-blocks/implementation-status.mkd}


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: Claudio Luck and Bernie Hoeneisen.

This work was initially created by pEp Foundation, and was initially reviewed and extended with funding by the Internet Society's Beyond the Net Programme on standardizing pEp. {{ISOC.bnet}}

--- back

Document Changelog

RFC Editor: This section is to be removed before publication

  • draft-marques-pep-email-03:

    • Major restructure of the document to align with {{I-D.birk-pep}}
    • 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
    • Add various examples of the message formats produced
  • 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

Open Issues

[[ RFC Editor: This section should be empty and is to be removed before publication ]]

  • Eventually move the many TODOs intothis Open Issues section.

  • Describe KeyImport to induce the import from secret keys from other devices

  • Describe / Reference KeySync (and other sync, through IMAP)

  • Add keypair 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.

  • Add pEp Message Format 2.1

  • Add pEp Message Format 2.x (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?)

  • Explain Key Mapping (between OpenPGP and S/MIME)