pEp Foundation

Oberer Graben 4 CH-8400 Winterthur Switzerland volker.birk@pep.foundation https://pep.foundation/

pEp Foundation

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

pEp Foundation

Oberer Graben 4 CH-8400 Winterthur Switzerland bernie.hoeneisen@pep.foundation https://pep.foundation/

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.

Secure and private communications are vital for many different reasons, and there are particular properties that privacy-preserving protocols need to fulfill in order to best serve users. In particular, has identified and documented important principles such as data minimization, the end-to-end principle, and interoperability as integral properties which enable access to Human Rights. Today’s applications widely lack privacy support that ordinary users can easily adapt. The pretty Easy privacy (pEp) protocols generally conform to the principles outlined in , and, as such, can facilitate the adoption and correct usage of secure and private communications technology. The pretty Easy privacy (pEp) protocols are propositions to the Internet community to create software for peers to automatically encrypt, anonymize (where possible), and verify their daily written digital communications. This is achieved by building upon already existing standards and tools and automating each step a user needs to carry out in order to engage in secure end-to-end encrypted communications. Significantly, the pEp protocols describe how do to this without dependence on centralized infrastructures. The pEp project emerged from the CryptoParty movement. During that time, the initiators learned that while step-by-step guides can help some users engage in secure end-to-end communications, it is both more effective and convenient for the vast majority of users if these step-by-step guides are put into running code (following a protocol), which automates the initial configuration and general usage of cryptographic tools. To facilitate this goal, pEp proposes the automation of key management, key discovery, and key synchronization through an in-band approach which follows the end-to-end principle. To mitigate man-in-the-middle attacks (MITM) by an active adversary, and as the only manual step users carry out in the course of the protocols, the proposed Trustwords mechanism uses natural language representations of two peers’ fingerprints for users to verify their trust in a paired communication channel. The privacy-by-default principles that pEp introduces are in accordance with the perspective outlined in , aiming to provide opportunistic security in the sense of “some protection most of the time”. This is done, however, with the subtle but important difference that when privacy is weighed against security, the choice defaults to privacy. Therefore, data minimization is a primary goal in pEp (e.g., hiding subject lines and headers unnecessary for email transport inside the encrypted payload of a message). The pEp propositions are focused on (but not limited to) written digital communications and cover asynchronous (offline) types of communications like email as well as synchronous (online) types such as chat. pEp’s goal is to bridge different standardized and widely-used communications channels such that users can reach communications partners in the most privacy-enhancing way possible.

While this document outlines the general design choices and principles of pEp, other related documents specialize in more particular aspects of the model, or the application of pEp on a specific protocol like as follows: pEp-enabled applications (e.g., pEp email ). Helper functions for peer interaction, which facilitate understanding and handling of the cryptographic aspects of pEp implementation for users (e.g., pEp Handshake ). Helper functions for interactions between a user’s own devices, which give the user the ability to run pEp applications on different devices at the same time, such as a computer, mobile phone, or tablets (e.g., pEp KeySync ). In addition, there are documents that do not directly depend on this one, but provide generic functions needed in pEp, e.g., IANA Registration of Trustword Lists . [[ Note: At this stage it is not yet clear to us how many of our implementation details should be part of new RFCs and where we can safely refer to already existing RFCs to clarify which RFCs we rely on. ]]

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’.

pEp’s most important goal is to ensure privacy above all else. To clarify, pEp’s protocol defaults are designed to maximize both security and privacy, but in the few cases where achieving both more privacy and more security are in conflict, pEp chooses more privacy. In contrast to pEp’s prioritization of user privacy, OpenPGP’s Web-of-Trust (WoT) releases user and trust level relationships to the public. In addition, queries to OpenPGP keyservers dynamically disclose the social graph, indicating a user’s intent to communicate with specific peers. Similar issues exist in other security protocols that rely upon a centralized trust model, such as the certificate revocation protocols used in XPKI (S/MIME). [[TODO: Fix the wording and reference to XPKI, S/MIME]]. In pEp messaging (e.g., when using HTML) content and information SHALL NOT be obtained from remote locations as this constitutes a privacy breach. Because of the inherent privacy risks in using remote or centralized infrastructures, implementations of pEp messaging, by default, SHALL NOT obtain content and information from remote or centralized locations, as this constitutes a privacy breach. In email this issue exists with HTML mails.

Data minimization keeps data spare and hides all technically concealable information whenever possible. It is an important design goal of pEp.

The proposed pEp protocols seek interoperability with established message formats, as well as cryptographic security protocols and their widespread implementations. To achieve this interoperability, pEp MUST follow Postel’s Robustness Principle outlined in : “Be liberal in what you accept, and conservative in what you send.” Particularly, pEp applies Postel’s principle as follows: pEp is conservative (strict) in requirements for pEp implementations and how they interact with pEp or other compatible implementations. pEp liberally accepts input from non-pEp implementations. For example, in email, pEp will not produce outgoing messages, but will transparently support decryption of incoming PGP/INLINE messages. Finally, where pEp requires divergence from established RFCs due to privacy concerns (e.g., from OpenPGP propositions as defined in , options SHOULD be implemented which empower the user to override pEp’s defaults.

Messaging and verification processes in pEp are designed to work in a peer-to-peer (P2P) manner, without the involvement of intermediaries. This means there MUST NOT be any pEp-specific central services whatsoever needed for pEp implementations, both in the case of verification of peers and for the actual encryption. However, implementers of pEp MAY provide options for interoperation with providers of centralized infrastructures (e.g., to enable users to communicate with their peers on platforms with vendor lock-in). Trust provided by global Certificate Authorities (e.g., commercial X.509 CAs) SHALL NOT be signaled as trustworthy (cf. ) to users of pEp (e.g., when interoperating with peers using S/MIME) by default.

Implementers of pEp MUST NOT expose users to technical terms and views, especially those specific to cryptography, like “keys”, “certificates”, or “fingerprints”. Users may explicitly opt-in to see such terms wanting seeking for more options; i.e., advanced settings MAY be available, and in some cases, these options may be required. The authors believe that widespread adoption of end-to-end cryptography is possible if users are not required to understand cryptography and key management. This belief forms the central goal of pEp, which is that users can simply rely on the principles of Privacy by Default. On the other hand, to preserve usability, users MUST NOT be required to wait for cryptographic tasks such as key generation to complete before being able to use their respective message client for its default purpose. In short, pEp implementers MUST ensure that the ability to draft, send, and receive messages is always preserved, even if that means a message is sent unencrypted, in accordance with the Opportunistic Security approach outlined in . In turn, pEp implementers MUST ensure that a distinguishable privacy status is clearly visible to the user, both on a per-contact as well as per-message level. This allows users to assess both the privacy level for the message and the trust level of its intended recipients before choosing to send it. [[ NOTE: We are aware of the fact that usually UX requirements are not part of RFCs. However, in order to encourage massive adoption of secure end-to-end encryption while at the same time avoiding putting users at risk, we believe certain straightforward signaling requirements for users to be a good idea, just as it is currently done for already-popular instant messaging services. ]]

Everyone has the right to choose how to reveal themselves to the world, both offline and online. This is an important element to maintain psychological, physical, and digital privacy. As such, pEp users MUST have the option to choose their identity, and they MUST have the ability to maintain multiple identities. These different identities MUST NOT be externally correlatable with each other by default. On the other hand, combining different identities when such information is known MUST be supported (alias support).

A user is a real world human being or a group of human beings. If it is a single human being, it can be called person. A user is identified by a user ID (user_id). The user_id SHOULD be a UUID, it MAY be an arbitrary unique string. The own user can have a user_id like all other users. If the own user does not have a user_id, then it is assigned a “pEp_own_userId” instead. A user can have a default key. [[ TODO: Provide ref explaining this. ]]

A pEp address is a network address, e.g., an SMTP address or another Universal Resource Identifier (URI). [[ Note: It might be necessary to introduce further addressing schemes through IETF contributions or IANA registrations, e.g., implementing pEp to bridge to popular messaging services with no URIs defined. ]]

A key is an OpenPGP-compatible asymmetric cryptographic key pair. Keys in pEp are identified by the full fingerprint (fpr) of the public key. The fingerprint is to be obtained from the specific cryptographic service used to handle the keys. The canonical representation in pEp is upper-case hexadecimal with zero-padding and no separators or spaces.

An identity is a representation of a user, encapsulating how this user appears within the network of a messaging system. This representation may or may not be pseudonymous in nature. An identity is defined by mapping a user_id to an address. If no user_id is known, it is guessed by mapping a username to an address. An identity can have a temporary user_id as a placeholder until a real user_id is known. In pEp a different key pair for each (e.g., email) account MUST be created. This allows a user to retain different identities, which are not correlated by the usage of the same key for all of those. This is beneficial in terms of privacy. A user MAY have a default key; each identity a user has MAY have a default key (of its own). When both an Identity and the related User have a default key set, the Identity’s default key MUST override the User’s default key. [[ TODO: Provide ref explaining this. ]] In , the definition of a pEp identity can be found according to the reference implementation by the pEp engine.

In order to achieve the goal of widespread adoption of secure communications, key management in pEp MUST be automated.

A pEp implementation MUST ensure that cryptographic keys for every configured identity are available. If a corresponding key pair for the identity of a user is found and said identity fulfills the requirements (e.g., for email, as set out in ), said key pair MUST be reused. Otherwise a new key pair MUST be generated. This may be carried out instantly upon its configuration. On devices with limited processing power (e.g., mobile devices) the key generation may take more time than a user is willing to wait. If this is the case, users SHOULD NOT be stopped from communicating, i.e., the key generation process SHOULD be carried out in the background.

Private keys in pEp implementations MUST always be held on the end user’s device(s): pEp implementers MUST NOT rely on private keys stored in centralized remote locations. This applies even for key storages where the private keys are protected with sufficiently long passphrases. It is considered a violation of pEp’s P2P design principle to rely on centralized infrastructures (cf. ). This also applies for pEp implementations created for applications not residing on a user’s device (e.g., web-based MUAs). In such cases, pEp implementations MUST be done in a way such that the locally-held private key can neither be directly accessed nor leaked to the outside world. [[ Note: It is particularly important that browser add-ons implementing pEp functionality do not obtain their cryptographic code from a centralized (cloud) service, as this must be considered a centralized attack vector allowing for backdoors, negatively impacting privacy. ]] Cf. for a means to synchronize private keys among different devices of the same network address in a secure manner.

Passphrases to protect a user’s private key MUST be supported by pEp implementations, but MUST NOT be enforced by default. That is, if a pEp implementation finds a suitable (i.e., secure enough) cryptographic setup, which uses passphrases, pEp implementations MUST provide a way to unlock the key. However, if a new key pair is generated for a given identity, no passphrase MUST be put in place. The authors assume that the enforcement of secure (i.e., unique and long enough) passphrases would massively reduce the number of pEp users (by hassling them), while providing little to no additional privacy for the common cases of passive monitoring being carried out by corporations or state-level actors.

As the key is available (cf. ) implementers of pEp are REQUIRED to ensure that the identity’s public key is attached to every outgoing message. However, this MAY be omitted if the peer has previously received a message encrypted with the public key of the sender. The sender’s public key SHOULD be sent encrypted whenever possible, i.e., when a public key of the receiving peer is available. If no encryption key of the recipient is available, the sender’s public key MAY be sent unencrypted. In either case, this approach ensures that messaging clients (e.g., MUAs that at least implement OpenPGP) do not need to have pEp implemented to see a user’s public key. Such peers thus have the chance to (automatically) import the sender’s public key. If there is already a known public key from the sender of a message and it is still valid and not expired, new keys MUST NOT be used for future communication unless they are signed by the previous key (to avoid a MITM attack). Messages MUST always be encrypted with the receiving peer’s oldest public key, as long as it is valid and not expired.

Implementers of pEp SHALL prevent the display of public keys attached to messages (e.g, in email) to the user in order to prevent user confusion by files they are potentially unaware of how to handle.

Metadata, such as email headers, MUST NOT be added in order to announce a user’s public key. This is considered unnecessary information leakage, may affect user privacy, and may be subject to a country’s data retention laws (cf. ). Furthermore, this may affect interoperability to existing users that have no knowledge of such header fields, such as users of OpenPGP in email, and lose the ability to import any keys distributed in this way as a result. The ability to extract and receive public keys from such metadata SHOULD be supported, however, in the event these approaches become widespread.

Keyservers or generally intermediate approaches to obtain a peer’s public key SHALL NOT be used by default. On the other hand, the user MAY be provided with the option to opt-in for remote locations to obtain keys, considering the widespread adoption of such approaches for key distribution. Keys generated or obtained by pEp clients MUST NOT be uploaded to any (intermediate) keystore locations without the user’s explicit consent.

The following example roughly describes a pEp scenario with a typical initial message flow to demonstrate key exchange and basic trust management: The following example describes a pEp scenario between two users – Alice and Bob – in order to demonstrate the message flow that occurs when exchanging keys and determining basic trust management for the first time: Alice – knowing nothing of Bob – sends a message to Bob. As Alice has no public key from Bob, this message is sent out unencrypted. However, Alice’s public key is automatically attached. Bob receives Alice’s message and her public key. He is able to reply to her and encrypt the message. His public key is automatically attached to the message. Because he has her public key now, Alice’s rating in his message client changes to ‘encrypted’. From a UX perspective, this status is displayed in yellow (cf. ). Alice receives Bob’s key. As of now Alice is also able to send secure messages to Bob. The rating for Bob changes to “encrypted” (with yellow color) in Alice’s messaging client (cf. ). Alice receives Bob’s reply with his public key attached. Now, Alice can send secure messages to Bob as well. The rating for Bob changes to yellow, or ‘encrypted’, in Alice’s messaging client . 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. See also . Alice and Bob can encrypt now, but they are not yet authenticated, leaving them vulnerable to man-in-the-middle (MitM) attacks. To prevent this from occurring, Alice and Bob can engage in a pEp Handshake to compare their Trustwords (cf. ) and confirm if they match. After this step is performed, their respective identity ratings change to “encrypted and authenticated”, which is represented by a green color (cf. .

| | | | +-----------------------+ | | 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: This section will explain how to deal with invalid keys, e.g., if expired or (potentially) leaked. ]]

[[ TODO: Intro ]]

The trust status for an identity can change due to a number of factors. These shifts will cause the color code assigned to this identity to change accordingly, and is applied to future communications with this identity. For end-users, the most important component of pEp, which MUST be made visible on a per-recipient and per-message level, is the Privacy Status. By colors, symbols and texts a user SHALL immediately understand how private a communication channel with a given peer was or ought to be and a given message was or ought to be.

To establishing trust between peers and to upgrade Privacy Status, pEp defines a handshake, which is specified in . In pEp, Trustwords are used for users to compare the authenticity of peers in order to mitigate MITM attacks. By default, Trustwords MUST be used to represent two peers’ fingerprints of their public keys in pEp implementations. In order to retain compatibility with peers not using pEp implementations (e.g., Mail User Agents (MUAs) with OpenPGP implementations without Trustwords), it is REQUIRED that pEp implementers give the user the choice to show both peers’ fingerprints instead of just their common Trustwords.

pEp includes a Trust Rating system defining Rating and Color Codes to express the Privacy Status of a peer or message . The ratings are labeled, e.g., as “Unencrypted”, “Encrypted”, “Trusted”, “Under Attack”, etc. The Privacy Status in its most general form is expressed with traffic lights semantics (and respective symbols and texts), whereas the three colors yellow, green and red can be applied for any peer or message – like this immediately indicating how secure and trustworthy (and thus private) a communication was or ought to be considered. The pEp Trust Rating system with all its states and respective representations to be followed is outlined in . Note: An example for the rating of communication types, the definition of the data structure by the pEp Engine reference implementation is provided in .

[[ TODO: This section will explain how to deal with the situation when a peer can no longer be trusted, e.g., if a peer’s device is compromised. ]]

An important feature of pEp is to assist the user to run pEp applications on different devices, such as personal computers, mobile phones and tablets, at the same time. Therefore, state needs to be synchronized among the different devices.

The pEp KeySync protocol (cf. ) is a decentralized proposition which defines how pEp users can distribute their private keys among their different devices in a user-authenticated manner. This allows users to read their messages across their various devices, as long as they share a common address, such as an email account.

[[ TODO: This section will explain how trust and other related state is synchronized among different devices in a user-authenticated manner. ]]

pEp aims to be interoperable with existing applications designed to enable privacy, e.g., OpenPGP and S/MIME in email.

In this section a non-exhaustive selection of options is provided.

By default, the sender attaches its public key to any outgoing message (cf. ). For situations where a sender wants to ensure that it only attaches a public key to an Internet user which has a pEp implementation, a Passive Mode MUST be made available.

Using this option, protection can be disabled generally or selectively. Implementers of pEp MUST provide an option “Disable Protection” to allow a user to disable encryption and signing for: all communication specific contacts specific messages The public key still attached, unless the option “Passive Mode” (cf. ) is activated at the same time.

For internal or enterprise environments, authorized personnel may need to centrally decrypt user messages for archival or other legal purposes. Therefore, pEp implementers MAY provide an “Extra Keys” option in which a message is encrypted with at least one additional public key. The corresponding secret key(s) are intended to be secured by CISO staff or other authorized personnel for the organization. However, it is crucial that the “Extra Keys” feature MUST NOT be activated by default for any network address, and is intended to be an option used only for organization-specific identities, as well as their corresponding network addresses and accounts. The “Extra Keys” feature SHOULD NOT be applied to the private identities, addresses, or accounts a user might possess once it is activated.

The “Extra Keys” feature also plays a role during pEp’s KeySync protocols, where the additional keys are used to decipher message transactions by both parties involved during the negotiation process for private key synchronization. During the encrypted (but untrusted) transactions, KeySync messages are not just encrypted with the sending device’s default key, but also with the default keys of both parties involved in the synchronization process.

A “Blacklist Keys” option MAY be provided for an advanced user, allowing them to disable keys of peers that they no longer want to use in new communications. However, the keys SHALL NOT be deleted. It MUST still be possible to verify and decipher past communications that used these keys.

By attaching the sender’s public key to outgoing messages, Trust on First Use (TOFU) is established. However, this is prone to MITM attacks. Cryptographic key subversion is considered Pervasive Monitoring (PM) according to . Those attacks can be mitigated, if the involved users compare their common Trustwords. This possibility MUST be made easily accessible to pEp users in the user interface implementation. If for compatibility reasons (e.g., with OpenPGP users) no Trustwords can be used, then a comparatively easy way to verify the respective public key fingerprints MUST be implemented. As the use of passphrases for private keys is not advised, devices themselves SHOULD use encryption.

[[ 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.

The pEp Foundation provides a reference implementation of pEp’s core principles and functionalities, which go beyond the documentation status of this Internet-Draft. pEp’s reference implementation is composed of pEp Engine and pEp Adapters (or bindings), alongside with some libraries which pEp Engine relies on to function on certain platforms (like a NetPGP fork we maintain for the iOS platform). The pEp engine is a Free Software library encapsulating implementations of: Key Management Key Management in pEp engine is based on GnuPG key chains (NetPGP on iOS). Keys are stored in an OpenPGP compatible format and can be used for different crypto implementations. Trust Rating pEp engine is sporting a two phase trust rating system. In phase one there is a rating based on channel, crypto and key security named “comm_types”. In phase 2 these are mapped to user representable values which have attached colors to present them in traffic light semantics. Abstract Crypto API The Abstract Crypto API is providing functions to encrypt and decrypt data or full messages without requiring an application programmer to understand the different formats and standards. Message Transports pEp engine will support a growing list of Message Transports to support any widespread text messaging system including email, SMS, XMPP and many more. pEp engine is written in C99 programming language. It is not meant to be used in application code directly. Instead, pEp engine is coming together with a list of software adapters for a variety of programming languages and development environments, which are: pEp COM Server Adapter pEp JNI Adapter pEp JSON Adapter pEp ObjC (and Swift) Adapter pEp Python Adapter pEp Qt Adapter

A selection of code excerpts from the pEp Engine reference implementation (encrypt message, decrypt message, and obtain trustwords) can be found in .

The pEp logo and “pretty Easy privacy” are registered trademarks owned by the non-profit pEp Foundation based in Switzerland. Primarily, we want to ensure the following: Software using the trademarks MUST be backdoor-free. Software using the trademarks MUST be accompanied by a serious (detailed) code audit carried out by a reputable third-party, for any proper release. The pEp Foundation will help to support any community-run (non-commercial) project with the latter, be it organizationally or financially. Through this, the foundation wants to make sure that software using the pEp trademarks is as safe as possible from a security and privacy point of view.

The authors would like to thank the following people who provided substantial contributions, helpful comments or suggestions for this document: Alexey Melnikov, Athena Schumacher, Ben Campbell, Brian Trammell, Bron Gondwana, Claudio Luck, Daniel Kahn Gillmor, Enrico Tomae, Eric Rescorla, Gabriele Lenzini, Hans-Peter Dittler, Iraklis Symeonidis, Kelly Bristol, Krista Bennett, Mirja Kuehlewind, Nana Kerlstetter, Neal Walfield, Pete Resnick, Russ Housley, S. Shelburn, and Stephen Farrel. This work was initially created by pEp Foundation, and then reviewed and extended with funding by the Internet Society’s Beyond the Net Programme on standardizing pEp.

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 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. 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 RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [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] Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. 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. This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed.This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group. 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 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. 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 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). 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 unsecure. The pEp KeySync protocol is designed to facilitate this personal key synchronization in a user-friendly manner.

This section provides excerpts of the running code from the pEp reference implementation pEp engine (C99 programming language).

How the pEp identity is defined in the data structure (cf. src/pEpEngine.h):

Relational table scheme excerpts (in SQL) used in current pEp implementations, held locally for every pEp installation in a SQLite database:

In the following, is an example for the rating of communication types as defined by a data structure (cf. src/pEpEngine.h ):

The following code excerpts are from the pEp Engine reference implementation, to be found in src/message_api.h. [[ Note: Just a selection; more functionality is available. ]]

Cf. src/message_api.h :

Cf. src/message_api.h :

Cf. src/message_api.h :

Cf. src/message_api.h :

[[ RFC Editor: This section is to be removed before publication ]] draft-birk-pep-06: Minor changes draft-birk-pep-05: Change authors Minor changes, especially in identity system draft-birk-pep-04: Fix internal reference Add IANA Considerations section Add other use case of Extra Keys Add Claudio Luck as author Incorporate review changes by Kelly Bristol and Nana Karlstetter draft-birk-pep-03: Major restructure of the document Adapt authors to the actual authors and extend Acknowledgments section Added several new sections, e.g., Key Reset, Trust Revoke, Trust Synchronization, Private Key Export / Import, Privacy Considerations (content yet mostly TODO) Added reference to HRPC work / RFC8280 Added text and figure to better explain pEp’s automated Key Exchange and Trust management (basic message flow) Lots of improvement in text and editorial changes draft-birk-pep-02: Move (updated) code to Appendix Add Changelog to Appendix Add Open Issue section to Appendix Fix description of what Extra Keys are Fix Passive Mode description Better explain pEp’s identity system draft-birk-pep-01: Mostly editorial draft-birk-pep-00: Initial version

[[ RFC Editor: This section should be empty and is to be removed before publication ]] Shorten Introduction and Abstract References to RFC6973 (Privacy Considerations) Add references to prior work, and what differs here - PEM (cf. RFC1421-1424) Better explain Passive Mode Better explain / illustrate pEp’s identity system Explain Concept of Key Mapping (e.g. to S/MIME, which is to be refined in pEp application docs auch as pEp email ) Add more information to deal with organizational requirements Add text to Key Reset () as well as reference as soon as available Add text to Trust Revoke () as well as reference as soon as available Add text to Trust Synchronization () as well as reference as soon as available Add text to Privacy Considerations () Scan for leftovers of email-specific stuff and move it to pEp email I-D , while replacing it herein with generic descriptions.