< draft-ietf-lamps-header-protection-00.txt		draft-ietf-lamps-header-protection-01.txt >
	Network Working Group B. Hoeneisen		LAMPS Working Group B. Hoeneisen
	Internet-Draft pEp Foundation		Internet-Draft pEp Foundation
	Intended status: Informational A. Melnikov		Intended status: Standards Track D. Gillmor
	Expires: January 14, 2021 Isode Ltd		Expires: May 6, 2021 American Civil Liberties Union
	July 13, 2020		A. Melnikov
			Isode Ltd
			November 02, 2020
	Header Protection for S/MIME		Header Protection for S/MIME
	draft-ietf-lamps-header-protection-00		draft-ietf-lamps-header-protection-01
	Abstract		Abstract
	Privacy and security issues with email header protection in S/MIME		S/MIME version 3.1 has introduced a feasible standardized option to
	have been identified for some time. However, the desire to fix these		accomplish Header Protection. However, implementations of Header
	issues has only recently been expressed in the IETF LAMPS Working		Protection can cause rendering issues on the receiving side. Clearer
	Group. The existing S/MIME specification is to be updated regarding		specifications regarding message processing, particularly with
	header protection.		respect to header sections, are needed in order to resolve these
			rendering issues.
	This document describes the problem statement, generic use cases, and		In order to help implementers to correctly compose and render email
	the S/MIME specification for header protection.		messages with Header Protection, this document updates S/MIME Header
			Protection specifications with additional guidance on MIME format,
			sender and receiver processing.
	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 January 14, 2021.		This Internet-Draft will expire on May 6, 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
	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
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.1. Other Protocols to Protect Email Headers . . . . . . . . 4
	1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
	2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 7		2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 8
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 8
	3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 7		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 7		3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 8
	3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 7		3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 8
	3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 9		3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 8
	4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 10
	4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 10		3.2.1. In-Scope . . . . . . . . . . . . . . . . . . . . . . 10
	4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 10		3.2.2. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 10
	4.1.2. Inner Message Header Fields . . . . . . . . . . . . . 15		4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.1.3. Wrapper . . . . . . . . . . . . . . . . . . . . . . . 16		4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 11
	4.1.4. Outer Message Header Fields . . . . . . . . . . . . . 16		4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 11
	4.1.5. Receiving User Facing Message Header Fields . . . . . 18		4.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 14
	4.1.6. Header Field Flow . . . . . . . . . . . . . . . . . . 18		4.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 18
	4.1.7. Sending Side Message Processing . . . . . . . . . . . 20		4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 18
	4.1.8. Receiving Side Message Processing . . . . . . . . . . 21		4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 18
	4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 21		4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 19
	4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 21		5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 22		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 22		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23		9.1. Normative References . . . . . . . . . . . . . . . . . . 20
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		9.2. Informative References . . . . . . . . . . . . . . . . . 21
	9.1. Normative References . . . . . . . . . . . . . . . . . . 23		Appendix A. Additional information . . . . . . . . . . . . . . . 22
	9.2. Informative References . . . . . . . . . . . . . . . . . 24		A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 22
	Appendix A. Additional information . . . . . . . . . . . . . . . 25		Appendix B. Text Moved from Above . . . . . . . . . . . . . . . 22
	A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 25		B.1. MIME Format . . . . . . . . . . . . . . . . . . . . . . . 23
	Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 26		B.1.1. S/MIME Specification . . . . . . . . . . . . . . . . 23
	Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 26
			Appendix C. Document Changelog . . . . . . . . . . . . . . . . . 25
			Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	A range of protocols for the protection of electronic mail (email)		Privacy and security issues regarding email Header Protection in
	exists, which allows to assess the authenticity and integrity of the		S/MIME have been identified for some time. Most current
	email headers section or selected header fields (HF) from the domain-		implementations of cryptographically-protected electronic mail
	level perspective, specifically DomainKeys Identified Mail (DKIM)		protect only the body of the message, which leaves significant room
	[RFC6376] and Sender Policy Framework (SPF) [RFC7208], and Domain-		for attacks against otherwise-protected messages. For example, lack
	based Message Authentication, Reporting, and Conformance (DMARC)		of header protection allows an attacker to substitute the message
	[RFC7489]. These protocols, while essential to responding to a range		subject and/or author.
	of attacks on email, do not offer (full) end-to-end protection to the
	header section and are not capable of providing privacy for the
	information contained therein.
	The need for means of Data Minimization, which includes data
	sparseness and hiding all technically concealable information
	whenever possible, has grown in importance over the past several
	years.
	A standard for end-to-end protection of the email header section		A way to provide end-to-end protection for the Header Section of an
	exists for S/MIME version 3.1 and later. (cf. [RFC8551]):		email message has been standardized for S/MIME version 3.1 and later
			(cf. [RFC8551]):
	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 (HP) has been standardized for		Unfortunately, implementations of Header Protection can cause
	PGP/MIME (Pretty Good Privacy) [RFC3156] yet.		rendering issues on the receiving side. In some cases, the user sees
			an attachment suggesting a forwarded email message, which - in fact -
			contains the protected email message that should be rendered
			directly. For these cases, the user can click on the attachment to
			view the protected message. However, there have also been reports of
			email clients displaying garbled text, or sometimes nothing at all.
			In those cases the email clients on the receiving side are (most
			likely) not fully MIME-capable.
	Several varying implementations of end-to-end protections for email		The following shortcomings have been identified to cause these
	header sections exist, though the total number of such		issues:
	implementations appears to be rather low.
	Some LAMPS WG participants expressed the opinion that regardless of		o Broken or incomplete implementations
	the mechanism chosen, it should not be limited to S/MIME, but also
	applicable to PGP/MIME.		o Lack of a simple means to distinguish "forwarded message" and
			"wrapped message" (for the sake of Header Protection)
			o Not enough guidance with respect to handling of Header Fields on
			both the sending and the receiving side
			Furthermore, the need (technical) Data Minimization, which includes
			data sparseness and hiding all technically concealable information,
			has grown in importance over the past several years. In addition,
			backwards compatibility must be considered when it is possible to do
			so without compromising privacy and security.
			No mechanism for Header Protection has been standardized for PGP/MIME
			(Pretty Good Privacy) [RFC3156] yet. PGP/MIME developers have
			implemented ad-hoc header-protection, and would like to see a
			specification that is applicable to both S/MIME and PGP/MIME.
	This document describes the problem statement (Section 2), generic		This document describes the problem statement (Section 2), generic
	use cases (Section 3) and the specification for Header Protection		use cases (Section 3) and the specification for Header Protection
	(Section 4).		(Section 4) with guidance on MIME format, sender and receiver
			processing .
	[I-D.ietf-lamps-header-protection-requirements] defines the		[I-D.ietf-lamps-header-protection-requirements] defines the
	requirements that this specification is based on.		requirements that this specification is based on.
	This document is in 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. Requirements Language		1.1. Other Protocols to Protect Email Headers
			A range of protocols for the protection of electronic mail (email)
			exists, which allows one to assess the authenticity and integrity of
			the email headers section or selected Header Fields from the domain-
			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
			to the domain name of the sending e-mail address, not the sending
			address itself, so these protocols do not provide end-to-end
			protection, and are incapable of providing any form of
			confidentiality.
			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.2. 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		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'.
	o S/MIME: Secure/Multipurpose Internet Mail Extensions (cf.		o S/MIME: Secure/Multipurpose Internet Mail Extensions (cf.
	[RFC8551])		[RFC8551])
	o PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156])		o PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156])
	o Message: An Email Message consisting of Header Fields		o 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		o 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; cf. [RFC5322].		body (value), and terminated by CRLF.
	o Header Section (HS): The Header Section is a sequence of lines of		o 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 characters that follows the		o 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		o 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.		o 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		o Essential Header Fields (EHF): The minimum set of Header Fields an
	Outer Message Header Section SHOULD contain; cf. Section 4.1.4.		Outer Message Header Section SHOULD contain; cf. Section 4.1.2.4.
	o Header Protection (HP): cryptographic protection of email Header		o 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): One of 'signature and encryption',		o Protection Levels (PL): The level of protection applied to a
	'signature only' or 'encryption only' (cf. Section 3.2)		Message, e.g. 'signature and encryption' or 'signature only' (cf.
			Section 3.2).
	o Protected: Protected refers to the parts of a Message where		o Protected: Portions of a message that have had any Protection
	protection measures of any Protection Level have been applied to.		Levels applied.
	o Protected Message: A Message that protection measures of any		o Protected Message: A Message that has had any Protection Levels
	Protection Levels have been applied to.		applied.
	o Unprotected: Unprotected refers to the parts of a Message where no		o Unprotected: Portions of a Message that has had no Protection
	protection measures of any Protection Levels have been applied to.		Levels applied.
	o Unprotected Message: A Message that no protection measures of any		o Unprotected Message: A Message that has had no Protection Levels
	Protection Levels have been applied to.		applied.
	o Submission Entity: The entity taking care of further processing of		o 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.		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 to:		depending on the stage where protection measures are applied: E.g.
	It could be e.g. a Message Submission Agent (MSA) [RFC6409] or		a Message Submission Agent (MSA) [RFC6409] or another
	another (proprietary) solution. The latter is particularly		(proprietary) solution. The latter is particularly relevant, if
	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		o 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.		side. If the source is not a "message/rfc822" Message, OrigM is
			defined as the "virtual" Message that would be constructed for
			sending it as unprotected email.
	o Inner Message (InnerM): The message to be protected, i.e. which		o Inner Message (InnerM): The Message to be protected which has had
	wrapping and protection measures are applied to on the sending		wrapping and protection measures aapplied on the sending side OR
	side or the result of decryption and unwrapping on the receiving		the resulting Message once decryption and unwrapping on the
	side respectively. Typically, the Inner Message is in clear text.		receiving side has been performed. Typically, the Inner Message
	The Inner Message is a subset of (or the same as) the Original		is in clear text. The Inner Message is a subset of (or the same
	Message (cf. Section 4.1.2). The Inner Message must be the same		as) the Original Message (cf. Section 4.1.2.1). The Inner
	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 handed over to the		o Outer Message (OuterM): The Message as provided to the Submission
	Submission Entity or received from the last hop respectively. The		Entity or received from the last hop respectively. The Outer
	Outer Message normally differs on the sending and the receiving		Message normally differs on the sending and the receiving side
	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		o 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		o Data Minimization: Data sparseness and hiding of all technically
	concealable information whenever possible.		concealable information whenever possible.
			o Cryptographic Layer, Cryptographic Payload, and Cryptographic
			Envelope are all used as defined in
			[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,
	usability and interoperability in cryptographically-protected		usability and interoperability in cryptographically-protected
	electronic mail. Most current implementations of		electronic mail. Most current implementations of
	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 Data Minimization, which includes data sparseness and hiding all		o (Technical) Data Minimization, which includes data sparseness and
	technically concealable information whenever possible		hiding all technically concealable information whenever possible
	2.2. Security		2.2. Security
	o MITM attacks (cf. [RFC4949])		o Prevent MITM attacks (cf. [RFC4949])
	2.3. Usability		2.3. Usability
	o User interaction / User experience		o Improved User interaction / User experience, in particular at the
			receiving side
	2.4. Interoperability		2.4. Interoperability
	o Interoperability with [RFC8551] implementations		o 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
	The following use cases assume that at least the sending side		The following use cases assume that at least the sending side
	supports Header Protection as specified in this document. Receiving		supports Header Protection as specified in this document. Receiving
	sides that support this specification are expected to be able to		sides that support this specification are expected to be able to
	distinguish between Messages that Header Protection - as specified in		distinguish between Messages that use Header Protection as specified
	this document - has been applied to and (legacy) Mail User Agents		in this document, and (legacy) Mail User Agents (MUAs) which do not
	(MUAs) not implementing this specification.		implement this specification.
	[[ TODO: Verify once solution is stable and update last sentence. ]]		[[ TODO: Verify once solution is stable and update last sentence. ]]
	3.1.1. Main Use Case		3.1.1. Main Use Case
	Both the sending and receiving side (fully) support Header Protection		Both the sending and receiving side (fully) support Header Protection
	as specified in this document.		as specified in this document.
	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". In the following an excerpt of		[RFC2049] on "MIME Conformance". The following excerpt is
	paragraphs relevant in this context:		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".
	[...]		[...]
	A user agent that meets the above conditions is said to be MIME-		An MUA that meets the above conditions is said to be MIME-
	conformant. The meaning of this phrase is that it is assumed to be		conformant. A MIME-conformant MUA is assumed to be "safe" to send
	"safe" to send virtually any kind of properly-marked data to users		virtually any kind of properly-marked data to users of such mail
	of such mail systems, because such systems will at least be able to		systems, because these systems are, at a minimum, capable of treating
	treat 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
	according to [RFC2045], ff. (cf. Section 3.1.2),		according to [RFC2045], ff. (cf. Section 3.1.2).
	This use case is specified in Section 4.2.1.		This use case is specified in Section 4.2.1.
	Note: This case should perform as expected if the sending side		Note: This case should perform as expected if the sending side
	applies this specification as outlined in Section 4.1.		applies this specification as outlined in Section 4.1.
	[[ TODO: Verify once solution is stable and update last sentence. ]]		[[ TODO: Verify once solution is stable and update last sentence. ]]
	3.1.2.2. Receiving Side Not MIME-Conformant		3.1.2.2. Receiving Side Not 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. Furthermore, the receiving side is *not* MIME-		specification. Furthermore, the receiving side is *not* MIME-
	conformant according to [RFC2045], ff. (cf. Section 3.1.2).		conformant according to [RFC2045], ff. (cf. Section 3.1.2).
	This use case is specified in Section 4.2.2.		This use case is specified in Section 4.2.2.
	3.2. Protection Levels		3.2. Protection Levels
	The following Protection Levels need to be considered:		3.2.1. In-Scope
			The following Protection Levels are in scope for this document:
	a) Signature and encryption		a) Signature and encryption
	Messages containing a cryptographic signature, which are also		Messages containing a cryptographic signature, which are also
	encrypted.		encrypted.
	b) Signature only		b) Signature only
	Messages containing a cryptographic signature, but which are not		Messages containing a cryptographic signature, but which are not
	encrypted.		encrypted.
	c) Encryption only		3.2.2. Out-of-Scope
	Messages that are encrypted, but do not contain a cryptographic		Legacy implementations, implementations not (fully) compliant with
	signature.		this document or corner-cases may lead to further Protection Levels
			to appear on the receiving side, such as (list not exhaustive):
	[[ TODO: There are further "Protection Levels" to describe for the		o Triple wrap
	receiving side, e.g. encrypted and signed (only after encryption),
	etc. ]]		o Encryption only
			o Encryption before signature
			o Signature and encryption, but:
			* Signature fails to validate
			* Signature validates but the signing certificate revoked
			o Signature only, but:
			* with multiple valid signatures, layered atop each other
			These Protection Levels, as well as any further Protection Levels not
			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/MIME to update and clarify Section 3.1 of [RFC8551] (S/MIME 4.0).		S/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.
	Certain implementations may decide to send "signature only" messages,		Certain implementations may decide to send "signature only" Messages,
	depending on the circumstances and customer requirements. Sending		depending on the circumstances and customer requirements. Sending
	sides MAY and receiving sides MUST implement "signature only"		sides MAY and receiving sides MUST implement "signature only"
	Protection Level.		Protection Level.
	It generally is NOT RECOMMENDED to send a message with Protection		It generally is NOT RECOMMENDED to send a Message with any other
	Level "encryption only". On the other hand, messages with Protection		Protection Level. On the other hand, the receiving side must be
	Level "encryption only" might arrive at the receiving side. While		prepared to receive Messages with other Protection Levels.
	not targeted to Protection Level "encryption only", this
	specification is assumed to also function for "encryption only".
	Receiving sides SHOULD implement "encryption only".
	[[ TODO: Further study is necessary to determine whether - and if yes		[[ TODO: Further study is necessary to determine whether - and if yes
	to what extent - additional guidance for handling messages with		to what extent - additional guidance for handling messages with other
	"encryption only" protection (as well as other variations) at the		Protection Levels, e.g. "encryption only" at the receiving side
	receiving side should be included in this document. ]]		should be included in this document. ]]
	4.1. Main Use Case		4.1. Main Use Case
	This section applies to the main use case, where the sending and		This section applies to the main use case, where the sending and
	receiving side (fully) support Header Protection as specified herein		receiving side (fully) support Header Protection as specified herein
	(cf. Section 3.1.1).		(cf. Section 3.1.1).
	Note: The sending side specification of the main use case is also		Note: The sending side specification of the main use case is also
	applicable to the cases where the sending side (fully) supports		applicable to the cases where the sending side (fully) supports
	Header Protection as specified herein, while the receiving side does		Header Protection as specified herein, while the receiving side does
	not, but is MIME-conformant according to [RFC2045], ff. (cf.		not, but is MIME-conformant according to [RFC2045], ff. (cf.
	Section 3.1.2) and Section 3.1.2.1)		Section 3.1.2 and Section 3.1.2.1).
	Further backward compatibility cases are defined in Section 4.2.		Further backward compatibility cases are defined in Section 4.2.
	4.1.1. MIME Format		4.1.1. MIME Format
	Currently there are two options in discussion:		4.1.1.1. Introduction
	1. The option according to the current S/MIME specification (cf.
	[RFC8551])
	2. An alternative option that is based on the former "memory hole"
	approach (cf. [I-D.autocrypt-lamps-protected-headers])
	4.1.1.1. S/MIME Specification
	As per S/MIME version 3.1 and later (cf. [RFC8551]), the sending		As per S/MIME version 3.1 and later (cf. [RFC8551]), the sending
	client MAY wrap a full MIME message in a message/RFC822 wrapper in		client MAY wrap a full MIME message in a message/RFC822 wrapper in
	order to apply S/MIME security services to these header fields.		order to apply S/MIME security services to these header fields.
	To help the receiving side to distinguish between a forwarded and a		To help the receiving side to distinguish between a forwarded and a
	wrapped message, the Content-Type header field parameter "forwarded"		wrapped message, the Content-Type header field parameter "forwarded"
	is added as defined in [I-D.melnikov-iana-reg-forwarded]. Certain		is added as defined in [I-D.melnikov-iana-reg-forwarded].
	mailing applications might display the Inner Message as an attachment
	otherwise.
	The MIME structure of an Email message looks as follows:		The simplified (cryptographic overhead not shown) MIME structure of
			such an Email Message looks as follows:
	<Outer Message Header Section (unprotected)>		<Outer Message Header Section (unprotected)>
	<Outer Message Body (protected)>		<Outer Message Body (protected)>
	<MIME Header Section (wrapper)>		<MIME Header Section (wrapper)>
	<Inner Message Header Section>		<Inner Message Header Section>
	<Inner Message Body>		<Inner Message Body>
	skipping to change at page 12, line 44 ¶		skipping to change at page 13, line 44 ¶
	[[base-64 encoded signature]]		[[base-64 encoded signature]]
	--boundary-AM--		--boundary-AM--
	The Outer Message Header Section is unprotected, while the remainder		The Outer Message Header Section is unprotected, while the remainder
	(Outer Message Body) is protected. The Outer Message Body consists		(Outer Message Body) is protected. The Outer Message Body consists
	of the wrapper (MIME Header Section) and the Inner Message (Header		of the wrapper (MIME Header Section) and the Inner Message (Header
	Section and Body).		Section and Body).
	The wrapper is a simple MIME Header Section with media type "message/		The wrapper is a simple MIME Header Section with media type "message/
	RFC822" containing a Content-Type header field parameter		rfc822" containing a Content-Type header field parameter
	"forwarded=no" followed by an empty line.		"forwarded=no" followed by an empty line.
	The Inner Message Header Section is the same as (or a subset of) the		If the source is an Original (message/rfc822) Message, the Inner
	Original Message Header Section (cf. Section 4.1.2).		Message Header Section is typically the same as (or a subset of) the
			Original Message Header Section (cf. Section 4.1.2.1), and the Inner
	The Inner Message Body is the same as the Original Message Body.		Message Body is typically the same as the Original Message Body.
	The Original Message itself may contain any MIME structure.
	4.1.1.2. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory
	Hole")
	An alternative option (based on the former autocrypt "Memory Hole"
	approach) to be considered, is described in
	[I-D.autocrypt-lamps-protected-headers].
	Unlike the option described in Section 4.1.1.1, this option does not
	use a "message/RFC822" wrapper to unambiguously delimit the Inner
	Message.
	Before choosing this option, the following two issues must be
	assessed to ensure no interoperability issues result from it:
	1. How current MIME parser implementations treat non-MIME Header
	Fields, which are not part of the outermost MIME entity and not
	part of a message wrapped into a MIME entity of media type
	"message/rfc822", and how such messages are rendered to the user.
	[I-D.autocrypt-lamps-protected-headers] provides some examples
	for testing this.
	2. MIME-conformance, i.e. whether or not this option is (fully)
	MIME-conformant [RFC2045] ff., in particular also Section 5.1. of
	[RFC2046] on "Multipart Media Type). In the following an excerpt
	of paragraphs that may be relevant in this context:
	The only header fields that have defined meaning for body parts
	are those the names of which begin with "Content-". All other
	header fields may be ignored in body parts. Although they
	should generally be retained if at all possible, they may be
	discarded by gateways if necessary. Such other fields are
	permitted to appear in body parts but must not be depended on.
	"X-" fields may be created for experimental or private
	purposes, with the recognition that the information they
	contain may be lost at some gateways.
	NOTE: The distinction between an RFC 822 message and a body
	part is subtle, but important. A gateway between Internet and
	X.400 mail, for example, must be able to tell the difference
	between a body part that contains an image and a body part
	that contains an encapsulated message, the body of which is a
	JPEG image. In order to represent the latter, the body part
	must have "Content-Type: message/rfc822", and its body (after
	the blank line) must be the encapsulated message, with its own
	"Content-Type: image/jpeg" header field. The use of similar
	syntax facilitates the conversion of messages to body parts,
	and vice versa, but the distinction between the two must be
	understood by implementors. (For the special case in which
	parts actually are messages, a "digest" subtype is also
	defined.)
	The MIME structure of an Email message looks as follows:
	<Outer Message Header Section (unprotected)>
	<Outer Message Body (protected)>
	<Inner Message Header Section>
	<Inner Message Body>
	The following example demonstrates how an Original Message might be
	protected, i.e., the Original Message is contained as Inner Message
	in the Protected Body of an Outer Message. It illustrates the first
	Body part (of the Outer Message) as a "multipart/signed"
	(application/pkcs7-signature) media type:
	Lines are prepended as follows:
	o "O: " Outer Message Header Section
	o "I: " Message Header Section
	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: Subject: Meeting at my place
	O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
	O: MIME-Version: 1.0
	O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
	O: protocol="application/pkcs7-signature";
	O: boundary=boundary-AM
	This is a multipart message in MIME format.
	--boundary-AM
	I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
	I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
	I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
	I: MIME-Version: 1.0
	I: MMHS-Primary-Precedence: 3
	I: Subject: Meeting at my place
	I: To: somebody@example.net
	I: X-Mailer: Isode Harrier Web Server
	I: Content-Type: text/plain; charset=us-ascii
	This is an important message that I don't want to be modified.
	--boundary-AM
	Content-Transfer-Encoding: base64
	Content-Type: application/pkcs7-signature
	[[base-64 encoded signature]]
	--boundary-AM--
	The Outer Message Header Section is unprotected, while the remainder		The Inner Message itself may contain any MIME structure.
	(Outer Message Body) is protected. The Outer Message Body consists
	of the Inner Message (Header Section and Body).
	The Inner Message Header Section is the same as (or a subset of) the		Note: It is still to be decided by the LAMPS WG whether or not to
	Original Message Header Section (cf. Section 4.1.2).		recommend an alternative MIME format as described in Appendix B.1.1.1
			(instead of the currently standardized and above defined format).
	The Inner Message Body is the same as the Original Message Body.		4.1.2. Sending Side
	The Original Message itself may contain any MIME structure.		To ease explanation, the following describes the case where an
			Original (message/rfc822) Message to be protected is present. If
			this is not the case, Original Message means the (virtual) Message
			that would be constructed for sending it as unprotected email.
	4.1.2. 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		o 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.3. 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
	the Content-Type header field parameter "forwarded=no" as defined in		the Content-Type header field parameter "forwarded=no" as defined in
	[I-D.melnikov-iana-reg-forwarded]. The wrapper unambiguously		[I-D.melnikov-iana-reg-forwarded]. The wrapper unambiguously
	delimits the Inner Message from the rest of the message.		delimits the Inner Message from the rest of the Message.
	4.1.4. Outer Message Header Fields		4.1.2.3. Cryptographic Layers / Envelope
			[[ TODO: Basically refer to S/MIME standards ]]
			4.1.2.4. Outer Message Header Fields
			4.1.2.4.1. Encrypted Messages
	To maximize Privacy, it is strongly RECOMMENDED to follow the		To maximize Privacy, it is strongly RECOMMENDED to follow the
	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 the encryption or		Fields of the MIME Header Section part to describe Cryptographic
	signature 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		o From
	o To (if present in the Original Message)		o To (if present in the Original Message)
	o Cc (if present in the Original Message)		o Cc (if present in the Original Message)
	o Bcc (if present in the Original Message, see also Section 4.1.2		o Bcc (if present in the Original Message, see also Section 4.1.2.1
	and Appendix A.1)		and Appendix A.1)
	o Date		o Date
	o Message-ID		o Message-ID
	o Subject		o 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
	skipping to change at page 17, line 4 ¶		skipping to change at page 15, line 27 ¶
	and Appendix A.1)		and Appendix A.1)
	o Date		o Date
	o Message-ID		o Message-ID
	o Subject		o 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. In addition, the value of other Essential		SHOULD be obfuscated as follows:
	Header Fields MAY be obfuscated. Further Header Fields MAY be
	obfuscated, though simply not adding those to the Outer Message		* Subject: [...]
	Header Section SHOULD be preferred over obfuscation. Header Field
	obfuscation is further specified in Section 4.1.4.1. Header Fields		and it is RECOMMENDED to replace the Message-ID by a new randomly
	not obfuscated should contain the same values as in the Original		generated Message-ID.
	Message.
			In addition, the value of other Essential Header Fields MAY be
			obfuscated.
			Non-Essential Header Fields SHOULD be omitted from the Outer Message
			Header Section where possible. If Non-essential Header Fields are
			included in the Outer Message Header Section, those MAY be obfuscated
			too.
			Header Fields that are not obfuscated should contain the same values
			as in the Original Message.
			If an implementation obfuscates the From, To, and/or Cc Header
			Fields, it may need to provide access to the clear text content of
			these Header Fields to the Submission Entity for processing purposes.
			This is particularly relevant, if proprietary Submission Entities are
			used. Obfuscation of Header Fields may adversely impact spam
			filtering.
			(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.
			[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		o Content-Type
	o Content-Transfer-Encoding		o Content-Transfer-Encoding
	o Content-Disposition		o 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		o References
	o Reply-To		o Reply-To
	o In-Reply-To		o In-Reply-To
	4.1.4.1. Obfuscation of Outer Message Header Fields		4.1.2.4.2. Unencrypted Messages
	If the values of the following Outer Message Header Fields are
	obfuscated, those SHOULD assume the following values:
	* Subject: ...
	* Message-ID: <new randomly generated Message-ID>
	* Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
	[[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the
	same week. The Impact of obfuscated Date HF content to certificate
	validation is for further study, in particular regarding legacy
	clients. ]]
	In certain implementations also the From, To, and/or Cc Header Field
	MAY be obfuscated. Those may be replaced by e.g.
	o To: Obfuscated <anonymous@anonymous.invalid>
	Such implementations may need to ensure that the Submission Entity
	has access to the content of these Header Fields in clear text and is
	capable of processing those. This is particularly relevant, if
	proprietary Submission Entities are used.
	A use case for obfuscation of all Outer Message Header Fields is
	routing email using onion routing or mix networks (e.g.
	[pEp.mixnet]).
	Note: It is for further study to what extent Header Field obfuscation
	adversely impacts spam filtering.
	4.1.5. Receiving User Facing Message Header Fields
	The Receiving User Facing Message SHOULD be a verbatim copy of the
	Inner Message.
	4.1.6. Header Field Flow
	The Following figure depicts the different message representations
	(OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
	from:
	OrigM InnerM Outer(S) OuterM(R) RUFM
	<Trace-HF>
	From (OrigM) = From
	To (OrigM) = To
	Cc (OrigM) = Cc
	Bcc (OrigM) = Bcc*
	Date (OrigM) = Date
	Message-ID (OrigM)= Message-ID
	Subject (new) = Subject
	<MIME-HSp> (new) = <MIME-HSp>
	PROTECTED: PROTECTED:
	<Wrapper> (new) = <Wrapper>
	From > From > From = From > From
	To > To > To = To > To
	Cc* > Cc > Cc = Cc > Cc
	Bcc*
	Date > Date > Date = Date > Date
	Message-ID > Message-ID > Message-ID = Message-ID > Message-ID
	Subject > Subject > Subject = Subject > Subject
	<More HF> > <More HF> > <More HF> = <More HF> > <More-HF>
	<MIME-HSp> > <MIME-HSp> > <MIME-HSp> = <MIME-HSp> > <MIME-HSp>
	<Body> > <Body> > <Body> = <Body> > <Body>
	<Signature>* (new)= <Signature>
	Legend:
	o OuterM(S): Outer Message (OuterM) at sending side (before handing
	it over to the Submission Entity)
	o OuterM(R): Outer Message at receiving side (as received by the
	last hop, before decryption and/or signature verification is
	applied to)
	o InnerM: Inner Message (that protection is applied to)
	o RUFM: Receiving User Facing Message
	o More-HF: Additional Header Fields (HF) in the Original Message
	(OrigM)
	o Wrapper: MIME Header Section; with media type (message/RFC822) to
	unambiguously delimit the inner message from the rest of the
	message.
	o MIME-HSp: MIME Header Section part to describe the encryption or
	signature as per [RFC8551]
	o Trace-HF: Header Fields added in Transit (between sending and
	receiving side) as per [RFC5322]
	o >: taken over / copied from last column
	o =: propagates unchanged, unless something unusual (e.g. attack)
	happens
	o *: HF that is often not present (also further HFs, e.g. To, may
	not be present). If a HF is not present, naturally it can neither
	be taken over nor propagated.
	o (new) / (OrigM): HF or MIME-HSp is generated depending on the		The Outer Message Header Section of unencrypted Messages SHOULD
	decision in Section 4.1.7.1, while '(new)' / '(OrigM)' designate		contain at least the Essential Header Fields and, in addition, MUST
	the default.		contain the Header Fields of the MIME Header Section part to describe
			Cryptographic Layer of the protected MIME subtree as per [RFC8551].
			It may contain further Header Fields, in particular those also
			present in the Inner Message Header Section.
	4.1.7. 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.7.1. Step 1: Decide on Protection Level and Information Disclosure		4.1.2.5.1. Step 1: Decide on Protection Level and Information
			Disclosure
	The entity applying protection to a message must decide:		The implementation which applies protection to a Message must decide:
	o Which Protection Level (signature and/or encryption) is applied to		o Which Protection Level (signature and/or encryption) shall be
	the message? This depends on user request and/or local policy as		applied to the Message? This depends on user request and/or local
	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		o 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.4.		Outer Message Header Section; cf. Section 4.1.2.4.
	o Which of these Header Fields are to be obfuscated? This depends		o 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.4.1.		Section 4.1.2.4.
	4.1.7.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
			shall compose the Outer Message Header Section. (Note that this also
			includes the necessary MIME Header Section part for the following
			protection layer.)
	Depending on the decision in Section 4.1.7.1, compose the Outer
	Message Header Section. (Note that this also includes the necessary
	MIME Header Section part for the following protection layer.)
	Outer Header Fields that are not obfuscated should contain the same		Outer Header Fields that are not obfuscated should contain the same
	values as in the Original Message (except for MIME Header		values as in the Original Message (except for MIME Header
	Section part, which depends on the Protection Level selected in		Section part, which depends on the Protection Level selected in
	Section 4.1.7.1).		Section 4.1.2.5.1).
	4.1.7.3. Step 3: Apply Protection to the Original Message		4.1.2.5.3. Step 3: Apply Protection to the Original Message
	Depending on the Protection Level selected in Section 4.1.7.1, apply		Depending on the Protection Level selected in Section 4.1.2.5.1, the
	signature and/or encryption to the Original Message, including the		implementation applies signature and/or encryption to the Original
	wrapper (as per [RFC8551]), and set the result to the message as		Message, including the wrapper (as per [RFC8551]), and sets the
	Outer Message Body.		resulting package as the Outer Message Body.
	The resulting (Outer) Message is then typically handed over to the		The resulting (Outer) Message is then typically handed over to the
	Submission Entity.		Submission Entity.
	[[ TODO: Example ]]		[[ TODO: Example ]]
	4.1.8. Receiving Side Message Processing		4.1.3. Receiving Side
	When a protected message is received, the following steps are		4.1.3.1. Receiving User Facing Message Header Fields
			The Receiving User Facing Message SHOULD be a verbatim copy of the
			Inner Message.
			4.1.3.2. Receiving Side Message Processing
			When a protected Message is received, the following steps are
	applied:		applied:
	4.1.8.1. Step 1: Decrypt message and/or check signature		4.1.3.2.1. Step 1: Decrypt Message and/or check signature
	Depending on the Protection Level, the received message is decrypted		Depending on the Protection Level, the received Message is decrypted
	and/or its signature is checked as per [RFC8551].		and/or its signature is checked as per [RFC8551].
	4.1.8.2. Step 2: Construct the Receiving User Facing Message		4.1.3.2.2. Step 2: Construct the Receiving User Facing Message
	The Receiving User Facing Message is constructed according to		The Receiving User Facing Message is constructed according to
	Section 4.1.5.		Section 4.1.3.1.
	The resulting message is handed over for further processing, which		The resulting Message is handed over for further processing, which
	typically involves rendering it for the user.		typically involves rendering it for the user.
	Note: Further study is needed to determine whether or not the Outer		4.1.3.3. Step 3: Prepare Information Cyptographic Verification
	Message Header Section, as received from the last hop, is preserved
	for the user, and if so, how this is to be achieved.		[[ TODO: Signature valid, etc. ]]
	4.2. Backward Compatibility Use Cases		4.2. Backward Compatibility Use Cases
	4.2.1. Receiving Side MIME-Conformant		4.2.1. Receiving Side MIME-Conformant
	This section applies to the case where the sending side (fully)		This section applies to the case where the sending side (fully)
	supports Header Protection as specified in this document, while the		supports Header Protection as specified in this document, while the
	receiving side does not support this specification, but is MIME-		receiving side does not support this specification, but is MIME-
	conformant according to [RFC2045], ff. (cf. Section 3.1.2) and		conformant according to [RFC2045], ff. (cf. Section 3.1.2 and
	Section 3.1.2.1)		Section 3.1.2.1)
	The sending side specification of the main use case (cf.		The sending side specification of the main use case (cf.
	Section 4.1) MUST ensure that receiving sides can still recognize and		Section 4.1) MUST ensure that receiving sides can still recognize and
	display or offer to display the encapsulated data in accordance with		display or offer to display the encapsulated data in accordance with
	its media type (cf. [RFC2049], Section 2). In particular, receiving		its media type (cf. [RFC2049], Section 2). In particular, receiving
	sides that do not support this specification, but are MIME-conformant		sides that do not support this specification, but are MIME-conformant
	according to [RFC2045], ff. can still recognize and display the		according to [RFC2045], ff. can still recognize and display the
	Message intended for the user.		Message intended for the user.
	[[ TODO: Verify once solution is stable and update last sentence. ]]		[[ TODO: Verify once solution is stable and update last sentence. ]]
	4.2.2. Receiving Side Not MIME-Conformant		4.2.2. Receiving Side Not MIME-Conformant
	This section applies to the case where the sending side (fully)		This section applies to cases where the sending side (fully) supports
	supports Header Protection as specified in this document, while the		Header Protection as specified in this document, while the receiving
	receiving side neither supports this specification *nor* is MIME-		side neither supports this specification *nor* is MIME-conformant
	conformant according to [RFC2045], ff. (cf. Section 3.1.2 and		according to [RFC2045], ff. (cf. Section 3.1.2 and Section 3.1.2.2).
	Section 3.1.2.2).
	[I-D.autocrypt-lamps-protected-headers] describes a possible way to		[I-D.autocrypt-lamps-protected-headers] describes a possible way to
	achieve backward compatibility with existing S/MIME (and PGP/MIME)		achieve backward compatibility with existing S/MIME (and PGP/MIME)
	implementations that predate this specification and are not MIME-		implementations that predate this specification and are not MIME-
	conformant (Legacy Display) either. It mainly focuses on email		conformant (Legacy Display) either. It mainly focuses on email
	clients that do not render emails using header protection (in a user		clients that do not render emails which utilize header protection in
	friendly manner) and may confuse the user. While this has been		a user friendly manner, which may confuse the user. While this has
	observed occasionally in PGP/MIME (cf. [RFC3156]), the extent of		been observed occasionally in PGP/MIME (cf. [RFC3156]), the extent
	this problem with S/MIME implementations is still unclear. (Note: At		of this problem with S/MIME implementations is still unclear. (Note:
	this time, none of the samples in		At this time, none of the samples in
	[I-D.autocrypt-lamps-protected-headers] apply header protection as		[I-D.autocrypt-lamps-protected-headers] apply header protection as
	specified in Section 3.1 of [RFC8551], which is wrapping as Media		specified in Section 3.1 of [RFC8551], which is wrapping as Media
	Type "message/RFC822".)		Type "message/RFC822".)
	Should serious backward compatibility issues with rendering at the		Should serious backward compatibility issues with rendering at the
	receiver be discovered, the Legacy Display format described in		receiving side be discovered, the Legacy Display format described in
	[I-D.autocrypt-lamps-protected-headers] may serve as a basis to		[I-D.autocrypt-lamps-protected-headers] may serve as a basis to
	mitigate those issues (cf. Section 4.2).		mitigate those issues (cf. Section 4.2).
	Another variant of backward compatibility has been implemented by pEp		Another variant of backward compatibility has been implemented by pEp
	[I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has		[I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has
	implemented this for PGP/MIME, but not yet S/MIME.		implemented this for PGP/MIME, but not yet S/MIME.
	5. Security Considerations		5. Security Considerations
	[[ TODO ]]		[[ TODO ]]
	skipping to change at page 23, line 19 ¶		skipping to change at page 19, line 52 ¶
	7. IANA Considerations		7. IANA Considerations
	This document requests no action from IANA.		This document requests no action from IANA.
	[[ RFC Editor: This section may be removed before publication. ]]		[[ RFC Editor: This section may be removed before publication. ]]
	8. Acknowledgments		8. Acknowledgments
	The authors would like to thank the following people who have		The authors would like to thank the following people who have
	provided helpful comments and suggestions for this document: Berna		provided helpful comments and suggestions for this document: Berna
	Alp, Claudio Luck, Daniel Kahn Gillmor, David Wilson, Hernani		Alp, Claudio Luck, David Wilson, Hernani Marques, juga, Krista
	Marques, juga, Krista Bennett, Kelly Bristol, Lars Rohwedder, Robert		Bennett, Kelly Bristol, Lars Rohwedder, Robert Williams, Russ
	Williams, 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]
			Gillmor, D., "Guidance on End-to-End E-mail Security",
			draft-dkg-lamps-e2e-mail-guidance-00 (work in progress),
			October 2020.
	[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", draft-ietf-lamps-
	header-protection-requirements-01 (work in progress),		header-protection-requirements-01 (work in progress),
	October 2019.		October 2019.
	[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>.
	skipping to change at page 25, line 5 ¶		skipping to change at page 21, line 45 ¶
	[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>.
	[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",		[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
	STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,		STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
	<https://www.rfc-editor.org/info/rfc6409>.		<https://www.rfc-editor.org/info/rfc6409>.
	[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
	Authorizing Use of Domains in Email, Version 1", RFC 7208,
	DOI 10.17487/RFC7208, April 2014,
	<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>.
	Appendix A. Additional information		Appendix A. Additional information
	A.1. Stored Variants of Messages with Bcc		A.1. Stored Variants of Messages with Bcc
	Messages containing at least one recipient address in the Bcc header		Messages containing at least one recipient address in the Bcc header
	field may appear in up to three different variants:		field may appear in up to three different variants:
	1. The message for the recipient addresses listed in To or Cc header		1. The Message for the recipient addresses listed in To or Cc header
	fields, which must not include the Bcc header field neither for		fields, which must not include the Bcc header field neither for
	signature calculation nor for encryption.		signature calculation nor for encryption.
	2. The message(s) sent to the recipient addresses in the Bcc header		2. The Message(s) sent to the recipient addresses in the Bcc header
	field, which depends on the implementation:		field, which depends on the implementation:
	a) One message for each recipient in the Bcc header field		a) One Message for each recipient in the Bcc header field
	separately, with a Bcc header field containing only the address		separately, with a Bcc header field containing only the address
	of the recipient it is sent to.		of the recipient it is sent to.
	b) The same message for each recipient in the Bcc header field		b) The same Message for each recipient in the Bcc header field
	with a Bcc header field containing an indication such as		with a Bcc header field containing an indication such as
	"Undisclosed recipients", but no addresses.		"Undisclosed recipients", but no addresses.
	c) The same message for each recipient in the Bcc header field		c) The same Message for each recipient in the Bcc header field
	which does not include a Bcc header field (this message is		which does not include a Bcc header field (this Message is
	identical to 1. / cf. above).		identical to 1. / cf. above).
	3. The message stored in the 'Sent'-Folder of the sender, which		3. The Message stored in the 'Sent'-Folder of the sender, which
	usually contains the Bcc unchanged from the original message,		usually contains the Bcc unchanged from the original Message,
	i.e., with all recipient addresses.		i.e., with all recipient addresses.
	The most privacy preserving method of the alternatives (2a, 2b, and		The most privacy preserving method of the alternatives (2a, 2b, and
	2c) is to standardize 2a, as in the other cases (2b and 2c),		2c) is to standardize 2a, as in the other cases (2b and 2c),
	information about hidden recipients is revealed via keys. In any		information about hidden recipients is revealed via keys. In any
	case, the message has to be cloned and adjusted depending on the		case, the Message has to be cloned and adjusted depending on the
	recipient.		recipient.
	Appendix B. Document Changelog		Appendix B. Text Moved from Above
			Note: Per an explicit request by the chair of the LAMPS WG to only
			present one option for the specification, the following text has been
			stripped from the main body of the draft. It is preserved in an
			Appendix for the time being and may be moved back to the main body or
			deleted, depending on the decision of the LAMPS WG.
			B.1. MIME Format
			Currently there are two options in discussion:
			1. The option according to the current S/MIME specification (cf.
			[RFC8551])
			2. An alternative option that is based on the former "memory hole"
			approach (cf. [I-D.autocrypt-lamps-protected-headers])
			B.1.1. S/MIME Specification
			Note: This is currently described in the main part of this document.
			B.1.1.1. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory
			Hole")
			An alternative option (based on the former autocrypt "Memory Hole"
			approach) to be considered, is described in
			[I-D.autocrypt-lamps-protected-headers].
			Unlike the option described in Appendix B.1.1, this option does not
			use a "message/RFC822" wrapper to unambiguously delimit the Inner
			Message.
			Before choosing this option, the following two issues must be
			assessed to ensure no interoperability issues result from it:
			1. How current MIME parser implementations treat non-MIME Header
			Fields, which are not part of the outermost MIME entity and not
			part of a Message wrapped into a MIME entity of media type
			"message/rfc822", and how such Messages are rendered to the user.
			[I-D.autocrypt-lamps-protected-headers] provides some examples
			for testing this.
			2. MIME-conformance, i.e. whether or not this option is (fully)
			MIME-conformant [RFC2045] ff., in particular also Section 5.1. of
			[RFC2046] on "Multipart Media Type). In the following an excerpt
			of paragraphs that may be relevant in this context:
			The only header fields that have defined meaning for body parts
			are those the names of which begin with "Content-". All other
			header fields may be ignored in body parts. Although they
			should generally be retained if at all possible, they may be
			discarded by gateways if necessary. Such other fields are
			permitted to appear in body parts but must not be depended on.
			"X-" fields may be created for experimental or private
			purposes, with the recognition that the information they
			contain may be lost at some gateways.
			NOTE: The distinction between an RFC 822 Message and a body
			part is subtle, but important. A gateway between Internet and
			X.400 mail, for example, must be able to tell the difference
			between a body part that contains an image and a body part
			that contains an encapsulated Message, the body of which is a
			JPEG image. In order to represent the latter, the body part
			must have "Content-Type: message/rfc822", and its body (after
			the blank line) must be the encapsulated Message, with its own
			"Content-Type: image/jpeg" header field. The use of similar
			syntax facilitates the conversion of Messages to body parts,
			and vice versa, but the distinction between the two must be
			understood by implementors. (For the special case in which
			parts actually are Messages, a "digest" subtype is also
			defined.)
			The MIME structure of an Email Message looks as follows:
			<Outer Message Header Section (unprotected)>
			<Outer Message Body (protected)>
			<Inner Message Header Section>
			<Inner Message Body>
			The following example demonstrates how an Original Message might be
			protected, i.e., the Original Message is contained as Inner Message
			in the Protected Body of an Outer Message. It illustrates the first
			Body part (of the Outer Message) as a "multipart/signed"
			(application/pkcs7-signature) media type:
			Lines are prepended as follows:
			o "O: " Outer Message Header Section
			o "I: " Message Header Section
			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: Subject: Meeting at my place
			O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
			O: MIME-Version: 1.0
			O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
			O: protocol="application/pkcs7-signature";
			O: boundary=boundary-AM
			This is a multipart message in MIME format.
			--boundary-AM
			I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
			I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
			I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
			I: MIME-Version: 1.0
			I: MMHS-Primary-Precedence: 3
			I: Subject: Meeting at my place
			I: To: somebody@example.net
			I: X-Mailer: Isode Harrier Web Server
			I: Content-Type: text/plain; charset=us-ascii
			This is an important message that I don't want to be modified.
			--boundary-AM
			Content-Transfer-Encoding: base64
			Content-Type: application/pkcs7-signature
			[[base-64 encoded signature]]
			--boundary-AM--
			The Outer Message Header Section is unprotected, while the remainder
			(Outer Message Body) is protected. The Outer Message Body consists
			of the Inner Message (Header Section and Body).
			The Inner Message Header Section is the same as (or a subset of) the
			Original Message Header Section (cf. Section 4.1.2.1).
			The Inner Message Body is the same as the Original Message Body.
			The Original Message itself may contain any MIME structure.
			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
			* 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
			[I-D.dkg-lamps-e2e-mail-guidance]) [DKG]
			* Enhanced MITM Definition to include Machine- / Meddler-in-the-
			middle [HB]
			* Relaxed definition of Original message, which may not be of
			type "message/rfc822" [HB]
			* Move "memory hole" option to the Appendix (on request by Chair
			to only maintain one option in the specification) [HB]
			* Updated Scope of Protection Levels according to WG discussion
			during IETF-108 [HB]
			* Obfuscation recommendation only for Subject and Message-Id and
			distinguish between Encrypted and Unencrypted Messages [HB]
			* Removed (commented out) Header Field Flow Figure (it appeared
			to be confusing as is was) [HB]
	o draft-ietf-lamps-header-protection-00		o 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 C. 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)		o 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) Section 4.1.1.2.		Section 5.1. (Multipart Media Type) Appendix B.1.1.1.
	o Decide on format of obfuscated HFs, in particular Date HF
	(Section 4.1.4.1)
	o Impact on spam filtering, if HFs are obfuscated (Section 4.1.4.1)
	o More examples (e.g. in Section 4.1.7)		o More examples (e.g. in Section 4.1.2.5)
	o Should Outer Message Header Section (as received) be preserved for		o Should Outer Message Header Section (as received) be preserved for
	the user? (Section 4.1.8.2)		the user? (Section 4.1.3.2.2)
	o Decide on whether or not merge requirements from		o 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		o 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).		o Enhance Introduction Section 1 and Problem Statement (Section 2).
	skipping to change at page 27, line 23 ¶		skipping to change at page 27, line 40 ¶
	Bernie Hoeneisen		Bernie Hoeneisen
	pEp Foundation		pEp Foundation
	Oberer Graben 4		Oberer Graben 4
	CH-8400 Winterthur		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
			American Civil Liberties Union
			125 Broad St.
			New York, NY 10004
			USA
			Email: dkg@fifthhorseman.net
	Alexey Melnikov		Alexey Melnikov
	Isode Ltd		Isode Ltd
	14 Castle Mews		14 Castle Mews
	Hampton, Middlesex TW12 2NP		Hampton, Middlesex TW12 2NP
	UK		UK
	Email: alexey.melnikov@isode.com		Email: alexey.melnikov@isode.com
End of changes. 120 change blocks.
	483 lines changed or deleted		542 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/