juga
/
internet-drafts
forked from pEp.foundation/internet-drafts
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Minor changes with HB in sections before emails formats.

Browse Source
master
Hernâni Marques 3 years ago
parent e9d2025b9a
commit 8dfebdc58a
Signed by untrusted user: hernani
GPG Key ID: CB5738652768F7E9
1 changed files with 62 additions and 78 deletions
Show Stats Download Patch File Download Diff File

140
pep-email/draft-pep-email.mkd
Unescape View File

@ -135,8 +135,6 @@ across various (very different) end-devices.
# Opportunistic Security and Privacy for Email
<!-- # Application of the Core Design Principles -->
In addition to the Protocol's Core Design Principles outlined in
{{I-D.birk-pep}}, the following sections on design principles are applicable
to pEp for email applications.
@ -144,50 +142,43 @@ to pEp for email applications.
## Privacy by Default
The pEp formats and protocols aim to maximize privacy. Where privacy goals
contradict with security goals, the privacy goals SHALL have precedence.
contradict with security goals, the privacy goals MUST have precedence.
Examples:
<!-- HB:
RFC2119 language is only useful, if specifying a protocol. Not sure this
should already be used in the introduction section.
Also condider s/SHALL/MUST/g
-->
* pEp implementers SHALL NOT make queries to public key servers by default,
in order to make it more expensive for centralized network actors to learn
a user's social graph. This is also problematic security-wise, as
centralized cryptgraphic key subversion at-scale is made cheaper.
* Instead, key distribution SHALL be handled in-band while communicating with
other peers.
* No trust information SHALL be attached to the communication partner's public
keys. This is metadata which SHALL be held locally and seperately from the
* pEp implementers MUST NOT make queries to public key servers by default.
The reason for this is to make it more expensive for centralized network
actors to learn a user's social graph. This is also problematic
security-wise, as centralized cryptographic key subversion at-scale is made
cheaper. Instead, key distribution MUST be handled in-band while communicating with other peers.
* No trust information MUST be attached to the communication partner's public
keys. This is metadata which MUST be held locally and seperately from the
keys. Trust is established between the peers directly (peer-to-peer) and no
transitive trust information is held centrally: that is, while pEp MUST be
able to work with OpenPGP keys which carry trust information, this trust
information SHALL not be used to signal any trust level.
* pEp-enabled MUAs SHALL either engage in a signed-and-encrypted communication
trust information is held centrally (no support for the Web
of Trust): that is, while pEp MUST be able to work with OpenPGP keys which
carry trust information, this trust information MUST not be used to signal
any trust level.
* pEp-enabled MUAs MUST either engage in a signed-and-encrypted communication
or in unsigned plaintext communication. While the signatures attached to
plaintext messages can be verified, this cannot enhance the perceived
quality of the message in the user interface, while an invalid signature
degrades the perception: signed-only messages per se do not increase security,
if no authentication was done and are -- as sole measure -- without positive
influence on privacy.
plaintext messages can be verified, signed-only messages per se do not
increase security as long as the corresponding public key is not
authenticated. Signed-only messages do not improve privacy either.
## Data Minimization
Data Minimization includes data spareness and hiding of all technically
concealable information whenever possible.
### Metadata Protection
## Metadata Protection
Email metadata (i.e., headers) MUST either be omitted or encrypted whenever
possible.
The PGP/MIME specification {{RFC3156}} provides no facility for
metadata protection. However, it is possible to protect the
information contained in header field values by encapsulating the
whole message into a new message body to be singed and encrypted.
The PGP/MIME specification as described in {{RFC3156}} provides little
facilities for metadata protection: while the email body gets protected,
the header section remains unprotected. However, it is possible to protect
also the information contained in header field values by encapsulating the
whole message into a MIME entity to be signed and encrypted.
The S/MIME Message Specification {{RFC8551}}, on the other hand,
defines a way to protect also the header section in addition to the
@ -202,37 +193,28 @@ S/MIME {{RFC8551}} provides no further guidance in deciding which header
fields are transport-relevant and thus might be copied to the wrapper.
-->
### Support for multiple formats
What concerns any kind of email (metadata) encryption: implementers
of pEp SHOULD be liberal in accepting other approaches to encrypt
email headers, but MUST use the strict and interoperable pEp
format (cf. {{pef-1-0}}) for any outgoing communication.
## Interoperability
While pEp implementers SHALL make sure that any communication between
pEp users is maximized for privacy, interoperability between other
approaches to encrypt payloads and hide metadata SHOULD be supported to
the widest extent. To mitigate artefacts in the presentation of messages
sent from non-pEp to pEp implementions (and vice versa).
Implementers of pEp SHOULD be liberal in accepting non-pEp formats to encrypt
email contents and metadata, but MUST use the strict and interoperable
pEp format (cf. {{pef-1-0}}) for any outgoing communication to non-pEp users.
## End-to-End {#end-to-end}
An email endpoint in pEp is the MUA on a user's end-device: that is,
encryption and decryption of messages SHALL be end-device-based and
MUST NOT happen on a server infrastructure.
encryption and decryption of messages MUST be executed on a user's end-device
and MUST NOT happen on a server infrastructure.
\[\[ **TODO**: Add enterprise settings with Key Escrow / Extra Keys \]\]
## Peer-to-Peer {#peer-to-peer}
All relevant pEp mechanisms and state information about other peers SHALL be
held locally, on a peer's end-device. There SHALL NOT be any reliance
All relevant pEp mechanisms and state information about other peers MUST be
held locally, on a peer's end-device. There MUST NOT be any reliance
on a email server or even a centralized network component to hold
relevant information for peers to be able to communicatate or to authenticate
themselves. Email servers (like, SMTP or IMAP) are only used as transport
infrastructure for messages, but SHALL not be relevant to hold actual state
infrastructure for messages, but MUST not be relevant to hold actual state
between peers.
## User Experience (UX) {#ux}
@ -261,7 +243,7 @@ held in a simple relational database.
### Address {#elements-address}
In pEp for Email the SMTP address (e.g., mailto:alice@example.org) constitutes
In pEp for email the SMTP address (e.g., mailto:alice@example.org) constitutes
the network address.
### Key {#elements-key}
@ -283,9 +265,9 @@ An identity in pEp for email is represented by an email
address URI, like mailto:alice@example.org.
This can be Alice with her real name, using this identity for
private purposes. Should Alice create another address, like
mailto:anonymous@example.com, this is considered a second
identity. By default, pEp-enabled MUAs SHALL create a new key
private purposes. Should Alice create another email address, like
anonymous@example.com, this is considered a second
identity. By default, pEp-enabled MUAs MUST create a new key
pair when a new email account is being configured, such as to
not allow correlation by using the same key. If in turn, Alice
wants different addresses of her to be collapsed into one
@ -306,33 +288,35 @@ identity.
The pEp Email Formats 1.0, 2.0 and 2.1 are restricted MIME-based email
formats, which ensure messages to be signed and encrypted. In accordance with
pEp's privacy (and not security) focus, signed-only messages SHALL NOT be
supported. <!-- todo: addreason --> pEp-enabled clients MUST be able to
pEp's privacy (and not security) focus, signed-only messages MUST NOT be
supported (cf. {{privacy-by-default}}). pEp-enabled clients MUST be able to
render all pEp Email Formats properly: for outgoing communications,
the most privacy-preserving format available,
taking interoperability into account.
the most privacy-preserving format available is to be used, taking
interoperability (cf. {{interoperability}}) into account.
Since pEp Email Format 2.0, a compatibility format (i.e., pEp Email Format
1.0, cf. {{pef-1-0}}) exists, which SHOULD be applied towards non-pEp users,
for which trustworthy public keys are available according to the local database.
In case no suitable encryption key is available, an unencrypted, unsigned
MIME email is sent out. This message SHALL contain the sender's public
key, unless Passive Mode (cf. {{passive-mode}}) is active.
<!-- HB
not only in unencrypted case
-->
In case no trustworthy encryption key is available, an unencrypted, unsigned
MIME email is sent out. As in all pEp formats, also this (unprotected) message
MUST contain the sender's public key, unless Passive Mode
(cf. {{passive-mode}}) is active.
<!-- Points to add here are things which are common to all formats, like:
- UTF-8 charset to be used always
- ...
-->
### Unencrypted pEp Format {#pef-0}
This is the format to be used when unencrypted messages are sent out.
The unencrypted pEp format is a multipart/mixed MIME format, which
by default ensures the delivery of the sender's public key disposed
as an attachment.
The unencrypted pEp format is a "multipart/mixed" MIME format, which
by default ensures the delivery of the sender's public key as an attachment
("Content-Disposition: attachment").
In its simplest form, such an email looks like the following:
A simple plaintext email looks like the following:
{::include ../shared/fence-line.mkd}
@ -397,7 +381,7 @@ as this format is implicitly assumed. Only users exposing
Only ancient pEp users and non-pEp users are served with this
compatibiltiy format.
A pEp-enabled MUA, however, SHALL add the X-pEp-Version header with
A pEp-enabled MUA, however, MUST add the X-pEp-Version header with
its highest value (preferly with value "2.1" as for pEp Email Format
2.1 {{pef-2-1}}) when producing this format, in order to announce oneself as
a pEp MUA with the capability to receive and render more privacy-preserving
@ -490,7 +474,7 @@ entity (media type "multipart/encrypted", cf. {{RFC1847}} /
Thus, the whole header section of the inner message can be fully
preserved, not only encrypted, but also signed. In the outer message,
however, when communicating with pEp users all header fields not
needed SHALL be omitted to the fullest extent possible.
needed MUST be omitted to the fullest extent possible.
As with PEF-1.0 {{pef-1-0}} the public key and other files attached
are structured in MIME tree (inner message). Once encrypted, only the
@ -665,7 +649,7 @@ Unwrapping the "msg.asc" multipart/encrypted MIME part, yields this:
##### Example PEF-2.1: pEp to pEp (support version 2.0) {#pef-2-1-ex2}
When the receiving peer was registered as being only PEF-2.0-capable,
that a special PEF-2.1 format SHALL be sent, which in its essence is a
that a special PEF-2.1 format MUST be sent, which in its essence is a
PEF-2.0 format.
The reason for this is that pEp-enabled MUAs which are only PEF-2.0-capable
@ -773,12 +757,12 @@ For the second group, individual Bcc email Messages are sent.
To be able to decide which email format to generate, the pEp-enabled MUA
REQUIRES to record state on a per-identity basis. Once a X-pEp-Version header
field is discovered, the user SHALL be recorded as a pEp user.
field is discovered, the user MUST be recorded as a pEp user.
### Saving Messages
In accordance to the Privacy by Default principle, messages sent
or received in encrypted form SHALL be saved with the identity's
or received in encrypted form MUST be saved with the identity's
respective public key.
Messages sent or received in unencrypted form, SHOULD NOT be saved
@ -795,15 +779,15 @@ untrusted.
For trusted environments (e.g., in organizations) and to conform to legally
binding archivign regulations, pEp implementations MUST provide a
"Trusted Server" option. With the user's explicit consent (opt-in),
unencrypted copies of the Messages SHALL be held on the mail servers
unencrypted copies of the Messages MUST be held on the mail servers
controlled by the organization.
# Key Management
## Key Generation
A pEp-enabled Mail User Agent SHALL consider every email account as an
new identity: for each identity, a different key pair SHALL be created
A pEp-enabled Mail User Agent MUST consider every email account as an
new identity: for each identity, a different key pair MUST be created
automatically if no key material with sufficient length is available.
By default, RSA-4096 key pairs for OpenPGP encryption
{{RFC4880}} SHOULD be generated automatically for each email account.
@ -865,7 +849,7 @@ trust management:
displayed using a green color.
As color code changes for an identity, this is also reflected to future
messages to/from this identity. Past messages, however, SHALL NOT be
messages to/from this identity. Past messages, however, MUST NOT be
altered.
{::include ../shared/fence-line.mkd}
@ -922,7 +906,7 @@ bother about keys).
Passive Mode has a negative impact on privacy: additional unencrypted message
exchanges are needed until pEp's by-default encryption can take place.
Passive Mode SHALL only affect unencrypted communications and be inactive by
Passive Mode MUST only affect unencrypted communications and be inactive by
default. By opting in to Passive Mode, the sender's public key MUST NOT be
attached when sending out unsecure emails. On the other hand, Passive Mode is
without any effect when pEp is able to send out an encrypted message, because
@ -935,7 +919,7 @@ constituent part of one of pEp's PGP/MIME-based message format described in
Additionally, Passive Mode MUST be without effect, if a receiver learns a MUA
is actually pEp-capable, even if the sender involved is in Passive Mode, too:
this SHALL be recognized by the "X-pEp-Version" header field, as the only
this MUST be recognized by the "X-pEp-Version" header field, as the only
clear indicator to detect pEp users. That means that a pEp-enabled MUA is
REQUIRED to attach its corresponding public key to another
pEp user in any case, such that they can engage in opportunistic encryption.
@ -945,7 +929,7 @@ pEp user in any case, such that they can engage in opportunistic encryption.
## Option "Disable Protection"
This is an opt-in mechanism to enforce that messages go out unprotected. Even
if encryption keys for recipient(s) are available, this option SHALL enforce
if encryption keys for recipient(s) are available, this option MUST enforce
that messages are sent in the {{pef-0}} format.
## Option "Extra Keys"

Write Preview
Loading…
Cancel
Save