< draft-luck-lamps-pep-header-protection-02.txt		draft-luck-lamps-pep-header-protection-03.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 July 05, 2019
	Expires: September 27, 2019 Ucom.ch		Expires: January 6, 2020
	March 26, 2019
	pretty Easy privacy (pEp): Header Protection		pretty Easy privacy (pEp): Progressive Header Disclosure
	draft-luck-lamps-pep-header-protection-02		draft-luck-lamps-pep-header-protection-03
	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, and adds space for carrying public keys next to the		MIME instead, and adds space for carrying public keys next to the
	protected message.		protected message.
	In LAMPS voices have also been expressed, that whatever mechanism		In LAMPS, it has been expressed that whatever mechanism will be
	will be chosen, it should not be limited to S/MIME, but also		chosen, it should not be limited to S/MIME, but also applicable to
	applicable to PGP/MIME.		PGP/MIME.
	This document aims to contribute to this discussion and share pEp		This document aims to contribute to this discussion and share the 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 27, 2019.		This Internet-Draft will expire on January 6, 2020.
	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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2.1. The OpenPGP Radix-64 . . . . . . . . . . . . . . . . . . 4		1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1.1. Radix-64 in the Context of MIME Messages . . . . . . 5		2. Message Format for Progressive Header Disclosure . . . . . . 4
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Inner Message . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 6		2.3. Content-Type Parameter "forwarded" . . . . . . . . . . . 5
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7		2.4. Outer Message . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. General Requirements . . . . . . . . . . . . . . . . . . 7		2.5. Transport Message . . . . . . . . . . . . . . . . . . . . 8
	4.1.1. Sending Side . . . . . . . . . . . . . . . . . . . . 7		2.6. S/MIME Compatibility . . . . . . . . . . . . . . . . . . 9
	4.1.2. Receiving Side . . . . . . . . . . . . . . . . . . . 8		3. Candidate Header Fields for Header Protection . . . . . . . . 9
	4.2. Additional Requirements for Backward-Compatibility With		4. Stub Outside Headers . . . . . . . . . . . . . . . . . . . . 9
	Legacy Clients Unaware of Header Protection . . . . . . . 8		5. Processing Incoming Email under Progressive Header Disclosure 10
	4.2.1. Sending side . . . . . . . . . . . . . . . . . . . . 8		5.1. Processing of Signed-only Email . . . . . . . . . . . . . 10
	4.2.2. Receiving side . . . . . . . . . . . . . . . . . . . 8		5.2. Incoming Filter Processing . . . . . . . . . . . . . . . 10
	4.3. Additional Requirements for Backward-Compatibility with		5.2.1. Staged Filtering of Inbound Messages . . . . . . . . 11
	Legacy Header Protection Systems (if supported) . . . . . 8		5.3. Outgoing Filter Processing . . . . . . . . . . . . . . . 11
	4.3.1. Sending Side . . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	4.3.2. Receiving Side . . . . . . . . . . . . . . . . . . . 9		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
	5. Message Format for progressive header disclosure . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Design principles . . . . . . . . . . . . . . . . . . . . 9		9. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
	5.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10		9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 12
	5.3. Inner message . . . . . . . . . . . . . . . . . . . . . . 11		9.2. Current software implementing pEp . . . . . . . . . . . . 12
	5.4. Content-Type property "forwarded" . . . . . . . . . . . . 11		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	5.5. Outer message . . . . . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.6. Transport message . . . . . . . . . . . . . . . . . . . . 14		11.1. Normative References . . . . . . . . . . . . . . . . . . 13
	5.7. S/MIME Compatibility . . . . . . . . . . . . . . . . . . 15		11.2. Informative References . . . . . . . . . . . . . . . . . 14
	6. Candidate Header Fields for Header Protection . . . . . . . . 15		Appendix A. About pEp Design Principles . . . . . . . . . . . . 15
	7. Stub Outside Headers . . . . . . . . . . . . . . . . . . . . 15		Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 16
	8. Processing Incoming Email under Progressive Header Disclosure 16		Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 17
	8.1. Resolving Conflicting Protected and Unprotected Header		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
	Fields . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2. Processing of Signed-only Email . . . . . . . . . . . . . 16
	8.3. Incoming Filter Processing . . . . . . . . . . . . . . . 16
	8.3.1. Staged Filtering of Inbound Messages . . . . . . . . 17
	8.4. Outgoing Filter Processing . . . . . . . . . . . . . . . 17
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
	10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 18
	10.2. Current software implementing pEp . . . . . . . . . . . 18
	11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	14.1. Normative References . . . . . . . . . . . . . . . . . . 19
	14.2. Informative References . . . . . . . . . . . . . . . . . 21
	Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 21
	Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	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, but limited to a
	perspective, specifically DomainKeys Identified Mail (DKIM) [RFC6376]		domain-level perspective. Specifically these are DomainKeys
	and Sender Policy Framework (SPF) [RFC7208] and Domain-based Message		Identified Mail (DKIM) [RFC6376] and Sender Policy Framework (SPF)
	Authentication, Reporting, and Conformance (DMARC) [RFC7489]. These		[RFC7208] and Domain-based Message Authentication, Reporting, and
	protocols, while essential to responding to a range of attacks on		Conformance (DMARC) [RFC7489]. These protocols, while essential to
	email, do not offer full end-to-end protection to the headers section		responding to a range of attacks on email, do not offer full End-to-
	and are not capable of providing privacy for the information		End protection to the headers section and are not capable of
	contained therein.		providing privacy regarding the information represented therein.
	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 technically hideable, has
	hidden, has grown in importance over the past years.		grown in importance over the past years.
	A standard for end-to-end protection of the email headers section		A standard for End-to-End protection of the email headers section
	exists for S/MIME since version 3.1. (cf. [RFC5751] and		exists for S/MIME since version 3.1. (cf. [RFC8551]):
	[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		No mechanism for header protection has been standardized for
	(Pretty Good Privacy) yet.		[PGPMIME] yet.
	End-to-end protection for the email headers section is currently not		End-to-End protection for the email headers section is currently not
	widely implemented - neither for messages protected by means of		widely implemented - neither for messages protected by means of
	S/MIME nor PGP. At least two variants of header protection are known		S/MIME nor PGP/MIME. At least two variants of header protection are
	to be implemented. A recently submitted Internet-Draft		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 (cf. Section 5,		Option 2, adapting the S/MIME standards to PGP/MIME (cf. Section 2,
	ff.). Existing implementations of pEp have also added inbound		ff.). Existing implementations of pEp have also added inbound
	support for "Memory Hole" referred to above as Option 1, thus being		support for "Memory Hole" referred to above as Option 1, thus being
	able to study the differences and the implementator's challenges.		able to study the differences and the implementator's challenges.
			pEp now also supports the "forwarded=no" attribute proposed in
			[I-D.melnikov-lamps-header-protection], and further described in
			Section 2.3.
	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 (Section 3) and requirements		This document describes Progressive Header Disclosure as implemented
	for header protection (Section 4) and describes progressive header		in the "pEp message format version 2". This format inherently offers
	disclosure as implemented in the "pEp message format version 2".		header protection as a side effect, but is only intended for use only
	This format inherently offers header protection, and may be		with signed-and-encrypted messages. The feature of protecting
	implemented independently by mail user agents otherwise not		headers may be used independently by mail user agents otherwise not
	conforming to pEp standards (Section 5, ff.).		wanting to conform to pEp standards (Section 2, ff.).
	2. Terms		1.1. Requirements Language
	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]		1.2. Terms
	2.1. The OpenPGP Radix-64
	In the examples following in this section, it is a common pattern to
	have a MIME encoded mail containing ("wrapping") another signed and
	eventually encrypted mail. Such enclosed mails are encoded following
	the OpenPGP standard, which specifies an encoding called "Radix-64",
	which is 7-bit transport-encoding compatible by design.
	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
	<CR><LF>, and an encoded CRC-24 value.
	The following is an example, with some similar lines of base64 output
	replaced with ellipsis:
	-----BEGIN PGP MESSAGE-----
	hQIMAwusnBHN80H+AQ//cJLQLOl+6hOofKEkQJeu0wedmwt+TkzPx/sCUQ80dzLv
	...
	j/ES8ndDBftM5mZLzFQ2VatqB9G9cqCgiOVFs6jfTI13nPfLit9IPWRavcVIMdwt
	Xd9bdvHx/ReenAk/
	=7WaL
	-----END PGP MESSAGE-----
	To make the examples look more compact and relevant, the above will
	be replaced symbolically by:
	[[----- OpenPGP Radix-64 Block -----]]
	2.1.1. Radix-64 in the Context of MIME Messages
	Note that OpenPGP and MIME specifications overlap when a Radix-64
	immediately precedes a MIME boundary. The <CR><LF> sequence
	immediately preceding a MIME boundary delimiter line is considered to
	be part of the delimiter in [RFC2046], 5.1. And in OpenPGP, line
	endings are considered a part of the Armor Header Line for the
	purposes of determining the content they delimit in [RFC4880], 6.2.
	Keeping an empty line between the end Armor Header Line and the MIME
	boundary line is suggested.
	3. Use Cases
	In the following, we show the generic use cases that need to be
	addressed independently of whether S/MIME, PGP/MIME or any other
	technology is used for which Header Protection (HP) is to be applied
	to.
	3.1. Interactions
	The main interaction case for Header Protection (HP) is:
	1) Both peers (sending and receiving side) fully support HP
	For backward compatibility of legacy clients - unaware of any HP -
	the following intermediate interactions need to be considered as
	well:
	2) The sending side fully supports HP, while the receiving side does
	not support any HP
	3) The sending side does not support any HP, while the receiving
	side fully supports HP (trivial case)
	4) Neither the sending side nor the receiving side supports any HP
	(trivial case)
	The following intermediate use cases may need to be considered as
	well for backward compatibility with legacy HP systems, such as
	S/MIME since version 3.1 (cf. [RFC5751] and
	[I-D.ietf-lamps-rfc5751-bis]), in the following designated as legacy
	HP:
	5) The sending side fully supports HP, while the receiving side
	supports legacy HP only
	6) The sending side supports legacy HP only, while the receiving side
	fully supports HP
	7) Both peers (sending and receiving side) support legacy HP only
	8) The sending side supports legacy HP only, while the receiving side
	does not support any HP
	9) The sending side does not support any HP, while the receiving side
	supports legacy HP only (trivial case)
	Note: It is to be decided whether to ensure legacy HP systems do not
	conflict with any new solution for HP at all or whether (and to which
	degree) backward compatibility to legacy HP systems shall be
	maintained.
	3.2. Protection Levels
	The following protection levels need to be considered:
	a) signature and encryption
	b) signature only
	c) encryption only [[ TODO: verify whether relevant ]]
	4. Requirements
	In the following a list of requirements that need to be addressed
	independently of whether S/MIME, PGP/MIME or any other technology is
	used to apply HP to.
	4.1. General Requirements
	This subsection is listing the requirements to address use case 1)
	(cf. Section 3.1).
	G1: Define the format for HP for all protection levels. This includes
	MIME structure, Content-Type (including charset and name),
	Content-Disposition (including filename), and
	Content-Transfer-Encoding.
	G2: Define how a 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
	GS1: Determine which Header Fields (HFs) should or must be protected
	at least for signed only email.
	GS2: Determine which HFs should or must be sent in clear of an
	encrypted email.
	GS3: Determine which HF should not or must not be included in the
	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).
	GS4: Determine which HF to not to include to any HP part (e.g. Bcc).
	4.1.2. Receiving Side
	GR1: Determine how HF should be displayed to the user in case of
	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
	Clients Unaware of Header Protection
	This sub-section addresses the use cases 2) - 4) (cf. Section 3.1)
	B1: Depending on the solution, define a means to distinguish between
	forwarded messages and encapsulated messages using new HP
	mechanism.
	4.2.1. Sending side
	BS1: Define how full HP support can be indicated to outgoing
	messages.
	BS2: Define how full HP support of the receiver can be detected or
	guessed.
	BS3: Ensure a HP unaware receiving side easily can display the
	"Subject" HF to the user.
	4.2.2. Receiving side
	BR1: Define how full HP support can be detected in incoming messages.
	4.3. Additional Requirements for Backward-Compatibility with Legacy
	Header Protection Systems (if supported)
	This sub-section addresses the use cases 5) - 9) (cf. Section 3.1).
	LS1: Depending on the solution, define a means to distinguish between
	forwarded messages, legacy encapsulated messages, and
	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
	LSS1: Determine how legacy HP support can be indicated to outgoing
	messages.
	LSS2: Determine how legacy HP support of the receiver can be detected
	or guessed.
	4.3.2. Receiving Side
	LSR1: Determine how legacy HP support can be detected in incoming
	messages.
	5. Message Format for progressive header disclosure
	5.1. Design principles
	pretty Easy privacy (pEp) is working on bringing state-of-the-art
	automatic cryptography known from areas like TLS to electronic mail
	(email) communication. pEp is determined to evolve the existing
	standards as fundamentally and comprehensively as needed to gain easy
	implementation and integration, and for easy use for regular Internet
	users. pEp for email wants to attaining to good security practice
	while still retaining backward compatibility for implementations
	widespread.
	To provide the required stability as a foundation for good security
	practice, pEp for email defines a fixed MIME structure for its
	innermost message structure, so to remove most attack vectors which
	have permitted the numerous EFAIL vulnerabilities. (TBD: ref)
	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		The following terms are defined for the scope of this document:
	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		o Man-in-the-middle attack (MITM): cf. [RFC4949]
	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		2. Message Format for Progressive Header Disclosure
	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		2.1. Compatibility
	The pEp message format version 2 is designed such that a receiving		The pEp message format version 2 is designed such that a receiving
	Mail User Agent (MUA), which is OpenPGP-compliant but not pEp-		Mail User Agent (MUA), which is OpenPGP-compliant but not pEp-
	compliant, still has built-in capability to properly verify the		compliant, still has built-in capability to properly verify the
	integrity of the mail, decode it and display all information of the		integrity of the mail, decode it and display all information of the
	original mail to the user. The recovered protected message is		original mail to the user. The recovered protected message is
	selfsufficiently described, including all protected header fields.		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 9) is similar to what is standardized
	for S/MIME in [RFC5751] and its successor		for S/MIME in [RFC8551]:
	[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, [...].
	5.3. Inner message		2.2. Inner Message
			*Note*: this section is for your information only. It does not add
			requirements for the header protection feature to work.
	The pEp message format requires the innermost protected message to		The pEp message format requires the innermost protected message to
	follow a fixed MIME structure and to consist of exactly one human-		follow a fixed MIME structure and to consist of exactly one human-
	readable message which is represented in plain or HTML format. Both		readable message which is represented in plain or HTML format. Both
	plain and html entities MUST represent the same message to the user.		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		Any attachment to the message must be laid out in a flat list. No
	additional multipart entities are allowed in the pEp message.		additional multipart entities are allowed in the pEp message.
	These restrictions permit to build mail user agents which are immune		These restrictions permit to build mail user agents which are immune
	to the EFAIL attacks.		to the EFAIL attacks.
	This message is herein further referred to as the "pEp inner		This message is herein further referred to as the "pEp inner
	message".		message".
	A mail user agent wanting to follow this standard, SHOULD transform		A mail user agent wanting to follow this standard, SHOULD transform
	any "original message" into a "pEp inner message" for safe		any "original message" into a "pEp inner message" for safe
	representation on the receiving side.		representation on the receiving side.
	5.4. Content-Type property "forwarded"		2.3. Content-Type Parameter "forwarded"
	One caveat of the design is that the user interaction with message/		One caveat of the design is that the user interaction with message/
	rfc822 entities varies considerably across different mail user		rfc822 entities varies considerably across different mail user
	agents. No standard is currently available which enables MUAs to		agents. No standard is currently available which enables MUAs to
	reliably determine whenever a nested message/rfc822 entity is meant		reliably determine whenever a nested message/rfc822 entity is meant
	to blend the containing message, or if it was effectively intended to		to blend the containing message, or if it was effectively intended to
	be forwarded as a file document. pEp currently intends to implement		be forwarded as a file document. pEp currently implements the
	the proposal described by [I-D.melnikov-lamps-header-protection],		proposal described by [I-D.melnikov-lamps-header-protection], 3.2,
	3.2, which defines a new Content-Type header field parameter with		which defines a new Content-Type header field parameter with name
	name "forwarded", for the MUA to distinguish between a forwarded		"forwarded", for the MUA to distinguish between a forwarded message
	message and a nested message for the purpose of header protection,		and a nested message for the purpose of header protection, i.e.,
	i.e., using "forwarded=no".		using "forwarded=no".
	5.5. Outer message		2.4. Outer Message
	With pEp message format version 2, the pEp standardized message is		With pEp message format version 2, the pEp standardized message is
	equally wrapped in a message/rfc822 entity, but this time being in		equally wrapped in a message/rfc822 entity, but this time being in
	turn wrapped in a multipart/mixed entity. The purpose of the		turn wrapped in a multipart/mixed entity. The purpose of the
	additional nesting is to allow for public keys of the sender to be		additional nesting is to allow for public keys of the sender to be
	stored alongside the original message while being protected by the		stored alongside the original message while being protected by the
	same mechanism.		same mechanism.
	For the case of PGP/MIME, the currently only implemented MIME		For the case of PGP/MIME, the currently only implemented MIME
	encryption protocol implemented in pEp, the top-level entity called		encryption protocol implemented in pEp, the top-level entity called
	skipping to change at page 14, line 5 ¶		skipping to change at page 8, line 5 ¶
	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.6. Transport message		2.5. Transport Message
	In pEp message format 2 the "outer message" consists of a full RFC822		In pEp message format 2 the "outer message" consists of a full RFC822
	message with body and a minimal set of header fields, just those		message with body and a minimal set of header fields, just those
	necessary to conform to MIME multipart standards.		necessary to conform to MIME multipart standards.
	The "outer message" should be encrypted and carry a signature		The "outer message" should be encrypted and carry a signature
	according to the MIME encryption standards. The resulting message is		according to the MIME encryption standards. The resulting message is
	the transport message which a root entity of type multipart/		the transport message which a root entity of type multipart/
	encrypted.		encrypted.
	A minimal set of header fields should be set on the "transport		A minimal set of header fields should be set on the "transport
	message", as to permit delivery, without disclosing private		message", as to permit delivery, without disclosing private
	information.		information.
	The structure of the transport message may be altered in-transit,		The structure of the transport message may be altered in-transit,
	e.g. through mailing list agents, or inspection gateways.		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 [PGPMIME],
	[RFC3156], yields a message with the following complete MIME		yields a message with the following complete MIME structure, seen
	structure, seen across the encryption layer:		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 ]
	|		|
	skipping to change at page 15, line 15 ¶		skipping to change at page 9, line 15 ¶
	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.7. S/MIME Compatibility		2.6. 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		3. Candidate Header Fields for Header Protection
	By default, all headers of the original message SHOULD be wrapped		By default, all headers of the original message SHOULD be wrapped
	with the original message, 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		4. 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"
	skipping to change at page 16, line 26 ¶		skipping to change at page 10, line 26 ¶
	The following header fields MUST be initialized with proper values		The following header fields MUST be initialized with proper values
	according to the MIME standards:		according to the MIME standards:
	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 under Progressive Header Disclosure		5. Processing Incoming Email under Progressive Header Disclosure
	[[ TODO ]]		[[ TODO ]]
	8.1. Resolving Conflicting Protected and Unprotected Header Fields		5.1. Processing of Signed-only Email
	Header field values from the transport message MUST NOT be shown,
	when displaying the inner message, or the outer message. The inner
	message MUST carry all relevant header fields necessary for display.
	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 (while an invalid		quality of the message in the user interface (while an invalid
	signature degrades the perception) [I-D.birk-pep].		signature degrades the perception) [I-D.birk-pep].
	8.3. Incoming Filter Processing		5.2. 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 configured 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.3.1. Staged Filtering of Inbound Messages		5.2.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
	configured 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.4. Outgoing Filter Processing		5.3. 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 prior to applying		(e.g., mass-mail generators) SHOULD be completed prior to applying
	protection, and thus also prior to applying header protection.		protection, and thus also prior to applying header protection.
	Redirection to alternate "Sent" folders MUST NOT be decided prior to		Redirection to alternate "Sent" folders MUST NOT be decided prior to
	applying protection, but MUAs MAY abide from this restriction if they		applying protection, but MUAs MAY abide from this restriction if they
	skipping to change at page 18, line 8 ¶		skipping to change at page 12, line 5 ¶
	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		6. Security Considerations
	[[ TODO ]]		[[ TODO ]]
	10. Implementation Status		7. Privacy Considerations
	10.1. Introduction		[[ TODO ]]
			8. IANA Considerations
			This document has no actions for IANA.
			9. Implementation Status
			9.1. Introduction
	This section records the status of known implementations of the		This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this		protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [RFC7942].		Internet-Draft, and is based on a proposal described in [RFC7942].
	The description of implementations in this section is intended to		The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to		assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation		RFCs. Please note that the listing of any individual implementation
	here does not imply endorsement by the IETF. Furthermore, no effort		here does not imply endorsement by the IETF. Furthermore, no effort
	has been spent to verify the information presented here that was		has been spent to verify the information presented here that was
	supplied by IETF contributors. This is not intended as, and must not		supplied by IETF contributors. This is not intended as, and must not
	skipping to change at page 18, line 36 ¶		skipping to change at page 12, line 41 ¶
	features. Readers are advised to note that other implementations may		features. Readers are advised to note that other implementations may
	exist.		exist.
	According to [RFC7942], "[...] this will allow reviewers and working		According to [RFC7942], "[...] this will allow reviewers and working
	groups to assign due consideration to documents that have the benefit		groups to assign due consideration to documents that have the benefit
	of running code, which may serve as evidence of valuable		of running code, which may serve as evidence of valuable
	experimentation and feedback that have made the implemented protocols		experimentation and feedback that have made the implemented protocols
	more mature. It is up to the individual working groups to use this		more mature. It is up to the individual working groups to use this
	information as they see fit."		information as they see fit."
	10.2. Current software implementing pEp		9.2. Current software implementing pEp
	The following software implementing the pEp protocols (to varying		The following software implementing the pEp protocols (to varying
	degrees) already exists:		degrees) already exists:
	o pEp for Outlook as add-on for Microsoft Outlook, release		o pEp for Outlook as add-on for Microsoft Outlook, release
	[SRC.pepforoutlook]		[SRC.pepforoutlook]
	o pEp for Android (based on a fork of the K9 MUA), release		o pEp for Android (based on a fork of the K9 MUA), release
	[SRC.pepforandroid]		[SRC.pepforandroid]
	skipping to change at page 19, line 4 ¶		skipping to change at page 13, line 9 ¶
	o pEp for Outlook as add-on for Microsoft Outlook, release		o pEp for Outlook as add-on for Microsoft Outlook, release
	[SRC.pepforoutlook]		[SRC.pepforoutlook]
	o pEp for Android (based on a fork of the K9 MUA), release		o pEp for Android (based on a fork of the K9 MUA), release
	[SRC.pepforandroid]		[SRC.pepforandroid]
	o Enigmail/pEp as add-on for Mozilla Thunderbird, release		o Enigmail/pEp as add-on for Mozilla Thunderbird, release
	[SRC.enigmailpep]		[SRC.enigmailpep]
	o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios]		o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios]
	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. Privacy Considerations		10. Acknowledgements
	[[ TODO ]]
	12. IANA Considerations
	This document has no actions for IANA.
	13. Acknowledgements
	Special thanks go to Krista Bennett and Volker Birk for valuable		The authors would like to thank the following people who have
	input to this draft and Hernani Marques for reviewing.		provided significant contributions or feedback for the development of
			this document: Krista Bennett, Volker Birk, Bernie Hoeneisen and
			Hernani Marques.
	14. References		11. References
	14.1. Normative References		11.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.
	[I-D.ietf-lamps-rfc5751-bis]
	Schaad, J., Ramsdell, B., and S. Turner, "Secure/
	Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
	Message Specification", draft-ietf-lamps-rfc5751-bis-12
	(work in progress), September 2018.
	[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.
			[PGPMIME] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
			"MIME Security with OpenPGP", RFC 3156,
			DOI 10.17487/RFC3156, August 2001,
			<https://www.rfc-editor.org/info/rfc3156>.
	[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,
	"MIME Security with OpenPGP", RFC 3156,
	DOI 10.17487/RFC3156, August 2001,
	<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",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,		FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
	<https://www.rfc-editor.org/info/rfc4949>.		<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
	Mail Extensions (S/MIME) Version 3.2 Message
	Specification", RFC 5751, DOI 10.17487/RFC5751, January
	2010, <https://www.rfc-editor.org/info/rfc5751>.
	[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,		[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
	"DomainKeys Identified Mail (DKIM) Signatures", STD 76,		"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
	RFC 6376, DOI 10.17487/RFC6376, September 2011,		RFC 6376, DOI 10.17487/RFC6376, September 2011,
	<https://www.rfc-editor.org/info/rfc6376>.		<https://www.rfc-editor.org/info/rfc6376>.
	[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for		[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
	Authorizing Use of Domains in Email, Version 1", RFC 7208,		Authorizing Use of Domains in Email, Version 1", RFC 7208,
	DOI 10.17487/RFC7208, April 2014,		DOI 10.17487/RFC7208, April 2014,
	<https://www.rfc-editor.org/info/rfc7208>.		<https://www.rfc-editor.org/info/rfc7208>.
	[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based		[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
	Message Authentication, Reporting, and Conformance		Message Authentication, Reporting, and Conformance
	(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,		(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
	<https://www.rfc-editor.org/info/rfc7489>.		<https://www.rfc-editor.org/info/rfc7489>.
	14.2. Informative References		[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
			Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
			Message Specification", RFC 8551, DOI 10.17487/RFC8551,
			April 2019, <https://www.rfc-editor.org/info/rfc8551>.
			11.2. Informative References
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		RFC 7942, DOI 10.17487/RFC7942, July 2016,
	<https://www.rfc-editor.org/info/rfc7942>.		<https://www.rfc-editor.org/info/rfc7942>.
	[SRC.enigmailpep]		[SRC.enigmailpep]
	"Source code for Enigmail/pEp", March 2019,		"Source code for Enigmail/pEp", July 2019,
	<https://enigmail.net/index.php/en/download/source-code>.		<https://enigmail.net/index.php/en/download/source-code>.
	[SRC.pepforandroid]		[SRC.pepforandroid]
	"Source code for pEp for Android", March 2019,		"Source code for pEp for Android", July 2019,
	<https://pep-security.lu/gitlab/android/pep>.		<https://pep-security.lu/gitlab/android/pep>.
	[SRC.pepforios]		[SRC.pepforios]
	"Source code for pEp for iOS", March 2019,		"Source code for pEp for iOS", July 2019,
	<https://pep-security.ch/dev/repos/pEp_for_iOS/>.		<https://pep-security.ch/dev/repos/pEp_for_iOS/>.
	[SRC.pepforoutlook]		[SRC.pepforoutlook]
	"Source code for pEp for Outlook", March 2019,		"Source code for pEp for Outlook", July 2019,
	<https://pep-security.lu/dev/repos/pEp_for_Outlook/>.		<https://pep-security.lu/dev/repos/pEp_for_Outlook/>.
	Appendix A. Document Changelog		Appendix A. About pEp Design Principles
			pretty Easy privacy (pEp) is working on bringing state-of-the-art
			automatic cryptography known from areas like TLS to electronic mail
			(email) communication. pEp is determined to evolve the existing
			standards as fundamentally and comprehensively as needed to gain easy
			implementation and integration, and for easy use for regular Internet
			users. pEp for email wants to attain to good security practice while
			still retaining backward compatibility for implementations
			widespread.
			To provide the required stability as a foundation for good security
			practice, pEp for email defines a fixed MIME structure for its
			innermost message structure, so to remove most attack vectors which
			have permitted the numerous EFAIL vulnerabilities. (TBD: ref)
			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.
			Appendix B. Document Changelog
	[[ RFC Editor: This section is to be removed before publication ]]		[[ RFC Editor: This section is to be removed before publication ]]
	o draft-luck-lamps-pep-header-protection-02		o draft-luck-lamps-pep-header-protection-03
			* Remove Use Cases / Requirements sections (move to new doc)
			* Adjust title of the document
			* Added note on implementation done of forwarded=no
			o draft-luck-lamps-pep-header-protection-02
	* Add Privacy and IANA Considerations sections		* Add Privacy and IANA Considerations sections
	* Added / Adjusted requirements		* Added / Adjusted requirements
	o draft-luck-lamps-pep-header-protection-01		o draft-luck-lamps-pep-header-protection-01
	* Major rewrite and update of whole document		* Major rewrite and update of whole document
	o draft-luck-lamps-pep-header-protection-00		o draft-luck-lamps-pep-header-protection-00
	* Initial version		* Initial version
	Appendix B. Open Issues		Appendix C. Open Issues
	[[ RFC Editor: This section should be empty and is to be removed		[[ RFC Editor: This section should be empty and is to be removed
	before publication. ]]		before publication. ]]
	o Align with specification for MIME Content-Type message/partial		o Align with specification for MIME Content-Type message/partial
	* 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		Author's Address
	* pEp only does header protection by applying both signing and
	encryption. Technically it is also possible to sign, but not
	encrypt the protected messages. This needs further study.
	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
	Ucom Standards Track Solutions GmbH
	CH-8046 Zuerich
	Switzerland
	Phone: +41 44 500 52 44
	Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
	URI: https://ucom.ch/
End of changes. 62 change blocks.
	430 lines changed or deleted		208 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/