new abstract and intro

pep/draft-birk-pep.mkd

@@ -11,21 +11,24 @@ pi: [toc, sortrefs, symrefs, comments]
 
 author:
 # {::include ../shared/author_tags/volker_birk.mkd}
+{::include ../shared/author_tags/claudio_luck.mkd}
 {::include ../shared/author_tags/hernani_marques.mkd}
 # {::include ../shared/author_tags/shelburn.mkd}
 {::include ../shared/author_tags/bernie_hoeneisen.mkd}
 
 normative:
-  RFC2119:
   RFC4949:
   RFC7435:
 
 informative:
-  RFC4880:
+  MIME: RFC2045
+  OpenPGP: RFC4880
+  SMIME: RFC5751
 #  RFC6973:
   RFC7258:
   RFC7942:
   RFC8280:
+  TLS: RFC8446
   I-D.marques-pep-email:
   I-D.birk-pep-trustwords:
   I-D.marques-pep-rating:
@@ -41,115 +44,126 @@ informative:
 
 --- abstract
 
-The pretty Easy privacy (pEp) protocols describe a set of conventions for
-the automation of operations traditionally seen as barriers to the 
-use and deployment of secure end-to-end interpersonal messaging. These include,
-but are not limited to, key management, key discovery, and private key handling 
-(including peer-to-peer synchronization of private keys and other user data 
-across devices). pEp also introduces means to verify communication peers and 
-proposes a trust-rating system to denote secure types of communications and 
-signal the privacy level available on a per-user and per-message level. 
-Significantly, the pEp protocols build on already available security formats
-and message transports (e.g., PGP/MIME), and are written with the intent to
-be interoperable with already widely-deployed systems in order to facilitate
-and ease adoption and implementation.
-This document outlines the general design choices and principles of pEp.
+The pretty Easy privacy (pEp) model and protocols propose a set of
+conventions for user control and effective automation of
+inter-personal privacy preservation over message based protocols.
+pEp in itself is not the next more secure encryption framework, it
+is a framework to opportunistically engage the best available
+end-to-end security and privacy technology available on a device,
+promoting the Human Rights principles like data minimization, the
+end-to-end principle, and interoperability. pEp uses privacy rating
+to dynamically rate the available transports which the users can
+additionally steer based on summarily expressing their trust in the
+context and the correspondents, eventually improving it by
+interactively engaging in a mutual authentication of the channel.
+pEp proposes the requirements for such a protocol, and proposes a
+specific authentication mechanism based on trustwords.
+
+This document outlines the general design choices and principles of
+pEp. Other documents referred herein specialize in parts of the
+model and the integration with and application on existing
+protocols.
 
 --- middle
 
 
 # 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
-Internet community to create software for peers to automatically
-encrypt, anonymize (where possible), and verify their daily written
-digital communications. This is achieved by building upon already
-existing standards and tools and automating each step a user needs to 
-carry out in order to engage in secure end-to-end encrypted
-communications. Significantly, the pEp protocols describe how do to this 
-without dependence on centralized infrastructures.
-
-In particular, pEp proposes automatation of key management, key discovery
-and synchronization of secret key material by an in-band
-peer-to-peer approach.
+The pretty Easy privacy (pEp) model and protocols represent an
+implementation guideline for bringing Human Rights privacy
+principles like data minimization, the end-to-end principle, and
+interoperability to existing messaging applications. The pretty Easy
+privacy (pEp) protocols are a proposition to the Internet community
+to create interoperable software to allow the users to encrypt,
+anonymize (where possible), and verify their daily written
+communication without application boundaries. pEp does cross-device
+trust-management such that users are assisted in their privacy
+preservation and end-to-end security. Users remain in control of
+expressing their personal trust in the correspondents in an easy
+way, an information which should be respected by as many
+applications as possible.
+
+Balancing security and privacy in remote communication protocols is
+vital for many different reasons, and there are unique properties
+that protocols prioritizing privacy-preservation need to fulfill in
+order to best serve users. In particular, {{RFC8280}} has identified
+and documented essential principles required from a Human Rights
+perspective when accessing the Internet, such as data minimization,
+the end-to-end principle, and interoperability. 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) propositions 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 communication technology.
+
+The pEp initiators learned from the CryptoParty movement, from which
+the project emerged, that manually engaging cryptographic services
+is only for the few. It is largely more effective and convenient to
+automatically bootstrap the security context, and have humans just
+do a verification whenever they prefer, and eventually re-use such
+pre-verified trust anchors to authenticate further transports
+automatically (multi-factor authentication).
+
+The privacy-by-default principles that pEp introduces are in
+accordance with the perspective outlined in {{RFC7435}}, aiming to
+provide opportunistic security in the sense of "some protection most
+of the time". This is done, however, with the subtle but important
+difference that when privacy is weighed against security, the choice
+defaults to privacy.
 
 To mitigate man-in-the-middle attacks (MITM) by an active adversary,
-and as the only manual step users carry out in the course of the
-protocols, the proposed Trustwords {{I-D.birk-pep-trustwords}}
-mechanism uses natural language representations of two peers'
-fingerprints for users to verify their trust in a paired 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 only manual step users carry out in the course of the pEp
+protocol, is the proposed Trustwords {{I-D.birk-pep-trustwords}}
+mechanism using natural language representations of two peers'
+fingerprints for users to verify their trust in a paired
+communication channel.
+
+The pEp propositions are focused on written digital communication,
+but it is not excluded to other forms of communication may build
+upon pEp. pEp covers both asynchronous (offline) types of
+communication like email as well as synchronous (online) types of
+communication such as chat protocols.
 
-The privacy-by-default principles that pEp introduces are in
-accordance with the perspective outlined in {{RFC7435}}, aiming to provide
-opportunistic security in the sense of "some protection most of the
-time". This is done, however, with the subtle but important difference 
-that when privacy is weighed against security, the choice defaults to privacy. 
-Therefore, data minimization is a primary goal in pEp (e.g., hiding subject 
-lines and headers unnecessary for email transport inside the encrypted
-payload of a message).
-
-The pEp propositions are focused on (but not limited to) written
-digital communications and cover asynchronous (offline) types of
-communications like email as well as synchronous (online) types such
-as chat.
-
-pEp's goal is to bridge different standardized and widely-used 
-communications channels such that users can reach
-communications partners in the most privacy-enhancing way possible.
 
 ## 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:
+While this document outlines the general design choices and
+principles of pEp, other related documents specialize in more
+particular aspects of the model, or the application of pEp on a
+specific protocol like e.g. Email, as follows:
 
-1. pEp enhanced applications (e.g., pEp Email {{I-D.marques-pep-email}}).
+1. pEp enabled applications (e.g., pEp Email
+{{I-D.marques-pep-email}}).
 
 1. 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.
+{{I-D.marques-pep-handshake}}) that assist the user with handling
+and understanding cryptographic parts that he/she needs to be aware
+of.
 
 1. 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.
+(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}}.
+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
+\[\[ **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 we can safely refer to already existing RFCs to make clear on
-  which RFCs we already rely.\]\]
+  which RFCs we rely. \]\]
 
 
 # Terms
 
+## Normative language
+
 {::include ../shared/text-blocks/key-words-rfc2119.mkd}
+
+## Other terms
+
 {::include ../shared/text-blocks/handshake.mkd}
 {::include ../shared/text-blocks/trustwords.mkd}
 {::include ../shared/text-blocks/tofu.mkd}
@@ -200,7 +214,7 @@ Therefore, pEp abides by the following guidelines:
   formats).
 
 * Where pEp requires divergence from an RFC for privacy reasons (e.g.,
-  from OpenPGP propositions as defined in {{RFC4880}}, options SHOULD
+  from OpenPGP propositions as defined in {{OpenPGP}}, options SHOULD
   be implemented to empower the user to override pEp's defaults.
 
 ## Peer-to-Peer (P2P)
@@ -1128,6 +1142,8 @@ DYNAMIC_API PEP_STATUS get_trustwords(
 \[\[ RFC Editor: This section should be empty and is to be removed
      before publication \]\]
 
+* Shorten Introduction and Abstract
+
 * References to RFC6973 (Privacy Considerations)
 
 * Add references to prior work, and what differs here - PEM (cf. RFC1421-1424)

shared/text-blocks/key-words-rfc2119.mkd

@@ -1,4 +1,4 @@
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in {{RFC2119}}.
+document are to be interpreted as described in {{!RFC2119}}.