< draft-luck-lamps-pep-header-protection-00.txt   draft-luck-lamps-pep-header-protection-01.txt >
Network Working Group C. Luck Network Working Group C. Luck
Internet-Draft pEp Foundation Internet-Draft pEp Foundation
Intended status: Informational B. Hoeneisen Intended status: Informational B. Hoeneisen
Expires: September 9, 2019 Ucom.ch Expires: September 13, 2019 Ucom.ch
March 08, 2019 March 12, 2019
pretty Easy privacy (pEp): Header Protection pretty Easy privacy (pEp): Header Protection
draft-luck-lamps-pep-header-protection-00 draft-luck-lamps-pep-header-protection-01
Abstract Abstract
Issues with email header protection in S/MIME have been recently Issues with email header protection in S/MIME have been recently
raised in the IETF LAMPS Working Group. The need for amendments to raised in the IETF LAMPS Working Group. The need for amendments to
the existing specification regarding header protection was expressed. the existing specification regarding header protection was expressed.
The pretty Easy privacy (pEp) implementations currently use a The pretty Easy privacy (pEp) implementations currently use a
mechanism quite similar to the currently standardized message mechanism quite similar to the currently standardized message
wrapping for S/MIME. The main difference is that pEp is using PGP/ wrapping for S/MIME. The main difference is that pEp is using PGP/
MIME instead. In LAMPS also voices have been expressed, that MIME instead, and adds space for carrying public keys next to the
whatever mechanism will be choosen, it should not be limited to protected message.
S/MIME, but also applied to PGP/MIME.
In LAMPS voices have also been expressed, that whatever mechanism
will be chosen, it should not be limited to S/MIME, but also
applicable to PGP/MIME.
This document aims to contribute to this discussion and share pEp This document aims to contribute to this discussion and share pEp
implementation experience with email header protection. implementation experience with email header protection.
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 9, 2019. This Internet-Draft will expire on September 13, 2019.
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
skipping to change at page 2, line 27 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The OpenPGP Radix-64 . . . . . . . . . . . . . . . . . . 4 2.1. The OpenPGP Radix-64 . . . . . . . . . . . . . . . . . . 4
2.1.1. Radix-64 in the Context of MIME Messages . . . . . . 5 2.1.1. Radix-64 in the Context of MIME Messages . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 6 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7
4.1.1. Sending Side . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Sending Side . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Receiving Side . . . . . . . . . . . . . . . . . . . 7 4.1.2. Receiving Side . . . . . . . . . . . . . . . . . . . 8
4.2. Additional Requirements for Backward-Compatibility With 4.2. Additional Requirements for Backward-Compatibility With
Legacy Clients Unaware of Header Protection . . . . . . . 7 Legacy Clients Unaware of Header Protection . . . . . . . 8
4.2.1. Sending side . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Sending side . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Receiving side . . . . . . . . . . . . . . . . . . . 8 4.2.2. Receiving side . . . . . . . . . . . . . . . . . . . 8
4.3. Additional Requirements for Backward-Compatibility with 4.3. Additional Requirements for Backward-Compatibility with
Legacy Header Protection Systems (if supported) . . . . . 8 Legacy Header Protection Systems (if supported) . . . . . 8
4.3.1. Sending Side . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Sending Side . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Receiving Side . . . . . . . . . . . . . . . . . . . 8 4.3.2. Receiving Side . . . . . . . . . . . . . . . . . . . 9
5. Message Format for Header Protection . . . . . . . . . . . . 8 5. Message Format for progressive header disclosure . . . . . . 9
5.1. Preparing a Message for Header Protection . . . . . . . . 11 5.1. Design principles . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Requirements for the Original Message . . . . . . . . 12 5.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Building the Inner Message . . . . . . . . . . . . . 12 5.3. Inner message . . . . . . . . . . . . . . . . . . . . . . 11
5.1.3. Building the Outer Message for Signed Inner Messages 14 5.4. Content-Type property "forwarded" . . . . . . . . . . . . 11
5.1.4. Building the Outer Message for Signed and Encrypted 5.5. Outer message . . . . . . . . . . . . . . . . . . . . . . 12
Inner Messages . . . . . . . . . . . . . . . . . . . 15 5.6. Transport message . . . . . . . . . . . . . . . . . . . . 14
5.1.5. S/MIME Compatibility . . . . . . . . . . . . . . . . 16 5.7. S/MIME Compatibility . . . . . . . . . . . . . . . . . . 15
6. Candidate Header Fields for Header Protection . . . . . . . . 16 6. Candidate Header Fields for Header Protection . . . . . . . . 15
7. Stub Outside Headers . . . . . . . . . . . . . . . . . . . . 16 7. Stub Outside Headers . . . . . . . . . . . . . . . . . . . . 15
8. Processing Incoming Email with Protected Headers . . . . . . 17 8. Processing Incoming Email under Progressive Header Disclosure 16
8.1. Detecting Header Protection in Incoming Email . . . . . . 17 8.1. Resolving Conflicting Protected and Unprotected Header
8.2. Resolving Conflicting Protected and Unprotected Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . 16
Fields . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. Processing of Signed-only Email . . . . . . . . . . . . . 16
8.3. Processing of Signed-only Email . . . . . . . . . . . . . 18 8.3. Incoming Filter Processing . . . . . . . . . . . . . . . 16
8.4. Incoming Filter Processing . . . . . . . . . . . . . . . 18 8.3.1. Staged Filtering of Inbound Messages . . . . . . . . 17
8.4.1. Staged Filtering of Inbound Messages . . . . . . . . 19 8.4. Outgoing Filter Processing . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.5. Outgoing Filter Processing . . . . . . . . . . . . . . . 19 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 18
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 10.2. Current software implementing pEp . . . . . . . . . . . 18
10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Current software implementing pEp . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
A range of protocols for the protection of electronic mail (email) A range of protocols for the protection of electronic mail (email)
exist, which allow to assess the authenticity and integrity of the exist, which allow to assess the authenticity and integrity of the
email headers section or selected header fields from the domain-level email headers section or selected header fields from the domain-level
perspective, specifically DomainKeys Identified Mail (DKIM) [RFC6376] perspective, specifically DomainKeys Identified Mail (DKIM) [RFC6376]
and Sender Policy Framework (SPF) [RFC7208] and Domain-based Message and Sender Policy Framework (SPF) [RFC7208] and Domain-based Message
Authentication, Reporting, and Conformance (DMARC) [RFC7489]. These Authentication, Reporting, and Conformance (DMARC) [RFC7489]. These
protocols, while essential to responding to a range of attacks on protocols, while essential to responding to a range of attacks on
email, do not offer end-to-end protection to the headers section and email, do not offer full end-to-end protection to the headers section
are not capable of providing privacy for the information contained and are not capable of providing privacy for the information
therein. contained therein.
Also the need for means of Data Minimization, which includes data The need for means of Data Minimization, which includes data
spareness and hiding of all information, which technically can be spareness and hiding of all information, which technically can be
hidden, has grown in importance over the past years. hidden, has grown in importance over the past years.
End-to-end protection for the email headers section or header fields A standard for end-to-end protection of the email headers section
(HF) is currently not widely implemented - neither for messages exists for S/MIME since version 3.1. (cf. [RFC5751] and
protected by means of S/MIME nor for PGP (Pretty Good Privacy) nor [I-D.ietf-lamps-rfc5751-bis]):
any other form. A standard exists for S/MIME since version 3.1. (cf.
[RFC5751] and [I-D.ietf-lamps-rfc5751-bis]):
In order to protect outer, non-content-related message header In order to protect outer, non-content-related message header
fields (for instance, the "Subject", "To", "From", and "Cc" fields (for instance, the "Subject", "To", "From", and "Cc"
fields), the sending client MAY wrap a full MIME message in a fields), the sending client MAY wrap a full MIME message in a
message/rfc822 wrapper in order to apply S/MIME security services message/rfc822 wrapper in order to apply S/MIME security services
to these header fields. to these header fields.
No mechanism for header protection has been standardized for PGP/MIME No mechanism for header protection has been standardized for PGP
yet. (Pretty Good Privacy) yet.
At least two variants of header protection are known to be End-to-end protection for the email headers section is currently not
implemented. A recently submitted Internet-Draft widely implemented - neither for messages protected by means of
S/MIME nor PGP. At least two variants of header protection are known
to be implemented. A recently submitted Internet-Draft
[I-D.melnikov-lamps-header-protection] discusses the two variants and [I-D.melnikov-lamps-header-protection] discusses the two variants and
the challenges with header protection for S/MIME. The two variants the challenges with header protection for S/MIME. The two variants
are referred to as: are referred to as:
o Option 1: Memory Hole o Option 1: Memory Hole
o Option 2: Wrapping with message/rfc822 or message/global o Option 2: Wrapping with message/rfc822 or message/global
pEp (pretty Easy privacy) [I-D.birk-pep] for email pEp (pretty Easy privacy) [I-D.birk-pep] for email
[I-D.marques-pep-email] already implements an option quite similar to [I-D.marques-pep-email] already implements an option quite similar to
Option 2, adapting the S/MIME standards to PGP/MIME. Option 2, adapting the S/MIME standards to PGP/MIME (cf. Section 5,
ff.). Existing implementations of pEp have also added inbound
Existing implementations of pEp have also added inbound support for support for "Memory Hole" referred to above as Option 1, thus being
"Memory Hole" referred to above as Option 1. On par with other able to study the differences and the implementator's challenges.
implementations of "Memory Hole" support for it is currently limited
to the "Subject" header field only.
Interoperability and implementation symmetry between PGP/MIME and Interoperability and implementation symmetry between PGP/MIME and
S/MIME is planned by pEp, but still in an early stage of development. S/MIME is planned by pEp, but still in an early stage of development.
This document lists generic use cases and requirements for header This document lists generic use cases (Section 3) and requirements
protection and describes the header protection implemented in "pEp for header protection (Section 4) and describes progressive header
message format version 2", and how non-pEp mail clients may implement disclosure as implemented in the "pEp message format version 2".
header protection independently from other pEp standards. This format inherently offers header protection, and may be
implemented independently by mail user agents otherwise not
conforming to pEp standards (Section 5, ff.).
2. Terms 2. Terms
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 Man-in-the-middle attack (MITM): cf. [RFC4949]
2.1. The OpenPGP Radix-64 2.1. The OpenPGP Radix-64
In the examples following in this section, it is a common pattern to In the examples following in this section, it is a common pattern to
have a MIME encoded mail containing ("wrapping") another signed and have a MIME encoded mail containing ("wrapping") another signed and
eventually encrypted mail. Such enclosed mails are encoded following eventually encrypted mail. Such enclosed mails are encoded following
the OpenPGP standard, which specifies an encoding called "Radix-64", the OpenPGP standard, which specifies an encoding called "Radix-64",
which is 7-bit transport-encoding compatible by design. which is 7-bit transport-encoding compatible by design.
The Radix-64 consists of a begin and an end Armor Header Line, a The Radix-64 consists of a begin and an end Armor Header Line, a
stream of base64-encoded data limited to 78 characters per line plus stream of base64-encoded data limited to 78 characters per line plus
skipping to change at page 5, line 38 skipping to change at page 5, line 41
3. Use Cases 3. Use Cases
In the following, we show the generic use cases that need to be In the following, we show the generic use cases that need to be
addressed independently of whether S/MIME, PGP/MIME or any other addressed independently of whether S/MIME, PGP/MIME or any other
technology is used for which Header Protection (HP) is to be applied technology is used for which Header Protection (HP) is to be applied
to. to.
3.1. Interactions 3.1. Interactions
The main interaction case for HP is: The main interaction case for Header Protection (HP) is:
1) Both peers (sending and receiving side) fully support HP 1) Both peers (sending and receiving side) fully support HP
For backward compatibility of legacy clients - unaware of any HP - For backward compatibility of legacy clients - unaware of any HP -
the following intermediate interactions need to be considered as the following intermediate interactions need to be considered as
well: well:
2) The sending side fully supports HP, while the receiving side does 2) The sending side fully supports HP, while the receiving side does
not support any HP not support any HP
skipping to change at page 7, line 22 skipping to change at page 7, line 22
This subsection is listing the requirements to address use case 1) This subsection is listing the requirements to address use case 1)
(cf. Section 3.1). (cf. Section 3.1).
G1: Define the format for HP for all protection levels. This includes G1: Define the format for HP for all protection levels. This includes
MIME structure, Content-Type (including charset and name), MIME structure, Content-Type (including charset and name),
Content-Disposition (including filename), and Content-Disposition (including filename), and
Content-Transfer-Encoding. Furthermore, it must be defined, how a Content-Transfer-Encoding. Furthermore, it must be defined, how a
public key should be included. public key should be included.
G3: To foster wide implementation of the new solution, it shall be
easily implementable. Unless needed for maximizing protection and
privacy, existing implementations shall not require substantial
changes in the existing code base. In particular also MIME
libraries widely used shall not need to be changed to comply with
the new mechanism for HP.
G4: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in
particular downgrade attacks, are mitigated as good as possible.
4.1.1. Sending Side 4.1.1. Sending Side
GS1: Define which HF (Header Fields) should or must be protected for GS1: Determine which Header Fields (HFs) should or must be protected
all protection levels. at least for all protection levels.
GS2: Define which HF should or must appear in clear-text of an GS2: Determine which HFs should or must be sent in clear of an
encrypted email. encrypted email.
GS3: Define which HF should or must not appear in clear-text of an GS3: Determine which HF should not or must not be included in the
encrypted email. visible header (for transport) of an encrypted email, with the
default being that whatever is not needed from GS2 is not put
into the unencrypted transport headers, thus fulfilling data
minimization requirements (including data spareness and hiding
of all information that technically can be hidden).
4.1.2. Receiving Side 4.1.2. Receiving Side
GR1: Define which HF are displayed to the user in case of conflicting GR1: Determine how HF should be displayed to the user in case of
information between the protected and unprotected headers. conflicting information between the protected and unprotected
headers.
GR2: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in
particular downgrade attacks, can be detected.
4.2. Additional Requirements for Backward-Compatibility With Legacy 4.2. Additional Requirements for Backward-Compatibility With Legacy
Clients Unaware of Header Protection Clients Unaware of Header Protection
This sub-section addresses the use cases 2) - 4) (cf. Section 3.1) This sub-section addresses the use cases 2) - 4) (cf. Section 3.1)
B1: Depending on the solution, define a means to distinguish between B1: Depending on the solution, define a means to distinguish between
forwarded messages and encapsulated messages using new HP forwarded messages and encapsulated messages using new HP
mechanism. mechanism.
4.2.1. Sending side 4.2.1. Sending side
BS1: Define how full HP support can be indicated to outgoing BS1: Define how full HP support can be indicated to outgoing
messages. messages.
BS2: Define how full HP support of the receiver can be detected or BS2: Define how full HP support of the receiver can be detected or
guessed guessed.
BS3: Ensure a HP unaware receiving side easily can display the
"Subject" HF to the user.
4.2.2. Receiving side 4.2.2. Receiving side
BR1: Define how full HP support can be detected in incoming messages. BR1: Define how full HP support can be detected in incoming messages.
4.3. Additional Requirements for Backward-Compatibility with Legacy 4.3. Additional Requirements for Backward-Compatibility with Legacy
Header Protection Systems (if supported) Header Protection Systems (if supported)
This sub-section addresses the use cases 5) - 9) (cf. Section 3.1). This sub-section addresses the use cases 5) - 9) (cf. Section 3.1).
LS1: Depending on the solution, define a means to distinguish between LS1: Depending on the solution, define a means to distinguish between
forwarded messages, legacy S/MIME encapsulated messages, and forwarded messages, legacy encapsulated messages, and
encapsulated messages using new HP mechanism. encapsulated messages using new HP mechanism.
LS2: The solution should be backward compatible to existing solutions
and aim to minimize the implementation effort to include support
for existing solutions.
4.3.1. Sending Side 4.3.1. Sending Side
LSS1: Define how legacy HP support can be indicated to outgoing LSS1: Determine how legacy HP support can be indicated to outgoing
messages. messages.
LSS2: Define how legacy HP support of the receiver can be detected or LSS2: Determine how legacy HP support of the receiver can be detected
guessed. or guessed.
4.3.2. Receiving Side 4.3.2. Receiving Side
LSR1: Define how legacy HP support can be detected in incoming LSR1: Determine how legacy HP support can be detected in incoming
messages. messages.
5. Message Format for Header Protection 5. Message Format for progressive header disclosure
The pEp message format version 2 is designed such that a receiving 5.1. Design principles
Mail User Agent (MUA), which is OpenPGP-compliant but not pEp-
compliant - and which is not implementing header protection either -,
still has built-in capability to properly decode the mail and display
all information to the user.
No standard is currently available which enables MUAs to reliably pretty Easy privacy (pEp) is working on bringing state-of-the-art
determine whenever a nested message/rfc822 entity is meant to automatic cryptography known from areas like TLS to electronic mail
override the containing message, or if it was effectively forwarded. (email) communication. pEp is determined to evolve the existing
pEp currently intends to implement the proposal described by standards as fundamentally and comprehensively as needed to gain easy
[I-D.melnikov-lamps-header-protection], 3.2, which defines a new implementation and integration, and for easy use for regular Internet
Content-Type header field parameter with name "forwarded", for the users. pEp for email wants to attaining to good security practice
MUA to distinguish between a forwarded message and a nested message while still retaining backward compatibility for implementations
for the purpose of header protection, i.e., using "forwarded=no". widespread.
Header protecton provides both integrity and confidentiality. To provide the required stability as a foundation for good security
Confidentiality requires the same effective key distribution practice, pEp for email defines a fixed MIME structure for its
mechanism to be in-place as for integrity, such that when integrity innermost message structure, so to remove most attack vectors which
can be achieved, also can confidentiality. Integrity and have permitted the numerous EFAIL vulnerabilities. (TBD: ref)
confidentiality SHOULD always be used together.
Security comes just next after privacy in pEp, for which reason the
application of signatures without encryption to messages in transit
is not considered purposeful. pEp for email herein referenced, and
further described in [I-D.marques-pep-email], either expects to
transfer messages in cleartext without signature or encryption, or
transfer them encrypted and with enclosed signature and necessary
public keys so that replies can be immediately upgraded to encrypted
messages.
The pEp message format is equivalent to the S/MIME standard in
ensuring header protection, in that the whole message is protected
instead, by wrapping it and providing cryptographic services to the
whole original message. The pEp message format is different compared
to the S/MIME standard in that the pEp protocols propose
opportunistic end-to-end security and signature, by allowing the
transport of the necessary public key material along with the
original messages.
For the purpose of allowing the insertion of such public keys, the
root entity of the protected message is thus nested once more into an
additional multipart/mixed MIME entity. The current pEp proposal is
for PGP/MIME, while an extension to S/MIME is next.
pEp's proposal is strict in that it requires that the cryptographic
services applied to the protected message MUST include encryption.
It also mandates a fixed MIME structure for the protected message,
which always MUST include a plaintext and optionally an HTML
representation (if HTML is used) of the same message, and requires
that all other optional elements to be eventually presented as
attachments. Alternatively the whole protected message could
represent in turn a wrapped pEp wrapper, which makes the message
structure fully recursive on purpose (e.g., for the purpose of
anonymization through onion routing).
For the purpose of implementing mixnet routing for email, it is
foreseen to nest pEp messages recursively. A protected message can
in turn contain a protected message due for forwarding. This is for
the purpose to increase privacy and counter the necessary leakage of
plaintext addressing in the envelope of the email.
The recursive nature of the pEp message format allows for the
implementation of progressive disclosure of the necessary transport
relevant header fields just as-needed to the next mail transport
agents along the transmission path.
5.2. Compatibility
The pEp message format version 2 is designed such that a receiving
Mail User Agent (MUA), which is OpenPGP-compliant but not pEp-
compliant, still has built-in capability to properly verify the
integrity of the mail, decode it and display all information of the
original mail to the user. The recovered protected message is
selfsufficiently described, including all protected header fields.
The pEp message format version 2 (as used by all the various pEp The pEp message format version 2 (as used by all the various pEp
implementations, cf. Section 10) is similar to what is standardized implementations, cf. Section 10) is similar to what is standardized
for S/MIME in [RFC5751] and its successor for S/MIME in [RFC5751] and its successor
[I-D.ietf-lamps-rfc5751-bis]: [I-D.ietf-lamps-rfc5751-bis]:
In order to protect outer, non-content-related message header In order to protect outer, non-content-related message header
fields (for instance, the "Subject", "To", "From", and "Cc" fields (for instance, the "Subject", "To", "From", and "Cc"
fields), the sending client MAY wrap a full MIME message in a fields), the sending client MAY wrap a full MIME message in a
message/rfc822 wrapper in order to apply S/MIME security services message/rfc822 wrapper in order to apply S/MIME security services
to these header fields. It is up to the receiving client to to these header fields. It is up to the receiving client to
decide how to present this "inner" header along with the decide how to present this "inner" header along with the
unprotected "outer" header. unprotected "outer" header.
When an S/MIME message is received, if the top-level protected When an S/MIME message is received, if the top-level protected
MIME entity has a Content-Type of message/rfc822, it can be MIME entity has a Content-Type of message/rfc822, it can be
assumed that the intent was to provide header protection. This assumed that the intent was to provide header protection. This
entity SHOULD be presented as the top-level message, [...]. entity SHOULD be presented as the top-level message, [...].
With pEp message format version 2, the original full MIME message is 5.3. Inner message
also wrapped in a message/rfc822 wrapper, but this entity is in turn
wrapped in a multipart/mixed entity. The purpose of the additional The pEp message format requires the innermost protected message to
nesting is to allow for public keys of the sender to be stored follow a fixed MIME structure and to consist of exactly one human-
alongside the original message while being protected by the same readable message which is represented in plain or HTML format. Both
mechanism. Thus, the top-level entity contains plain and html entities MUST represent the same message to the user.
Any attachment to the message must be laid out in a flat list. No
additional multipart entities are allowed in the pEp message.
These restrictions permit to build mail user agents which are immune
to the EFAIL attacks.
This message is herein further referred to as the "pEp inner
message".
A mail user agent wanting to follow this standard, SHOULD transform
any "original message" into a "pEp inner message" for safe
representation on the receiving side.
5.4. Content-Type property "forwarded"
One caveat of the design is that the user interaction with message/
rfc822 entities varies considerably across different mail user
agents. No standard is currently available which enables MUAs to
reliably determine whenever a nested message/rfc822 entity is meant
to blend the containing message, or if it was effectively intended to
be forwarded as a file document. pEp currently intends to implement
the proposal described by [I-D.melnikov-lamps-header-protection],
3.2, which defines a new Content-Type header field parameter with
name "forwarded", for the MUA to distinguish between a forwarded
message and a nested message for the purpose of header protection,
i.e., using "forwarded=no".
5.5. Outer message
With pEp message format version 2, the pEp standardized message is
equally wrapped in a message/rfc822 entity, but this time being in
turn wrapped in a multipart/mixed entity. The purpose of the
additional nesting is to allow for public keys of the sender to be
stored alongside the original message while being protected by the
same mechanism.
For the case of PGP/MIME, the currently only implemented MIME
encryption protocol implemented in pEp, the top-level entity called
the "outer message" MUST contain:
o exactly one entity of type message/rfc822, and o exactly one entity of type message/rfc822, and
o at most one entity of type application/pgp-keys o one or more entity of type application/pgp-keys
The current pEp message format version 2.0 also adds one entity of Notes on the current pEp client implementations:
type text/plain where the body part reads "pEp-Wrapped-Message-Info:
OUTER<CR><LF>". It is currently being discussed if this information
should be migrated to the headers section of the top-level entity;
such an upgrade would be part of the the pEp message format version
2.1.
A pEp message MUST have a text/plain element. The original plaintext o the current pEp implementation also adds a text/plain entity
message is prepended by the string "pEp-Wrapped-Message-Info: containing "pEp-Wrapped-Message-Info: OUTER" as first element in
INNER<CR><LF>". Also this header may be moved into the headers the MIME tree. This element is not strictly necessary, but is in
section of the entity in message format version 2.1. place for better backwards compatibility when manually navigating
the nested message structure. This is part of the study of
various solutions to maximize backwards compatibility, and has
been omitted from the following examples.
[[ TODO: The pEp-Wrapped-Message-Info information is probably not o the current pEp implementation prepends "pEp-Wrapped-Message-Info:
needed for header protection. ]] INNER<CR><LF>" to the original message body. This is an
implementation detail which should be ignored, and has been
omitted in the following examples.
o the current pEp implementation may render a text/plain directly in
place of the multipart/alternate, when no HTML representation was
generated by the sending MUA. This is not strict according to
pEp's own specification, and is currently being investigated.
This is an example of the top-level MIME entity, before being This is an example of the top-level MIME entity, before being
encrypted and signed: encrypted and signed:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/mixed; Content-Type: multipart/mixed;
boundary="6b8b4567327b23c6643c986966334873" boundary="6b8b4567327b23c6643c986966334873"
--6b8b4567327b23c6643c986966334873 --6b8b4567327b23c6643c986966334873
Content-Type: text/plain; charset="utf-8"; name="msg.txt"
Content-Disposition: inline; filename="msg.txt"
pEp-Wrapped-Message-Info: OUTER
--6b8b4567327b23c6643c986966334873
Content-Type: message/rfc822; forwarded="no" Content-Type: message/rfc822; forwarded="no"
From: John Doe <jdoe@machine.example> From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net> To: Mary Smith <mary@example.net>
Subject: Example Subject: Example
Date: Fri, 30 Jun 2018 09:55:06 +0200 Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy> Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy>
X-Pep-Version: 2.0 X-Pep-Version: 2.0
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; name="msg.txt" Content-Type: multipart/alternative;
Content-Disposition: inline; filename="msg.txt" boundary="29fe9d2b2d7f6a703c1bffc47c162a8c"
Content-Transfer-Encoding: quoted-printable
pEp-Wrapped-Message-Info: INNER --29fe9d2b2d7f6a703c1bffc47c162a8c
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; filename="msg.txt"
p=E2=89=A1p for Privacy by Default. p=E2=89=A1p for Privacy by Default.
-- =20
Sent from my p=E2=89=A1p for Android.
--29fe9d2b2d7f6a703c1bffc47c162a8c
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
p=E2=89=A1p for Privacy by Default.<br>
-- <br>
Sent from my p=E2=89=A1p for Android.<br>
--29fe9d2b2d7f6a703c1bffc47c162a8c--
--6b8b4567327b23c6643c986966334873 --6b8b4567327b23c6643c986966334873
Content-Type: application/pgp-keys Content-Type: application/pgp-keys
Content-Disposition: attachment; filename="pEpkey.asc" Content-Disposition: attachment; filename="pEpkey.asc"
-----BEGIN PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PUBLIC KEY BLOCK-----
... ...
-----END PGP PUBLIC KEY BLOCK----- -----END PGP PUBLIC KEY BLOCK-----
--6b8b4567327b23c6643c986966334873-- --6b8b4567327b23c6643c986966334873--
5.1. Preparing a Message for Header Protection 5.6. Transport message
Header protection requires an ideal "original message" to be
transformed into an "inner message", which must be signed and
preferably encrypted according to MIME Security with OpenPGP
[RFC3156], resulting in an "outer message" (not to be confused with
the "inner" and "outer" labels in the above mentioned pEp-Wrapped-
Message-Info header field). The resulting "outer message" requires
some additional adjustments so that the protected message is properly
handled on all Mail User Agents.
Note that pEp email clients are REQUIRED to sign and encrypt the
message as per [I-D.marques-pep-email], while non-pEp clients MAY
encrypt messages.
5.1.1. Requirements for the Original Message
The original message MUST be structured as a valid [RFC5322] message
with a header and a body.
Additionally, the body of the original message MUST be structured in
body parts according to the MIME standard [RFC2046].
The primary entity of type text/plain which is implicitly or
explicitly intended for inline display SHOULD be noted (the "message
entity"). The selection MUST adhere to MIME standards regarding
precedence of parts in multipart structures.
[[ TODO: It is currently undefined how to proceed if no such message
entity exists. ]]
5.1.2. Building the Inner Message
The original message entity is to be substituted with a text/plain
part (and the headers and parameters as specified later), which in
turn will contain a valid [RFC5322] message, where:
o the message SHOULD NOT be structured in MIME parts,
o the body replicates the body of the substituee message entity
decoded according to its eventual Content-Transfer-Encoding header
field value,
o the Content-Type header field is set to "text/plain"
* and the "charset" parameter is set to "UTF-8"
* and the "name" parameter is set to "msg.txt"
* and no other parameter is set on the Content-Type header field,
o the Content-Disposition is set to "inline"
* and the "filename" parameter is set to "msg.txt"
* and no other parameter is set on the Content-Disposition header
field.
The new body of the message-body (which now contains a valid
[RFC5322] message) must be re-applied a Content-Transfer-Encoding
such that:
o if the message is to be signed and encrypted, the substituted
message-body part results in a valid UTF-8 string not containing
UTF-8 null symbols,
o if the message is to be signed but not encrypted, the substituted
message entity is 7-bit transport-safe.
The Content-Transfer-Encoding previously in place on the substitutee
message-body SHOULD be preferred for the substitued message-body
whenever it is not to be excluded by other criterias.
The inner message is then to be produced such that it can be
represented as a string which consists of only valid UTF-8 symbols
and additionally such that it does not eventually contain the UTF-8
null symbol.
No other Content-Transfer-Encoding other than "7bit", "8bit", or
"binary" is permitted for the root part of the inner message. The
headers section, the MIME boundaries and the headers sections of the
body parts MUST be limited to valid UTF-8 symbols and no UTF-8 null
symbol. Body parts and sub-parts which do not represent a valid
UTF-8 string or MAY include a UTF-8 null symbol, MUST be applied an
appropriate Content-Transfer-Encoding to make their encoded
representation valid in UTF-8 (e.g., with "quoted-printable" or
"base64").
The following shows an example original message and the resulting
message/rfc822 entity for inclusion in the outer multipart/mixed.
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Example
Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
p=E2=89=A1p for Privacy by Default.
MIME-Version: 1.0
Content-Type: message/rfc822; forwarded="no"
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Example
Date: Fri, 30 Jun 2018 09:55:06 +0200
Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy>
X-pEp-Version: 2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; name="msg.txt"
Content-Disposition: inline; filename="msg.txt"
Content-Transfer-Encoding: quoted-printable
pEp-Wrapped-Message-Info: INNER
p=E2=89=A1p for Privacy by Default.
The protected message has the following structure.
+ message/rfc822; forwarded="no";
[
{
all protected headers, overridden by:
Message-ID:
X-pEp-Version: 2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; name="msg.txt"
Content-Disposition: inline; filename="msg.txt"
Content-Transfer-Encoding: ...
}
[
pEp-Wrapped-Message-Info: INNER (content-transfer-encoded)
[ original body ]
]
]
+ application/pgp-keys (optional)
5.1.3. Building the Outer Message for Signed Inner Messages
The outer message is an email with a body part of type multipart/
signed or multipart/encrypted resulting from applying security
services according to [RFC1847].
Signing, but not encrypting, a message with MIME Security with In pEp message format 2 the "outer message" consists of a full RFC822
OpenPGP ([RFC4880] and [RFC3156]), yields a message with the message with body and a minimal set of header fields, just those
following basic MIME structure. If any part directly below necessary to conform to MIME multipart standards.
multipart/signed is of type message/rfc822, then the property
forwarded="no" SHOULD be set.
= multipart/signed; protocol="application/pgp-signature"; The "outer message" should be encrypted and carry a signature
+ multipart/mixed according to the MIME encryption standards. The resulting message is
+ message/rfc822; forwarded="no"; the transport message which a root entity of type multipart/
| encrypted.
[ protected message ]
+ application/pgp-keys
{
Content-Disposition: attachment;
filename="pEpkey.asc"
}
+ application/pgp-signature
No additional requirements exist for a signed but not encrypted A minimal set of header fields should be set on the "transport
message with header protection. message", as to permit delivery, without disclosing private
information.
5.1.4. Building the Outer Message for Signed and Encrypted Inner The structure of the transport message may be altered in-transit,
Messages e.g. through mailing list agents, or inspection gateways.
Signing and encrypting a message with MIME Security with OpenPGP Signing and encrypting a message with MIME Security with OpenPGP
[RFC3156], yields a message with the following basic MIME structure: [RFC3156], yields a message with the following complete MIME
structure, seen across the encryption layer:
= multipart/encrypted; protocol="application/pgp-encrypted"; = multipart/encrypted; protocol="application/pgp-encrypted";
+ application/pgp-encrypted [ Version: 1 ] + application/pgp-encrypted [ Version: 1 ]
+ application/octet-stream; name="msg.asc" + application/octet-stream; name="msg.asc"
{ {
Content-Disposition: inline; filename="msg.asc"; Content-Disposition: inline; filename="msg.asc";
} }
| |
[ opaque encrypted structure ] [ opaque encrypted structure ]
| |
{ minimal headers }
+ multipart/mixed + multipart/mixed
+ text/plain [ pEp-Wrapped-Message-Info: OUTER ]
+ message/rfc822; forwarded="no"; + message/rfc822; forwarded="no";
| |
[ protected message ] { protected message headers }
+ multipart/mixed
+ multipart/alternate
+ text/plain
+ text/html
+ application/octet-stream [ attachmet_1 ]
+ application/octet-stream [ attachmet_2 ]
+ application/pgp-keys + application/pgp-keys
The header fields of the sub-part of type application/octet-stream The header fields of the sub-part of type application/octet-stream
must be modified to ensure that: SHOULD be modified to ensure that:
o the Content-Type header field's o the Content-Type header field's
* "name" parameter is set to the value "msg.asc", and * "name" parameter is set to the value "msg.asc", and
* parameter "forwarded" is set to "no", and * parameter "forwarded" is set to "no", and
o the Content-Disposition header field value is set to "inline" o the Content-Disposition header field value is set to "inline"
* and the "filename" parameter is set to "msg.asc". * and the "filename" parameter is set to "msg.asc".
5.1.5. S/MIME Compatibility 5.7. S/MIME Compatibility
Interoperability and implementation symmetry between PGP/MIME and Interoperability and implementation symmetry between PGP/MIME and
S/MIME is on the roadmap of pEp. S/MIME is on the roadmap of pEp.
6. Candidate Header Fields for Header Protection 6. Candidate Header Fields for Header Protection
By default, all headers of the original message SHOULD be protected, By default, all headers of the original message SHOULD be wrapped
with one exception: with the original message, with one exception:
o the header field "Bcc" MUST NOT be added to the protected headers. o the header field "Bcc" MUST NOT be added to the protected headers.
7. Stub Outside Headers 7. Stub Outside Headers
The outer message requires a minimal set of headers to be in place The outer message requires a minimal set of headers to be in place
for being eligible for transport. This includes the "From", "To", for being eligible for transport. This includes the "From", "To",
"Cc", "Bcc", "Subject" and "Message-ID" header fields. The protocol "Cc", "Bcc", "Subject" and "Message-ID" header fields. The protocol
hereby defined also depends on the "MIME-Version", "Content-Type", hereby defined also depends on the "MIME-Version", "Content-Type",
"Content-Disposition" and eventually the "Content-Transport-Encoding" "Content-Disposition" and eventually the "Content-Transport-Encoding"
header field to be present. header field to be present.
Submission and forwarding based on SMTP carries "from" and Submission and forwarding based on SMTP carries "from" and
"receivers" information out-of-band, so that the "From" and "To" "receivers" information out-of-band, so that the "From" and "To"
header fields are not strictly necessary. Nevertheless, "From", header fields are not strictly necessary. Nevertheless, "From",
"Date", and at least one destination header field is mandatory as per "Date", and at least one destination header field is mandatory as per
[RFC5322]. They SHOULD be conserved for reliability. [RFC5322]. They SHOULD be conserved for reliability.
The following header fields should contain a verbatim copy of the The following header fields should contain a verbatim copy of the
header fields of the original message: header fields of the inner message:
o Date o Date
o From o From
o To o To
o Cc (*) o Cc (*)
o Bcc (*) o Bcc (*)
The entries with an asterisk mark (*) should only be set if also The entries with an asterisk mark (*) should only be set if also
present in the original message. present in the original message.
If signing, but no encryption is applied to the inner message, all
other headers of the original message SHOULD be copied verbatim to
the outer message as well.
Clients which follow pEp standards MUST set the header field value Clients which follow pEp standards MUST set the header field value
for "Subject" to "=?utf-8?Q?p=E2=89=A1p?=" or "pEp". Clients which for "Subject" to "=?utf-8?Q?p=E2=89=A1p?=" or "pEp". Clients which
do not adhere to all pEp standards should set the header field value do not adhere to all pEp standards should set the header field value
of "Subject" to a descriptive stub value. An example used in of "Subject" to a descriptive stub value. An example used in
practice is practice is
o Subject: Encrypted message o Subject: Encrypted message
The following header fields should be initialized with proper values: The following header fields MUST be initialized with proper values
according to the MIME standards:
o Message-ID
o Content-Type o Content-Type
o Content-Disposition o Content-Disposition
o Content-Transport-Encoding (if necessary) o Content-Transport-Encoding (if necessary)
8. Processing Incoming Email with Protected Headers 8. Processing Incoming Email under Progressive Header Disclosure
[[ TODO ]] [[ TODO ]]
8.1. Detecting Header Protection in Incoming Email 8.1. Resolving Conflicting Protected and Unprotected Header Fields
[[ TODO: Reverse of above. Multiple equivalent specs available. ]]
8.2. Resolving Conflicting Protected and Unprotected Header Fields
For the purpose of selecting messages based on search criteria, or
just for displaying them, pEp clients may have to temporarily rebuild
the unprotected representation of the email (pEp clients may
implement a caching mechanism to avoid rebuilding these messages
repeatedly, provided they can use a trusted storage for the cache).
Every pEp wrapper email MUST contain exactly one multipart/encrypted
MIME part, which contains the protected signed-and-encrypted email as
an application/octet-stream encoded as a OpenPGP Radix-64. Such a
protected email MAY be in turn a pEp wrapper email and contain
another protected email which the client MUST try to decrypt
recursively. Through recursion, intermediate protected emails will
be encountered and header fields encountered therein, protected or
not, MUST be ignored for the purpose of rebuilding the unprotected
representation of the email.
[[ TODO: Describe what happens when the messages do not validate;
difference between have-no-key-for-it, and broken-according-to-key-
we-have. ]]
Values of protected header fields always override the header fields
defined in the outer context. A single protected header field
requires to discard ALL header fields from the outer context with the
same header name.
A header field defined in the wrapper message and not in the
protected header section, or alternatively present in the protected
header section and not in the wrapper message, MUST be present in the
unprotected representation of the email.
For the purpose of rebuilding the unprotected email, the selection of Header field values from the transport message MUST NOT be shown,
headers in DKIM is not relevant. The unprotected representation of when displaying the inner message, or the outer message. The inner
the email MAY NOT validate to DKIM or SPF rules anymore. message MUST carry all relevant header fields necessary for display.
8.3. Processing of Signed-only Email 8.2. Processing of Signed-only Email
pEp either engages in a signed-and-encrypted communication or in an pEp either engages in a signed-and-encrypted communication or in an
unsigned plaintext communication. Inbound signatures attached to unsigned plaintext communication. Inbound signatures attached to
plaintext messages are duly verified but cannot enhance the perceived plaintext messages are duly verified but cannot enhance the perceived
quality of the message in the user interface (an invalid signature quality of the message in the user interface (while an invalid
degrades the perception) ([I-D.birk-pep]). signature degrades the perception) [I-D.birk-pep].
8.4. Incoming Filter Processing 8.3. Incoming Filter Processing
The Mail User Agent may implement outgoing filtering of mails, which The Mail User Agent may implement outgoing filtering of mails, which
may veto, alter, redirect or replicate the messages. The may veto, alter, redirect or replicate the messages. The
functionality may be implemented on the mailbox server and be functionality may be implemented on the mailbox server and be
configurable through a well-known protocol, e.g., by means of The configurable through a well-known protocol, e.g., by means of The
Sieve Mail-Filtering Language [RFC5490], or be implemented client- Sieve Mail-Filtering Language [RFC5490], or be implemented client-
side, or in a combination of both. side, or in a combination of both.
A mailbox server, which is required to process the full range of A mailbox server, which is required to process the full range of
possible filters, is requiring plaintext access to the header fields. possible filters, is requiring plaintext access to the header fields.
In an end-to-end-encryption context, which pEp enforces by default, In an end-to-end-encryption context, which pEp enforces by default,
upon first reception of the message the mailbox server is limited to upon first reception of the message the mailbox server is limited to
see the transport- relevant headers of the outer wrapper message. A see the transport- relevant headers of the outer wrapper message. A
pEp client configued to trust the server ("trusted server" setting pEp client configured to trust the server ("trusted server" setting
[I-D.marques-pep-email]) will later download the encrypted message, [I-D.marques-pep-email]) will later download the encrypted message,
decrypt it and replace the copy on the server by the decrypted copy. decrypt it and replace the copy on the server by the decrypted copy.
8.4.1. Staged Filtering of Inbound Messages 8.3.1. Staged Filtering of Inbound Messages
Inbound messages are expected to be delivered to the inbox while Inbound messages are expected to be delivered to the inbox while
still being encrypted. At this point in time, server-side filtering still being encrypted. At this point in time, server-side filtering
can only evaluate the unprotected header fields in the wrapper can only evaluate the unprotected header fields in the wrapper
message. message.
In an end-to-end-encryption context, which pEp enforces by default, In an end-to-end-encryption context, which pEp enforces by default,
the mailbox server is limited to see the transport-relevant headers the mailbox server is limited to see the transport-relevant headers
of the outer wrapper message only upon first delivery. A pEp client of the outer wrapper message only upon first delivery. A pEp client
configued to trust the server ("trusted server" setting configured to trust the server ("trusted server" setting
[I-D.marques-pep-email]) will eventually download the encrypted [I-D.marques-pep-email]) will eventually download the encrypted
message, decrypt it locally and replace the copy on the server by the message, decrypt it locally and replace the copy on the server by the
decrypted copy. Server-side message filters SHOULD be able to detect decrypted copy. Server-side message filters SHOULD be able to detect
such post-processed messages, and apply the pending filters. The such post-processed messages, and apply the pending filters. The
client SHOULD easily reflect the post-filtered messages in the user client SHOULD easily reflect the post-filtered messages in the user
interface. interface.
8.5. Outgoing Filter Processing 8.4. Outgoing Filter Processing
The Mail User Agent may implement outgoing filtering of emails, which The Mail User Agent may implement outgoing filtering of emails, which
may veto, alter or replicate the email. They may also hint the MUA may veto, alter or replicate the email. They may also hint the MUA
to store a copy in an alternate "Sent" folder. to store a copy in an alternate "Sent" folder.
Filters which veto the sending or do alter the mail or replicate it Filters which veto the sending or do alter the mail or replicate it
(e.g., mass-mail generators) SHOULD be completed priorly to applying (e.g., mass-mail generators) SHOULD be completed prior to applying
protection, and thus also priorly to applying header protection. protection, and thus also prior to applying header protection.
Redirection to alternate "Sent" folders MUST NOT be decided priorly Redirection to alternate "Sent" folders MUST NOT be decided prior to
to applying protection, but MUAs MAY abide from this restriction if applying protection, but MUAs MAY abide from this restriction if they
they implement the "trusted server" option and the option is selected implement the "trusted server" option and the option is selected for
for the specific mailbox server; in this case, MUAs MUST NOT allow to the specific mailbox server; in this case, MUAs MUST NOT allow to
redirect a message to an untrusted server by these rules, to prevent redirect a message to an untrusted server by these rules, to prevent
information leakage to the untrusted server. information leakage to the untrusted server.
[[ TODO: Mention implicit filter for minimal color-rating for message [[ TODO: Mention implicit filter for minimal color-rating for message
replication. ]] replication. ]]
[[ TODO: How to produce key-export-mails manually this way? That is, [[ TODO: How to produce key-export-mails manually this way? That is,
what about non-pEp-mode? ]] what about non-pEp-mode? ]]
9. Security Considerations 9. Security Considerations
skipping to change at page 21, line 7 skipping to change at page 19, line 14
pEp for Android, iOS and Outlook are provided by pEp Security, a pEp for Android, iOS and Outlook are provided by pEp Security, a
commercial entity specializing in end-user software implementing pEp commercial entity specializing in end-user software implementing pEp
while Enigmail/pEp is pursued as community project, supported by the while Enigmail/pEp is pursued as community project, supported by the
pEp Foundation. pEp Foundation.
All software is available as Free Software and published also in All software is available as Free Software and published also in
source form. source form.
11. Acknowledgements 11. Acknowledgements
Special thanks go to Krista Bennett for valuable input to this draft Special thanks go to Krista Bennett and Volker Birk for valuable
and Hernani Marques for reviewing. input to this draft and Hernani Marques for reviewing.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.birk-pep] [I-D.birk-pep]
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
Privacy by Default", draft-birk-pep-03 (work in progress), Privacy by Default", draft-birk-pep-03 (work in progress),
March 2019. March 2019.
skipping to change at page 21, line 35 skipping to change at page 19, line 42
[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.melnikov-lamps-header-protection] [I-D.melnikov-lamps-header-protection]
Melnikov, A., "Considerations for protecting Email header Melnikov, A., "Considerations for protecting Email header
with S/MIME", draft-melnikov-lamps-header-protection-00 with S/MIME", draft-melnikov-lamps-header-protection-00
(work in progress), October 2018. (work in progress), October 2018.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847,
October 1995, <https://www.rfc-editor.org/info/rfc1847>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>. <https://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, "MIME Security with OpenPGP", RFC 3156,
DOI 10.17487/RFC3156, August 2001, DOI 10.17487/RFC3156, August 2001,
<https://www.rfc-editor.org/info/rfc3156>. <https://www.rfc-editor.org/info/rfc3156>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] 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>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5490] Melnikov, A., "The Sieve Mail-Filtering Language -- [RFC5490] Melnikov, A., "The Sieve Mail-Filtering Language --
Extensions for Checking Mailbox Status and Accessing Extensions for Checking Mailbox Status and Accessing
Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March
2009, <https://www.rfc-editor.org/info/rfc5490>. 2009, <https://www.rfc-editor.org/info/rfc5490>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
skipping to change at page 23, line 45 skipping to change at page 21, line 50
* We probably have issues and overlapping specifications about * We probably have issues and overlapping specifications about
encoding for nested message/rfc822 entities, specified in encoding for nested message/rfc822 entities, specified in
[RFC2046]. Further study is needed to find and understand the [RFC2046]. Further study is needed to find and understand the
issues. issues.
o Signed-only protection needs further study o Signed-only protection needs further study
* pEp only does header protection by applying both signing and * pEp only does header protection by applying both signing and
encryption. Technically it is also possible to sign, but not encryption. Technically it is also possible to sign, but not
encrypt the protected messages. This needs futher study. encrypt the protected messages. This needs further study.
Authors' Addresses Authors' Addresses
Claudio Luck Claudio Luck
pEp Foundation pEp Foundation
Oberer Graben 4 Oberer Graben 4
CH-8400 Winterthur CH-8400 Winterthur
Switzerland Switzerland
Email: claudio.luck@pep.foundation Email: claudio.luck@pep.foundation
URI: https://pep.foundation/ URI: https://pep.foundation/
Bernie Hoeneisen Bernie Hoeneisen
 End of changes. 75 change blocks. 
368 lines changed or deleted 313 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/