< draft-pep-email-00.txt		draft-pep-email-01.txt >
	Network Working Group H. Marques		Network Working Group H. Marques
	Internet-Draft pEp Foundation		Internet-Draft pEp Foundation
	Intended status: Standards Track July 10, 2020		Intended status: Standards Track November 03, 2020
	Expires: January 11, 2021		Expires: May 7, 2021
	pretty Easy privacy (pEp): Email Formats and Protocols		pretty Easy privacy (pEp): Email Formats and Protocols
	draft-pep-email-00		draft-pep-email-01
	Abstract		Abstract
	The proposed pretty Easy privacy (pEp) protocols for email are based		The proposed pretty Easy privacy (pEp) protocols for email are based
	upon already existing email and encryption formats (as PGP/MIME) and		upon already existing email and encryption formats (as PGP/MIME) and
	designed to allow for easily implementable and interoperable		designed to allow for easily implementable and interoperable
	opportunistic encryption. The protocols range from key distribution,		opportunistic encryption. The protocols range from key distribution,
	secret key synchronization between own devices, to mechanisms of		secret key synchronization between own devices, to mechanisms of
	metadata and content protection. The metadata and content protection		metadata and content protection. The metadata and content protection
	is achieved by moving the whole message (not only the body part) into		is achieved by moving the whole message (not only the body part) into
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 January 11, 2021.		This Internet-Draft will expire on May 7, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 42 ¶		skipping to change at page 2, line 42 ¶
	2.5. End-to-End . . . . . . . . . . . . . . . . . . . . . . . 7		2.5. End-to-End . . . . . . . . . . . . . . . . . . . . . . . 7
	2.6. Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . 7		2.6. Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . 7
	2.7. User Experience (UX) . . . . . . . . . . . . . . . . . . 7		2.7. User Experience (UX) . . . . . . . . . . . . . . . . . . 7
	2.8. Identity System . . . . . . . . . . . . . . . . . . . . . 7		2.8. Identity System . . . . . . . . . . . . . . . . . . . . . 7
	2.8.1. Address . . . . . . . . . . . . . . . . . . . . . . . 8		2.8.1. Address . . . . . . . . . . . . . . . . . . . . . . . 8
	2.8.2. Key . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.8.2. Key . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.8.3. User . . . . . . . . . . . . . . . . . . . . . . . . 8		2.8.3. User . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.8.4. Identity . . . . . . . . . . . . . . . . . . . . . . 8		2.8.4. Identity . . . . . . . . . . . . . . . . . . . . . . 8
	2.8.5. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9		2.8.5. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.9. pEp Email Formats . . . . . . . . . . . . . . . . . . . . 9		2.9. pEp Email Formats . . . . . . . . . . . . . . . . . . . . 9
	2.9.1. Unencrypted pEp Format . . . . . . . . . . . . . . . 9		2.9.1. Unencrypted pEp Format . . . . . . . . . . . . . . . 10
	2.9.2. pEp Email Format 1.0 . . . . . . . . . . . . . . . . 11		2.9.2. pEp Email Format 1.0 . . . . . . . . . . . . . . . . 11
	2.9.3. pEp Email Format 2.0 . . . . . . . . . . . . . . . . 15		2.9.3. pEp Email Format 2.0 . . . . . . . . . . . . . . . . 15
	2.9.4. pEp Email Format 2.1 . . . . . . . . . . . . . . . . 18		2.9.4. pEp Email Format 2.1 . . . . . . . . . . . . . . . . 18
	2.9.5. Protocol Negotiation for Format Selection . . . . . . 21		2.9.5. Protocol Negotiation for Format Selection . . . . . . 21
	2.9.6. Saving Messages . . . . . . . . . . . . . . . . . . . 21		2.9.6. Saving Messages . . . . . . . . . . . . . . . . . . . 21
	3. Key Management . . . . . . . . . . . . . . . . . . . . . . . 21		3. Key Management . . . . . . . . . . . . . . . . . . . . . . . 21
	3.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 21		3.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 21
	3.2. Private Keys . . . . . . . . . . . . . . . . . . . . . . 22		3.2. Private Keys . . . . . . . . . . . . . . . . . . . . . . 22
	3.2.1. Storage . . . . . . . . . . . . . . . . . . . . . . . 22		3.2.1. Storage . . . . . . . . . . . . . . . . . . . . . . . 22
	3.2.2. Passphrase . . . . . . . . . . . . . . . . . . . . . 22		3.2.2. Passphrase . . . . . . . . . . . . . . . . . . . . . 22
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27		9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	11. Implementation Status . . . . . . . . . . . . . . . . . . . . 27		11. Implementation Status . . . . . . . . . . . . . . . . . . . . 27
	11.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 27		11.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 27
	11.2. Current software implementations of pEp . . . . . . . . 27		11.2. Current software implementations of pEp . . . . . . . . 27
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
	13.1. Normative References . . . . . . . . . . . . . . . . . . 28		13.1. Normative References . . . . . . . . . . . . . . . . . . 28
	13.2. Informative References . . . . . . . . . . . . . . . . . 29		13.2. Informative References . . . . . . . . . . . . . . . . . 29
	Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 31		Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 31
	Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 31		Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 32
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	This document contains propositions for implementers of Mail User		This document contains propositions for implementers of Mail User
	Agents (MUAs) seeking to support pretty Easy privacy (pEp)		Agents (MUAs) seeking to support pretty Easy privacy (pEp)
	specifically for email [RFC5322]. All the propositions of		specifically for email [RFC5322]. All the propositions of
	[I-D.birk-pep] also apply to pEp for email. In this document,		[I-D.birk-pep] also apply to pEp for email. In this document,
	requirements are outlined for MUAs wanting to establish		requirements are outlined for MUAs wanting to establish
	interoperability and/or to implement pEp for email.		interoperability and/or to implement pEp for email.
	pEp for email builds upon the cryptographic security services offered		pEp for email builds upon the cryptographic security services offered
	by PGP/MIME [RFC3156]. The primary goal is		by PGP/MIME [RFC3156]. The primary goals of pEp for email are:
	(1) Maximization of email privacy for Internet actors deploying and		(1) Maximization of email privacy for Internet actors deploying and
	using the pretty Easy privacy approach.		using the pretty Easy privacy approach.
	(2) Compatibility with legacy or other automatic email encryption		(2) Compatibility with legacy or other automatic email encryption
	solutions in order to preserve privacy to the greatest extent		solutions in order to preserve privacy to the greatest extent
	possible.		possible.
	Interoperability with S/MIME [RFC8551] is a also goal, but at this		Interoperability with S/MIME [RFC8551] is a also goal, but at this
	time there is no specification or running code that achieves this		time there is no specification or running code that achieves this
	skipping to change at page 5, line 33 ¶		skipping to change at page 5, line 33 ¶
	authenticating that assertion. Subsequent communication that is		authenticating that assertion. Subsequent communication that is
	authenticated using the cached key or credential is secure against		authenticated using the cached key or credential is secure against
	an MiTM attack, if such an attack did not succeed during the		an MiTM attack, if such an attack did not succeed during the
	vulnerable initial communication."		vulnerable initial communication."
	o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A		o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A
	form of active wiretapping attack in which the attacker intercepts		form of active wiretapping attack in which the attacker intercepts
	and selectively modifies communicated data to masquerade as one or		and selectively modifies communicated data to masquerade as one or
	more of the entities involved in a communication association."		more of the entities involved in a communication association."
			Note: Historically, MITM has stood for '_Man_-in-the-middle'.
			However, to indicate that the entity in the middle is not always a
			human attacker, MITM can also stand for 'Machine-in-the-middle' or
			'Meddler-in-the-middle'.
	2. Opportunistic Security and Privacy for Email		2. Opportunistic Security and Privacy for Email
	In addition to the Protocol's Core Design Principles outlined in		In addition to the Protocol's Core Design Principles outlined in
	[I-D.birk-pep], the following sections on design principles are		[I-D.birk-pep], the following sections on design principles are
	applicable to pEp for email applications.		applicable to pEp for email applications.
	2.1. Privacy by Default		2.1. Privacy by Default
	The pEp formats and protocols aim to maximize privacy. Where privacy		The pEp formats and protocols aim to maximize privacy. Where privacy
	goals contradict with security goals, the privacy goals MUST take		goals contradict with security goals, the privacy goals MUST take
	skipping to change at page 11, line 39 ¶		skipping to change at page 11, line 39 ¶
	Thus, legacy clients not aware of nor able to parse pEp's subject		Thus, legacy clients not aware of nor able to parse pEp's subject
	encryption, still display the actual subject (in the above example:		encryption, still display the actual subject (in the above example:
	"Credentials") to the user. Whenever the first encrypted "text/		"Credentials") to the user. Whenever the first encrypted "text/
	plain" MIME entity contains such a subject line, the MUAs		plain" MIME entity contains such a subject line, the MUAs
	implementing pEp MUST render it to the user. Note that also the		implementing pEp MUST render it to the user. Note that also the
	lines starting with "subject:" or "SUBJECT:" are to be rendered (as		lines starting with "subject:" or "SUBJECT:" are to be rendered (as
	with header fields, this is case-insensitive).		with header fields, this is case-insensitive).
	A pEp-enabled MUA MUST add the "X-pEp-Version" header field with its		A pEp-enabled MUA MUST add the "X-pEp-Version" header field with its
	highest value (preferably with value "2.1" as for pEp Email Format		highest value (preferably with value "2.1" as for pEp Email Format
	2.1 Section 2.9.4) when producing this format. Herewith, a pEp-		2.1 Section 2.9.4) when producing this format. Here, a pEp-enabled
	enabled MUA announces its capability to receive and render more		MUA declares its capability to receive and render more privacy-
	privacy-preserving formats. Upgrading both sides to the highest		preserving formats. Upgrading both sides to the highest version of
	version of the pEp Email Format allows pEp-enabled MUAs for best		the pEp Email Format allows pEp-enabled MUAs for best possible
	possible protection of metadata. For non-pEp MUAs it is OPTIONAL to		protection of metadata. For non-pEp MUAs it is OPTIONAL to add the
	add the "X-pEp-Version: 1.0" header field. However, this format is		"X-pEp-Version: 1.0" header field. However, this format is
	implicitly assumed (if this header field is not present).		implicitly assumed even if this header field is not present.
	Please note that for messages between pEp- and non-pEp clients the		Please note that for messages between pEp- and non-pEp clients the
	subject encryption MAY be disabled, sacrificing usability (avoiding		subject encryption MAY be disabled, sacrificing usability over
	artifacts for receiving non-pEp clients) over privacy.		privacy by avoiding artefacts for non-pEp recipients.
	PEF-1.0 is also considered pEp's compatibility format towards non-pEp		PEF-1.0 is also considered pEp's compatibility format towards non-pEp
	clients.		clients.
	A PEF-1.0 example looks as follows:		A PEF-1.0 example looks as follows:
	From: Alice <alice@example.org>		From: Alice <alice@example.org>
	To: Bob <bob@example.org>		To: Bob <bob@example.org>
	Date: Wed, 1 Jan 2020 23:23:23 +0200		Date: Wed, 1 Jan 2020 23:23:23 +0200
	X-pEp-Version: 1.0		X-pEp-Version: 1.0
	skipping to change at page 30, line 8 ¶		skipping to change at page 30, line 8 ¶
	[I-D.birk-pep-trustwords]		[I-D.birk-pep-trustwords]
	Hoeneisen, B. and H. Marques, "IANA Registration of		Hoeneisen, B. and H. Marques, "IANA Registration of
	Trustword Lists: Guide, Template and IANA Considerations",		Trustword Lists: Guide, Template and IANA Considerations",
	draft-birk-pep-trustwords-05 (work in progress), January		draft-birk-pep-trustwords-05 (work in progress), January
	2020.		2020.
	[I-D.pep-keysync]		[I-D.pep-keysync]
	Birk, V., Hoeneisen, B., and K. Bristol, "pretty Easy		Birk, V., Hoeneisen, B., and K. Bristol, "pretty Easy
	privacy (pEp): Key Synchronization Protocol (KeySync)",		privacy (pEp): Key Synchronization Protocol (KeySync)",
	draft-pep-keysync-00 (work in progress), November 2019.		draft-pep-keysync-02 (work in progress), July 2020.
	[ISOC.bnet]		[ISOC.bnet]
	Simao, I., "Beyond the Net. 12 Innovative Projects		Simao, I., "Beyond the Net. 12 Innovative Projects
	Selected for Beyond the Net Funding. Implementing Privacy		Selected for Beyond the Net Funding. Implementing Privacy
	via Mass Encryption: Standardizing pretty Easy privacy's		via Mass Encryption: Standardizing pretty Easy privacy's
	protocols", June 2017, <https://www.internetsociety.org/		protocols", June 2017, <https://www.internetsociety.org/
	blog/2017/06/12-innovative-projects-selected-for-beyond-		blog/2017/06/12-innovative-projects-selected-for-beyond-
	the-net-funding/>.		the-net-funding/>.
	[pEp.mixnet]		[pEp.mixnet]
	skipping to change at page 30, line 33 ¶		skipping to change at page 30, line 33 ¶
	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>.
	[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/		[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
	Multipurpose Internet Mail Extensions (S/MIME) Version 4.0		Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
	Message Specification", RFC 8551, DOI 10.17487/RFC8551,		Message Specification", RFC 8551, DOI 10.17487/RFC8551,
	April 2019, <https://www.rfc-editor.org/info/rfc8551>.		April 2019, <https://www.rfc-editor.org/info/rfc8551>.
	[SRC.enigmailpep]		[SRC.enigmailpep]
	"Source code for Enigmail/pEp", July 2020,		"Source code for Enigmail/pEp", November 2020,
	<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", July 2020,		"Source code for pEp for Android", November 2020,
	<https://pep-security.lu/gitlab/android/pep>.		<https://pep-security.lu/gitlab/android/pep>.
	[SRC.pepforios]		[SRC.pepforios]
	"Source code for pEp for iOS", July 2020,		"Source code for pEp for iOS", November 2020,
	<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", July 2020,		"Source code for pEp for Outlook", November 2020,
	<https://pep-security.lu/dev/repos/pEp_for_Outlook/>.		<https://pep-security.lu/dev/repos/pEp_for_Outlook/>.
	[SRC.pepforthunderbird]		[SRC.pepforthunderbird]
	"Source code for pEp for Thunderbird", July 2020,		"Source code for pEp for Thunderbird", November 2020,
	<https://pep-security.lu/dev/repos/pEp_for_Thunderbird/>.		<https://pep-security.lu/dev/repos/pEp_for_Thunderbird/>.
	Appendix A. Document Changelog		Appendix A. Document Changelog
	[[ RFC Editor: This section is to be removed before publication ]]		[[ RFC Editor: This section is to be removed before publication ]]
			o draft-pep-email-01:
			* Minor language improvements
	o draft-pep-email-00:		o draft-pep-email-00:
	* Major restructure of the document		* Major restructure of the document
	* Major fixes in the description of the various message formats		* Major fixes in the description of the various message formats
	* Add many open questions and comments inline (TODO)		* Add many open questions and comments inline (TODO)
	* Add IANA Considerations section		* Add IANA Considerations section
End of changes. 16 change blocks.
	22 lines changed or deleted		31 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/