< draft-birk-pep-03.txt   draft-birk-pep-04.txt >
Network Working Group H. Marques Network Working Group H. Marques
Internet-Draft pEp Foundation Internet-Draft C. Luck
Intended status: Standards Track B. Hoeneisen Intended status: Standards Track pEp Foundation
Expires: September 8, 2019 Ucom.ch Expires: January 9, 2020 B. Hoeneisen
March 07, 2019 Ucom.ch
July 08, 2019
pretty Easy privacy (pEp): Privacy by Default pretty Easy privacy (pEp): Privacy by Default
draft-birk-pep-03 draft-birk-pep-04
Abstract Abstract
The pretty Easy privacy (pEp) protocols describe a set of conventions The pretty Easy privacy (pEp) model and protocols describe a set of
for the automation of operations traditionally seen as barriers to conventions for the automation of operations traditionally seen as
the use and deployment of secure end-to-end interpersonal messaging. barriers to the use and deployment of secure, privacy-preserving end-
These include, but are not limited to, key management, key discovery, to-end interpersonal messaging. These include, but are not limited
and private key handling (including peer-to-peer synchronization of to, key management, key discovery, and private key handling
private keys and other user data across devices). pEp also introduces (including peer-to-peer synchronization of private keys and other
means to verify communication peers and proposes a trust-rating 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 system to denote secure types of communications and signal the
privacy level available on a per-user and per-message level. privacy level available on a per-user and per-message level.
Significantly, the pEp protocols build on already available security Significantly, the pEp protocols build on already available security
formats and message transports (e.g., PGP/MIME), and are written with formats and message transports (e.g., PGP/MIME with email), and are
the intent to be interoperable with already widely-deployed systems written with the intent to be interoperable with already widely-
in order to facilitate and ease adoption and implementation. This deployed systems in order to ease adoption and implementation. This
document outlines the general design choices and principles of pEp. 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 September 8, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
1.1. Relationship to other pEp documents . . . . . . . . . . . 5 1.1. Relationship to other pEp documents . . . . . . . . . . . 5
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Protocol's Core Design Principles . . . . . . . . . . . . . . 6 1.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Privacy by Default . . . . . . . . . . . . . . . . . . . 6 2. Protocol's Core Design Principles . . . . . . . . . . . . . . 6
3.2. Data Minimization . . . . . . . . . . . . . . . . . . . . 6 2.1. Privacy by Default . . . . . . . . . . . . . . . . . . . 6
3.3. Interoperability . . . . . . . . . . . . . . . . . . . . 6 2.2. Data Minimization . . . . . . . . . . . . . . . . . . . . 7
3.4. Peer-to-Peer (P2P) . . . . . . . . . . . . . . . . . . . 7 2.3. Interoperability . . . . . . . . . . . . . . . . . . . . 7
3.5. User Experience (UX) . . . . . . . . . . . . . . . . . . 7 2.4. Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . 7
4. Specific Elements in pEp . . . . . . . . . . . . . . . . . . 8 2.5. User Interaction . . . . . . . . . . . . . . . . . . . . 8
4.1. pEp identity system . . . . . . . . . . . . . . . . . . . 8 3. Identity System . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. User . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Key . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. User . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Identity . . . . . . . . . . . . . . . . . . . . . . 9 4. Key Management . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.4. Address . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 10
4.3. Example: Difference between pEp and OpenPGP . . . . . . . 9 4.2. Private Keys . . . . . . . . . . . . . . . . . . . . . . 10
5. Key Management . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Storage . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Passphrase . . . . . . . . . . . . . . . . . . . . . 11
5.2. Private Keys . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Key Reset . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Storage . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Public Key Distribution . . . . . . . . . . . . . . . . . 11
5.2.2. Passphrase . . . . . . . . . . . . . . . . . . . . . 11 4.4.1. UX Considerations . . . . . . . . . . . . . . . . . . 12
5.2.3. Private Key Export / Import . . . . . . . . . . . . . 11 4.4.2. No addition of unnecessary metadata . . . . . . . . . 12
5.3. Public Key Distribution . . . . . . . . . . . . . . . . . 11 4.4.3. No centralized public key storage or retrieval by
5.4. Key Reset . . . . . . . . . . . . . . . . . . . . . . . . 12 default . . . . . . . . . . . . . . . . . . . . . . . 12
6. Trust Management . . . . . . . . . . . . . . . . . . . . . . 12 4.4.4. Example message flow . . . . . . . . . . . . . . . . 12
6.1. Privacy Status . . . . . . . . . . . . . . . . . . . . . 15 4.5. Key Reset . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Trust Management . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Trust Rating . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Privacy Status . . . . . . . . . . . . . . . . . . . . . 15
6.4. Trust Revoke . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Trust Rating . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Private Key Synchronization . . . . . . . . . . . . . . . 16 5.4. Trust Revoke . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Trust Synchronization . . . . . . . . . . . . . . . . . . 16 6. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 16
8. Interoperability . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Private Key Synchronization . . . . . . . . . . . . . . . 16
9. Options in pEp . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Trust Synchronization . . . . . . . . . . . . . . . . . . 16
9.1. Option "Passive Mode" . . . . . . . . . . . . . . . . . . 16 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Option "Disable Protection" . . . . . . . . . . . . . . . 17 8. Options in pEp . . . . . . . . . . . . . . . . . . . . . . . 17
9.3. Option "Extra Keys" . . . . . . . . . . . . . . . . . . . 17 8.1. Option "Passive Mode" . . . . . . . . . . . . . . . . . . 17
9.4. Option "Blacklist Keys" . . . . . . . . . . . . . . . . . 17 8.2. Option "Disable Protection" . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.3. Option "Extra Keys" . . . . . . . . . . . . . . . . . . . 17
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 8.3.1. Use Case for Organizations . . . . . . . . . . . . . 17
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 8.3.2. Use Case for Key Synchronization . . . . . . . . . . 18
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 18 8.4. Option "Blacklist Keys" . . . . . . . . . . . . . . . . . 18
12.2. Current software implementing pEp . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12.3. Reference implementation of pEp's core . . . . . . . . . 19 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
12.4. Abstract Crypto API examples . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 19
12.2. Current software implementing pEp . . . . . . . . . . . 19
12.3. Reference implementation of pEp's core . . . . . . . . . 20
12.4. Abstract Crypto API examples . . . . . . . . . . . . . . 21
13. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.1. Normative References . . . . . . . . . . . . . . . . . . 21 15.1. Normative References . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 21 15.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Code Excerpts . . . . . . . . . . . . . . . . . . . 23 Appendix A. Code Excerpts . . . . . . . . . . . . . . . . . . . 24
A.1. pEp Identity . . . . . . . . . . . . . . . . . . . . . . 23 A.1. pEp Identity . . . . . . . . . . . . . . . . . . . . . . 24
A.1.1. Corresponding SQL . . . . . . . . . . . . . . . . . . 24 A.1.1. Corresponding SQL . . . . . . . . . . . . . . . . . . 24
A.2. pEp Communication Type . . . . . . . . . . . . . . . . . 25 A.2. pEp Communication Type . . . . . . . . . . . . . . . . . 25
A.3. Abstract Crypto API examples . . . . . . . . . . . . . . 26 A.3. Abstract Crypto API examples . . . . . . . . . . . . . . 27
A.3.1. Encrypting a Message . . . . . . . . . . . . . . . . 26 A.3.1. Encrypting a Message . . . . . . . . . . . . . . . . 27
A.3.2. Decrypting a Message . . . . . . . . . . . . . . . . 27 A.3.2. Decrypting a Message . . . . . . . . . . . . . . . . 28
A.3.3. Obtain Common Trustwords . . . . . . . . . . . . . . 29 A.3.3. Obtain Common Trustwords . . . . . . . . . . . . . . 30
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 29 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 30
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 30 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Secure and private communications are vital for many different Secure and private communications are vital for many different
reasons, and there are particular properties that privacy-preserving reasons, and there are particular properties that privacy-preserving
protocols need to fulfill in order to best serve users. In protocols need to fulfill in order to best serve users. In
particular, [RFC8280] has identified and documented important particular, [RFC8280] has identified and documented important
principles such as data minimization, the end-to-end principle, and principles such as data minimization, the end-to-end principle, and
interoperability as integral properties for access to the Internet interoperability as integral properties which enable access to Human
for human rights purposes. While (partial) implementations of these Rights. Today's applications widely lack privacy support that
concepts are already available, today's applications widely lack ordinary users can easily adapt. The pretty Easy privacy (pEp)
privacy support that ordinary users can easily handle. The pretty protocols generally conform to the principles outlined in [RFC8280],
Easy privacy (pEp) protocols generally conform with the principles and, as such, can facilitate the adoption and correct usage of secure
outlined in [RFC8280] as a matter of course, and as such can be used and private communications technology.
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), and verify their daily written encrypt, anonymize (where possible), and verify their daily written
digital communications. This is achieved by building upon already digital communications. This is achieved by building upon already
existing standards and tools and automating each step a user needs to existing standards and tools and automating each step a user needs to
carry out in order to engage in secure end-to-end encrypted carry out in order to engage in secure end-to-end encrypted
communications. Significantly, the pEp protocols describe how do to communications. Significantly, the pEp protocols describe how do to
this without dependence on centralized infrastructures. this without dependence on centralized infrastructures.
In particular, pEp proposes automatation of key management, key The pEp project emerged from the CryptoParty movement. During that
discovery and synchronization of secret key material by an in-band time, the initiators learned that while step-by-step guides can help
peer-to-peer approach. 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, 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 and as the only manual step users carry out in the course of the
protocols, the proposed Trustwords [I-D.birk-pep-trustwords] protocols, the proposed Trustwords [I-D.birk-pep-trustwords]
mechanism uses natural language representations of two peers' mechanism uses natural language representations of two peers'
fingerprints for users to verify their trust in a paired fingerprints for users to verify their trust in a paired
communication channel. communication channel.
[[ Note: The pEp initiators learned from the CryptoParty movement,
from which the project emerged, that while step-by-step guides can be
helpful for some users to engage in secure end-to-end communications,
for the vast majority of users, it is both more effective and more
convenient to have these step-by-step procedures put into actual code
(as such, following a protocol) and thus automating the initial
configuration and whole usage of cryptographic tools.]]
The privacy-by-default principles that pEp introduces are in The privacy-by-default principles that pEp introduces are in
accordance with the perspective outlined in [RFC7435], aiming to accordance with the perspective outlined in [RFC7435], aiming to
provide opportunistic security in the sense of "some protection most provide opportunistic security in the sense of "some protection most
of the time". This is done, however, with the subtle but important of the time". This is done, however, with the subtle but important
difference that when privacy is weighed against security, the choice difference that when privacy is weighed against security, the choice
defaults to privacy. Therefore, data minimization is a primary goal defaults to privacy. Therefore, data minimization is a primary goal
in pEp (e.g., hiding subject lines and headers unnecessary for email in pEp (e.g., hiding subject lines and headers unnecessary for email
transport inside the encrypted payload of a message). 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 different standardized and widely-used pEp's goal is to bridge different standardized and widely-used
communications channels such that users can reach communications communications channels such that users can reach communications
partners in the most privacy-enhancing way possible. partners in the most privacy-enhancing way possible.
1.1. Relationship to other pEp documents 1.1. Relationship to other pEp documents
While this document describes the general concept of pEp, other While this document outlines the general design choices and
documents build on top of this. These documents define other parts principles of pEp, other related documents specialize in more
of the pEp environment as follows: particular aspects of the model, or the application of pEp on a
specific protocol like as follows:
1. pEp enhanced applications (e.g., pEp Email 1. pEp-enabled applications (e.g., pEp email
[I-D.marques-pep-email]). [I-D.marques-pep-email]).
2. Helper functions for interaction with peers (e.g., pEp Handshake 2. Helper functions for peer interaction, which facilitate
[I-D.marques-pep-handshake]) that assist the user with handling understanding and handling of the cryptographic aspects of pEp
and understanding cryptographic parts that he/she needs to be implementation for users (e.g., pEp Handshake
aware of. [I-D.marques-pep-handshake]).
3. Helper functions for interactions between a user's own devices 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 which give the user the ability to run pEp applications on
to run pEp applications on different devices (such as computer, different devices at the same time, such as a computer, mobile
mobile phone or tables) at the same time. phone, or tablets (e.g., pEp KeySync
[I-D.hoeneisen-pep-keysync]).
In addition, there are documents that do not directly depend on this In addition, there are documents that do not directly depend on this
one, but provide generic functions needed in pEp, e.g., IANA one, but provide generic functions needed in pEp, e.g., IANA
Registration of Trustword Lists [I-D.birk-pep-trustwords]. Registration of Trustword Lists [I-D.birk-pep-trustwords].
[[At this stage it is not yet clear to us how many of our [[ Note: 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 where we can
we can safely refer to already existing RFCs to make clear on which safely refer to already existing RFCs to clarify which RFCs we rely
RFCs we already rely.]] on. ]]
2. Terms 1.2. Requirements Language
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 pEp Handshake: The process when Alice - e.g., in-person or via 1.3. Terms
phone - contacts Bob to verify Trustwords (or by fallback:
fingerprints) is called pEp Handshake. The following terms are defined for the scope of this document:
o pEp Handshake: The process of one user contacting another over an
independent channel in order to verify Trustwords (or by fallback:
fingerprints). This can be done in-person or through established
verbal communication channels, like a phone call.
[I-D.marques-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], 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."
o Man-in-the-middle attack (MITM): cf. [RFC4949] o Man-in-the-middle (MITM) attack: cf. [RFC4949], 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."
3. Protocol's Core Design Principles 2. Protocol's Core Design Principles
3.1. Privacy by Default 2.1. Privacy by Default
The pEp protocols are to intended specifically to ensure privacy. pEp's most important goal is to ensure privacy above all else. To
There exist cases in the secure communications ecosystem, however, clarify, pEp's protocol defaults are designed to maximize both
where achieving privacy is in direct contradiction to security security and privacy, but in the few cases where achieving both more
though. For instance, in PGP's Web of Trust, relations between privacy and more security are in conflict, pEp chooses more privacy.
people and trust levels are exposed to the public. Additionally, the
privacy of queries is not ensured in such a model when obtaining keys
from remote locations. Within the pEp protocols, when security and
privacy goals are not in conflict, then the protocols are designed to
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 contrast to pEp's prioritization of user privacy, OpenPGP's Web-
obtained from remote locations as this constitutes a privacy breach. 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).
3.2. Data Minimization [[*TODO*: Fix the wording and reference to XPKI, S/MIME]].
Another important design goal is data minimization, which includes In pEp messaging (e.g., when using HTML) content and information
data spareness and hiding all technically concealable information SHALL NOT be obtained from remote locations as this constitutes a
when possible. privacy breach.
3.3. Interoperability 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.
The pEp propositions seek to be interoperable with already-widespread 2.2. Data Minimization
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.
Therefore, pEp abides by the following guidelines: Data minimization keeps data spare and hides all technically
concealable information whenever possible. It is an important design
goal of pEp.
2.3. Interoperability
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 [RFC1122]: "Be liberal in what you accept, and
conservative in what you send."
Particularly, pEp applies Postel's principle as follows:
o pEp is conservative (strict) in requirements for pEp o pEp is conservative (strict) in requirements for pEp
implementations and how they interact with pEp or other implementations and how they interact with pEp or other compatible
(messaging) implementations. implementations.
o pEp is liberal in accepting input from non-pEp implementations o pEp liberally accepts input from non-pEp implementations. For
(e.g., it will not produce, but will support the decryption of, example, in email, pEp will not produce outgoing messages, but
PGP/INLINE formats). will transparently support decryption of incoming PGP/INLINE
messages.
o Where pEp requires divergence from an RFC for privacy reasons o Finally, where pEp requires divergence from established RFCs due
(e.g., from OpenPGP propositions as defined in [RFC4880], options to privacy concerns (e.g., from OpenPGP propositions as defined in
SHOULD be implemented to empower the user to override pEp's [OpenPGP], options SHOULD be implemented which empower the user to
defaults. override pEp's defaults.
3.4. Peer-to-Peer (P2P) 2.4. Peer-to-Peer
Messaging and verification processes in pEp are designed to work in a Messaging and verification processes in pEp are designed to work in a
peer-to-peer (P2P) manner, without the involvement of intermediaries. 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 pEp implementations, both in the case of whatsoever needed for pEp implementations, both in the case of
verification of peers and for the actual encryption. verification of peers and for the actual encryption.
However, implementers of pEp MAY provide options for interoperation However, implementers of pEp MAY provide options for interoperation
with providers of centralized infrastructures (e.g., to enable users with providers of centralized infrastructures (e.g., to enable users
skipping to change at page 7, line 22 skipping to change at page 8, line 4
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 pEp implementations, both in the case of whatsoever needed for pEp implementations, both in the case of
verification of peers and for the actual encryption. verification of peers and for the actual encryption.
However, implementers of pEp MAY provide options for interoperation However, implementers of pEp MAY provide options for interoperation
with providers of centralized infrastructures (e.g., to enable users with providers of centralized infrastructures (e.g., to enable users
to 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.
[I-D.marques-pep-rating]) to users of pEp (e.g., when interoperating [I-D.marques-pep-rating]) to users of pEp (e.g., when interoperating
with peers using S/MIME) by default. with peers using S/MIME) by default.
3.5. User Experience (UX) 2.5. User Interaction
Implementers of pEp MUST take special care not to confuse users with Implementers of pEp MUST take special care not to overburden users
technical terms, especially those of cryptography (e.g., "keys", with technical terms, especially those specific to cryptography, like
"certificates" or "fingerprints"), unless users explicitly ask for "keys", "certificates", or "fingerprints". Users may explicitly opt
such terms; i.e., advanced settings MAY be available, and in some for exposure to these terms; i.e., advanced settings MAY be
cases further options may even be required. However, those SHALL NOT available, and in some cases, these options may be required.
be unnecessarily exposed to users of pEp implementations at first However, these options SHALL NOT be exposed to users of pEp
glance. implementations unless necessary or opted-for."
The authors believe widespread adoption of end-to-end cryptography is The authors believe that widespread adoption of end-to-end
much less of a problem if the users are not confronted with the need cryptography is possible if users are not required to understand
to understand cryptography; that is to say, a central goal of pEp of cryptography and key management. This belief forms the central goal
the pEp protocol is that users can just rely on the principles of of pEp, which is that users can simply rely on the principles of
Privacy by Default. Privacy by Default.
As a consequence, this means that users must not wait for On the other hand, to preserve usability, users MUST NOT be required
cryptographic tasks (e.g., key generation or public key retrieval) to to wait for cryptographic tasks such as key generation to complete
finish before being able to have their respective message clients before being able to use their respective message client for its
ready to communicate. The end result of this is that pEp default purpose. In short, pEp implementers MUST ensure that the
implementers MUST ensure that the ability to draft, send and receive ability to draft, send, and receive messages is always preserved,
messages is always preserved - even if that means a message is sent even if that means a message is sent unencrypted, in accordance with
out unencrypted, thus being in accordance with the Opportunistic the Opportunistic Security approach outlined in [RFC7435].
Security approach outlined in [RFC7435].
In turn, pEp implementers MUST ensure that a discernible privacy In turn, pEp implementers MUST ensure that an unambiguous privacy
status is clearly visible to the user - on a per-contact as well as status is clearly visible to the user, both on a per-contact as well
per-message level - so that users easily understand which level of as per-message level. This allows users to see at a glance both the
privacy messages are about to be sent with or were received with, privacy level for the message and the trust level of its intended
respectively. recipients before choosing to send it.
[[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
part of RFCs. However, in order to encourage massive adoption of not part of RFCs. However, in order to encourage massive adoption of
secure end-to-end encryption while at the same time avoiding putting secure end-to-end encryption while at the same time avoiding putting
users at risk, we believe certain straightforward signaling users at risk, we believe certain straightforward signaling
requirements for users to be a good idea, just as is currently done requirements for users to be a good idea, just as it is currently
for already-popular instant messaging services.]] done for already-popular instant messaging services. ]]
4. Specific Elements in pEp
4.1. pEp identity system
In pEp, users MUST have the ability to have multiple different 3. Identity System
identities.
pEp users MUST have the option to choose different identities. This Everyone has the right to choose how to reveal themselves to the
allows an Internet user to decide how to reveal himself/herself to world, both offline and online. This is an important element to
the world and is an important element in order to achieve privacy. 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 These different identities MUST NOT be externally correlatable with
each other by default. On the other hand, combining different each other by default. On the other hand, combining different
identities when such information is known MUST be supported (alias identities when such information is known MUST be supported (alias
support). support).
4.2. Identifiers 3.1. User
4.2.1. Key
A key is an OpenPGP-compatible asymmetric key pair. Other formats
and temporary symmetrical keys can be generated by Key Mapping.
Keys in pEp are identified by the full fingerprint (fpr) of the
public key.
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 A user is identified by a user ID (user_id). The user_id SHOULD be a
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 the own
then it has PEP_OWN_USERID "pEp_own_userId" as user_id. user does not have a user_id, then it is assigned a "pEp_own_userId"
instead.
A user can have a default key. (cf. Section 4.2.1)
4.2.3. Identity A user can have a default key. [[ TODO: Provide ref explaining this.
]]
An identity is a (possibly pseudonymous) representation of a user 3.2. Address
encapsulating how this user appears in the network.
An identity is defined by the mapping of user_id to address. If no A pEp address is a network address, e.g., an SMTP address or another
user_id is known, it is guessed by mapping of username and address. Universal Resource Identifier (URI).
An identity can have a temporary user_id as a placeholder until a [[ Note: It might be necessary to introduce further addressing
real user_id is known. schemes through IETF contributions or IANA registrations, e.g.,
implementing pEp to bridge to popular messaging services with no URIs
defined. ]]
An identity can have a default key. (cf. Section 4.2.1) 3.3. Identity
[[ Note: This is the reason why in current pEp implementations for An identity is a representation of a user, encapsulating how this
each (email) account a different key pair is created, which allows a user appears within the network of a messaging system. This
user to retain different identities. ]] representation may or may not be pseudonymous in nature.
In Appendix A.1 you can find how a pEp identity is defined in the An identity is defined by mapping a user_id to an address. If no
reference implementation of the pEp Engine. user_id is known, it is guessed by mapping a username to an address.
4.2.4. Address An identity can have a temporary user_id as a placeholder until a
real user_id is known.
An address is a network address, e.g., an SMTP address or another For this reason, in pEp a different key pair for each (e.g., email)
URI. 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.
[[ Note: It might be necessary to introduce further addressing A user MAY have a default key; each identity a user has MAY have a
schemes through IETF contributions or IANA registrations, e.g., default key (of its own).
implementing pEp to bridge to popular messaging services with no URIs
defined. ]]
4.3. Example: Difference between pEp and OpenPGP [[ TODO: Provide ref explaining this. ]]
+--------------------+--------------+-------------------------------+ In Appendix A.1, the definition of a pEp identity can be found
| pEp | OpenPGP | Comments | according to the reference implementation by the pEp engine.
+--------------------+--------------+-------------------------------+
| user_id | (no concept) | ID for a person, i.e. a |
| | | contact |
| | | |
| username + address | uid | comparable only for email |
| | | |
| fpr | fingerprint | used as key ID in pEp |
| | | |
| (no concept) | Key ID | does not exist in pEp |
+--------------------+--------------+-------------------------------+
5. Key Management 4. 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 automated. communications, key management in pEp MUST be automated.
5.1. Key Generation 4.1. Key Generation
A pEp implementation MUST ensure that cryptographic keys for every A pEp implementation MUST ensure that cryptographic keys for every
identity configured are available. If a corresponding key pair for configured identity are available. If a corresponding key pair for
the identity of a user is found and said identity fulfills the the identity of a user is found and said identity fulfills the
requirements (e.g., for email, as set out in requirements (e.g., for email, as set out in
[I-D.marques-pep-email]), said key pair MUST be reused. Otherwise a [I-D.marques-pep-email]), said key pair MUST be reused. Otherwise a
new key pair MUST be generated. This may be carried out instantly new key pair MUST be generated. This may be carried out instantly
upon its configuration. upon its configuration.
On devices with limited processing power (e.g., mobile devices) the 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 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, this is the case, users SHOULD NOT be stopped from communicating,
i.e., the key generation process SHOULD be carried out in the i.e., the key generation process SHOULD be carried out in the
background. background.
5.2. Private Keys 4.2. Private Keys
5.2.1. Storage 4.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 is 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 (cf. Section 3.4). principle to rely on centralized infrastructures (cf. Section 2.4).
This also applies for pEp implementations created for applications This also applies for pEp implementations created for applications
not residing on a user's device (e.g., web-based MUAs). In such 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 cases, pEp implementations MUST be done in a way such that the
locally-held private key can neither be directly accessed nor leaked locally-held private key can neither be directly accessed nor leaked
to the outside world. 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. ]]
Cf. Section 7.1 for a means to synchronize private keys among Cf. Section 6.1 for a means to synchronize private keys among
different devices of the same network address in a secure manner. different devices of the same network address in a secure manner.
5.2.2. Passphrase 4.2.2. Passphrase
Passphrases to protect a user's private key MUST be supported by pEp 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 implementations, but MUST NOT be enforced by default. That is, if a
pEp implementation finds a suitable (i.e., secure enough) pEp implementation finds a suitable (i.e., secure enough)
cryptographic setup, which uses passphrases, pEp implementations MUST cryptographic setup, which uses passphrases, pEp implementations MUST
provide a way to unlock the key. However, if a new key pair is 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. generated for a given identity, no passphrase MUST be put in place.
The authors assume that the enforcement of secure (i.e., unique and The authors assume that the enforcement of secure (i.e., unique and
long enough) passphrases would massively reduce the number of pEp long enough) passphrases would massively reduce the number of pEp
users (by hassling them), while providing little to no additional users (by hassling them), while providing little to no additional
privacy for the common cases of passive monitoring being carried out privacy for the common cases of passive monitoring being carried out
by corporations or state-level actors. by corporations or state-level actors.
5.2.3. Private Key Export / Import 4.3. Key Reset
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 4.4. Public Key Distribution
As the key is available (cf. Section 5.3) implementers of pEp are As the key is available (cf. Section 4.1) implementers of pEp are
REQUIRED to ensure that the identity's public key is attached to REQUIRED to ensure that the identity's public key is attached to
every outgoing message. However, this MAY be omitted if the peer has every outgoing message. However, this MAY be omitted if the peer has
previously received a message encrypted with the public key of the previously received a message encrypted with the public key of the
sender. 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.
4.4.1. UX Considerations
Implementers of pEp SHALL prevent the display of public keys attached 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 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. 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 4.4.2. No addition of unnecessary metadata
public key. This is considered unnecessary information leakage as it
may affect user privacy, which depends also on a country's data Metadata, such as email headers, MUST NOT be added in order to
retention laws. Furthermore, this affects interoperability to announce a user's public key. This is considered unnecessary
existing users (e.g., in the OpenPGP field) that have no notion of information leakage, may affect user privacy, and may be subject to a
such header fields and thus lose the ability to import any such keys country's data retention laws (cf. Section 2.2). Furthermore, this
distributed this way. It SHOULD, though, be supported to obtain may affect interoperability to existing users that have no knowledge
other users' public keys by extracting them from respective header of such header fields, such as users of OpenPGP in email, and lose
fields of received messages (in case such approaches get widespread). 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.
4.4.3. No centralized public key storage or retrieval by default
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 MUST NOT be uploaded to any Keys generated or obtained by pEp clients MUST NOT be uploaded to any
(intermediate) keystore locations without the user's explicit (intermediate) keystore locations without the user's explicit
consent. consent.
5.4. Key Reset 4.4.4. Example message flow
[[ TODO: This section will explain how to deal with keys no longer
valid, e.g. if leaked ]]
6. Trust Management
The following example roughly describes a pEp scenario with a typical The following example roughly describes a pEp scenario with a typical
initial message flow to demonstrate key exchange and basic trust initial message flow to demonstrate key exchange and basic trust
management: 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:
1. Alice - knowing nothing of Bob - sends a message to Bob. As Alice 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. has no public key from Bob, this message is sent out unencrypted.
However, Alice's public key is automatically attached. However, Alice's public key is automatically attached.
2. Bob can just reply to Alice and - as he received her public key - 2. Bob receives Alice's message and her public key. He is able to
his messaging client is now able to encrypt the message. At this reply to her and encrypt the message. His public key is
point the rating for Alice changes to "encrypted" in Bob's automatically attached to the message. Because he has her public
messaging client, which (UX-wise) can be displayed using yellow key now, Alice's rating in his message client changes to
color (cf. Section 6.3). 'encrypted'. From a UX perspective, this status is displayed in
yellow (cf. Section 5.3).
3. Alice receives Bob's key. As of now Alice is also able to send 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" secure messages to Bob. The rating for Bob changes to "encrypted"
(with yellow color) in Alice's messaging client (cf. (with yellow color) in Alice's messaging client (cf.
Section 6.3). Section 5.3).
4. If Alice and Bob want to prevent man-in-the-middle (MITM) 4. 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 Section 5.3.
5. If Alice and Bob want to prevent man-in-the-middle (MITM)
attacks, they can engage in a pEp Handshake comparing their so- attacks, they can engage in a pEp Handshake comparing their so-
called Trustwords (cf. Section 6.2) and confirm this process if called Trustwords (cf. Section 5.2) and confirm this process if
those match. After doing so, their identity rating changes to those match. After doing so, their identity rating changes to
"encrypted and authenticated" (cf. Section 6.3), which (UX-wise) "encrypted and authenticated" (cf. Section 5.3), which (UX-wise)
can be displayed using a green color. can be displayed using a green color. See also Section 5.
As color code changes for an identity, it is also applied to future 6. Alice and Bob can encrypt now, but they are not yet
messages to/from this identity. 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.
Section 5.2) 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.
Section 5.
----- ----- ----- -----
| A | | B | | A | | B |
----- ----- ----- -----
| | | |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| auto-generate key pair | | auto-generate key pair | | auto-generate key pair | | auto-generate key pair |
| (if no key yet) | | (if no key yet) | | (if no key yet) | | (if no key yet) |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| | | |
skipping to change at page 14, line 38 skipping to change at page 14, line 38
| | | |
| B sends message to A (Public Key | | B sends message to A (Public Key |
| attached) / signed and ENCRYPTED | | attached) / signed and ENCRYPTED |
|<------------------------------------------+ |<------------------------------------------+
| | | |
+-----------------------+ | +-----------------------+ |
| Privacy Status for B: | | | Privacy Status for B: | |
| *Encrypted* | | | *Encrypted* | |
+-----------------------+ | +-----------------------+ |
| | | |
| A and B sucessfully compare their | | A and B successfully compare their |
| Trustwords over an alternative channel | | Trustwords over an alternative channel |
| (e.g., phone line) | | (e.g., phone line) |
|<-- -- -- -- -- -- -- -- -- -- -- -- -- -->| |<-- -- -- -- -- -- -- -- -- -- -- -- -- -->|
| | | |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Privacy Status for B: | | Privacy Status for A: | | Privacy Status for B: | | Privacy Status for A: |
| *Trusted* | | *Trusted* | | *Trusted* | | *Trusted* |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| | | |
6.1. Privacy Status 4.5. Key Reset
[[ TODO: This section will explain how to deal with invalid keys,
e.g., if expired or (potentially) leaked. ]]
5. Trust Management
[[ TODO: Intro ]]
5.1. Privacy Status
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 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.
6.2. Handshake 5.2. Handshake
To establishing trust between peers and to upgrade Privacy Status, To establishing trust between peers and to upgrade Privacy Status,
pEp defines a handshake, which is specified in pEp defines a handshake, which is specified in
[I-D.marques-pep-handshake]. [I-D.marques-pep-handshake].
In pEp, Trustwords [I-D.birk-pep-trustwords] are used for users to In pEp, Trustwords [I-D.birk-pep-trustwords] are used for users to
compare the authenticity of peers in order to mitigate MITM attacks. compare the authenticity of peers in order to mitigate MITM attacks.
By default, Trustwords MUST be used to represent two peers' By default, Trustwords MUST be used to represent two peers'
fingerprints of their public keys in pEp implementations. fingerprints of their public keys in pEp implementations.
In order to retain compatibility with peers not using pEp In order to retain compatibility with peers not using pEp
implementations (e.g., Mail User Agents (MUAs) with OpenPGP implementations (e.g., Mail User Agents (MUAs) with OpenPGP
implementations without Trustwords), it is REQUIRED that pEp implementations without Trustwords), it is REQUIRED that pEp
implementers give the user the choice to show both peers' implementers give the user the choice to show both peers'
fingerprints instead of just their common Trustwords. fingerprints instead of just their common Trustwords.
6.3. Trust Rating 5.3. Trust Rating
pEp includes a Trust Rating system defining Rating and Color Codes to pEp includes a Trust Rating system defining Rating and Color Codes to
express the Privacy Status of a peer or message express the Privacy Status of a peer or message
[I-D.marques-pep-rating]. The ratings are labeled, e.g., as [I-D.marques-pep-rating]. The ratings are labeled, e.g., as
"Unencrypted", "Encrypted", "Trusted", "Under Attack", etc. The "Unencrypted", "Encrypted", "Trusted", "Under Attack", etc. The
Privacy Status in its most general form is expressed with traffic Privacy Status in its most general form is expressed with traffic
lights semantics (and respective symbols and texts), whereas the lights semantics (and respective symbols and texts), whereas the
three colors yellow, green and red can be applied for any peer or 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. (and thus private) a communication was or ought to be considered.
The pEp Trust Rating system with all its states and respective The pEp Trust Rating system with all its states and respective
representations to be followed is outlined in representations to be followed is outlined in
[I-D.marques-pep-rating]. [I-D.marques-pep-rating].
Note: An example for the rating of communication types, the Note: An example for the rating of communication types, the
definition of the data structure by the pEp Engine reference definition of the data structure by the pEp Engine reference
implementation is provided in Appendix A.2. implementation is provided in Appendix A.2.
6.4. Trust Revoke 5.4. Trust Revoke
[[ TODO: This section will explain how to deal with the situation [[ 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 when a peer can no longer be trusted, e.g., if a peer's device is
compromised. ]] compromised. ]]
7. Synchronization 6. Synchronization
An important feature of pEp is to assist the user to run pEp An important feature of pEp is to assist the user to run pEp
applications on different devices, such as computer, mobile phone or applications on different devices, such as personal computers, mobile
tables, at the same time. Therefore state needs to be synchronized phones and tablets, at the same time. Therefore, state needs to be
among the different devices. synchronized among the different devices.
7.1. Private Key Synchronization 6.1. Private Key Synchronization
A decentralized proposition - the pEp Key Synchronization protocol. The pEp KeySync protocol (cf. [I-D.hoeneisen-pep-keysync]) is a
[E-D.birk-pep-keysync] - defines how pEp users can distribute their decentralized proposition which defines how pEp users can distribute
private keys among different devices in a secure and trusted manner: their private keys among their different devices in a user-
this allows Internet users to read their messages across their authenticated manner. This allows users to read their messages
different devices, when sharing a common address (e.g., the same across their various devices, as long as they share a common address,
email account). such as an email account.
7.2. Trust Synchronization 6.2. Trust Synchronization
[[ TODO: This section will explain how trust and other related state [[ TODO: This section will explain how trust and other related state
is synchronized among different devices in a secure manner. ]] is synchronized among different devices in a user-authenticated
manner. ]]
8. Interoperability 7. Interoperability
pEp aims to be interoperable with existing applications designed to pEp aims to be interoperable with existing applications designed to
enable privacy, e.g., OpenPGP and S/MIME in email. enable privacy, e.g., OpenPGP and S/MIME in email.
9. Options in pEp 8. 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.
9.1. Option "Passive Mode" 8.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
(cf. Section 5.3). For situations where a sender wants to ensure message (cf. Section 4.4). For situations where a sender wants to
that it only attaches a public key to an Internet user which has a ensure that it only attaches a public key to an Internet user which
pEp implementation, a Passive Mode MUST be available. has a pEp implementation, a Passive Mode MUST be made available.
9.2. Option "Disable Protection" 8.2. Option "Disable Protection"
Using this option, protection can be disabled generally or Using this option, protection can be disabled generally or
selectively. Implementers of pEp MUST provide an option "Disable selectively. Implementers of pEp MUST provide an option "Disable
Protection" to allow a user to disable encryption and signing for: Protection" to allow a user to disable encryption and signing for:
1. all communication 1. all communication
2. specific contacts 2. specific contacts
3. specific messages 3. specific messages
The public key still attached, unless the option "Passive Mode" (cf. The public key still attached, unless the option "Passive Mode" (cf.
Section 9.1) is activated at the same time. Section 8.1) is activated at the same time.
9.3. Option "Extra Keys" 8.3. Option "Extra Keys"
For internal environments there may be a need to centrally decrypt 8.3.1. Use Case for Organizations
persons' messages for archiving or other legal purposes (e.g., in the
contexts of public offices and enterprises) by authorized personnel.
Therefore, pEp implementers MAY provide an "Extra Keys" option where
a message gets encrypted with at least one additional public key.
The corresponding secret key(s) are intended to be held (safely and
securely), e.g., by CISO staff or other authorized personnel for such
an organization.
The Extra Keys feature MUST NOT be activated by default for any For internal or enterprise environments, authorized personnel may
network address and is intended to be an option only for need to centrally decrypt user messages for archival or other legal
organizational identities and their corresponding network addresses purposes. Therefore, pEp implementers MAY provide an "Extra Keys"
and accounts - not for addresses used for private purposes. That is, option in which a message is encrypted with at least one additional
the Extra Keys feature is a feature which SHOULD NOT apply to all public key. The corresponding secret key(s) are intended to be
identities a user might posses, even if activated. secured by CISO staff or other authorized personnel for the
organization.
9.4. Option "Blacklist Keys" 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.
An option "Blacklist Keys" MUST be provided for an advanced user to 8.3.2. Use Case for Key Synchronization
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
deleted. It MUST still be possible to verify and decipher past
communications.
10. Security Considerations 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.
8.4. Option "Blacklist Keys"
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.
9. 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 a 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.
11. Privacy Considerations 10. Privacy Considerations
[[ TODO ]] [[ TODO ]]
11. IANA Considerations
This document has no actions for IANA.
12. Implementation Status 12. Implementation Status
12.1. Introduction 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
skipping to change at page 21, line 13 skipping to change at page 21, line 47
point of view. point of view.
14. 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 significant contributions to the development of this provided significant contributions to the development of this
document: Volker Birk, Krista Bennett, and S. Shelburn. document: Volker Birk, Krista Bennett, and S. Shelburn.
Furthermore, the authors would like to thank the following people who Furthermore, the authors would like to thank the following people who
who provided helpful comments and suggestions for this document: 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- Alexey Melnikov, Athena Schumacher, Ben Campbell, Brian Trammell,
Peter Dittler, Iraklis Symeonidis, Mirja Kuehlewind, Neal Walfield, Bron Gondwana, Daniel Kahn Gillmor, Enrico Tomae, Eric Rescorla,
Pete Resnick, Russ Housley, and Stephen Farrel. Gabriele Lenzini, Hans-Peter Dittler, Iraklis Symeonidis, Kelly
Bristol, Mirja Kuehlewind, Nana Kerlstetter, 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]
15. References 15. References
15.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
skipping to change at page 21, line 41 skipping to change at page 22, line 30
[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>.
15.2. Informative References 15.2. Informative References
[E-D.birk-pep-keysync]
Birk, V. and H. Marques, "pretty Easy privacy (pEp): Key
Synchronization Protocol", June 2018,
<https://pep.foundation/dev/repos/internet-
drafts/file/tip/pep-keysync/
draft-birk-pep-keysync-NN.txt>.
Early draft
[I-D.birk-pep-trustwords] [I-D.birk-pep-trustwords]
Birk, V., Marques, H., and B. Hoeneisen, "IANA Hoeneisen, B. and H. Marques, "IANA Registration of
Registration of Trustword Lists: Guide, Template and IANA Trustword Lists: Guide, Template and IANA Considerations",
Considerations", draft-birk-pep-trustwords-02 (work in draft-birk-pep-trustwords-04 (work in progress), July
progress), June 2018. 2019.
[I-D.hoeneisen-pep-keysync]
Hoeneisen, B. and H. Marques, "pretty Easy privacy (pEp):
Key Synchronization Protocol", draft-hoeneisen-pep-
keysync-00 (work in progress), July 2019.
[I-D.marques-pep-email] [I-D.marques-pep-email]
Marques, H., "pretty Easy privacy (pEp): Email Formats and Marques, H., "pretty Easy privacy (pEp): Email Formats and
Protocols", draft-marques-pep-email-02 (work in progress), Protocols", draft-marques-pep-email-02 (work in progress),
October 2018. October 2018.
[I-D.marques-pep-handshake] [I-D.marques-pep-handshake]
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
Contact and Channel Authentication through Handshake", Contact and Channel Authentication through Handshake",
draft-marques-pep-handshake-01 (work in progress), October draft-marques-pep-handshake-03 (work in progress), July
2018. 2019.
[I-D.marques-pep-rating] [I-D.marques-pep-rating]
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
Mapping of Privacy Rating", draft-marques-pep-rating-00 Mapping of Privacy Rating", draft-marques-pep-rating-02
(work in progress), July 2018. (work in progress), July 2019.
[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. [OpenPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007, DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>. <https://www.rfc-editor.org/info/rfc4880>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[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 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights
Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
October 2017, <https://www.rfc-editor.org/info/rfc8280>. October 2017, <https://www.rfc-editor.org/info/rfc8280>.
[SRC.enigmailpep] [SRC.enigmailpep]
"Source code for Enigmail/pEp", July 2018, "Source code for Enigmail/pEp", July 2019,
<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)", July 2018, (engine and adapters)", July 2018,
<https://pep.foundation/dev/>. <https://pep.foundation/dev/>.
[SRC.pepforandroid] [SRC.pepforandroid]
"Source code for pEp for Android", July 2018, "Source code for pEp for Android", July 2019,
<https://pep-security.lu/gitlab/android/pep>. <https://pep-security.lu/gitlab/android/pep>.
[SRC.pepforios] [SRC.pepforios]
"Source code for pEp for iOS", July 2018, "Source code for pEp for iOS", July 2019,
<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", July 2018, "Source code for pEp for Outlook", July 2019,
<https://pep-security.lu/dev/repos/pEp_for_Outlook/>. <https://pep-security.lu/dev/repos/pEp_for_Outlook/>.
Appendix A. Code Excerpts 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).
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/
skipping to change at page 28, line 9 skipping to change at page 29, line 9
// 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 // or PEP_CANNOT_REENCRYPT if message was decrypted (and
// possibly verified) but a reencryption operation is // possibly verified) but a reencryption operation is
// expected by the 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
skipping to change at page 29, line 52 skipping to change at page 30, 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-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
o draft-birk-pep-03: o draft-birk-pep-03:
* Major restructure of the document * Major restructure of the document
* Adapt authors to the actual authors and extend acknowledgement * Adapt authors to the actual authors and extend Acknowledgments
section section
* Added several new sections, e.g., Key Reset, Trust Revoke, * Added several new sections, e.g., Key Reset, Trust Revoke,
Trust Synchronization, Private Key Export / Import, Privacy Trust Synchronization, Private Key Export / Import, Privacy
Considerations (content yet mostly TODO) Considerations (content yet mostly TODO)
* Added reference to HRPC work / RFC8280 * Added reference to HRPC work / RFC8280
+ Added text and figure to better explain pEp's automated Key + Added text and figure to better explain pEp's automated Key
Exchange and Trust management (basic message flow) Exchange and Trust management (basic message flow)
skipping to change at page 30, line 48 skipping to change at page 32, line 12
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 Shorten Introduction and Abstract
o References to RFC6973 (Privacy Considerations) o References to RFC6973 (Privacy Considerations)
o Add references to prior work, and what differs here - PEM (cf. o Add references to prior work, and what differs here - PEM (cf.
RFC1421-1424) 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 (to S/MIME) o Explain Concept of Key Mapping (e.g. to S/MIME, which is to be
refined in pEp application docs auch as pEp email
[I-D.marques-pep-email])
o Add more information to deal with organizational requirements o Add more information to deal with organizational requirements
o Add text to Key Reset (Section 5.4) as well as reference as soon o Add text to Key Reset (Section 4.3) as well as reference as soon
as available as available
o Add text to Trust Revoke (Section 6.4) as well as reference as o Add text to Trust Revoke (Section 5.4) as well as reference as
soon as available soon as available
o Add text to Trust Synchronization (Section 7.2) as well as o Add text to Trust Synchronization (Section 6.2) as well as
reference as soon as available reference as soon as available
o Add references to Private Key Export / Import (Section 5.2.3) as o Add text to Privacy Considerations (Section 10)
soon as reference available
o Add text to Privacy Considerations (Section 11) o Scan for leftovers of email-specific stuff and move it to pEp
email I-D [I-D.marques-pep-email], while replacing it herein with
generic descriptions.
Authors' Addresses Authors' Addresses
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/
Claudio Luck
pEp Foundation
Oberer Graben 4
CH-8400 Winterthur
Switzerland
Email: claudio.luck@pep.foundation
URI: https://pep.foundation/
Bernie Hoeneisen Bernie Hoeneisen
Ucom Standards Track Solutions GmbH Ucom Standards Track Solutions GmbH
CH-8046 Zuerich CH-8046 Zuerich
Switzerland Switzerland
Phone: +41 44 500 52 44 Phone: +41 44 500 52 40
Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: https://ucom.ch/ URI: https://ucom.ch/
 End of changes. 129 change blocks. 
369 lines changed or deleted 453 lines changed or added

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