@ -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.
<!-- (e.g., from OpenPGP propositions as defined in {{TLS}} -->
\[\[ **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.
