< draft-birk-pep-02.txt   draft-birk-pep-03.txt >
Network Working Group V. Birk Network Working Group H. Marques
Internet-Draft H. Marques Internet-Draft pEp Foundation
Intended status: Standards Track S. Shelburn Intended status: Standards Track B. Hoeneisen
Expires: December 29, 2018 pEp Foundation Expires: September 8, 2019 Ucom.ch
June 27, 2018 March 07, 2019
pretty Easy privacy (pEp): Privacy by Default pretty Easy privacy (pEp): Privacy by Default
draft-birk-pep-02 draft-birk-pep-03
Abstract Abstract
Building on already available security formats and message transports The pretty Easy privacy (pEp) protocols describe a set of conventions
(like PGP/MIME for email), and with the intention to stay for the automation of operations traditionally seen as barriers to
interoperable to systems widespreadly deployed, pretty Easy privacy the use and deployment of secure end-to-end interpersonal messaging.
(pEp) describes protocols to automatize operations (key management, These include, but are not limited to, key management, key discovery,
key discovery, private key handling including peer-to-peer and private key handling (including peer-to-peer synchronization of
synchronization of private keys and other user data across devices) private keys and other user data across devices). pEp also introduces
that have been seen to be barriers to deployment of end-to-end secure means to verify communication peers and proposes a trust-rating
interpersonal messaging. pEp also relies on "Trustwords" (as a word system to denote secure types of communications and signal the
mapping of of fingerprints) to verify communication peers and privacy level available on a per-user and per-message level.
proposes a trust rating system to denote secure types of Significantly, the pEp protocols build on already available security
communications and signal the privacy level available on a per-user formats and message transports (e.g., PGP/MIME), and are written with
and per-message level. In this document, the general design choices the intent to be interoperable with already widely-deployed systems
and principles of pEp are outlined. in order to facilitate and ease adoption and implementation. This
document outlines the general design choices and principles of pEp.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2018. This Internet-Draft will expire on September 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Relationship to other pEp documents . . . . . . . . . . . 5
3. Protocol's Core Design Principles . . . . . . . . . . . . . . 4 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Privacy by Default . . . . . . . . . . . . . . . . . . . 4 3. Protocol's Core Design Principles . . . . . . . . . . . . . . 6
3.2. Interoperability . . . . . . . . . . . . . . . . . . . . 5 3.1. Privacy by Default . . . . . . . . . . . . . . . . . . . 6
3.3. Peer-to-Peer (P2P) . . . . . . . . . . . . . . . . . . . 5 3.2. Data Minimization . . . . . . . . . . . . . . . . . . . . 6
3.4. User Experience (UX) . . . . . . . . . . . . . . . . . . 6 3.3. Interoperability . . . . . . . . . . . . . . . . . . . . 6
4. pEp identity system . . . . . . . . . . . . . . . . . . . . . 6 3.4. Peer-to-Peer (P2P) . . . . . . . . . . . . . . . . . . . 7
4.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. User Experience (UX) . . . . . . . . . . . . . . . . . . 7
4.1.1. Key . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Specific Elements in pEp . . . . . . . . . . . . . . . . . . 8
4.1.2. User . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. pEp identity system . . . . . . . . . . . . . . . . . . . 8
4.1.3. Address . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Key . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Example: Difference between pEp and OpenPGP . . . . . . . 8 4.2.2. User . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Key Management . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.3. Identity . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Private Keys . . . . . . . . . . . . . . . . . . . . . . 9 4.2.4. Address . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Public Key Distribution . . . . . . . . . . . . . . . . . 9 4.3. Example: Difference between pEp and OpenPGP . . . . . . . 9
5.3. Passphrases . . . . . . . . . . . . . . . . . . . . . . . 10 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . 10
6. Privacy Status . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 10
7. Options in pEp . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Private Keys . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Option "Passive Mode" . . . . . . . . . . . . . . . . . . 11 5.2.1. Storage . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Option "Disable Protection" . . . . . . . . . . . . . . . 11 5.2.2. Passphrase . . . . . . . . . . . . . . . . . . . . . 11
7.2.1. For all communications . . . . . . . . . . . . . . . 11 5.2.3. Private Key Export / Import . . . . . . . . . . . . . 11
7.2.2. For some communications . . . . . . . . . . . . . . . 11 5.3. Public Key Distribution . . . . . . . . . . . . . . . . . 11
7.3. Option "Extra Keys" . . . . . . . . . . . . . . . . . . . 12 5.4. Key Reset . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Option "Blacklist Keys" . . . . . . . . . . . . . . . . . 12 6. Trust Management . . . . . . . . . . . . . . . . . . . . . . 12
7.5. Establishing trust between peers . . . . . . . . . . . . 12 6.1. Privacy Status . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.2. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 6.3. Trust Rating . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 13 6.4. Trust Revoke . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Reference implementation of pEp's core . . . . . . . . . 13 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 16
9.3. Abstract Crypto API examples . . . . . . . . . . . . . . 14 7.1. Private Key Synchronization . . . . . . . . . . . . . . . 16
9.4. Current software implementing pEp . . . . . . . . . . . . 15 7.2. Trust Synchronization . . . . . . . . . . . . . . . . . . 16
10. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Interoperability . . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Options in pEp . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Option "Passive Mode" . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Option "Disable Protection" . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 16 9.3. Option "Extra Keys" . . . . . . . . . . . . . . . . . . . 17
Appendix A. Excerpts from the pEp Reference Implementation . . . 18 9.4. Option "Blacklist Keys" . . . . . . . . . . . . . . . . . 17
A.1. pEp Identity . . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
A.1.1. Corresponding SQL . . . . . . . . . . . . . . . . . . 19 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
A.2. pEp Communication Type . . . . . . . . . . . . . . . . . 20 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
A.3. Abstract Crypto API examples . . . . . . . . . . . . . . 21 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 18
A.3.1. Encrypting a Message . . . . . . . . . . . . . . . . 21 12.2. Current software implementing pEp . . . . . . . . . . . 18
A.3.2. Decrypting a Message . . . . . . . . . . . . . . . . 22 12.3. Reference implementation of pEp's core . . . . . . . . . 19
A.3.3. Obtain Common Trustwords . . . . . . . . . . . . . . 24 12.4. Abstract Crypto API examples . . . . . . . . . . . . . . 20
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 24 13. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 25 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . 21
15.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Code Excerpts . . . . . . . . . . . . . . . . . . . 23
A.1. pEp Identity . . . . . . . . . . . . . . . . . . . . . . 23
A.1.1. Corresponding SQL . . . . . . . . . . . . . . . . . . 24
A.2. pEp Communication Type . . . . . . . . . . . . . . . . . 25
A.3. Abstract Crypto API examples . . . . . . . . . . . . . . 26
A.3.1. Encrypting a Message . . . . . . . . . . . . . . . . 26
A.3.2. Decrypting a Message . . . . . . . . . . . . . . . . 27
A.3.3. Obtain Common Trustwords . . . . . . . . . . . . . . 29
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 29
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
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, [RFC8280] has identified and documented important
principles such as data minimization, the end-to-end principle, and
interoperability as integral properties for access to the Internet
for human rights purposes. While (partial) implementations of these
concepts are already available, today's applications widely lack
privacy support that ordinary users can easily handle. The pretty
Easy privacy (pEp) protocols generally conform with the principles
outlined in [RFC8280] as a matter of course, and as such can be used
to facilitate the adoption and correct usage of secure and private
communications technology.
The pretty Easy privacy (pEp) protocols are propositions to the The pretty Easy privacy (pEp) protocols are propositions to the
Internet community to create software for peers to automatically Internet community to create software for peers to automatically
encrypt, anonymize (where possible, depending on the message encrypt, anonymize (where possible), and verify their daily written
transport used) and verify their daily written digital communications digital communications. This is achieved by building upon already
- this is done by building upon already existing standards and tools existing standards and tools and automating each step a user needs to
and automatizing all steps a user would need to carry out to engage carry out in order to engage in secure end-to-end encrypted
in secure end-to-end encrypted communications without depending on communications. Significantly, the pEp protocols describe how do to
centralized infrastructures. this without dependence on centralized infrastructures.
Particularly, pEp proposes to automatize key management, key In particular, pEp proposes automatation of key management, key
discovery and also synchronization of secret key material by an in- discovery and synchronization of secret key material by an in-band
band peer-to-peer approach. peer-to-peer approach.
To mitigate Man-In-The-Middle Attacks (MITM) and as the only manual To mitigate man-in-the-middle attacks (MITM) by an active adversary,
step users may carry out, Trustwords [I-D.birk-pep-trustwords] as and as the only manual step users carry out in the course of the
natural language representations of two peers' fingerprints are protocols, the proposed Trustwords [I-D.birk-pep-trustwords]
proposed, for peers to put trust on their communication channel. mechanism uses natural language representations of two peers'
fingerprints for users to verify their trust in a paired
communication channel.
[[ Note: The pEp initiators had to learn from the CryptoParty [[ Note: The pEp initiators learned from the CryptoParty movement,
movement, from which the project emerged, that step-by-step guides from which the project emerged, that while step-by-step guides can be
can be helpful to a particular set of users to engage in secure end- helpful for some users to engage in secure end-to-end communications,
to-end communications, but that for a much major fraction of users it for the vast majority of users, it is both more effective and more
would be more convenient to have the step-by-step procedures put into convenient to have these step-by-step procedures put into actual code
actual code (as such, following a protocol) and thus automatizing the (as such, following a protocol) and thus automating the initial
initial configuration and whole usage of cryptographic tools.]] configuration and whole usage of cryptographic tools.]]
The Privacy by Default principles that pretty Easy privacy (pEp) The privacy-by-default principles that pEp introduces are in
introduces, are in accordance with the perspective outlined in accordance with the perspective outlined in [RFC7435], aiming to
[RFC7435] to bring Opportunistic Security in the sense of "some provide opportunistic security in the sense of "some protection most
protection most of the time", with the subtle, but important of the time". This is done, however, with the subtle but important
difference that when privacy is weighted against security, the choice difference that when privacy is weighed against security, the choice
falls to privacy. Therefore, data minimization is a primary goal in defaults to privacy. Therefore, data minimization is a primary goal
pEp (e.g., omitting unnecessary email headers and encrypting the in pEp (e.g., hiding subject lines and headers unnecessary for email
subject line). transport inside the encrypted payload of a message).
The pEp propositions are focused on (but not limited to) written The pEp propositions are focused on (but not limited to) written
digital communications and cover asynchronous (offline) types of digital communications and cover asynchronous (offline) types of
communications like email as well as synchronous (online) types such communications like email as well as synchronous (online) types such
as chat. as chat.
pEp's goal is to bridge the different standardized and/or widely pEp's goal is to bridge different standardized and widely-used
spread communications channels, such that users can reach their peers communications channels such that users can reach communications
in the most privacy-enhancing way possible. partners in the most privacy-enhancing way possible.
[[At this stage it is not year clear to us how many of our 1.1. Relationship to other pEp documents
While this document describes the general concept of pEp, other
documents build on top of this. These documents define other parts
of the pEp environment as follows:
1. pEp enhanced applications (e.g., pEp Email
[I-D.marques-pep-email]).
2. Helper functions for interaction with peers (e.g., pEp Handshake
[I-D.marques-pep-handshake]) that assist the user with handling
and understanding cryptographic parts that he/she needs to be
aware of.
3. Helper functions for interactions between a user's own devices
(e.g., pEp Key Sync [E-D.birk-pep-keysync]) that assist the user
to run pEp applications on different devices (such as computer,
mobile phone or tables) at the same time.
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 [I-D.birk-pep-trustwords].
[[At this stage it is not yet clear to us how many of our
implementation details should be part of new RFCs and at which places implementation details should be part of new RFCs and at which places
we can safely refer to already existing RFCs to make clear on which we can safely refer to already existing RFCs to make clear on which
RFCs we are already relying.]] RFCs we already rely.]]
2. Terms 2. Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
o Handshake: The process when Alice - e.g. in-person or via phone - o pEp Handshake: The process when Alice - e.g., in-person or via
contacts Bob to verify Trustwords (or by fallback: fingerprints) phone - contacts Bob to verify Trustwords (or by fallback:
is called handshake. [E-D.birk-pep-handshake] fingerprints) is called pEp Handshake.
[I-D.marques-pep-handshake]
o Trustwords: A scalar-to-word representation of 16-bit numbers (0 o Trustwords: A scalar-to-word representation of 16-bit numbers (0
to 65535) to natural language words. When doing a handshake, to 65535) to natural language words. When doing a Handshake,
peers are shown combined Trustwords of both public keys involved peers are shown combined Trustwords of both public keys involved
to ease the comparison. [I-D.birk-pep-trustwords] to ease the comparison. [I-D.birk-pep-trustwords]
o Trust on First Use (TOFU): cf. [RFC7435] o Trust on First Use (TOFU): cf. [RFC7435]
o Man-in-the-middle attack (MITM): cf. [RFC4949] o Man-in-the-middle attack (MITM): cf. [RFC4949]
3. Protocol's Core Design Principles 3. Protocol's Core Design Principles
3.1. Privacy by Default 3.1. Privacy by Default
The pEp protocols are about to ensure privacy. However, there are The pEp protocols are to intended specifically to ensure privacy.
cases where privacy and security are contradicting, e.g., in PGP's There exist cases in the secure communications ecosystem, however,
Web of Trust, because relations between people and trust levels are where achieving privacy is in direct contradiction to security
leaked. Also query privacy is not ensured in such a model when though. For instance, in PGP's Web of Trust, relations between
obtaining keys from remote locations. Whenever security and privacy people and trust levels are exposed to the public. Additionally, the
fit together, highest security and privacy is to be reached. privacy of queries is not ensured in such a model when obtaining keys
However, where they contradict each other, privacy is always to be from remote locations. Within the pEp protocols, when security and
chosen over security. Though, users SHOULD have the choice to privacy goals are not in conflict, then the protocols are designed to
override the default by corresponding options. maximize both security and privacy. However, where they contradict
each other, privacy goals are chosen as the default over security
considerations. However, in implementing these protocols, it is
always the case that users SHOULD have the choice to override the
default by corresponding options.
In pEp messaging (e.g., when using HTML) content SHALL NOT be In pEp messaging (e.g., when using HTML) content SHALL NOT be
obtained from remote locations as this constitutes a privacy breach. obtained from remote locations as this constitutes a privacy breach.
3.2. Interoperability 3.2. Data Minimization
The pEp propositions seek to be interoperable with message formats Another important design goal is data minimization, which includes
and cryptography already widespread. Seamless communication between data spareness and hiding all technically concealable information
users of software, which implements pEp and other messaging tools for when possible.
end-to-end encryption, is a design goal.
Therefore: 3.3. Interoperability
o Be conservative (strict) in requirements for pEp implementations The pEp propositions seek to be interoperable with already-widespread
and how they behave between each other. message formats and cryptographic protocols and implementations.
Seamless communication between users of software which implements pEp
and and users of other messaging tools for end-to-end encryption is a
design goal.
o Be liberal (accepting) in what comes in from non-pEp Therefore, pEp abides by the following guidelines:
implementations (e.g., do not send, but support to decipher PGP/
INLINE formats).
o Where pEp requires diverging from an RFC for privacy reasons o pEp is conservative (strict) in requirements for pEp
implementations and how they interact with pEp or other
(messaging) implementations.
o pEp is liberal in accepting input from non-pEp implementations
(e.g., it will not produce, but will support the decryption of,
PGP/INLINE formats).
o Where pEp requires divergence from an RFC for privacy reasons
(e.g., from OpenPGP propositions as defined in [RFC4880], options (e.g., from OpenPGP propositions as defined in [RFC4880], options
SHOULD be implemented to empower the user to comply to practices SHOULD be implemented to empower the user to override pEp's
already (widespreadly) used (either at contact level or globally). defaults.
3.3. Peer-to-Peer (P2P) 3.4. Peer-to-Peer (P2P)
Messaging and verification processes in pEp are designed to work Messaging and verification processes in pEp are designed to work in a
Peer-to-Peer (P2P) without intermediaries in between. peer-to-peer (P2P) manner, without the involvement of intermediaries.
This means, there MUST NOT be any pEp-specific central services This means there MUST NOT be any pEp-specific central services
whatsoever needed for implementers of pEp to rely on, neither for whatsoever needed for pEp implementations, both in the case of
verification of peers nor for the actual encryption. verification of peers and for the actual encryption.
Still, implementers of pEp MAY provide options to interoperate with However, implementers of pEp MAY provide options for interoperation
providers of centralized infrastructures (e.g., to enable users to with providers of centralized infrastructures (e.g., to enable users
communicate with their peers on platforms with vendor lock-in). to communicate with their peers on platforms with vendor lock-in).
Trust provided by global Certificate Authorities (e.g., commercial Trust provided by global Certificate Authorities (e.g., commercial
X.509 CAs) SHALL NOT be signaled as trustworthy (cf. X.509 CAs) SHALL NOT be signaled as trustworthy (cf.
[E-D.birk-pep-trust-rating]) to users of pEp (e.g., when [I-D.marques-pep-rating]) to users of pEp (e.g., when interoperating
interoperating with peers using S/MIME) by default. with peers using S/MIME) by default.
3.4. User Experience (UX) 3.5. User Experience (UX)
Implementers of pEp MUST take special care not to confuse users with Implementers of pEp MUST take special care not to confuse users with
technical terms, especially those of cryptography (e.g., "keys", technical terms, especially those of cryptography (e.g., "keys",
"certificates" or "fingerprints"), unless users explicitly ask for "certificates" or "fingerprints"), unless users explicitly ask for
such terms; i.e., advanced settings MAY be available, in some cases such terms; i.e., advanced settings MAY be available, and in some
further options may even be required. However, those SHALL NOT be cases further options may even be required. However, those SHALL NOT
unnecessarily exposed to users of pEp implementations at the first be unnecessarily exposed to users of pEp implementations at first
sight. glance.
The authors believe widespread adoption of end-to-end cryptography is The authors believe widespread adoption of end-to-end cryptography is
much less of an issue, if the users are not hassled and visibly much less of a problem if the users are not confronted with the need
forced in any way to use cryptography, i.e., a goal of pEp is that to understand cryptography; that is to say, a central goal of pEp of
users can just rely on the principles of Privacy by Default. the pEp protocol is that users can just rely on the principles of
Privacy by Default.
By consequence, this means that users must not wait for cryptographic As a consequence, this means that users must not wait for
tasks (e.g., key generation or public key retrieval) to finish, cryptographic tasks (e.g., key generation or public key retrieval) to
before being able to have their respective message clients ready to finish before being able to have their respective message clients
communicate. This finally means, pEp implementers MUST ensure that ready to communicate. The end result of this is that pEp
the ability to draft, send and receive messages is always preserved - implementers MUST ensure that the ability to draft, send and receive
even if that means a message is sent out unencrypted, thus being in messages is always preserved - even if that means a message is sent
accordance with the Opportunistic Security approach outlined in out unencrypted, thus being in accordance with the Opportunistic
[RFC7435]. Security approach outlined in [RFC7435].
In turn, pEp implementers MUST ensure a Privacy Status is clearly In turn, pEp implementers MUST ensure that a discernible privacy
visible to the user - on contact as well as on message level - so status is clearly visible to the user - on a per-contact as well as
that users easily understand, which level of privacy messages are per-message level - so that users easily understand which level of
about to be sent or were received with, respectively. privacy messages are about to be sent with or were received with,
respectively.
[[Note: We are aware of the fact that usually UX requirements are not [[Note: We are aware of the fact that usually UX requirements are not
part of RFCs. However, to have massively more people engaged in part of RFCs. However, in order to encourage massive adoption of
secure end-to-end encryption and at the same time to avoid putting secure end-to-end encryption while at the same time avoiding putting
users at risk, we believe requiring certain straightforward signaling users at risk, we believe certain straightforward signaling
for the users to be a good idea - in a similar way as this happens to requirements for users to be a good idea, just as is currently done
be the case for already popular Instant Messaging services.]] for already-popular instant messaging services.]]
4. pEp identity system 4. Specific Elements in pEp
In pEp, users MUST have the possibility to have different identities. 4.1. pEp identity system
In pEp, users MUST have the ability to have multiple different
identities.
pEp users MUST have the option to choose different identities. This pEp users MUST have the option to choose different identities. This
allows an Internet user to decide how to reveal oneself to the world allows an Internet user to decide how to reveal himself/herself to
and is an important element to achieve privacy. the world and is an important element in order to achieve privacy.
The different identities MUST NOT correlate with other by default. These different identities MUST NOT be externally correlatable with
On the other hand, combining different identities MUST be supported each other by default. On the other hand, combining different
(to support aliases). identities when such information is known MUST be supported (alias
support).
4.1. Terms 4.2. Identifiers
4.1.1. Key 4.2.1. Key
A key is an OpenPGP compatible asymmetric key pair. Other formats A key is an OpenPGP-compatible asymmetric key pair. Other formats
and temporary symmetrical keys can be generated by Key Mapping. and temporary symmetrical keys can be generated by Key Mapping.
Keys in pEp are identified by the full fingerprint (fpr) of its Keys in pEp are identified by the full fingerprint (fpr) of the
public key. public key.
4.1.2. User 4.2.2. User
A user is a real world human being or a group of human beings. If it 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. 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 user is identified by a user ID (user_id). The user_id SHOULD be a
an UUID, it MAY be an arbitrary unique string. UUID, it MAY be an arbitrary unique string.
The own user can have a user_id like all other users. If it doesn't, The own user can have a user_id like all other users. If it doesn't,
then it has PEP_OWN_USERID "pEp_own_userId" as user_id. then it has PEP_OWN_USERID "pEp_own_userId" as user_id.
A user can have a default key. A user can have a default key. (cf. Section 4.2.1)
4.1.3. Address
An address is a network address, e.g., an SMTP address or another
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. ]]
4.1.4. Identity 4.2.3. Identity
An identity is a (possibly pseudonymous) representation of a user An identity is a (possibly pseudonymous) representation of a user
encapsulating how this user appears in the network. encapsulating how this user appears in the network.
An identity is defined by the mapping of user_id to address. If no An identity is defined by the mapping of user_id to address. If no
user_id is known, it is guessed by mapping of username and address. user_id is known, it is guessed by mapping of username and address.
An identity can have a temporary user_id as a placeholder until a An identity can have a temporary user_id as a placeholder until a
real user_id is known. real user_id is known.
An identity can have a default key. An identity can have a default key. (cf. Section 4.2.1)
[[ Note: This is the reason why in current pEp implementations for [[ Note: This is the reason why in current pEp implementations for
each email account a different key pair is created, which allows a each (email) account a different key pair is created, which allows a
user to retain different identities. ]] user to retain different identities. ]]
In Appendix A.1 you can find how a pEp identity is defined in the In Appendix A.1 you can find how a pEp identity is defined in the
reference implementation of the pEp Engine. reference implementation of the pEp Engine.
4.2. Example: Difference between pEp and OpenPGP 4.2.4. Address
An address is a network address, e.g., an SMTP address or another
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. ]]
4.3. Example: Difference between pEp and OpenPGP
+--------------------+--------------+-------------------------------+ +--------------------+--------------+-------------------------------+
| pEp | OpenPGP | Comments | | pEp | OpenPGP | Comments |
+--------------------+--------------+-------------------------------+ +--------------------+--------------+-------------------------------+
| user_id | (no concept) | ID for a person, i.e. a | | user_id | (no concept) | ID for a person, i.e. a |
| | | contact | | | | contact |
| | | | | | | |
| username + address | uid | comparable only for email | | username + address | uid | comparable only for email |
| | | | | | | |
| fpr | fingerprint | used as key ID in pEp | | fpr | fingerprint | used as key ID in pEp |
| | | | | | | |
| (no concept) | Key ID | does not exist in pEp | | (no concept) | Key ID | does not exist in pEp |
+--------------------+--------------+-------------------------------+ +--------------------+--------------+-------------------------------+
5. Key Management 5. Key Management
In order to achieve the goal of widespread adoption of secure In order to achieve the goal of widespread adoption of secure
communications, key management in pEp MUST be automatized communications, key management in pEp MUST be automated.
A pEp implementation MUST ensure cryptographic keys for end-to-end 5.1. Key Generation
cryptography are generated for every identity configured (or
instantly upon its configuration [[ TODO: unclear/rewrite/simplify
]]), if no secure cryptographic setup can be found. Users SHALL NOT
be stopped from communicating - this also applies for initial
situations where cryptographic keys are not generated fast enough.
This process MUST be carried out in the background so the user is not
stopped from communicating. [[ TODO: rewrite/simplify ]]
pEp includes a Trust Rating system [E-D.birk-pep-trust-rating] A pEp implementation MUST ensure that cryptographic keys for every
defining what kind of encryption is considered reliable and is thus identity configured are available. If a corresponding key pair for
secure enough for usage in pEp implementations. This also applies the identity of a user is found and said identity fulfills the
for keys already available for the given identity. If the available requirements (e.g., for email, as set out in
keys are considered insecure (e.g, insufficient key length), pEp [I-D.marques-pep-email]), said key pair MUST be reused. Otherwise a
implementers are REQUIRED to generate new keys for use with the new key pair MUST be generated. This may be carried out instantly
respective identity. upon its configuration.
An example for the rating of communication types, the definition of On devices with limited processing power (e.g., mobile devices) the
the data structure by the pEp Engine reference implementation is key generation may take more time than a user is willing to wait. If
provided in Appendix A.2. this is the case, users SHOULD NOT be stopped from communicating,
i.e., the key generation process SHOULD be carried out in the
background.
5.1. Private Keys 5.2. Private Keys
5.2.1. Storage
Private keys in pEp implementations MUST always be held on the end Private keys in pEp implementations MUST always be held on the end
user's device(s): pEp implementers MUST NOT rely on private keys user's device(s): pEp implementers MUST NOT rely on private keys
stored in centralized remote locations. This applies even for key stored in centralized remote locations. This applies even for key
storages where the private keys are protected with sufficiently long storages where the private keys are protected with sufficiently long
passphrases. It MUST be considered a violation of pEp's P2P design passphrases. It is considered a violation of pEp's P2P design
principle to rely on centralized infrastructures. This also applies principle to rely on centralized infrastructures (cf. Section 3.4).
for pEp implementations created for applications not residing on a This also applies for pEp implementations created for applications
user's device (e.g., web-based MUAs). In such cases, pEp not residing on a user's device (e.g., web-based MUAs). In such
implementations MUST be done in a way the locally-held private key cases, pEp implementations MUST be done in a way such that the
can neither be directly accessed nor leaked to the outside world. locally-held private key can neither be directly accessed nor leaked
to the outside world.
[[ Note: It is particularly important that browser add-ons [[ Note: It is particularly important that browser add-ons
implementing pEp functionality do not obtain their cryptographic code implementing pEp functionality do not obtain their cryptographic code
from a centralized (cloud) service, as this must be considered a from a centralized (cloud) service, as this must be considered a
centralized attack vector allowing for backdoors, negatively centralized attack vector allowing for backdoors, negatively
impacting privacy. ]] impacting privacy. ]]
A decentralized proposition - the pEp Key Synchronization protocol. Cf. Section 7.1 for a means to synchronize private keys among
[E-D.birk-pep-keysync] - defines how pEp users can distribute their different devices of the same network address in a secure manner.
private keys among different devices in a secure and trusted manner:
this allows Internet users to read their messages across their
different devices, when sharing a common address (e.g., the same
email account).
5.2. Public Key Distribution 5.2.2. Passphrase
Implementers of pEp are REQUIRED to ensure that the identity's public Passphrases to protect a user's private key MUST be supported by pEp
key is attached to every outgoing message. However, this MAY be implementations, but MUST NOT be enforced by default. That is, if a
omitted if the peer previously received a message encrypted with the pEp implementation finds a suitable (i.e., secure enough)
public key of the sender. 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.
5.2.3. Private Key Export / Import
A private key can be exported from one device for import onto another
device. When pEp's Key Sync (cf. Section 7.1) is not available or
not desired to be used, this is largely a manual process.
5.3. Public Key Distribution
As the key is available (cf. Section 5.3) 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, 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 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 encryption key of the recipient is available, the sender's public key
MAY be sent unencrypted. In either case, this approach ensures that MAY be sent unencrypted. In either case, this approach ensures that
messaging clients (e.g., MUAs that at least implement OpenPGP) do not 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 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 thus have the chance to (automatically) import the sender's public
key. key.
If there is already a known public key from the sender of a message 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 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 future communication unless they are signed by the previous key (to
avoid a MITM attack). Messages MUST always be encrypted with the 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 receiving peer's oldest public key, as long as it is valid and not
expired. expired.
Implementers of pEp SHALL prevent that public keys attached to Implementers of pEp SHALL prevent the display of public keys attached
messages (e.g, in email) are displayed to the user, in order to avoid to messages (e.g, in email) to the user in order to prevent user
users getting confused by a file they cannot potentially deal with. confusion by files they are potentially unaware of how to handle.
Metadata (e.g., email headers) MUST NOT be added to announce a user's Metadata (e.g., email headers) MUST NOT be added to announce a user's
public key. This is considered unnecessary information leakage as it public key. This is considered unnecessary information leakage as it
may affect users' privacy, which depends also on a country's data may affect user privacy, which depends also on a country's data
retention laws. Furthermore, this affects interoperability to retention laws. Furthermore, this affects interoperability to
existing users (e.g., in the OpenPGP field) that have no notion of existing users (e.g., in the OpenPGP field) that have no notion of
such header fields and thus lose the ability to import any such keys such header fields and thus lose the ability to import any such keys
distributed this way. It SHOULD, though, be supported to obtain distributed this way. It SHOULD, though, be supported to obtain
other users' public keys by extracting them from respective header other users' public keys by extracting them from respective header
fields of received messages (in case such approaches get widespread). fields of received messages (in case such approaches get widespread).
Keyservers or generally intermediate approaches to obtain a peer's Keyservers or generally intermediate approaches to obtain a peer's
public key SHALL NOT be used by default. On the other hand, the user 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 MAY be provided with the option to opt-in for remote locations to
obtain keys, considering the widespread adoption of such approaches obtain keys, considering the widespread adoption of such approaches
for key distribution. for key distribution.
Keys generated or obtained by pEp clients SHALL NOT be uploaded to Keys generated or obtained by pEp clients MUST NOT be uploaded to any
any (intermediate) keystore locations without the user's explicit (intermediate) keystore locations without the user's explicit
consent. consent.
5.3. Passphrases 5.4. Key Reset
Passphrases to protect a user's private key MUST be supported by pEp [[ TODO: This section will explain how to deal with keys no longer
implementations, but SHALL NOT be enforced by default. That is, if a valid, e.g. if leaked ]]
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 SHALL 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.
6. Privacy Status 6. Trust Management
The following example roughly describes a pEp scenario with a typical
initial message flow to demonstrate key exchange and basic trust
management:
1. 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.
2. Bob can just reply to Alice and - as he received her public key -
his messaging client is now able to encrypt the message. At this
point the rating for Alice changes to "encrypted" in Bob's
messaging client, which (UX-wise) can be displayed using yellow
color (cf. Section 6.3).
3. 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.
Section 6.3).
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. Section 6.2) and confirm this process if
those match. After doing so, their identity rating changes to
"encrypted and authenticated" (cf. Section 6.3), which (UX-wise)
can be displayed using a green color.
As color code changes for an identity, it is also applied to future
messages to/from this identity.
----- -----
| A | | B |
----- -----
| |
+------------------------+ +------------------------+
| auto-generate key pair | | auto-generate key pair |
| (if no key yet) | | (if no key yet) |
+------------------------+ +------------------------+
| |
+-----------------------+ +-----------------------+
| Privacy Status for B: | | Privacy Status for A: |
| *Unencrypted* | | *Unencrypted* |
+-----------------------+ +-----------------------+
| |
| A sends message to B (Public Key |
| attached) / optionally signed, but |
| NOT ENCRYPTED |
+------------------------------------------>|
| |
| +-----------------------+
| | Privacy Status for A: |
| | *Encrypted* |
| +-----------------------+
| |
| B sends message to A (Public Key |
| attached) / signed and ENCRYPTED |
|<------------------------------------------+
| |
+-----------------------+ |
| Privacy Status for B: | |
| *Encrypted* | |
+-----------------------+ |
| |
| A and B sucessfully compare their |
| Trustwords over an alternative channel |
| (e.g., phone line) |
|<-- -- -- -- -- -- -- -- -- -- -- -- -- -->|
| |
+-----------------------+ +-----------------------+
| Privacy Status for B: | | Privacy Status for A: |
| *Trusted* | | *Trusted* |
+-----------------------+ +-----------------------+
| |
6.1. Privacy Status
For end-users, the most important component of pEp, which MUST be 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 made visible on a per-recipient and per-message level, is the Privacy
Status. Status.
By colors, symbols and texts a user SHALL immediately understand how By colors, symbols and texts a user SHALL immediately understand how
private private
o a communication channel with a given peer was or ought to be and o a communication channel with a given peer was or ought to be and
o a given message was or ought to be. o a given message was or ought to be.
The Privacy Status in its most general form MUST be expressed with 6.2. Handshake
traffic lights semantics (and respective symbols and texts), whereas
the three colors yellow, green and red can be applied for any peer or To establishing trust between peers and to upgrade Privacy Status,
pEp defines a handshake, which is specified in
[I-D.marques-pep-handshake].
In pEp, Trustwords [I-D.birk-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.
6.3. Trust Rating
pEp includes a Trust Rating system defining Rating and Color Codes to
express the Privacy Status of a peer or message
[I-D.marques-pep-rating]. 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 message - like this immediately indicating how secure and trustworthy
(and thus private) a communication was or ought to be considered. In (and thus private) a communication was or ought to be considered.
cases no (special) Privacy Status can be inferred for peers or
messages, no color (or the gray color) MUST be shown and respective
texts - being "unknown" or "unreliable" - MUST be shown.
The detailed Privacy Status as an end-user element of the pEp Trust The pEp Trust Rating system with all its states and respective
Rating system with all its states and respective representations to representations to be followed is outlined in
be followed is outlined in [E-D.birk-pep-trust-rating]. [I-D.marques-pep-rating].
7. Options in pEp Note: An example for the rating of communication types, the
definition of the data structure by the pEp Engine reference
implementation is provided in Appendix A.2.
6.4. Trust Revoke
[[ 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. ]]
7. Synchronization
An important feature of pEp is to assist the user to run pEp
applications on different devices, such as computer, mobile phone or
tables, at the same time. Therefore state needs to be synchronized
among the different devices.
7.1. Private Key Synchronization
A decentralized proposition - the pEp Key Synchronization protocol.
[E-D.birk-pep-keysync] - defines how pEp users can distribute their
private keys among different devices in a secure and trusted manner:
this allows Internet users to read their messages across their
different devices, when sharing a common address (e.g., the same
email account).
7.2. Trust Synchronization
[[ TODO: This section will explain how trust and other related state
is synchronized among different devices in a secure manner. ]]
8. Interoperability
pEp aims to be interoperable with existing applications designed to
enable privacy, e.g., OpenPGP and S/MIME in email.
9. Options in pEp
In this section a non-exhaustive selection of options is provided. In this section a non-exhaustive selection of options is provided.
7.1. Option "Passive Mode" 9.1. Option "Passive Mode"
By default the sender attaches its public key to any outgoing message By default the sender attaches its public key to any outgoing message
(cf. Section 5.2). For situations where a sender wants to ensure (cf. Section 5.3). For situations where a sender wants to ensure
that it only attaches a public key to an Internet user which has a that it only attaches a public key to an Internet user which has a
pEp implementation, a Passive Mode MUST be available. pEp implementation, a Passive Mode MUST be available.
7.2. Option "Disable Protection" 9.2. Option "Disable Protection"
This option SHALL not affect the user's ability to decipher already
received or sent messages. [[ TODO: Public key added in these cases?
]]
Protection can be disabled generally or selectively. 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:
7.2.1. For all communications 1. all communication
Implementers of pEp MUST provide an option "Disable Protection" for 2. specific contacts
the user's choice to disable any outgoing encryption and signing.
7.2.2. For some communications 3. specific messages
Implementers of pEp MUST provide an option to allow users to disable The public key still attached, unless the option "Passive Mode" (cf.
protection (encryption and signing) for specific contacts or Section 9.1) is activated at the same time.
messages.
7.3. Option "Extra Keys" 9.3. Option "Extra Keys"
For internal environments there may be a need to centrally decrypt For internal environments there may be a need to centrally decrypt
persons' messages for archiving or other legal purposes (e.g., in the persons' messages for archiving or other legal purposes (e.g., in the
contexts of public offices and enterprises) by authorized personnel. contexts of public offices and enterprises) by authorized personnel.
Therefore, pEp implementers MAY provide an "Extra Keys" option where Therefore, pEp implementers MAY provide an "Extra Keys" option where
a message gets encrypted with at least one additional public key. a message gets encrypted with at least one additional public key.
The corresponding (shared) secret(s) to decrypt are intended to be The corresponding secret key(s) are intended to be held (safely and
held - safely - by CISO staff and/or other authorized personnel for securely), e.g., by CISO staff or other authorized personnel for such
such an organization. [[ TODO: Shared secret? no private key? ]] an organization.
The Extra Keys feature MUST NOT be activated by default for any The Extra Keys feature MUST NOT be activated by default for any
network address and is intended to be an option only for network address and is intended to be an option only for
organizational identities and their corresponding network addresses organizational identities and their corresponding network addresses
and accounts - not for addresses used for private purposes. That is, and accounts - not for addresses used for private purposes. That is,
the Extra Keys feature is a feature which SHOULD NOT apply to all the Extra Keys feature is a feature which SHOULD NOT apply to all
identities a user might posses, even if activated. identities a user might posses, even if activated.
7.4. Option "Blacklist Keys" 9.4. Option "Blacklist Keys"
An option "Blacklist Keys" MUST be provided for an advanced user to An option "Blacklist Keys" MUST be provided for an advanced user to
be able to disable keys which the user does not want to be used be able to disable keys which the user does not want to be used
anymore for any new communications. However, the keys SHALL NOT be anymore for any new communications. However, the keys SHALL NOT be
deleted. It MUST still be possible to verify and decipher past deleted. It MUST still be possible to verify and decipher past
communications. communications.
7.5. Establishing trust between peers 10. Security Considerations
In pEp, Trustwords [I-D.birk-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.
8. Security Considerations
By attaching the sender's public key to outgoing messages, Trust on By attaching the sender's public key to outgoing messages, Trust on
First Use (TOFU) is established. However, this is prone to MITM First Use (TOFU) is established. However, this is prone to MITM
attacks. Cryptographic key subversion is considered Pervasive attacks. Cryptographic key subversion is considered Pervasive
Monitoring (PM) according to [RFC7258]. Those attacks can be Monitoring (PM) according to [RFC7258]. Those attacks can be
mitigated, if the involved users compare their common Trustwords. mitigated, if the involved users compare their common Trustwords.
This possibility MUST be made easily accessible to pEp users in the This possibility MUST be made easily accessible to pEp users in the
user interface implementation. If for compatibility reasons (e.g., user interface implementation. If for compatibility reasons (e.g.,
with OpenPGP users) no Trustwords can be used, then an comparatively with OpenPGP users) no Trustwords can be used, then a comparatively
easy way to verify the respective public key fingerprints MUST be easy way to verify the respective public key fingerprints MUST be
implemented. implemented.
As the use of passphrases for private keys is not advised, devices As the use of passphrases for private keys is not advised, devices
themselves SHOULD use encryption. themselves SHOULD use encryption.
9. Implementation Status 11. Privacy Considerations
9.1. Introduction [[ TODO ]]
12. Implementation Status
12.1. Introduction
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
skipping to change at page 13, line 36 skipping to change at page 18, line 42
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
According to [RFC7942], "[...] this will allow reviewers and working According to [RFC7942], "[...] this will allow reviewers and working
groups to assign due consideration to documents that have the benefit groups to assign due consideration to documents that have the benefit
of running code, which may serve as evidence of valuable of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this more mature. It is up to the individual working groups to use this
information as they see fit." information as they see fit."
9.2. Reference implementation of pEp's core 12.2. Current software implementing pEp
The following software implementing the pEp protocols (to varying
degrees) already exists:
o pEp for Outlook as add-on for Microsoft Outlook, release
[SRC.pepforoutlook]
o pEp for Android (based on a fork of the K9 MUA), release
[SRC.pepforandroid]
o Enigmail/pEp as add-on for Mozilla Thunderbird, release
[SRC.enigmailpep]
o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios]
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.
12.3. Reference implementation of pEp's core
The pEp Foundation provides a reference implementation of pEp's core The pEp Foundation provides a reference implementation of pEp's core
principles and functionalities, which go beyond the documentation principles and functionalities, which go beyond the documentation
status of this Internet-Draft. [SRC.pepcore] status of this Internet-Draft. [SRC.pepcore]
pEp's reference implementation is composed of pEp Engine and pEp pEp's reference implementation is composed of pEp Engine and pEp
Adapters (or bindings), alongside with some libraries which pEp Adapters (or bindings), alongside with some libraries which pEp
Engine relies on to function on certain platforms (like a NetPGP fork Engine relies on to function on certain platforms (like a NetPGP fork
we maintain for the iOS platform). we maintain for the iOS platform).
skipping to change at page 14, line 45 skipping to change at page 20, line 25
o pEp JNI Adapter o pEp JNI Adapter
o pEp JSON Adapter o pEp JSON Adapter
o pEp ObjC (and Swift) Adapter o pEp ObjC (and Swift) Adapter
o pEp Python Adapter o pEp Python Adapter
o pEp Qt Adapter o pEp Qt Adapter
9.3. Abstract Crypto API examples 12.4. Abstract Crypto API examples
A selection of code excerpts from the pEp Engine reference A selection of code excerpts from the pEp Engine reference
implementation (encrypt message, decrypt message, and obtain implementation (encrypt message, decrypt message, and obtain
trustwords) can be found in Appendix A.3. trustwords) can be found in Appendix A.3.
9.4. Current software implementing pEp 13. Notes
The following software implementing the pEp protocols (to varying
degrees) already exists; it does not yet go beyond implementing pEp
for email, which is described nearer in [E-D.birk-pep-email]:
o pEp for Outlook as add-on for Microsoft Outlook, release
[SRC.pepforoutlook]
o pEp for Android (based on a fork of the K9 MUA), release
[SRC.pepforandroid]
o Enigmail/pEp as add-on for Mozilla Thunderbird, release
[SRC.enigmailpep]
o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios]
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.
10. Notes
The pEp logo and "pretty Easy privacy" are registered trademarks The pEp logo and "pretty Easy privacy" are registered trademarks
owned by pEp Foundation in Switzerland, a tax-free, non-commercial owned by the non-profit pEp Foundation based in Switzerland.
entity.
Primarily, we want to ensure the following: Primarily, we want to ensure the following:
o Software using the trademarks MUST be backdoor-free. o Software using the trademarks MUST be backdoor-free.
o Software using the trademarks MUST be accompanied by a serious o Software using the trademarks MUST be accompanied by a serious
(detailed) code audit carried out by a reputable third-party, for (detailed) code audit carried out by a reputable third-party, for
any proper release. any proper release.
The pEp Foundation will help to support any community-run (non- The pEp Foundation will help to support any community-run (non-
commercial) project with the latter, be it organizationally or commercial) project with the latter, be it organizationally or
financially. financially.
Through this, the foundation wants to make sure that software using Through this, the foundation wants to make sure that software using
the pEp trademarks is as safe as possible from a security and privacy the pEp trademarks is as safe as possible from a security and privacy
point of view. point of view.
11. Acknowledgments 14. Acknowledgments
The authors would like to thank the following people who have The authors would like to thank the following people who have
provided feedback or significant contributions to the development of provided significant contributions to the development of this
this document: Bernie Hoeneisen, Brian Trammell, Enrico Tomae, Eric document: Volker Birk, Krista Bennett, and S. Shelburn.
Rescorla Neal Walfield, and Stephen Farrel.
[[ TODO: Add those who commented on mailing list (on this draft) as Furthermore, the authors would like to thank the following people who
well as those who provided feedback in person or during BarBoFs. ]] who provided helpful comments and suggestions for this document:
Alexey Melnikov, Ben Campbell, Brian Trammell, Bron Gondwana, Daniel
Kahn Gillmor, Enrico Tomae, Eric Rescorla, Gabriele Lenzini, Hans-
Peter Dittler, Iraklis Symeonidis, Mirja Kuehlewind, Neal Walfield,
Pete Resnick, Russ Housley, and Stephen Farrel.
This work was initially created by pEp Foundation, and then reviewed This work was initially created by pEp Foundation, and then reviewed
and extended with funding by the Internet Society's Beyond the Net and extended with funding by the Internet Society's Beyond the Net
Programme on standardizing pEp. [ISOC.bnet] Programme on standardizing pEp. [ISOC.bnet]
12. References 15. References
12.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
12.2. Informative References 15.2. Informative References
[E-D.birk-pep-email]
Birk, V. and H. Marques, "pretty Easy privacy (pEp):
Secure and Trusted Email Communication", June 2018,
<https://pep.foundation/dev/repos/internet-
drafts/file/tip/pep-email/draft-birk-pep-email-NN.txt>.
Early draft
[E-D.birk-pep-handshake]
Marques, H., "pretty Easy privacy (pEp): Contact
Authentication through Handshake", June 2018,
<https://pep.foundation/dev/repos/internet-
drafts/file/tip/pep-handshake/
draft-marques-pep-handshake-00.txt>.
Early draft
[E-D.birk-pep-keysync] [E-D.birk-pep-keysync]
Birk, V. and H. Marques, "pretty Easy privacy (pEp): Key Birk, V. and H. Marques, "pretty Easy privacy (pEp): Key
Synchronization Protocol", June 2018, Synchronization Protocol", June 2018,
<https://pep.foundation/dev/repos/internet- <https://pep.foundation/dev/repos/internet-
drafts/file/tip/pep-keysync/ drafts/file/tip/pep-keysync/
draft-birk-pep-keysync-NN.txt>. draft-birk-pep-keysync-NN.txt>.
Early draft Early draft
[E-D.birk-pep-trust-rating]
Birk, V. and H. Marques, "pretty Easy privacy (pEp): Trust
Rating System", June 2018,
<https://pep.foundation/trac/browser/internet-drafts/pep-
rating/draft-marques-pep-rating-00.txt>.
Early draft
[I-D.birk-pep-trustwords] [I-D.birk-pep-trustwords]
Birk, V., Marques, H., and B. Hoeneisen, "IANA Birk, V., Marques, H., and B. Hoeneisen, "IANA
Registration of Trustword Lists: Guide, Template and IANA Registration of Trustword Lists: Guide, Template and IANA
Considerations", draft-birk-pep-trustwords-02 (work in Considerations", draft-birk-pep-trustwords-02 (work in
progress), June 2018. progress), June 2018.
[I-D.marques-pep-email]
Marques, H., "pretty Easy privacy (pEp): Email Formats and
Protocols", draft-marques-pep-email-02 (work in progress),
October 2018.
[I-D.marques-pep-handshake]
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
Contact and Channel Authentication through Handshake",
draft-marques-pep-handshake-01 (work in progress), October
2018.
[I-D.marques-pep-rating]
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
Mapping of Privacy Rating", draft-marques-pep-rating-00
(work in progress), July 2018.
[ISOC.bnet] [ISOC.bnet]
Simao, I., "Beyond the Net. 12 Innovative Projects Simao, I., "Beyond the Net. 12 Innovative Projects
Selected for Beyond the Net Funding. Implementing Privacy Selected for Beyond the Net Funding. Implementing Privacy
via Mass Encryption: Standardizing pretty Easy privacy's via Mass Encryption: Standardizing pretty Easy privacy's
protocols", June 2017, <https://www.internetsociety.org/ protocols", June 2017, <https://www.internetsociety.org/
blog/2017/06/12-innovative-projects-selected-for-beyond- blog/2017/06/12-innovative-projects-selected-for-beyond-
the-net-funding/>. the-net-funding/>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, Thayer, "OpenPGP Message Format", RFC 4880,
skipping to change at page 18, line 5 skipping to change at page 22, line 49
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights
Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
October 2017, <https://www.rfc-editor.org/info/rfc8280>.
[SRC.enigmailpep] [SRC.enigmailpep]
"Source code for Enigmail/pEp", June 2018, "Source code for Enigmail/pEp", July 2018,
<https://enigmail.net/index.php/en/download/source-code>. <https://enigmail.net/index.php/en/download/source-code>.
[SRC.pepcore] [SRC.pepcore]
"Core source code and reference implementation of pEp "Core source code and reference implementation of pEp
(engine and adapters)", June 2018, (engine and adapters)", July 2018,
<https://pep.foundation/dev/>. <https://pep.foundation/dev/>.
[SRC.pepforandroid] [SRC.pepforandroid]
"Source code for pEp for Android", June 2018, "Source code for pEp for Android", July 2018,
<https://pep-security.lu/gitlab/android/pep>. <https://pep-security.lu/gitlab/android/pep>.
[SRC.pepforios] [SRC.pepforios]
"Source code for pEp for iOS", June 2018, "Source code for pEp for iOS", July 2018,
<https://pep-security.ch/dev/repos/pEp_for_iOS/>. <https://pep-security.ch/dev/repos/pEp_for_iOS/>.
[SRC.pepforoutlook] [SRC.pepforoutlook]
"Source code for pEp for Outlook", June 2018, "Source code for pEp for Outlook", July 2018,
<https://pep-security.lu/dev/repos/pEp_for_Outlook/>. <https://pep-security.lu/dev/repos/pEp_for_Outlook/>.
Appendix A. Excerpts from the pEp Reference Implementation Appendix A. Code Excerpts
This section provides excerpts of the running code from the pEp This section provides excerpts of the running code from the pEp
reference implementation pEp engine (C99 programming language). [[ reference implementation pEp engine (C99 programming language).
TODO: Maybe rewrite sentence a bit ]]
A.1. pEp Identity A.1. pEp Identity
How the pEp identity is defined in the data structure (cf. src/ How the pEp identity is defined in the data structure (cf. src/
pEpEngine.h): pEpEngine.h):
typedef struct _pEp_identity { typedef struct _pEp_identity {
char *address; // C string with address UTF-8 encoded char *address; // C string with address UTF-8 encoded
char *fpr; // C string with fingerprint UTF-8 char *fpr; // C string with fingerprint UTF-8
// encoded // encoded
skipping to change at page 20, line 7 skipping to change at page 25, line 7
expires integer, expires integer,
comment text, comment text,
flags integer default 0 flags integer default 0
); );
CREATE INDEX pgp_keypair_expires on pgp_keypair ( CREATE INDEX pgp_keypair_expires on pgp_keypair (
expires expires
); );
A.2. pEp Communication Type A.2. pEp Communication Type
In the following, an example for the rating of communication types, In the following, is an example for the rating of communication types
the definition of the data structure (cf. src/pEpEngine.h as defined by a data structure (cf. src/pEpEngine.h [SRC.pepcore]):
[SRC.pepcore]):
typedef enum _PEP_comm_type { typedef enum _PEP_comm_type {
PEP_ct_unknown = 0, PEP_ct_unknown = 0,
// range 0x01 to 0x09: no encryption, 0x0a to 0x0e: // range 0x01 to 0x09: no encryption, 0x0a to 0x0e:
// nothing reasonable // nothing reasonable
PEP_ct_no_encryption = 0x01, // generic PEP_ct_no_encryption = 0x01, // generic
PEP_ct_no_encrypted_channel = 0x02, PEP_ct_no_encrypted_channel = 0x02,
PEP_ct_key_not_found = 0x03, PEP_ct_key_not_found = 0x03,
skipping to change at page 22, line 5 skipping to change at page 27, line 5
The following code excerpts are from the pEp Engine reference The following code excerpts are from the pEp Engine reference
implementation, to be found in src/message_api.h. implementation, to be found in src/message_api.h.
[[ Note: Just a selection; more functionality is available. ]] [[ Note: Just a selection; more functionality is available. ]]
A.3.1. Encrypting a Message A.3.1. Encrypting a Message
Cf. src/message_api.h [SRC.pepcore]: Cf. src/message_api.h [SRC.pepcore]:
// encrypt_message() - encrypt message in memory // encrypt_message() - encrypt message in memory
// //
// parameters: // parameters:
// session (in) session handle // session (in) session handle
// src (in) message to encrypt // src (in) message to encrypt
// extra (in) extra keys for encryption // extra (in) extra keys for encryption
// dst (out) pointer to new encrypted message or NULL if no // dst (out) pointer to new encrypted message or NULL if
// encryption could take place // no encryption could take place
// enc_format (in) encrypted format // enc_format (in) encrypted format
// flags (in) flags to set special encryption features // flags (in) flags to set special encryption features
// //
// return value: // return value:
// PEP_STATUS_OK on success // PEP_STATUS_OK on success
// PEP_KEY_HAS_AMBIG_NAME at least one of the recipient // PEP_KEY_HAS_AMBIG_NAME at least one of the recipient
// keys has an ambiguous name // keys has an ambiguous name
// PEP_UNENCRYPTED no recipients with usable key, // PEP_UNENCRYPTED no recipients with usable key,
// message is left unencrypted, // message is left unencrypted,
// and key is attached to it // and key is attached to it
// //
// caveat: // caveat:
// the ownership of src remains with the caller // the ownership of src remains with the caller
// the ownership of dst goes to the caller // the ownership of dst goes to the caller
DYNAMIC_API PEP_STATUS encrypt_message( DYNAMIC_API PEP_STATUS encrypt_message(
PEP_SESSION session, PEP_SESSION session,
message *src, message *src,
stringlist_t *extra, stringlist_t *extra,
message **dst, message **dst,
PEP_enc_format enc_format, PEP_enc_format enc_format,
PEP_encrypt_flags_t flags PEP_encrypt_flags_t flags
); );
Cf. src/message_api.h [SRC.pepcore]: Cf. src/message_api.h [SRC.pepcore]:
A.3.2. Decrypting a Message A.3.2. Decrypting a Message
Cf. src/message_api.h [SRC.pepcore]: Cf. src/message_api.h [SRC.pepcore]:
// decrypt_message() - decrypt message in memory // decrypt_message() - decrypt message in memory
// //
// parameters: // parameters:
// session (in) session handle // session (in) session handle
// src (in) message to decrypt // src (in) message to decrypt
// dst (out) pointer to new decrypted message // dst (out) pointer to new decrypted message
// or NULL on failure // or NULL on failure
// keylist (out) stringlist with keyids // keylist (out) stringlist with keyids
// rating (out) rating for the message // rating (out) rating for the message
// flags (out) flags to signal special decryption features // flags (out) flags to signal special decryption features
// //
// return value: // return value:
// error status // error status
// or PEP_DECRYPTED if message decrypted but not verified // or PEP_DECRYPTED if message decrypted but not verified
// or PEP_CANNOT_REENCRYPT if message was decrypted (and possibly // or PEP_CANNOT_REENCRYPT if message was decrypted (and
// verified) but a reencryption operation is expected by the // possibly verified) but a reencryption operation is
// caller and failed // expected by the caller and failed
// or PEP_STATUS_OK on success // or PEP_STATUS_OK on success
// //
// flag values: // flag values:
// in: // in:
// PEP_decrypt_flag_untrusted_server // PEP_decrypt_flag_untrusted_server
// used to signal that decrypt function should engage in // used to signal that decrypt function should engage in
// behaviour specified for when the server storing the // behaviour specified for when the server storing the
// source is untrusted // source is untrusted
// out: // out:
// PEP_decrypt_flag_own_private_key // PEP_decrypt_flag_own_private_key
// private key was imported for one of our addresses (NOT // private key was imported for one of our addresses
// trusted or set to be used - handshake/trust is required // (NOT trusted or set to be used - handshake/trust is
// for that) // required for that)
// PEP_decrypt_flag_src_modified // PEP_decrypt_flag_src_modified
// indicates that the src object has been modified. At the // indicates that the src object has been modified. At
// moment, this is always as a direct result of the // the moment, this is always as a direct result of the
// behaviour driven by the input flags. This flag is the // behaviour driven by the input flags. This flag is the
// ONLY value that should be relied upon to see if such // ONLY value that should be relied upon to see if such
// changes have taken place. // changes have taken place.
// PEP_decrypt_flag_consume // PEP_decrypt_flag_consume
// used by sync // used by sync
// PEP_decrypt_flag_ignore // PEP_decrypt_flag_ignore
// used by sync // used by sync
// //
// //
// caveat: // caveat:
// the ownership of src remains with the caller - however, the // the ownership of src remains with the caller - however, the
// contents might be modified (strings freed and allocated anew // contents might be modified (strings freed and allocated anew
// or set to NULL, etc) intentionally; when this happens, // or set to NULL, etc) intentionally; when this happens,
// PEP_decrypt_flag_src_modified is set. // PEP_decrypt_flag_src_modified is set.
// the ownership of dst goes to the caller // the ownership of dst goes to the caller
// the ownership of keylist goes to the caller // the ownership of keylist goes to the caller
// if src is unencrypted this function returns PEP_UNENCRYPTED and // if src is unencrypted this function returns PEP_UNENCRYPTED
// sets // and sets
// dst to NULL // dst to NULL
DYNAMIC_API PEP_STATUS decrypt_message( DYNAMIC_API PEP_STATUS decrypt_message(
PEP_SESSION session, PEP_SESSION session,
message *src, message *src,
message **dst, message **dst,
stringlist_t **keylist, stringlist_t **keylist,
PEP_rating *rating, PEP_rating *rating,
PEP_decrypt_flags_t *flags PEP_decrypt_flags_t *flags
); );
A.3.3. Obtain Common Trustwords A.3.3. Obtain Common Trustwords
Cf. src/message_api.h [SRC.pepcore]: Cf. src/message_api.h [SRC.pepcore]:
// get_trustwords() - get full trustwords string // get_trustwords() - get full trustwords string
// for a *pair* of identities // for a *pair* of identities
// //
// parameters: // parameters:
// session (in) session handle // session (in) session handle
skipping to change at page 24, line 52 skipping to change at page 29, line 52
DYNAMIC_API PEP_STATUS get_trustwords( DYNAMIC_API PEP_STATUS get_trustwords(
PEP_SESSION session, const pEp_identity* id1, PEP_SESSION session, const pEp_identity* id1,
const pEp_identity* id2, const char* lang, const pEp_identity* id2, const char* lang,
char **words, size_t *wsize, bool full char **words, size_t *wsize, bool full
); );
Appendix B. Document Changelog Appendix B. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]] [[ RFC Editor: This section is to be removed before publication ]]
o draft-birk-pep-03:
* Major restructure of the document
* Adapt authors to the actual authors and extend acknowledgement
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
o draft-birk-pep-02: o draft-birk-pep-02:
* Move (updated) code to Appendix * Move (updated) code to Appendix
* Add Changelog to Appendix * Add Changelog to Appendix
* Add Open Issue section to Appendix * Add Open Issue section to Appendix
* Fix description of what Extra Keys are * Fix description of what Extra Keys are
skipping to change at page 25, line 30 skipping to change at page 30, line 48
o draft-birk-pep-00: o draft-birk-pep-00:
* Initial version * Initial version
Appendix C. Open Issues Appendix C. Open Issues
[[ RFC Editor: This section should be empty and is to be removed [[ RFC Editor: This section should be empty and is to be removed
before publication ]] before publication ]]
o References to RFC6973 (Privacy Considerations)
o Add references to prior work, and what differs here - PEM (cf.
RFC1421-1424)
o Better explain Passive Mode o Better explain Passive Mode
o Better explain / illustrate pEp's identity system o Better explain / illustrate pEp's identity system
o Explain Key Mapping o Explain Key Mapping (to S/MIME)
Authors' Addresses o Add more information to deal with organizational requirements
Volker Birk o Add text to Key Reset (Section 5.4) as well as reference as soon
pEp Foundation as available
Oberer Graben 4
CH-8400 Winterthur o Add text to Trust Revoke (Section 6.4) as well as reference as
Switzerland soon as available
o Add text to Trust Synchronization (Section 7.2) as well as
reference as soon as available
o Add references to Private Key Export / Import (Section 5.2.3) as
soon as reference available
o Add text to Privacy Considerations (Section 11)
Authors' Addresses
Email: volker.birk@pep.foundation
URI: https://pep.foundation/
Hernani Marques Hernani Marques
pEp Foundation pEp Foundation
Oberer Graben 4 Oberer Graben 4
CH-8400 Winterthur CH-8400 Winterthur
Switzerland Switzerland
Email: hernani.marques@pep.foundation Email: hernani.marques@pep.foundation
URI: https://pep.foundation/ URI: https://pep.foundation/
Shelburn Bernie Hoeneisen
pEp Foundation Ucom Standards Track Solutions GmbH
Oberer Graben 4 CH-8046 Zuerich
CH-8400 Winterthur
Switzerland Switzerland
Email: shelburn@pep.foundation Phone: +41 44 500 52 44
URI: https://pep.foundation/ Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: https://ucom.ch/
 End of changes. 121 change blocks. 
476 lines changed or deleted 701 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/