draft-ietf-lamps-header-protection-01.txt		draft-ietf-lamps-header-protection-02.txt
	LAMPS Working Group B. Hoeneisen		LAMPS Working Group B. Hoeneisen
	Internet-Draft pEp Foundation		Internet-Draft pEp Foundation
	Intended status: Standards Track D. Gillmor		Intended status: Standards Track D.K. Gillmor
	Expires: May 6, 2021 American Civil Liberties Union		Expires: 7 May 2021 American Civil Liberties Union
	A. Melnikov		A. Melnikov
	Isode Ltd		Isode Ltd
	November 02, 2020		3 November 2020
	Header Protection for S/MIME		Header Protection for S/MIME
	draft-ietf-lamps-header-protection-01		draft-ietf-lamps-header-protection-02
	Abstract		Abstract
	S/MIME version 3.1 has introduced a feasible standardized option to		S/MIME version 3.1 has introduced a feasible standardized option to
	accomplish Header Protection. However, implementations of Header		accomplish Header Protection. However, implementations of Header
	Protection can cause rendering issues on the receiving side. Clearer		Protection can cause rendering issues on the receiving side. Clearer
	specifications regarding message processing, particularly with		specifications regarding message processing, particularly with
	respect to header sections, are needed in order to resolve these		respect to header sections, are needed in order to resolve these
	rendering issues.		rendering issues.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 May 6, 2021.		This Internet-Draft will expire on 7 May 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		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
	1.1. Other Protocols to Protect Email Headers . . . . . . . . 4		1.1. Other Protocols to Protect Email Headers . . . . . . . . 4
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
	1.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 8		2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 8		2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 8		2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 8
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 8		3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 8
	3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 8		3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 8
	3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 8		3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 8
	3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 10		3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 10
	3.2.1. In-Scope . . . . . . . . . . . . . . . . . . . . . . 10		3.2.1. In-Scope . . . . . . . . . . . . . . . . . . . . . . 10
	3.2.2. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 10		3.2.2. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 10
	4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 11		4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 11
	4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 11		4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 11
	4.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 14		4.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 14
	4.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 18		4.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 18
	4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 18		4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 18
	4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 18		4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 18
	4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 19		4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 19
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 19		5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . 20
	9.2. Informative References . . . . . . . . . . . . . . . . . 21		9.2. Informative References . . . . . . . . . . . . . . . . . 21
	Appendix A. Additional information . . . . . . . . . . . . . . . 22		Appendix A. Additional information . . . . . . . . . . . . . . . 22
	A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 22		A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 22
	Appendix B. Text Moved from Above . . . . . . . . . . . . . . . 22		Appendix B. Text Moved from Above . . . . . . . . . . . . . . . 23
	B.1. MIME Format . . . . . . . . . . . . . . . . . . . . . . . 23		B.1. MIME Format . . . . . . . . . . . . . . . . . . . . . . . 23
	B.1.1. S/MIME Specification . . . . . . . . . . . . . . . . 23		B.1.1. S/MIME Specification . . . . . . . . . . . . . . . . 23
	Appendix C. Document Changelog . . . . . . . . . . . . . . . . . 25		Appendix C. Document Changelog . . . . . . . . . . . . . . . . . 25
	Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 26		Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	Privacy and security issues regarding email Header Protection in		Privacy and security issues regarding email Header Protection in S/
	S/MIME have been identified for some time. Most current		MIME have been identified for some time. Most current
	implementations of cryptographically-protected electronic mail		implementations of cryptographically-protected electronic mail
	protect only the body of the message, which leaves significant room		protect only the body of the message, which leaves significant room
	for attacks against otherwise-protected messages. For example, lack		for attacks against otherwise-protected messages. For example, lack
	of header protection allows an attacker to substitute the message		of header protection allows an attacker to substitute the message
	subject and/or author.		subject and/or author.
	A way to provide end-to-end protection for the Header Section of an		A way to provide end-to-end protection for the Header Section of an
	email message has been standardized for S/MIME version 3.1 and later		email message has been standardized for S/MIME version 3.1 and later
	(cf. [RFC8551]):		(cf. [RFC8551]):
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 40 ¶
	contains the protected email message that should be rendered		contains the protected email message that should be rendered
	directly. For these cases, the user can click on the attachment to		directly. For these cases, the user can click on the attachment to
	view the protected message. However, there have also been reports of		view the protected message. However, there have also been reports of
	email clients displaying garbled text, or sometimes nothing at all.		email clients displaying garbled text, or sometimes nothing at all.
	In those cases the email clients on the receiving side are (most		In those cases the email clients on the receiving side are (most
	likely) not fully MIME-capable.		likely) not fully MIME-capable.
	The following shortcomings have been identified to cause these		The following shortcomings have been identified to cause these
	issues:		issues:
	o Broken or incomplete implementations		* Broken or incomplete implementations
	o Lack of a simple means to distinguish "forwarded message" and		* Lack of a simple means to distinguish "forwarded message" and
	"wrapped message" (for the sake of Header Protection)		"wrapped message" (for the sake of Header Protection)
	o Not enough guidance with respect to handling of Header Fields on		* Not enough guidance with respect to handling of Header Fields on
	both the sending and the receiving side		both the sending and the receiving side
	Furthermore, the need (technical) Data Minimization, which includes		Furthermore, the need (technical) Data Minimization, which includes
	data sparseness and hiding all technically concealable information,		data sparseness and hiding all technically concealable information,
	has grown in importance over the past several years. In addition,		has grown in importance over the past several years. In addition,
	backwards compatibility must be considered when it is possible to do		backwards compatibility must be considered when it is possible to do
	so without compromising privacy and security.		so without compromising privacy and security.
	No mechanism for Header Protection has been standardized for PGP/MIME		No mechanism for Header Protection has been standardized for PGP/MIME
	(Pretty Good Privacy) [RFC3156] yet. PGP/MIME developers have		(Pretty Good Privacy) [RFC3156] yet. PGP/MIME developers have
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 30 ¶
	This document is in an early draft state and contains a proposal on		This document is in an early draft state and contains a proposal on
	which to base future discussions of this topic. In any case, the		which to base future discussions of this topic. In any case, the
	final mechanism is to be determined by the IETF LAMPS WG.		final mechanism is to be determined by the IETF LAMPS WG.
	1.1. Other Protocols to Protect Email Headers		1.1. Other Protocols to Protect Email Headers
	A range of protocols for the protection of electronic mail (email)		A range of protocols for the protection of electronic mail (email)
	exists, which allows one to assess the authenticity and integrity of		exists, which allows one to assess the authenticity and integrity of
	the email headers section or selected Header Fields from the domain-		the email headers section or selected Header Fields from the domain-
	level perspective, specifically DomainKeys Identified Mail (DKIM)		level perspective, specifically DomainKeys Identified Mail (DKIM)
	[RFC6376], as used by Domain-based Message Authentication, Reporting,
	and Conformance (DMARC) [RFC7489]. These protocols provide a domain-
	based reputation mechanism that can be used to mitigate some forms of
	unsolicited email (spam). At the same time, these protocols can
	provide a level of cryptographic integrity and authenticity for some
	headers, depending on how they are used.
	However, integrity protection and proof of authenticity are both tied		However, integrity protection and proof of authenticity are both tied
	to the domain name of the sending e-mail address, not the sending		to the domain name of the sending e-mail address, not the sending
	address itself, so these protocols do not provide end-to-end		address itself, so these protocols do not provide end-to-end
	protection, and are incapable of providing any form of		protection, and are incapable of providing any form of
	confidentiality.		confidentiality.[RFC6376], as used by Domain-based Message
			Authentication, Reporting, and Conformance (DMARC) [RFC7489]. These
			protocols provide a domain-based reputation mechanism that can be
			used to mitigate some forms of unsolicited email (spam). At the same
			time, these protocols can provide a level of cryptographic integrity
			and authenticity for some headers, depending on how they are used.
	1.2. Requirements Language		1.2. 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].
	1.3. Terms		1.3. Terms
	The following terms are defined for the scope of this document:		The following terms are defined for the scope of this document:
	o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A		* 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'.		Note: Historically, MITM has stood for '_Man_-in-the-middle'.
	However, to indicate that the entity in the middle is not always a		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		human attacker, MITM can also stand for 'Machine-in-the-middle' or
	'Meddler-in-the-middle'.		'Meddler-in-the-middle'.
	o S/MIME: Secure/Multipurpose Internet Mail Extensions (cf.		* S/MIME: Secure/Multipurpose Internet Mail Extensions (cf.
	[RFC8551])		[RFC8551])
	o PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156])		* PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156])
	o Message: An Email Message consisting of Header Fields		* Message: An Email Message consisting of Header Fields
	(collectively called "the Header Section of the message")		(collectively called "the Header Section of the message")
	followed, optionally, by a Body; cf. [RFC5322].		followed, optionally, by a Body; cf. [RFC5322].
	Note: To avoid ambiguity, this document does not use the terms		Note: To avoid ambiguity, this document does not use the terms
	"Header" or "Headers" in isolation, but instead always uses		"Header" or "Headers" in isolation, but instead always uses
	"Header Field" to refer to the individual field and "Header		"Header Field" to refer to the individual field and "Header
	Section" to refer to the entire collection; cf. [RFC5322].		Section" to refer to the entire collection; cf. [RFC5322].
	o Header Field (HF): cf. [RFC5322] Header Fields are lines beginning		* Header Field (HF): cf. [RFC5322] Header Fields are lines beginning
	with a field name, followed by a colon (":"), followed by a field		with a field name, followed by a colon (":"), followed by a field
	body (value), and terminated by CRLF.		body (value), and terminated by CRLF.
	o Header Section (HS): The Header Section is a sequence of lines of		* Header Section (HS): The Header Section is a sequence of lines of
	characters with special syntax as defined in [RFC5322]. It is the		characters with special syntax as defined in [RFC5322]. It is the
	(top) section of a Message containing the Header Fields.		(top) section of a Message containing the Header Fields.
	o Body: The Body is simply a sequence of bytes that follows the		* Body: The Body is simply a sequence of bytes that follows the
	Header Section and is separated from the Header Section by an		Header Section and is separated from the Header Section by an
	empty line (i.e., a line with nothing preceding the CRLF); cf		empty line (i.e., a line with nothing preceding the CRLF); cf
	[RFC5322]. It is the (bottom) section of Message containing the		[RFC5322]. It is the (bottom) section of Message containing the
	payload of a Message. Typically, the Body consists of a (possibly		payload of a Message. Typically, the Body consists of a (possibly
	multipart) MIME [RFC2045] construct.		multipart) MIME [RFC2045] construct.
	o MIME Header Fields: Header Fields describing content of a MIME		* MIME Header Fields: Header Fields describing content of a MIME
	entity [RFC2045], in particular the MIME structure. Each MIME		entity [RFC2045], in particular the MIME structure. Each MIME
	Header Field name starts with "Content-" prefix.		Header Field name starts with "Content-" prefix.
	o MIME Header Section (part): The collection of MIME Header Fields.		* MIME Header Section (part): The collection of MIME Header Fields.
	"MIME Header Section" refers to a Header Sections that contains		"MIME Header Section" refers to a Header Sections that contains
	only MIME Header Fields, whereas "MIME Header Section part" refers		only MIME Header Fields, whereas "MIME Header Section part" refers
	to the MIME Header Fields of a Header Section that - in addition		to the MIME Header Fields of a Header Section that - in addition
	to MIME Header Fields - also contains non-MIME Header Fields.		to MIME Header Fields - also contains non-MIME Header Fields.
	o Essential Header Fields (EHF): The minimum set of Header Fields an		* Essential Header Fields (EHF): The minimum set of Header Fields an
	Outer Message Header Section SHOULD contain; cf. Section 4.1.2.4.		Outer Message Header Section SHOULD contain; cf. Section 4.1.2.4.
	o Header Protection (HP): cryptographic protection of email Header		* Header Protection (HP): cryptographic protection of email Header
	Sections (or parts of it) for signatures and/or encryption		Sections (or parts of it) for signatures and/or encryption
	o Protection Levels (PL): The level of protection applied to a		* Protection Levels (PL): The level of protection applied to a
	Message, e.g. 'signature and encryption' or 'signature only' (cf.		Message, e.g. 'signature and encryption' or 'signature only' (cf.
	Section 3.2).		Section 3.2).
	o Protected: Portions of a message that have had any Protection		* Protected: Portions of a message that have had any Protection
	Levels applied.		Levels applied.
	o Protected Message: A Message that has had any Protection Levels		* Protected Message: A Message that has had any Protection Levels
	applied.		applied.
	o Unprotected: Portions of a Message that has had no Protection		* Unprotected: Portions of a Message that has had no Protection
	Levels applied.		Levels applied.
	o Unprotected Message: A Message that has had no Protection Levels		* Unprotected Message: A Message that has had no Protection Levels
	applied.		applied.
	o Submission Entity: The entity which executes further processing of		* Submission Entity: The entity which executes further processing of
	the Message (incl. transport towards the receiver), after		the Message (incl. transport towards the receiver), after
	protection measures have been applied to the Message.		protection measures have been applied to the Message.
	Note: The Submission Entity varies among implementations, mainly		Note: The Submission Entity varies among implementations, mainly
	depending on the stage where protection measures are applied: E.g.		depending on the stage where protection measures are applied: E.g.
	a Message Submission Agent (MSA) [RFC6409] or another		a Message Submission Agent (MSA) [RFC6409] or another
	(proprietary) solution. The latter is particularly relevant, if		(proprietary) solution. The latter is particularly relevant, if
	protection is implemented as a plugin solution. Some		protection is implemented as a plugin solution. Some
	implementations may determine the destination recipients by		implementations may determine the destination recipients by
	reading the To, Cc and Bcc Header Fields of the Outer Message.		reading the To, Cc and Bcc Header Fields of the Outer Message.
	o Original Message (OrigM): The Message to be protected before any		* Original Message (OrigM): The Message to be protected before any
	protection-related processing has been applied on the sending		protection-related processing has been applied on the sending
	side. If the source is not a "message/rfc822" Message, OrigM is		side. If the source is not a "message/rfc822" Message, OrigM is
	defined as the "virtual" Message that would be constructed for		defined as the "virtual" Message that would be constructed for
	sending it as unprotected email.		sending it as unprotected email.
	o Inner Message (InnerM): The Message to be protected which has had		* Inner Message (InnerM): The Message to be protected which has had
	wrapping and protection measures aapplied on the sending side OR		wrapping and protection measures aapplied on the sending side OR
	the resulting Message once decryption and unwrapping on the		the resulting Message once decryption and unwrapping on the
	receiving side has been performed. Typically, the Inner Message		receiving side has been performed. Typically, the Inner Message
	is in clear text. The Inner Message is a subset of (or the same		is in clear text. The Inner Message is a subset of (or the same
	as) the Original Message (cf. Section 4.1.2.1). The Inner		as) the Original Message (cf. Section 4.1.2.1). The Inner
	Message must be the same on the sending and the receiving side.		Message must be the same on the sending and the receiving side.
	o Outer Message (OuterM): The Message as provided to the Submission		* Outer Message (OuterM): The Message as provided to the Submission
	Entity or received from the last hop respectively. The Outer		Entity or received from the last hop respectively. The Outer
	Message normally differs on the sending and the receiving side		Message normally differs on the sending and the receiving side
	(e.g. new Header Fields are added by intermediary nodes).		(e.g. new Header Fields are added by intermediary nodes).
	o Receiving User Facing Message (RUFM): The Message used for		* Receiving User Facing Message (RUFM): The Message used for
	rendering at the receiving side. Typically this is the same as		rendering at the receiving side. Typically this is the same as
	the Inner Message.		the Inner Message.
	o Data Minimization: Data sparseness and hiding of all technically		* Data Minimization: Data sparseness and hiding of all technically
	concealable information whenever possible.		concealable information whenever possible.
	o Cryptographic Layer, Cryptographic Payload, and Cryptographic		* Cryptographic Layer, Cryptographic Payload, and Cryptographic
	Envelope are all used as defined in		Envelope are all used as defined in
	[I-D.dkg-lamps-e2e-mail-guidance]		[I-D.dkg-lamps-e2e-mail-guidance]
	2. Problem Statement		2. Problem Statement
	The LAMPS charter contains the following Work Item:		The LAMPS charter contains the following Work Item:
	Update the specification for the cryptographic protection of email		Update the specification for the cryptographic protection of email
	headers - both for signatures and encryption - to improve the		headers - both for signatures and encryption - to improve the
	implementation situation with respect to privacy, security,		implementation situation with respect to privacy, security,
	skipping to change at page 7, line 45 ¶		skipping to change at page 7, line 40 ¶
	cryptographically-protected electronic mail protect only the body		cryptographically-protected electronic mail protect only the body
	of the message, which leaves significant room for attacks against		of the message, which leaves significant room for attacks against
	otherwise-protected messages.		otherwise-protected messages.
	In the following a set of challenges to be addressed:		In the following a set of challenges to be addressed:
	[[ TODO: Enhance this section, add more items to the following. ]]		[[ TODO: Enhance this section, add more items to the following. ]]
	2.1. Privacy		2.1. Privacy
	o (Technical) Data Minimization, which includes data sparseness and		* (Technical) Data Minimization, which includes data sparseness and
	hiding all technically concealable information whenever possible		hiding all technically concealable information whenever possible
	2.2. Security		2.2. Security
	o Prevent MITM attacks (cf. [RFC4949])		* Prevent MITM attacks (cf. [RFC4949])
	2.3. Usability		2.3. Usability
	o Improved User interaction / User experience, in particular at the		* Improved User interaction / User experience, in particular at the
	receiving side		receiving side
	2.4. Interoperability		2.4. Interoperability
	o Interoperability with [RFC8551] implementations		* Interoperability with [RFC8551] implementations
	3. Use Cases		3. Use Cases
	In the following, the reader can find a list of the generic use cases		In the following, the reader can find a list of the generic use cases
	that need to be addressed for Messages with Header Protection (HP).		that need to be addressed for Messages with Header Protection (HP).
	These use cases apply regardless of technology (S/MIME, PGP/MIME,		These use cases apply regardless of technology (S/MIME, PGP/MIME,
	etc.) used to achieve HP.		etc.) used to achieve HP.
	3.1. Interactions		3.1. Interactions
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	The main use case is specified in Section 4.1.		The main use case is specified in Section 4.1.
	3.1.2. Backward Compatibility Use Cases		3.1.2. Backward Compatibility Use Cases
	Regarding backward compatibility, the main distinction is based on		Regarding backward compatibility, the main distinction is based on
	whether or not the receiving side conforms to MIME according to		whether or not the receiving side conforms to MIME according to
	[RFC2046], ff., which in particular also includes Section 2 of		[RFC2046], ff., which in particular also includes Section 2 of
	[RFC2049] on "MIME Conformance". The following excerpt is		[RFC2049] on "MIME Conformance". The following excerpt is
	contextually relevant:		contextually relevant:
	A mail user agent that is MIME-conformant MUST:		A mail user agent that is MIME-conformant MUST:
	[...]		[...]
	-- Recognize and display at least the RFC822 message		-- Recognize and display at least the RFC822 message
	encapsulation (message/rfc822) in such a way as to		encapsulation (message/rfc822) in such a way as to
	preserve any recursive structure, that is, displaying		preserve any recursive structure, that is, displaying
	or offering to display the encapsulated data in		or offering to display the encapsulated data in
	accordance with its media type.		accordance with its media type.
	-- Treat any unrecognized subtypes as if they were		-- Treat any unrecognized subtypes as if they were
	"application/octet-stream".		"application/octet-stream".
	[...]		[...]
	An MUA that meets the above conditions is said to be MIME-		An MUA that meets the above conditions is said to be MIME-
	conformant. A MIME-conformant MUA is assumed to be "safe" to send		conformant. A MIME-conformant MUA is assumed to be "safe" to send
	virtually any kind of properly-marked data to users of such mail		virtually any kind of properly-marked data to users of such mail
	systems, because these systems are, at a minimum, capable of treating		systems, because these systems are, at a minimum, capable of treating
	the data as undifferentiated binary, and will not simply		the data as undifferentiated binary, and will not simply
	splash it onto the screen of unsuspecting users.		splash it onto the screen of unsuspecting users.
	[[ TODO: The compatibility of legacy HP systems with this new		[[ TODO: The compatibility of legacy HP systems with this new
	solution, and how to handle issues surrounding future maintenance for		solution, and how to handle issues surrounding future maintenance for
	these legacy systems, will be decided by the LAMPS WG. ]]		these legacy systems, will be decided by the LAMPS WG. ]]
	3.1.2.1. Receiving Side MIME-Conformant		3.1.2.1. Receiving Side MIME-Conformant
	The sending side (fully) supports Header Protection as specified in		The sending side (fully) supports Header Protection as specified in
	this document, while the receiving side does not support this		this document, while the receiving side does not support this
	specification. However, the receiving side is MIME-conformant		specification. However, the receiving side is MIME-conformant
	skipping to change at page 10, line 29 ¶		skipping to change at page 10, line 27 ¶
	Messages containing a cryptographic signature, but which are not		Messages containing a cryptographic signature, but which are not
	encrypted.		encrypted.
	3.2.2. Out-of-Scope		3.2.2. Out-of-Scope
	Legacy implementations, implementations not (fully) compliant with		Legacy implementations, implementations not (fully) compliant with
	this document or corner-cases may lead to further Protection Levels		this document or corner-cases may lead to further Protection Levels
	to appear on the receiving side, such as (list not exhaustive):		to appear on the receiving side, such as (list not exhaustive):
	o Triple wrap		* Triple wrap
	o Encryption only		* Encryption only
	o Encryption before signature		* Encryption before signature
	o Signature and encryption, but:		* Signature and encryption, but:
	* Signature fails to validate		- Signature fails to validate
	* Signature validates but the signing certificate revoked		- Signature validates but the signing certificate revoked
	o Signature only, but:		* Signature only, but:
	* with multiple valid signatures, layered atop each other		- with multiple valid signatures, layered atop each other
	These Protection Levels, as well as any further Protection Levels not		These Protection Levels, as well as any further Protection Levels not
	listed in Section 3.2.1 are beyond the scope of this document.		listed in Section 3.2.1 are beyond the scope of this document.
	4. Specification		4. Specification
	This section contains the specification for Header Protection in		This section contains the specification for Header Protection in S/
	S/MIME to update and clarify Section 3.1 of [RFC8551] (S/MIME 4.0).		MIME to update and clarify Section 3.1 of [RFC8551] (S/MIME 4.0).
	Note: It is likely that PGP/MIME [RFC3156] will also incorporate this		Note: It is likely that PGP/MIME [RFC3156] will also incorporate this
	specification or parts of it.		specification or parts of it.
	This specification applies to the Protection Levels "signature &		This specification applies to the Protection Levels "signature &
	encryption" and "signature only" (cf. Section 3.2):		encryption" and "signature only" (cf. Section 3.2):
	Sending and receiving sides MUST implement the "signature and		Sending and receiving sides MUST implement the "signature and
	encryption" Protection Level, which SHOULD be used as default on the		encryption" Protection Level, which SHOULD be used as default on the
	sending side.		sending side.
	skipping to change at page 12, line 30 ¶		skipping to change at page 12, line 26 ¶
	<Inner Message Body>		<Inner Message Body>
	The following example demonstrates how an Original Message might be		The following example demonstrates how an Original Message might be
	protected, i.e., the Original Message is contained as Inner Message		protected, i.e., the Original Message is contained as Inner Message
	in the Protected Body of an Outer Message. It illustrates the first		in the Protected Body of an Outer Message. It illustrates the first
	Body part (of the Outer Message) as a "multipart/signed"		Body part (of the Outer Message) as a "multipart/signed"
	(application/pkcs7-signature) media type:		(application/pkcs7-signature) media type:
	Lines are prepended as follows:		Lines are prepended as follows:
	o "O: " Outer Message Header Section		* "O: " Outer Message Header Section
	o "I: " Message Header Section		* "I: " Message Header Section
	o "W: " Wrapper (MIME Header Section)		* "W: " Wrapper (MIME Header Section)
	O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)		O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
	O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>		O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
	O: Subject: Meeting at my place		O: Subject: Meeting at my place
	O: From: "Alexey Melnikov" <alexey.melnikov@example.net>		O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
	O: To: somebody@example.net		O: To: somebody@example.net
	O: MIME-Version: 1.0		O: MIME-Version: 1.0
	O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;		O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
	O: protocol="application/pkcs7-signature";		O: protocol="application/pkcs7-signature";
	O: boundary=boundary-AM		O: boundary=boundary-AM
	skipping to change at page 14, line 25 ¶		skipping to change at page 14, line 25 ¶
	this is not the case, Original Message means the (virtual) Message		this is not the case, Original Message means the (virtual) Message
	that would be constructed for sending it as unprotected email.		that would be constructed for sending it as unprotected email.
	4.1.2.1. Inner Message Header Fields		4.1.2.1. Inner Message Header Fields
	It is RECOMMENDED that the Inner Message contains all Header Fields		It is RECOMMENDED that the Inner Message contains all Header Fields
	of the Original Message with the exception of the following Header		of the Original Message with the exception of the following Header
	Field, which MUST NOT be included within the Inner Message nor within		Field, which MUST NOT be included within the Inner Message nor within
	any other protected part of the Message:		any other protected part of the Message:
	o Bcc		* Bcc
	[[ TODO: Bcc handling needs to be further specified (see also		[[ TODO: Bcc handling needs to be further specified (see also
	Appendix A.1). Certain MUAs cannot properly decrypt Messages with		Appendix A.1). Certain MUAs cannot properly decrypt Messages with
	Bcc recipients. ]]		Bcc recipients. ]]
	4.1.2.2. Wrapper		4.1.2.2. Wrapper
	The wrapper is a simple MIME Header Section followed by an empty line		The wrapper is a simple MIME Header Section followed by an empty line
	preceding the Inner Message (inside the Outer Message Body). The		preceding the Inner Message (inside the Outer Message Body). The
	media type of the wrapper MUST be "message/RFC822" and MUST contain		media type of the wrapper MUST be "message/RFC822" and MUST contain
	skipping to change at page 15, line 10 ¶		skipping to change at page 15, line 10 ¶
	principle of Data Minimization (cf. Section 2.1).		principle of Data Minimization (cf. Section 2.1).
	However, the Outer Message Header Section SHOULD contain the		However, the Outer Message Header Section SHOULD contain the
	Essential Header Fields and, in addition, MUST contain the Header		Essential Header Fields and, in addition, MUST contain the Header
	Fields of the MIME Header Section part to describe Cryptographic		Fields of the MIME Header Section part to describe Cryptographic
	Layer of the protected MIME subtree as per [RFC8551].		Layer of the protected MIME subtree as per [RFC8551].
	The following Header Fields are defined as the Essential Header		The following Header Fields are defined as the Essential Header
	Fields:		Fields:
	o From		* From
	o To (if present in the Original Message)		* To (if present in the Original Message)
	o Cc (if present in the Original Message)		* Cc (if present in the Original Message)
	o Bcc (if present in the Original Message, see also Section 4.1.2.1		* Bcc (if present in the Original Message, see also Section 4.1.2.1
	and Appendix A.1)		and Appendix A.1)
	o Date		* Date
	o Message-ID		* Message-ID
	o Subject		* Subject
	Further processing by the Submission Entity normally depends on part		Further processing by the Submission Entity normally depends on part
	of these Header Fields, e.g. From and Date HFs are required by		of these Header Fields, e.g. From and Date HFs are required by
	[RFC5322]. Furthermore, not including certain Header Fields may		[RFC5322]. Furthermore, not including certain Header Fields may
	trigger spam detection to flag the Message, and/or lead to user		trigger spam detection to flag the Message, and/or lead to user
	experience (UX) issues.		experience (UX) issues.
	For further Data Minimization, the value of the Subject Header Field		For further Data Minimization, the value of the Subject Header Field
	SHOULD be obfuscated as follows:		SHOULD be obfuscated as follows:
	skipping to change at page 16, line 18 ¶		skipping to change at page 16, line 18 ¶
	(A use case for obfuscation of all Outer Message Header Fields is		(A use case for obfuscation of all Outer Message Header Fields is
	routing email through the use of onion routing or mix networks, e.g.		routing email through the use of onion routing or mix networks, e.g.
	[pEp.mixnet].)		[pEp.mixnet].)
	The MIME Header Section part is the collection of MIME Header Fields		The MIME Header Section part is the collection of MIME Header Fields
	describing the following MIME structure as defined in [RFC2045]. A		describing the following MIME structure as defined in [RFC2045]. A
	MIME Header Section part typically includes the following Header		MIME Header Section part typically includes the following Header
	Fields:		Fields:
	o Content-Type		* Content-Type
	o Content-Transfer-Encoding		* Content-Transfer-Encoding
	o Content-Disposition		* Content-Disposition
	The following example shows the MIME Header Section part of an S/MIME		The following example shows the MIME Header Section part of an S/MIME
	signed Message (using application/pkcs7-mime with SignedData):		signed Message (using application/pkcs7-mime with SignedData):
	MIME-Version: 1.0		MIME-Version: 1.0
	Content-Type: application/pkcs7-mime; smime-type=signed-data;		Content-Type: application/pkcs7-mime; smime-type=signed-data;
	name=smime.p7m		name=smime.p7m
	Content-Transfer-Encoding: base64		Content-Transfer-Encoding: base64
	Content-Disposition: attachment; filename=smime.p7m		Content-Disposition: attachment; filename=smime.p7m
	Depending on the scenario, further Header Fields MAY be exposed in		Depending on the scenario, further Header Fields MAY be exposed in
	the Outer Message Header Section, which is NOT RECOMMENDED unless		the Outer Message Header Section, which is NOT RECOMMENDED unless
	justified. Such Header Fields may include e.g.:		justified. Such Header Fields may include e.g.:
	o References		* References
	o Reply-To		* Reply-To
	o In-Reply-To		* In-Reply-To
	4.1.2.4.2. Unencrypted Messages		4.1.2.4.2. Unencrypted Messages
	The Outer Message Header Section of unencrypted Messages SHOULD		The Outer Message Header Section of unencrypted Messages SHOULD
	contain at least the Essential Header Fields and, in addition, MUST		contain at least the Essential Header Fields and, in addition, MUST
	contain the Header Fields of the MIME Header Section part to describe		contain the Header Fields of the MIME Header Section part to describe
	Cryptographic Layer of the protected MIME subtree as per [RFC8551].		Cryptographic Layer of the protected MIME subtree as per [RFC8551].
	It may contain further Header Fields, in particular those also		It may contain further Header Fields, in particular those also
	present in the Inner Message Header Section.		present in the Inner Message Header Section.
	4.1.2.5. Sending Side Message Processing		4.1.2.5. Sending Side Message Processing
	For a protected Message the following steps are applied before a		For a protected Message the following steps are applied before a
	Message is handed over to the Submission Entity:		Message is handed over to the Submission Entity:
	4.1.2.5.1. Step 1: Decide on Protection Level and Information		4.1.2.5.1. Step 1: Decide on Protection Level and Information
	Disclosure		Disclosure
	The implementation which applies protection to a Message must decide:		The implementation which applies protection to a Message must decide:
	o Which Protection Level (signature and/or encryption) shall be		* Which Protection Level (signature and/or encryption) shall be
	applied to the Message? This depends on user request and/or local		applied to the Message? This depends on user request and/or local
	policy as well as availability of cryptographic keys.		policy as well as availability of cryptographic keys.
	o Which Header Fields of the Original Message shall be part of the		* Which Header Fields of the Original Message shall be part of the
	Outer Message Header Section? This typically depends on local		Outer Message Header Section? This typically depends on local
	policy. By default, the Essential Header Fields are part of the		policy. By default, the Essential Header Fields are part of the
	Outer Message Header Section; cf. Section 4.1.2.4.		Outer Message Header Section; cf. Section 4.1.2.4.
	o Which of these Header Fields are to be obfuscated? This depends		* Which of these Header Fields are to be obfuscated? This depends
	on local policy and/or specific Privacy requirements of the user.		on local policy and/or specific Privacy requirements of the user.
	By default only the Subject Header Field is obfuscated; cf.		By default only the Subject Header Field is obfuscated; cf.
	Section 4.1.2.4.		Section 4.1.2.4.
	4.1.2.5.2. Step 2: Compose the Outer Message Header Section		4.1.2.5.2. Step 2: Compose the Outer Message Header Section
	Depending on the decision in Section 4.1.2.5.1, the implementation		Depending on the decision in Section 4.1.2.5.1, the implementation
	shall compose the Outer Message Header Section. (Note that this also		shall compose the Outer Message Header Section. (Note that this also
	includes the necessary MIME Header Section part for the following		includes the necessary MIME Header Section part for the following
	protection layer.)		protection layer.)
	skipping to change at page 20, line 13 ¶		skipping to change at page 20, line 19 ¶
	Alp, Claudio Luck, David Wilson, Hernani Marques, juga, Krista		Alp, Claudio Luck, David Wilson, Hernani Marques, juga, Krista
	Bennett, Kelly Bristol, Lars Rohwedder, Robert Williams, Russ		Bennett, Kelly Bristol, Lars Rohwedder, Robert Williams, Russ
	Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.		Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.dkg-lamps-e2e-mail-guidance]		[I-D.dkg-lamps-e2e-mail-guidance]
	Gillmor, D., "Guidance on End-to-End E-mail Security",		Gillmor, D., "Guidance on End-to-End E-mail Security",
	draft-dkg-lamps-e2e-mail-guidance-00 (work in progress),		Work in Progress, Internet-Draft, draft-dkg-lamps-e2e-
	October 2020.		mail-guidance-00, 31 October 2020, <http://www.ietf.org/
			internet-drafts/draft-dkg-lamps-e2e-mail-guidance-00.txt>.
	[I-D.ietf-lamps-header-protection-requirements]		[I-D.ietf-lamps-header-protection-requirements]
	Melnikov, A. and B. Hoeneisen, "Problem Statement and		Melnikov, A. and B. Hoeneisen, "Problem Statement and
	Requirements for Header Protection", draft-ietf-lamps-		Requirements for Header Protection", Work in Progress,
	header-protection-requirements-01 (work in progress),		Internet-Draft, draft-ietf-lamps-header-protection-
	October 2019.		requirements-01, 29 October 2019, <http://www.ietf.org/
			internet-drafts/draft-ietf-lamps-header-protection-
			requirements-01.txt>.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,		Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
	<https://www.rfc-editor.org/info/rfc2045>.		<https://www.rfc-editor.org/info/rfc2045>.
	[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>.
	skipping to change at page 21, line 9 ¶		skipping to change at page 21, line 16 ¶
	[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>.
	9.2. Informative References		9.2. Informative References
	[I-D.autocrypt-lamps-protected-headers]		[I-D.autocrypt-lamps-protected-headers]
	Einarsson, B., juga, j., and D. Gillmor, "Protected		Einarsson, B., juga, j., and D. Gillmor, "Protected
	Headers for Cryptographic E-mail", draft-autocrypt-lamps-		Headers for Cryptographic E-mail", Work in Progress,
	protected-headers-02 (work in progress), December 2019.		Internet-Draft, draft-autocrypt-lamps-protected-headers-
			02, 20 December 2019, <http://www.ietf.org/internet-
			drafts/draft-autocrypt-lamps-protected-headers-02.txt>.
	[I-D.melnikov-iana-reg-forwarded]		[I-D.melnikov-iana-reg-forwarded]
	Melnikov, A. and B. Hoeneisen, "IANA Registration of		Melnikov, A. and B. Hoeneisen, "IANA Registration of
	Content-Type Header Field Parameter 'forwarded'", draft-		Content-Type Header Field Parameter 'forwarded'", Work in
	melnikov-iana-reg-forwarded-00 (work in progress),		Progress, Internet-Draft, draft-melnikov-iana-reg-
	November 2019.		forwarded-00, 4 November 2019, <http://www.ietf.org/
			internet-drafts/draft-melnikov-iana-reg-forwarded-00.txt>.
	[I-D.pep-email]		[I-D.pep-email]
	Marques, H., "pretty Easy privacy (pEp): Email Formats and		Marques, H., "pretty Easy privacy (pEp): Email Formats and
	Protocols", draft-pep-email-00 (work in progress), July		Protocols", Work in Progress, Internet-Draft, draft-pep-
	2020.		email-00, 10 July 2020, <http://www.ietf.org/internet-
			drafts/draft-pep-email-00.txt>.
	[pEp.mixnet]		[pEp.mixnet]
	pEp Foundation, "Mixnet", June 2020,		pEp Foundation, "Mixnet", June 2020,
	<https://dev.pep.foundation/Mixnet>.		<https://dev.pep.foundation/Mixnet>.
	[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>.
	skipping to change at page 24, line 48 ¶		skipping to change at page 24, line 48 ¶
	<Inner Message Body>		<Inner Message Body>
	The following example demonstrates how an Original Message might be		The following example demonstrates how an Original Message might be
	protected, i.e., the Original Message is contained as Inner Message		protected, i.e., the Original Message is contained as Inner Message
	in the Protected Body of an Outer Message. It illustrates the first		in the Protected Body of an Outer Message. It illustrates the first
	Body part (of the Outer Message) as a "multipart/signed"		Body part (of the Outer Message) as a "multipart/signed"
	(application/pkcs7-signature) media type:		(application/pkcs7-signature) media type:
	Lines are prepended as follows:		Lines are prepended as follows:
	o "O: " Outer Message Header Section		* "O: " Outer Message Header Section
	o "I: " Message Header Section		* "I: " Message Header Section
	O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)		O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
	O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>		O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
	O: Subject: Meeting at my place		O: Subject: Meeting at my place
	O: From: "Alexey Melnikov" <alexey.melnikov@example.net>		O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
	O: MIME-Version: 1.0		O: MIME-Version: 1.0
	O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;		O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
	O: protocol="application/pkcs7-signature";		O: protocol="application/pkcs7-signature";
	O: boundary=boundary-AM		O: boundary=boundary-AM
	This is a multipart message in MIME format.		This is a multipart message in MIME format.
	skipping to change at page 25, line 50 ¶		skipping to change at page 25, line 50 ¶
	Original Message Header Section (cf. Section 4.1.2.1).		Original Message Header Section (cf. Section 4.1.2.1).
	The Inner Message Body is the same as the Original Message Body.		The Inner Message Body is the same as the Original Message Body.
	The Original Message itself may contain any MIME structure.		The Original Message itself may contain any MIME structure.
	Appendix C. Document Changelog		Appendix C. Document Changelog
	[[ RFC Editor: This section is to be removed before publication ]]		[[ RFC Editor: This section is to be removed before publication ]]
	o draft-ietf-lamps-header-protection-01		* draft-ietf-lamps-header-protection-02
	* Add DKG as co-author		- editorial changes / improve language
	* Partial Rewrite of Abstract and Introduction [HB/AM/DKG]		* draft-ietf-lamps-header-protection-01
	* Adding definiations for Cryptographic Layer, Cryptographic		- Add DKG as co-author
			- Partial Rewrite of Abstract and Introduction [HB/AM/DKG]
			- Adding definiations for Cryptographic Layer, Cryptographic
	Payload, and Cryptographic Envelope (reference to		Payload, and Cryptographic Envelope (reference to
	[I-D.dkg-lamps-e2e-mail-guidance]) [DKG]		[I-D.dkg-lamps-e2e-mail-guidance]) [DKG]
	* Enhanced MITM Definition to include Machine- / Meddler-in-the-		- Enhanced MITM Definition to include Machine- / Meddler-in-the-
	middle [HB]		middle [HB]
	* Relaxed definition of Original message, which may not be of		- Relaxed definition of Original message, which may not be of
	type "message/rfc822" [HB]		type "message/rfc822" [HB]
	* Move "memory hole" option to the Appendix (on request by Chair		- Move "memory hole" option to the Appendix (on request by Chair
	to only maintain one option in the specification) [HB]		to only maintain one option in the specification) [HB]
	* Updated Scope of Protection Levels according to WG discussion		- Updated Scope of Protection Levels according to WG discussion
	during IETF-108 [HB]		during IETF-108 [HB]
	* Obfuscation recommendation only for Subject and Message-Id and		- Obfuscation recommendation only for Subject and Message-Id and
	distinguish between Encrypted and Unencrypted Messages [HB]		distinguish between Encrypted and Unencrypted Messages [HB]
	* Removed (commented out) Header Field Flow Figure (it appeared		- Removed (commented out) Header Field Flow Figure (it appeared
	to be confusing as is was) [HB]		to be confusing as is was) [HB]
	o draft-ietf-lamps-header-protection-00		* draft-ietf-lamps-header-protection-00
	* Initial version (text partially taken over from		- Initial version (text partially taken over from
	[I-D.ietf-lamps-header-protection-requirements]		[I-D.ietf-lamps-header-protection-requirements]
	Appendix D. Open Issues		Appendix D. 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 Ensure "protected header" (Ex-Memory-Hole) option is (fully)		* Ensure "protected header" (Ex-Memory-Hole) option is (fully)
	compliant with the MIME standard, in particular also [RFC2046],		compliant with the MIME standard, in particular also [RFC2046],
	Section 5.1. (Multipart Media Type) Appendix B.1.1.1.		Section 5.1. (Multipart Media Type) Appendix B.1.1.1.
	o More examples (e.g. in Section 4.1.2.5)		* More examples (e.g. in Section 4.1.2.5)
	o Should Outer Message Header Section (as received) be preserved for		* Should Outer Message Header Section (as received) be preserved for
	the user? (Section 4.1.3.2.2)		the user? (Section 4.1.3.2.2)
	o Decide on whether or not merge requirements from		* Decide on whether or not merge requirements from
	[I-D.ietf-lamps-header-protection-requirements] into this		[I-D.ietf-lamps-header-protection-requirements] into this
	document.		document.
	o Decide what parts of [I-D.autocrypt-lamps-protected-headers] to		* Decide what parts of [I-D.autocrypt-lamps-protected-headers] to
	merge into this document.		merge into this document.
	o Enhance Introduction Section 1 and Problem Statement (Section 2).		* Enhance Introduction Section 1 and Problem Statement (Section 2).
	o Decide on whether or not specification for more legacy HP		* Decide on whether or not specification for more legacy HP
	requirements should be added to this document (Section 3.1.2).		requirements should be added to this document (Section 3.1.2).
	o Verify simple backward compatibility case (Receiving Side MIME-		* Verify simple backward compatibility case (Receiving Side MIME-
	Conformant) is working; once solution is stable and update		Conformant) is working; once solution is stable and update
	paragraphs in Section 4.1, Section 3.1.2.1 and Section 4.2.1		paragraphs in Section 4.1, Section 3.1.2.1 and Section 4.2.1
	accordingly.		accordingly.
	o Verify ability to distinguish between Messages with Header		* Verify ability to distinguish between Messages with Header
	Protection as specified in this document and legacy clients and		Protection as specified in this document and legacy clients and
	update Section 3.1 accordingly.		update Section 3.1 accordingly.
	o Improve definitions of Protection Levels and enhance list of		* Improve definitions of Protection Levels and enhance list of
	Protection Levels (Section 3.2, Section 4).		Protection Levels (Section 3.2, Section 4).
	o Privacy Considerations Section 6		* Privacy Considerations Section 6
	o Security Considerations Section 5		* Security Considerations Section 5
	Authors' Addresses		Authors' Addresses
	Bernie Hoeneisen		Bernie Hoeneisen
	pEp Foundation		pEp Foundation
	Oberer Graben 4		Oberer Graben 4
	CH-8400 Winterthur		CH- CH-8400 Winterthur
	Switzerland		Switzerland
	Email: bernie.hoeneisen@pep.foundation		Email: bernie.hoeneisen@pep.foundation
	URI: https://pep.foundation/		URI: https://pep.foundation/
	Daniel Kahn Gillmor		Daniel Kahn Gillmor
	American Civil Liberties Union		American Civil Liberties Union
	125 Broad St.		125 Broad St.
	New York, NY 10004		New York, NY, 10004
	USA		United States of America
	Email: dkg@fifthhorseman.net		Email: dkg@fifthhorseman.net
	Alexey Melnikov		Alexey Melnikov
	Isode Ltd		Isode Ltd
	14 Castle Mews		14 Castle Mews
	Hampton, Middlesex TW12 2NP		Hampton, Middlesex
	UK		TW12 2NP
			United Kingdom
	Email: alexey.melnikov@isode.com		Email: alexey.melnikov@isode.com
End of changes. 111 change blocks.
	147 lines changed or deleted		156 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/