From 4fde2746c37883ae4b562f782b037c343696be90 Mon Sep 17 00:00:00 2001 From: Claudio Luck Date: Mon, 24 Jun 2019 16:07:13 +0200 Subject: [PATCH] editing principles --- pep/draft-birk-pep.mkd | 89 ++++++++++++++++++++++++++++-------------- 1 file changed, 59 insertions(+), 30 deletions(-) diff --git a/pep/draft-birk-pep.mkd b/pep/draft-birk-pep.mkd index cbca92b1..ed550822 100644 --- a/pep/draft-birk-pep.mkd +++ b/pep/draft-birk-pep.mkd @@ -174,50 +174,79 @@ Registration of Trustword Lists {{I-D.birk-pep-trustwords}}. ## Privacy by Default -The pEp protocols are to intended specifically to ensure privacy. -There exist cases in the secure communications ecosystem, -however, where achieving privacy is in direct contradiction to security though. For instance, -in PGP's Web of Trust, relations between 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 obtained -from remote locations as this constitutes a privacy breach. +The pEp protocols top concern is ensuring privacy during the full +lifecycle of a correspondence. The protocol defaults are designed to +maximize both security and privacy. In the few cases where the +achieving of higher privacy and security are in coflict, the choice +is made for more privacy. + +As an example not to follow is the current implementation of +OpenPGP's Web-of-Trust, which releases the recorded trust relations +to the public, including the trust levels. Moreover, queries are made +to centralized keyservers disclosing the social graph and the intent +to correspond with specific peers. Similar issues exist in other +security protocols, e.g. in certificate revocation protocols used in +XPKI (S/MIME). + +\[\[**TODO**: Fix the wording and reference to XPKI, S/MIME]]. + +In pEp messaging (e.g., when using HTML) content and information +SHALL NOT be obtained from remote locations as this constitutes a +privacy breach. ## Data Minimization Another important design goal is data minimization, which includes -data spareness and hiding all technically concealable information when possible. +data spareness and the hiding of all technically concealable +information whenever possible. ## Interoperability -The pEp propositions seek to be interoperable with already-widespread -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. +The pEp propositions seek to be interoperable with established +message formats and cryptographic security protocols and their +widespread implementations. -Therefore, pEp abides by the following guidelines: +Two integration strategies are considered: -* pEp is conservative (strict) in requirements for pEp implementations and - how they interact with pEp or other (messaging) implementations. + 1. install asymmetric keys which have been produced and transferred + under control of pEp into the existing cryptographic security + services of a transport, to measure and defend the end-to-end + principle, + + 1. wrapping messages, for transparently transporting them over + alternative transports. + +Seamless communication between users of software which implement pEp +and users of other software which employ the same encrpytion services +and technically allow for maintaining the same level of end-to-end +encryption MUST be guaranteed. + +pEp MUST follows Postel's principle outlined in {{?RFC1122}}: "Be +liberal in what you accept, and conservative in what you send.". +Particularly, + +* pEp is conservative (strict) in requirements for pEp +implementations and how they interact with pEp or other compatible +implementations, * pEp is liberal in accepting input from non-pEp implementations - (e.g., it will not produce, but will support the decryption of, PGP/INLINE - formats). -* Where pEp requires divergence from an RFC for privacy reasons (e.g., - from OpenPGP propositions as defined in {{OpenPGP}}, options SHOULD - be implemented to empower the user to override pEp's defaults. + +(e.g., it will not produce, but will support the decryption of, +PGP/INLINE formats). --> + +* and, where pEp requires divergence from established RFC for privacy +reasons, options SHOULD be implemented to empower the user to +override pEp's defaults. + + + +\[\[ **TODO**: Keyreset and Keysync are ASN.1 specified, so that vendor-independent integration is easily possible. \]\] + +\[\[ **TODO**: tcpdump dissector anyone? \]\] -## Peer-to-Peer (P2P) +## End-to-End Messaging and verification processes in pEp are designed to work in a peer-to-peer (P2P) manner, without the involvement of intermediaries.