< draft-ietf-lamps-e2e-mail-guidance-00.txt		draft-ietf-lamps-e2e-mail-guidance-01.txt >
	lamps D.K. Gillmor, Ed.		lamps D.K. Gillmor, Ed.
	Internet-Draft ACLU		Internet-Draft ACLU
	Intended status: Informational 26 July 2021		Intended status: Informational 24 January 2022
	Expires: 27 January 2022		Expires: 28 July 2022
	Guidance on End-to-End E-mail Security		Guidance on End-to-End E-mail Security
	draft-ietf-lamps-e2e-mail-guidance-00		draft-ietf-lamps-e2e-mail-guidance-01
	Abstract		Abstract
	End-to-end cryptographic protections for e-mail messages can provide		End-to-end cryptographic protections for e-mail messages can provide
	useful security. However, the standards for providing cryptographic		useful security. However, the standards for providing cryptographic
	protection are extremely flexible. That flexibility can trap users		protection are extremely flexible. That flexibility can trap users
	and cause surprising failures. This document offers guidance for		and cause surprising failures. This document offers guidance for
	mail user agent implementers that need to compose or interpret e-mail		mail user agent implementers that need to compose or interpret e-mail
	messages with end-to-end cryptographic protection. It provides a		messages with end-to-end cryptographic protection. It provides a
	useful set of vocabulary as well as suggestions to avoid common		useful set of vocabulary as well as suggestions to avoid common
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 27 January 2022.		This Internet-Draft will expire on 28 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2.1. Structural Headers . . . . . . . . . . . . . . . . . 4		1.2.1. Structural Headers . . . . . . . . . . . . . . . . . 4
	2. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. E-mail Users Want a Familiar Experience . . . . . . . . . 5		2.2. E-mail Users Want a Familiar Experience . . . . . . . . . 5
	skipping to change at page 2, line 49 ¶		skipping to change at page 2, line 49 ¶
	5.2. Encryption Outside, Signature Inside . . . . . . . . . . 13		5.2. Encryption Outside, Signature Inside . . . . . . . . . . 13
	5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 13		5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 13
	5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 14		5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 14
	6. Message Interpretation . . . . . . . . . . . . . . . . . . . 15		6. Message Interpretation . . . . . . . . . . . . . . . . . . . 15
	6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 15		6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 15
	6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 15		6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 15
	6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 15		6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 15
	6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 17		6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 17
	6.3. Forwarded Messages with Cryptographic Protection . . . . 18		6.3. Forwarded Messages with Cryptographic Protection . . . . 18
	6.4. Signature failures . . . . . . . . . . . . . . . . . . . 18		6.4. Signature failures . . . . . . . . . . . . . . . . . . . 18
	7. Certificate Management . . . . . . . . . . . . . . . . . . . 19		7. Reasoning about Message Parts . . . . . . . . . . . . . . . . 19
	7.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 19		7.1. Main Body Part . . . . . . . . . . . . . . . . . . . . . 19
	7.1.1. Cert Discovery from Incoming Messages . . . . . . . . 19		7.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 20
	7.1.2. Certificate Directories . . . . . . . . . . . . . . . 20		7.3. MIME Part Examples . . . . . . . . . . . . . . . . . . . 21
	7.1.3. Peer Certificate Selection . . . . . . . . . . . . . 20
	7.1.4. Checking for Revocation . . . . . . . . . . . . . . . 20		8. Certificate Management . . . . . . . . . . . . . . . . . . . 22
	7.2. Local Certificates . . . . . . . . . . . . . . . . . . . 21		8.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 22
	7.2.1. Getting a Certificate for the User . . . . . . . . . 21		8.1.1. Cert Discovery from Incoming Messages . . . . . . . . 22
	7.2.2. Local Certificate Maintenance . . . . . . . . . . . . 21		8.1.2. Certificate Directories . . . . . . . . . . . . . . . 22
	7.2.3. Shipping Certificates in Outbound Messages . . . . . 22		8.1.3. Peer Certificate Selection . . . . . . . . . . . . . 22
	7.3. Certificate Authorities . . . . . . . . . . . . . . . . . 22		8.1.4. Checking for Revocation . . . . . . . . . . . . . . . 23
	8. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 22		8.2. Local Certificates . . . . . . . . . . . . . . . . . . . 23
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		8.2.1. Getting a Certificate for the User . . . . . . . . . 23
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 23		8.2.2. Local Certificate Maintenance . . . . . . . . . . . . 24
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		8.2.3. Shipping Certificates in Outbound Messages . . . . . 24
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		8.3. Certificate Authorities . . . . . . . . . . . . . . . . . 25
	12.1. Normative References . . . . . . . . . . . . . . . . . . 23		9. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 25
	12.2. Informative References . . . . . . . . . . . . . . . . . 24		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 25		11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	Appendix B. Document Considerations . . . . . . . . . . . . . . 25		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	B.1. Document History . . . . . . . . . . . . . . . . . . . . 25		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	B.1.1. Substantive changes from draft-dkg-...-01 to		13.1. Normative References . . . . . . . . . . . . . . . . . . 26
	draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 25		13.2. Informative References . . . . . . . . . . . . . . . . . 26
	B.1.2. Substantive changes from draft-dkg-...-00 to		Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 27
	draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 25		Appendix B. Document Considerations . . . . . . . . . . . . . . 28
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26		B.1. Document History . . . . . . . . . . . . . . . . . . . . 28
			B.1.1. Substantive changes from draft-ietf-...-00 to
			draft-ietf-...-01 . . . . . . . . . . . . . . . . . . 28
			B.1.2. Substantive changes from draft-dkg-...-01 to
			draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 28
			B.1.3. Substantive changes from draft-dkg-...-00 to
			draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 28
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME		E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME
	([RFC3156]) cryptographic standards can provide integrity,		([RFC3156]) cryptographic standards can provide integrity,
	authentication and confidentiality to MIME ([RFC4289]) e-mail		authentication and confidentiality to MIME ([RFC4289]) e-mail
	messages.		messages.
	However, there are many ways that a receiving mail user agent can		However, there are many ways that a receiving mail user agent can
	misinterpret or accidentally break these security guarantees (e.g.,		misinterpret or accidentally break these security guarantees (e.g.,
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 37 ¶
	* _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic		* _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic
	Payload_, and _Errant Cryptographic Layer_ are defined in		Payload_, and _Errant Cryptographic Layer_ are defined in
	Section 4		Section 4
	* A _well-formed_ e-mail message with cryptographic protection has		* A _well-formed_ e-mail message with cryptographic protection has
	both a _Cryptographic Envelope_ and a _Cryptographic Payload_.		both a _Cryptographic Envelope_ and a _Cryptographic Payload_.
	* _Structural Headers_ are documented in Section 1.2.1.		* _Structural Headers_ are documented in Section 1.2.1.
			* _Main Body Part_ is the part (or parts) that are typically
			rendered to the user as the message itself (not "as an
			attachment). See Section 7.1.
	1.2.1. Structural Headers		1.2.1. Structural Headers
	A message header whose name begins with "Content-" is referred to in		A message header whose name begins with Content- is referred to in
	this document as a "structural" header.		this document as a "structural" header.
	These headers indicate something about the specific MIME part they		These headers indicate something about the specific MIME part they
	are attached to, and cannot be transferred or copied to other parts		are attached to, and cannot be transferred or copied to other parts
	without endangering the readability of the message.		without endangering the readability of the message.
	This includes (but is not limited to):		This includes (but is not limited to):
	* "Content-Type"		* Content-Type
			* Content-Transfer-Encoding
	* "Content-Transfer-Encoding"
	* "Content-Disposition"		* Content-Disposition
	FIXME: are there any non-"Content-*" headers we should consider as		FIXME: are there any non-Content-* headers we should consider as
	structural?		structural?
	2. Usability		2. Usability
	Any MUA that enables its user to transition from unprotected messages		Any MUA that enables its user to transition from unprotected messages
	to messages with end-to-end cryptographic protection needs to		to messages with end-to-end cryptographic protection needs to
	consider how the user understands this transition. That said, the		consider how the user understands this transition. That said, the
	primary goal of the user of an MUA is communication -- so interface		primary goal of the user of an MUA is communication -- so interface
	elements that get in the way of communication should be avoided where		elements that get in the way of communication should be avoided where
	possible.		possible.
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 47 ¶
	This MIME layer offers confidentiality.		This MIME layer offers confidentiality.
	4.1.1.4. S/MIME PKCS7 authEnveloped-data Cryptographic Layer		4.1.1.4. S/MIME PKCS7 authEnveloped-data Cryptographic Layer
	└─╴application/pkcs7-mime; smime-type="authEnveloped-data"		└─╴application/pkcs7-mime; smime-type="authEnveloped-data"
	↧ (decrypts to)		↧ (decrypts to)
	└─╴[protected part]		└─╴[protected part]
	This MIME layer offers confidentiality and integrity.		This MIME layer offers confidentiality and integrity.
	Note that "enveloped-data" (Section 4.1.1.3) and "authEnveloped-data"		Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data
	(Section 4.1.1.4) have identical message structure and semantics.		(Section 4.1.1.4) have identical message structure and semantics.
	The only difference between the two is ciphertext malleability.		The only difference between the two is ciphertext malleability.
	The examples in this document only include "enveloped-data", but the		The examples in this document only include enveloped-data, but the
	implications for that layer apply to "authEnveloped-data" as well.		implications for that layer apply to authEnveloped-data as well.
	4.1.1.5. PKCS7 Compression is NOT a Cryptographic Layer		4.1.1.5. PKCS7 Compression is NOT a Cryptographic Layer
	The Cryptographic Message Syntax (CMS) provides a MIME compression		The Cryptographic Message Syntax (CMS) provides a MIME compression
	layer ("smime-type="compressed-data""), as defined in [RFC3274].		layer (smime-type="compressed-data"), as defined in [RFC3274]. While
	While the compression layer is technically a part of CMS, it is not		the compression layer is technically a part of CMS, it is not
	considered a Cryptographic Layer for the purposes of this document.		considered a Cryptographic Layer for the purposes of this document.
	4.1.2. PGP/MIME Cryptographic Layers		4.1.2. PGP/MIME Cryptographic Layers
	For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers,		For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers,
	signing and encryption.		signing and encryption.
	4.1.2.1. PGP/MIME Signing Cryptographic Layer (multipart/signed)		4.1.2.1. PGP/MIME Signing Cryptographic Layer (multipart/signed)
	└┬╴multipart/signed; protocol="application/pgp-signature"		└┬╴multipart/signed; protocol="application/pgp-signature"
	skipping to change at page 10, line 37 ¶		skipping to change at page 10, line 37 ¶
	4.4.1. Simple Cryptographic Envelopes		4.4.1. Simple Cryptographic Envelopes
	As described above, if the "protected part" identified in the sction		As described above, if the "protected part" identified in the sction
	above is not itself a Cryptographic Layer, that part _is_ the		above is not itself a Cryptographic Layer, that part _is_ the
	Cryptographic Payload.		Cryptographic Payload.
	If the application wants to generate a message that is both encrypted		If the application wants to generate a message that is both encrypted
	and signed, it MAY use the simple MIME structure from Section 4.1.2.2		and signed, it MAY use the simple MIME structure from Section 4.1.2.2
	by ensuring that the [RFC4880] Encrypted Message within the		by ensuring that the [RFC4880] Encrypted Message within the
	"application/octet-stream" part contains an [RFC4880] Signed Message		application/octet-stream part contains an [RFC4880] Signed Message
	(the final option described in Section 4.1.2.2.		(the final option described in Section 4.1.2.2.
	4.4.2. Multilayer Cryptographic Envelopes		4.4.2. Multilayer Cryptographic Envelopes
	It is possible to construct a Cryptographic Envelope consisting of		It is possible to construct a Cryptographic Envelope consisting of
	multiple layers with either S/MIME or PGP/MIME , for example using		multiple layers with either S/MIME or PGP/MIME , for example using
	the following structure:		the following structure:
	A └─╴application/pkcs7-mime; smime-type="enveloped-data"		A └─╴application/pkcs7-mime; smime-type="enveloped-data"
	B ↧ (decrypts to)		B ↧ (decrypts to)
	C └─╴application/pkcs7-mime; smime-type="signed-data"		C └─╴application/pkcs7-mime; smime-type="signed-data"
	D ⇩ (unwraps to)		D ⇩ (unwraps to)
	E └─╴[protected part]		E └─╴[protected part]
	When handling such a message, the properties of the Cryptographic		When handling such a message, the properties of the Cryptographic
	Envelope are derived from the series "A", "C".		Envelope are derived from the series A, C.
	As noted in Section 4.4.1, PGP/MIME applications also have a simpler		As noted in Section 4.4.1, PGP/MIME applications also have a simpler
	MIME construction available with the same cryptographic properties.		MIME construction available with the same cryptographic properties.
	4.5. Errant Crytptographic Layers		4.5. Errant Crytptographic Layers
	Due to confusion, malice, or well-intentioned tampering, a message		Due to confusion, malice, or well-intentioned tampering, a message
	may contain a Cryptographic Layer that is not part of the		may contain a Cryptographic Layer that is not part of the
	Cryptographic Envelope. Such a layer is an Errant Cryptographic		Cryptographic Envelope. Such a layer is an Errant Cryptographic
	Layer.		Layer.
	skipping to change at page 11, line 35 ¶		skipping to change at page 11, line 35 ¶
	Some mailing list software will re-wrap a well-formed signed message		Some mailing list software will re-wrap a well-formed signed message
	before re-sending to add a footer, resulting in the following		before re-sending to add a footer, resulting in the following
	structure seen by recipients of the e-mail:		structure seen by recipients of the e-mail:
	H └┬╴multipart/mixed		H └┬╴multipart/mixed
	I ├┬╴multipart/signed		I ├┬╴multipart/signed
	J │├─╴text/plain		J │├─╴text/plain
	K │└─╴application/pgp-signature		K │└─╴application/pgp-signature
	L └─╴text/plain		L └─╴text/plain
	In this message, "L" is the footer added by the mailing list. "I" is		In this message, L is the footer added by the mailing list. I is now
	now an Errant Cryptographic Layer.		an Errant Cryptographic Layer.
	Note that this message has no Cryptographic Envelope at all.		Note that this message has no Cryptographic Envelope at all.
	It is NOT RECOMMENDED to produce e-mail messages with this structure,		It is NOT RECOMMENDED to produce e-mail messages with this structure,
	because the data in part "L" may appear to the user as though it were		because the data in part L may appear to the user as though it were
	part of "J", though they have different cryptographic properties. In		part of J, though they have different cryptographic properties. In
	particular, if the user believes that the message is signed, but		particular, if the user believes that the message is signed, but
	cannot distinguish "L" from "J" then the author of "L" can		cannot distinguish L from J then the author of L can effectively
	effectively tamper with content of the signed message, breaking the		tamper with content of the signed message, breaking the user's
	user's expectation of integrity and authenticity.		expectation of integrity and authenticity.
	4.5.2. A Baroque Example		4.5.2. A Baroque Example
	Consider a message with the following overcomplicated structure:		Consider a message with the following overcomplicated structure:
	M └┬╴multipart/encrypted		M └┬╴multipart/encrypted
	N ├─╴application/pgp-encrypted		N ├─╴application/pgp-encrypted
	O └─╴application/octet-stream		O └─╴application/octet-stream
	P ↧ (decrypts to)		P ↧ (decrypts to)
	Q └┬╴multipart/signed		Q └┬╴multipart/signed
	R ├┬╴multipart/mixed		R ├┬╴multipart/mixed
	S │├┬╴multipart/signed		S │├┬╴multipart/signed
	T ││├─╴text/plain		T ││├─╴text/plain
	U ││└─╴application/pgp-signature		U ││└─╴application/pgp-signature
	V │└─╴text/plain		V │└─╴text/plain
	W └─╴application/pgp-signature		W └─╴application/pgp-signature
	The 3 Cryptographic Layers in such a message are rooted in parts "M",		The 3 Cryptographic Layers in such a message are rooted in parts M,
	"Q", and "S". But the Cryptographic Envelope of the message consists		Q, and S. But the Cryptographic Envelope of the message consists
	only of the properties derived from the series "M", "Q". The		only of the properties derived from the series M, Q. The
	Cryptographic Payload of the message is part "R". Part "S" is an		Cryptographic Payload of the message is part R. Part S is an Errant
	Errant Cryptographic Layer.		Cryptographic Layer.
	Note that this message has both a Cryptographic Envelope _and_ an		Note that this message has both a Cryptographic Envelope _and_ an
	Errant Cryptographic Layer.		Errant Cryptographic Layer.
	It is NOT RECOMMENDED to generate messages with such complicated		It is NOT RECOMMENDED to generate messages with such complicated
	structures. Even if a receiving MUA can parse this structure		structures. Even if a receiving MUA can parse this structure
	properly, it is nearly impossible to render in a way that the user		properly, it is nearly impossible to render in a way that the user
	can reason about the cryptographic properties of part "T" compared to		can reason about the cryptographic properties of part T compared to
	part "V".		part V.
	5. Message Composition		5. Message Composition
	This section describes the ideal composition of an e-mail message		This section describes the ideal composition of an e-mail message
	with end-to-end cryptographic protection. A message composed with		with end-to-end cryptographic protection. A message composed with
	this form is most likely to achieve its end-to-end security goals.		this form is most likely to achieve its end-to-end security goals.
	5.1. Message Composition Algorithm		5.1. Message Composition Algorithm
	This section roughly describes the steps that a MUA should use to		This section roughly describes the steps that a MUA should use to
	compose a cryptographically-protected message that has a proper		compose a cryptographically-protected message that has a proper
	cryptographic envelope and payload.		cryptographic envelope and payload.
	The message composition algorithm takes three parameters:		The message composition algorithm takes three parameters:
	* "origbody": the traditional unprotected message body as a well-		* origbody: the traditional unprotected message body as a well-
	formed MIME tree (possibly just a single MIME leaf part). As a		formed MIME tree (possibly just a single MIME leaf part). As a
	well-formed MIME tree, "origbody" already has structural headers		well-formed MIME tree, origbody already has structural headers
	present (see Section 1.2.1).		present (see Section 1.2.1).
	* "origheaders": the intended non-structural headers for the		* origheaders: the intended non-structural headers for the message,
	message, represented here as a list of "(h,v)" pairs, where "h" is		represented here as a list of (h,v) pairs, where h is a header
	a header field name and "v" is the associated value.		field name and v is the associated value.
	* "crypto": The series of cryptographic protections to apply (for		* crypto: The series of cryptographic protections to apply (for
	example, "sign with the secret key corresponding to X.509		example, "sign with the secret key corresponding to X.509
	certificate X, then encrypt to X.509 certificates X and Y"). This		certificate X, then encrypt to X.509 certificates X and Y"). This
	is a routine that accepts a MIME tree as input (the Cryptographic		is a routine that accepts a MIME tree as input (the Cryptographic
	Payload), wraps the input in the appropriate Cryptographic		Payload), wraps the input in the appropriate Cryptographic
	Envelope, and returns the resultant MIME tree as output.		Envelope, and returns the resultant MIME tree as output.
	The algorithm returns a MIME object that is ready to be injected into		The algorithm returns a MIME object that is ready to be injected into
	the mail system:		the mail system:
	* Apply "crypto" to "origbody", yielding MIME tree "output"		* Apply crypto to origbody, yielding MIME tree output
	* For each header name and value "(h,v)" in "origheaders":		* For each header name and value (h,v) in origheaders:
	- Add header "h" of "output" with value "v"		- Add header h of output with value v
	* Return "output"		* Return output
	5.2. Encryption Outside, Signature Inside		5.2. Encryption Outside, Signature Inside
	Users expect any message that is both signed and encrypted to be		Users expect any message that is both signed and encrypted to be
	signed _inside_ the encryption, and not the other way around.		signed _inside_ the encryption, and not the other way around.
	Putting the signature inside the encryption has two advantages:		Putting the signature inside the encryption has two advantages:
	* The details of the signature remain confidential, visible only to		* The details of the signature remain confidential, visible only to
	the parties capable of decryption.		the parties capable of decryption.
	skipping to change at page 16, line 28 ¶		skipping to change at page 16, line 28 ¶
	In such a situation, an MUA SHOULD NOT indicate in the cryptographic		In such a situation, an MUA SHOULD NOT indicate in the cryptographic
	summary that the message is signed.		summary that the message is signed.
	6.2.1.1. Exception: Mailing List Footers		6.2.1.1. Exception: Mailing List Footers
	The use case described in Section 4.5.1 is common enough in some		The use case described in Section 4.5.1 is common enough in some
	contexts, that a MUA MAY decide to handle it as a special exception.		contexts, that a MUA MAY decide to handle it as a special exception.
	If the MUA determines that the message comes from a mailing list (it		If the MUA determines that the message comes from a mailing list (it
	has a "List-ID" header), and it has a structure that appends a footer		has a List-ID header), and it has a structure that appends a footer
	to a signing-only Cryptographic Layer with a valid signature, such		to a signing-only Cryptographic Layer with a valid signature, such
	as:		as:
	H └┬╴multipart/mixed		H └┬╴multipart/mixed
	I ├┬╴multipart/signed		I ├┬╴multipart/signed
	J │├─╴[protected part, may be arbitrary MIME subtree]		J │├─╴[protected part, may be arbitrary MIME subtree]
	K │└─╴application/{pgp,pkcs7}-signature		K │└─╴application/{pgp,pkcs7}-signature
	L └─╴[footer, typically text/plain]		L └─╴[footer, typically text/plain]
	or:		or:
	H └┬╴multipart/mixed		H └┬╴multipart/mixed
	I ├─╴application/pkcs7-mime; smime-type="signed-data"		I ├─╴application/pkcs7-mime; smime-type="signed-data"
	│⇩ (unwraps to)		│⇩ (unwraps to)
	J │└─╴[protected part, may be an arbitrary MIME subtree]		J │└─╴[protected part, may be an arbitrary MIME subtree]
	L └─╴[footer, typically text/plain]		L └─╴[footer, typically text/plain]
	Then, the MUA MAY indicate to the user that this is a signed message		Then, the MUA MAY indicate to the user that this is a signed message
	that has been wrapped by the mailing list.		that has been wrapped by the mailing list.
	In this case, the MUA MUST distinguish the footer (part "L") from the		In this case, the MUA MUST distinguish the footer (part L) from the
	protected part (part "J") when rendering any information about the		protected part (part J) when rendering any information about the
	signature.		signature.
	One way to do this is to offer the user two different views of the		One way to do this is to offer the user two different views of the
	message: the "mailing list" view, which hides any cryptographic		message: the "mailing list" view, which hides any cryptographic
	summary but shows the footer:		summary but shows the footer:
	Cryptographic Protections: none		Cryptographic Protections: none
	H └┬╴multipart/mixed		H └┬╴multipart/mixed
	J ├─╴[protected part, may be arbitrary MIME subtree]		J ├─╴[protected part, may be arbitrary MIME subtree]
	L └─╴[footer, typically text/plain]		L └─╴[footer, typically text/plain]
	skipping to change at page 18, line 8 ¶		skipping to change at page 18, line 8 ¶
	decrypted subpart, the reply message SHOULD be marked for encryption,		decrypted subpart, the reply message SHOULD be marked for encryption,
	as noted in {#composing-reply}.		as noted in {#composing-reply}.
	Alternately, if the reply message cannot be encrypted (or if the user		Alternately, if the reply message cannot be encrypted (or if the user
	elects to not encrypt the reply), the composed reply MUST NOT include		elects to not encrypt the reply), the composed reply MUST NOT include
	any material from the decrypted subpart.		any material from the decrypted subpart.
	6.3. Forwarded Messages with Cryptographic Protection		6.3. Forwarded Messages with Cryptographic Protection
	An incoming e-mail message may include an attached forwarded message,		An incoming e-mail message may include an attached forwarded message,
	typically as a MIME subpart with "Content-Type: message/rfc822"		typically as a MIME subpart with Content-Type: message/rfc822
	([RFC5322]) or "Content-Type: message/global" ([RFC5355]).		([RFC5322]) or Content-Type: message/global ([RFC5355]).
	Regardless of the cryptographic protections and structure of the		Regardless of the cryptographic protections and structure of the
	incoming message, the internal forwarded message may have its own		incoming message, the internal forwarded message may have its own
	Cryptographic Envelope.		Cryptographic Envelope.
	The Cryptographic Layers that are part of the Cryptographic Envelope		The Cryptographic Layers that are part of the Cryptographic Envelope
	of the forwarded message are not Errant Cryptographic Layers of the		of the forwarded message are not Errant Cryptographic Layers of the
	surrounding message -- they are simply layers that apply to the		surrounding message -- they are simply layers that apply to the
	forwarded message itself.		forwarded message itself.
	skipping to change at page 19, line 16 ¶		skipping to change at page 19, line 16 ¶
	does not have access to.		does not have access to.
	* the certificate that made the signature was revoked.		* the certificate that made the signature was revoked.
	* the certificate that made the signature was expired at the time		* the certificate that made the signature was expired at the time
	that the signature was made.		that the signature was made.
	* the certificate that made the signature does not correspond to the		* the certificate that made the signature does not correspond to the
	author of the message. (for X.509, there is no subjectAltName of		author of the message. (for X.509, there is no subjectAltName of
	type RFC822Name whose value matches an e-mail address found in		type RFC822Name whose value matches an e-mail address found in
	"From:" or "Sender:")		From: or Sender:)
	* the certificate that made the signature was not issued by an		* the certificate that made the signature was not issued by an
	authority that the MUA user is willing to rely on for certifying		authority that the MUA user is willing to rely on for certifying
	the sender's e-mail address.		the sender's e-mail address.
	* the signature indicates that it was made at a time much before or		* the signature indicates that it was made at a time much before or
	much after from the date of the message itself.		much after from the date of the message itself.
	A valid signature must pass all these tests, but of course invalid		A valid signature must pass all these tests, but of course invalid
	signatures may be invalid in more than one of the ways listed above.		signatures may be invalid in more than one of the ways listed above.
	7. Certificate Management		7. Reasoning about Message Parts
			When generating or rendering messages, it is useful to know what
			parts of the message are likely to be displayed, and how. This
			section introduces some common terms that can be applied to parts
			within the Cryptographic Payload.
			7.1. Main Body Part
			When an e-mail message is composed or rendered to the user there is
			typically one main view that presents a (mostly textual) part of the
			message.
			While the message itself may be constructed of several distinct MIME
			parts in a tree, but the part that is rendered to the user is the
			"Main Body Part".
			When rendering a message, one of the primary jobs of the recieving
			MUA is identifying which part (or parts) is the Main Body Part.
			Typically, this is found by traversing the MIME tree of the message
			looking for a leaf node that has a primary content type of text (e.g.
			text/plain or text/html) and is not Content-Disposition: attachment.
			MIME tree traversal follows the first child of every multipart node,
			with the exception of multipart/alternative. When traversing a
			multipart/alternative node, all children should be scanned, with
			preference given to the last child node with a MIME type that the MUA
			is capable of rendering directly. A MUA MAY offer the user a
			mechanism to prefer a particular MIME type within multipart/
			alternative instead of the last renderable child. For example, a
			user may explicitly prefer a text/plain alternative part over text/
			html.
			Note that due to uncertainty about the capabilities and configuration
			of the receiving MUA, the composing MUA SHOULD consider that multiple
			parts might be rendered as the Main Body Part when the message is
			ultimately viewed.
			When composing a message, an originating MUA operating on behalf of
			an active user can identify which part (or parts) are the "main"
			parts: these are the parts the MUA generates from the user's editor.
			Tooling that automatically generates e-mail messages should also have
			a reasonable estimate of which part (or parts) are the "main" parts,
			as they can be programmatically identified by the message author.
			For a filtering program that attempts to transform an outbound
			message without any special knowledge about which parts are Main Body
			Parts, it can identify the likely parts by following the same routine
			as a receiving MUA.
			7.2. Attachments
			A message may contain one or more separated MIME parts that are
			intended for download or extraction. Such a part is commonly called
			an "attachment", and is commonly identified by having Content-
			Disposition: attachment, and is a subpart of a multipart/mixed or
			multipart/related container.
			An MUA MAY identify a subpart as an attachment, or permit extraction
			of a subpart even when the subpart does not have Content-Disposition:
			attachment.
			For end-to-end encrypted messages, attachments _MUST_ be included
			within the Cryptographic Payload. If an attachment is found outside
			the Cryptographic Payload, then the message is not well-formed (see
			Section 6.1).
			Some MUAs have tried to compose messages where each attachment is
			placed in its own cryptographic envelope. Such a message is
			problematic for several reasons:
			* The attachments can be stripped, replaced, or reordered without
			breaking any cryptographic integrity mechanism.
			* The resulting message may have a mix of cryptographic statuses
			(e.g. if a signature on one part fails but another succeeds, or if
			one part is encrypted and another is not). This mix of statuses
			is difficult to represent to the user in a comprehensible way.
			7.3. MIME Part Examples
			Consider a common message with the folloiwing MIME structure:
			M └─╴application/pkcs7-mime
			↧ (decrypts to)
			N └─╴application/pkcs7-mime
			⇩ (unwraps to)
			O └┬╴multipart/mixed
			P ├┬╴multipart/alternative
			Q │├─╴text/plain
			R │└─╴text/html
			S └─╴image/png
			Parts M and N comprise the Cryptographic Envelope.
			Parts Q and R are both Main Body Parts.
			If part S is Content-Disposition: attachment, then it is an
			attachment. If part S has no Content-Disposition header, it is
			potentially ambiguous whether it is an attachment or not.
			Consider also this alternate structure:
			M └─╴application/pkcs7-mime
			↧ (decrypts to)
			N └─╴application/pkcs7-mime
			⇩ (unwraps to)
			O └┬╴multipart/alternative
			P ├─╴text/plain
			Q └┬╴multipart/related
			R ├─╴text/html
			S └─╴image/png
			In this case, parts M and N are still the Cryptographic Envelope.
			Parts P and R (the first two leaf nodes within each subtree of part
			O) are the Main Body Parts.
			Part S is more likely not to be an attachment, as the subtree layout
			suggests that it is only relevant for the HTML version of the
			message. For example, it might be rendered as an image within the
			HTML alternative.
			8. Certificate Management
	A cryptographically-capable MUA typically maintains knowledge about		A cryptographically-capable MUA typically maintains knowledge about
	certificates for the user's own account(s), as well as certificates		certificates for the user's own account(s), as well as certificates
	for the peers that it communicates with.		for the peers that it communicates with.
	7.1. Peer Certificates		8.1. Peer Certificates
	Most certificates that a cryptographically-capable MUA will use will		Most certificates that a cryptographically-capable MUA will use will
	be certificates belonging to the parties that the user communicates		be certificates belonging to the parties that the user communicates
	with through the MUA. This section discusses how to manage the		with through the MUA. This section discusses how to manage the
	certificates that belong to such a peer.		certificates that belong to such a peer.
	The MUA will need to be able to discover X.509 certificates for each		The MUA will need to be able to discover X.509 certificates for each
	peer, cache them, and select among them when composing an encrypted		peer, cache them, and select among them when composing an encrypted
	message.		message.
	7.1.1. Cert Discovery from Incoming Messages		8.1.1. Cert Discovery from Incoming Messages
	TODO: incoming PKCS#7 messages tend to have a bundle of certificates		TODO: incoming PKCS#7 messages tend to have a bundle of certificates
	in them. How should these certs be handled?		in them. How should these certs be handled?
	TODO: point to Autocrypt certificate discovery mechanism		TODO: point to Autocrypt certificate discovery mechanism
	TODO: point to OpenPGP embedded certificate subpacket proposal		TODO: point to OpenPGP embedded certificate subpacket proposal
	TODO: compare mechanisms, explain where each case is useful.		TODO: compare mechanisms, explain where each case is useful.
	7.1.2. Certificate Directories		8.1.2. Certificate Directories
	Some MUAs may have the capability to look up peer certificates in a		Some MUAs may have the capability to look up peer certificates in a
	directory.		directory.
	TODO: more information here about X.509 directories -- LDAP?		TODO: more information here about X.509 directories -- LDAP?
	TODO: mention WKD for OpenPGP certificates?		TODO: mention WKD for OpenPGP certificates?
	7.1.3. Peer Certificate Selection		8.1.3. Peer Certificate Selection
	When composing an encrypted message, the MUA needs to select a		When composing an encrypted message, the MUA needs to select a
	certificate for each recipient that is capable of encryption.		certificate for each recipient that is capable of encryption.
	To select such a certificate for a given destination e-mail address,		To select such a certificate for a given destination e-mail address,
	the MUA should look through all of its known certificates and verify		the MUA should look through all of its known certificates and verify
	that _all_ of the conditions below are met:		that _all_ of the conditions below are met:
	* The certificate must be valid, not expired or revoked.		* The certificate must be valid, not expired or revoked.
	skipping to change at page 20, line 48 ¶		skipping to change at page 23, line 27 ¶
	* If extendedKeyUsage is present, it contains at least one of the		* If extendedKeyUsage is present, it contains at least one of the
	following OIDs: e-mail protection, anyExtendedKeyUsage.		following OIDs: e-mail protection, anyExtendedKeyUsage.
	TODO: If OID is EC Public Key and keyUsage is absent, what should		TODO: If OID is EC Public Key and keyUsage is absent, what should
	happen?		happen?
	TODO: what if multiple certificates meet all of these criteria for a		TODO: what if multiple certificates meet all of these criteria for a
	given recipient?		given recipient?
	7.1.4. Checking for Revocation		8.1.4. Checking for Revocation
	TODO: discuss how/when to check for peer certificate revocation		TODO: discuss how/when to check for peer certificate revocation
	TODO: privacy concerns: what information leaks to whom when checking		TODO: privacy concerns: what information leaks to whom when checking
	peer cert revocations?		peer cert revocations?
	7.2. Local Certificates		8.2. Local Certificates
	The MUA also needs to know about one or more certificates associated		The MUA also needs to know about one or more certificates associated
	with the user's e-mail account. It is typically expected to have		with the user's e-mail account. It is typically expected to have
	access to the secret key material associated with the public keys in		access to the secret key material associated with the public keys in
	those certificates.		those certificates.
	7.2.1. Getting a Certificate for the User		8.2.1. Getting a Certificate for the User
	TODO: mention ACME SMIME?		TODO: mention ACME SMIME?
	TODO: mention automatic self-signed certs e.g. OpenPGP?		TODO: mention automatic self-signed certs e.g. OpenPGP?
	TODO: SHOULD generate secret key material locally, and MUST NOT		TODO: SHOULD generate secret key material locally, and MUST NOT
	accept secret key material from an untrusted third party as the basis		accept secret key material from an untrusted third party as the basis
	for the user's certificate.		for the user's certificate.
	7.2.2. Local Certificate Maintenance		8.2.2. Local Certificate Maintenance
	The MUA should warn the user when/if:		The MUA should warn the user when/if:
	* The user's own certificate set does not include a valid, unexpired		* The user's own certificate set does not include a valid, unexpired
	encryption-capable X.509 certificate, and a valid, unexpired		encryption-capable X.509 certificate, and a valid, unexpired
	signature-capable X.509 certificate.		signature-capable X.509 certificate.
	* Any of the user's own certificates is due to expire soon (TODO:		* Any of the user's own certificates is due to expire soon (TODO:
	what is "soon"?)		what is "soon"?)
	skipping to change at page 22, line 5 ¶		skipping to change at page 24, line 33 ¶
	extendedKeyUsage extension		extendedKeyUsage extension
	TODO: how does the MUA do better than warning in the cases above?		TODO: how does the MUA do better than warning in the cases above?
	What can the MUA actually _do_ here to fix problems before they		What can the MUA actually _do_ here to fix problems before they
	happen?		happen?
	TODO: discuss how/when to check for own certificate revocation, and		TODO: discuss how/when to check for own certificate revocation, and
	what to do if it (or any intermediate certificate authority) is found		what to do if it (or any intermediate certificate authority) is found
	to be revoked.		to be revoked.
	7.2.3. Shipping Certificates in Outbound Messages		8.2.3. Shipping Certificates in Outbound Messages
	TODO: What certificates should the MUA include in an outbound message		TODO: What certificates should the MUA include in an outbound message
	so that peers can discover them?		so that peers can discover them?
	* local signing certificate so that signature can be validated		* local signing certificate so that signature can be validated
	* local encryption-capable certificate(s) so that incoming messages		* local encryption-capable certificate(s) so that incoming messages
	can be encypted.		can be encypted.
	* On an encrypted message to multiple recipients, the encryption-		* On an encrypted message to multiple recipients, the encryption-
	capable peer certs of the other recipients (to enable "reply		capable peer certs of the other recipients (to enable "reply
	all")?		all")?
	* intermediate certificates to chain all of the above to some set of		* intermediate certificates to chain all of the above to some set of
	root authorities?		root authorities?
	7.3. Certificate Authorities		8.3. Certificate Authorities
	TODO: how should the MUA select root certificate authorities?		TODO: how should the MUA select root certificate authorities?
	TODO: should the MUA cache intermediate CAs?		TODO: should the MUA cache intermediate CAs?
	TODO: should the MUA share such a cache with other PKI clients (e.g.,		TODO: should the MUA share such a cache with other PKI clients (e.g.,
	web browsers)? Are there distinctions between a CA for S/MIME and		web browsers)? Are there distinctions between a CA for S/MIME and
	for the web?		for the web?
	8. Common Pitfalls and Guidelines		9. Common Pitfalls and Guidelines
	This section highlights a few "pitfalls" and guidelines based on		This section highlights a few "pitfalls" and guidelines based on
	these discussions and lessons learned.		these discussions and lessons learned.
	FIXME: some possible additional commentary on:		FIXME: some possible additional commentary on:
	* indexing and search of encrypted messages		* indexing and search of encrypted messages
	* managing access to cryptographic secret keys that require user		* managing access to cryptographic secret keys that require user
	interaction		interaction
	skipping to change at page 23, line 4 ¶		skipping to change at page 25, line 36 ¶
	* secure deletion		* secure deletion
	* inline PGP, ugh		* inline PGP, ugh
	* storage of composed/sent messages		* storage of composed/sent messages
	* encrypt-to-self during composition		* encrypt-to-self during composition
	* cached signature validation		* cached signature validation
	* interaction between encryption and Bcc		* interaction between encryption and Bcc
	* aggregated cryptographic status of threads/conversations ?		* aggregated cryptographic status of threads/conversations ?
	* Draft messages		* Draft messages
	* copies to the Sent folder		* copies to the Sent folder
	9. IANA Considerations		10. IANA Considerations
	MAYBE: provide an indicator in the IANA header registry for which		MAYBE: provide an indicator in the IANA header registry for which
	headers are "structural" ? This is probably unnecessary.		headers are "structural" ? This is probably unnecessary.
	10. Security Considerations		11. Security Considerations
	This entire document addresses security considerations about end-to-		This entire document addresses security considerations about end-to-
	end cryptographic protections for e-mail messages.		end cryptographic protections for e-mail messages.
	11. Acknowledgements		12. Acknowledgements
	The set of constructs and recommendations in this document are		The set of constructs and recommendations in this document are
	derived from discussions with many different implementers, including		derived from discussions with many different implementers, including
	Alexey Melnikov, Bernie Hoeneisen, Bjarni Runar Einarsson, David		Alexey Melnikov, Bernie Hoeneisen, Bjarni Runar Einarsson, David
	Bremner, Deb Cooley, Holger Krekel, Jameson Rollins, Jonathan		Bremner, Deb Cooley, Holger Krekel, Jameson Rollins, Jonathan
	Hammell, juga, Patrick Brunschwig, Santosh Chokhani, and Vincent		Hammell, juga, Patrick Brunschwig, Santosh Chokhani, and Vincent
	Breitmoser.		Breitmoser.
	12. References		13. References
	12.1. Normative References		13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,		[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
	"MIME Security with OpenPGP", RFC 3156,		"MIME Security with OpenPGP", RFC 3156,
	DOI 10.17487/RFC3156, August 2001,		DOI 10.17487/RFC3156, August 2001,
	<https://www.rfc-editor.org/info/rfc3156>.		<https://www.rfc-editor.org/info/rfc3156>.
	skipping to change at page 24, line 14 ¶		skipping to change at page 26, line 47 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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>.
	12.2. Informative References		13.2. Informative References
	[chrome-indicators]		[chrome-indicators]
	Schechter, E., "Evolving Chrome's security indicators",		Schechter, E., "Evolving Chrome's security indicators",
	May 2018, <https://blog.chromium.org/2018/05/evolving-		May 2018, <https://blog.chromium.org/2018/05/evolving-
	chromes-security-indicators.html>.		chromes-security-indicators.html>.
	[EFAIL] "EFAIL", n.d., <https://efail.de>.		[EFAIL] "EFAIL", n.d., <https://efail.de>.
	[I-D.draft-bre-openpgp-samples-01]		[I-D.draft-bre-openpgp-samples-01]
	Einarsson, B. R., "juga", and D. K. Gillmor, "OpenPGP		Einarsson, B. R., "juga", and D. K. Gillmor, "OpenPGP
	Example Keys and Certificates", Work in Progress,		Example Keys and Certificates", Work in Progress,
	Internet-Draft, draft-bre-openpgp-samples-01, 20 December		Internet-Draft, draft-bre-openpgp-samples-01, 20 December
	2019, <https://www.ietf.org/archive/id/draft-bre-openpgp-		2019, <https://www.ietf.org/archive/id/draft-bre-openpgp-
	samples-01.txt>.		samples-01.txt>.
	[I-D.draft-dkg-lamps-samples-05]		[I-D.draft-ietf-lamps-samples-05]
	Gillmor, D. K., "S/MIME Example Keys and Certificates",		Gillmor, D. K., "S/MIME Example Keys and Certificates",
	Work in Progress, Internet-Draft, draft-dkg-lamps-samples-		Work in Progress, Internet-Draft, draft-ietf-lamps-
	05, 18 February 2021, <https://www.ietf.org/archive/id/		samples-05, 5 August 2021,
	draft-dkg-lamps-samples-05.txt>.		<https://www.ietf.org/archive/id/draft-ietf-lamps-samples-
			05.txt>.
	[RFC3274] Gutmann, P., "Compressed Data Content Type for		[RFC3274] Gutmann, P., "Compressed Data Content Type for
	Cryptographic Message Syntax (CMS)", RFC 3274,		Cryptographic Message Syntax (CMS)", RFC 3274,
	DOI 10.17487/RFC3274, June 2002,		DOI 10.17487/RFC3274, June 2002,
	<https://www.rfc-editor.org/info/rfc3274>.		<https://www.rfc-editor.org/info/rfc3274>.
	[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.		[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
	Thayer, "OpenPGP Message Format", RFC 4880,		Thayer, "OpenPGP Message Format", RFC 4880,
	DOI 10.17487/RFC4880, November 2007,		DOI 10.17487/RFC4880, November 2007,
	<https://www.rfc-editor.org/info/rfc4880>.		<https://www.rfc-editor.org/info/rfc4880>.
	skipping to change at page 25, line 21 ¶		skipping to change at page 27, line 51 ¶
	[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>.
	Appendix A. Test Vectors		Appendix A. Test Vectors
	FIXME: This document should contain examples of well-formed and		FIXME: This document should contain examples of well-formed and
	malformed messages using cryptographic key material and certificates		malformed messages using cryptographic key material and certificates
	from [I-D.draft-bre-openpgp-samples-01] and		from [I-D.draft-bre-openpgp-samples-01] and
	[I-D.draft-dkg-lamps-samples-05].		[I-D.draft-ietf-lamps-samples-05].
	It may also include example renderings of these messages.		It may also include example renderings of these messages.
	Appendix B. Document Considerations		Appendix B. Document Considerations
	[ RFC Editor: please remove this section before publication ]		[ RFC Editor: please remove this section before publication ]
	This document is currently edited as markdown. Minor editorial		This document is built from markdown using ruby-kramdown-rfc2629
	changes can be suggested via merge requests at		(https://rubygems.org/gems/kramdown-rfc2629), and tracked using git
			(https://git-scm.com/). The markdown source under development can be
			found in the file e2e-mail-guidance.md in the main branch of the git
			repository (https://gitlab.com/dkg/e2e-mail-guidance).
			You may also be interested in the latest editor's copy
			(https://dkg.gitlab.io/e2e-mail-guidance/).
			Minor editorial changes can be suggested via merge requests at
	https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the editor.		https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the editor.
	Please direct all significant commentary to the public IETF LAMPS		Please direct all significant commentary to the public IETF LAMPS
	mailing list: spasm@ietf.org		mailing list, spasm@ietf.org (https://www.ietf.org/mailman/listinfo/
			spasm).
	B.1. Document History		B.1. Document History
	B.1.1. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00		B.1.1. Substantive changes from draft-ietf-...-00 to draft-ietf-...-01
			* Added section about distinguishing Main Body Parts and Attachments
			* Updated document considerations section, including reference to
			auto-built editor's copy
			B.1.2. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00
	* WG adopted draft		* WG adopted draft
	* moved Document History and Document Considerations sections to end		* moved Document History and Document Considerations sections to end
	of appendix, to avoid section renumbering when removed		of appendix, to avoid section renumbering when removed
	B.1.2. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01		B.1.3. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01
	* consideration of success/failure indicators for usability		* consideration of success/failure indicators for usability
	* clarify extendedKeyUsage and keyUsage algorithm-specific details		* clarify extendedKeyUsage and keyUsage algorithm-specific details
	* initial section on certificate management		* initial section on certificate management
	* added more TODO items		* added more TODO items
	Author's Address		Author's Address
End of changes. 61 change blocks.
	105 lines changed or deleted		257 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/