rfc9787v5.txt		rfc9787.txt
	Internet Engineering Task Force (IETF) D. K. Gillmor, Ed.		Internet Engineering Task Force (IETF) D. K. Gillmor, Ed.
	Request for Comments: 9787 ACLU		Request for Comments: 9787 ACLU
	Category: Informational B. Hoeneisen, Ed.		Category: Informational A. Melnikov, Ed.
	ISSN: 2070-1721 pEp Project		ISSN: 2070-1721 Isode Ltd
	A. Melnikov, Ed.		B. Hoeneisen, Ed.
	Isode Ltd		pEp Project
	June 2025		July 2025
	Guidance on End-to-End Email Security		Guidance on End-to-End Email Security
	Abstract		Abstract
	End-to-end cryptographic protections for email messages can provide		End-to-end cryptographic protections for email 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 (MUA) implementers to help mitigate those risks and		Mail User Agent (MUA) implementers to help mitigate those risks and
	skipping to change at line 578 ¶		skipping to change at line 578 ¶
	status of the message. This section establishes some conventions		status of the message. This section establishes some conventions
	about how to think about message structure.		about how to think about message structure.
	4.1. Cryptographic Layers		4.1. Cryptographic Layers
	"Cryptographic Layer" refers to a MIME substructure that supplies		"Cryptographic Layer" refers to a MIME substructure that supplies
	some cryptographic protections to an internal MIME subtree. The		some cryptographic protections to an internal MIME subtree. The
	internal subtree is known as the "protected part", though of course		internal subtree is known as the "protected part", though of course
	it may itself be a multipart object.		it may itself be a multipart object.
	In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7)		In the diagrams below, "╧" (BOX DRAWINGS UP SINGLE AND HORIZONTAL
	indicates "decrypts to" and "⇩" (DOWNWARDS WHITE ARROW, U+21E9)		DOUBLE, U+2567) indicates "decrypts to" and "┴" (BOX DRAWINGS LIGHT
	indicates "unwraps to".		UP AND HORIZONTAL, U+2534) indicates "unwraps to".
	4.1.1. S/MIME Cryptographic Layers		4.1.1. S/MIME Cryptographic Layers
	For S/MIME [RFC8551], there are four forms of Cryptographic Layers:		For S/MIME [RFC8551], there are four forms of Cryptographic Layers:
	multipart/signed, PKCS #7 signed-data, PKCS #7 enveloped-data, and		multipart/signed, PKCS #7 signed-data, PKCS #7 enveloped-data, and
	PKCS #7 authEnveloped-data.		PKCS #7 authEnveloped-data.
	4.1.1.1. S/MIME Multipart Signed Cryptographic Layer		4.1.1.1. S/MIME Multipart Signed Cryptographic Layer
	└┬╴multipart/signed; protocol="application/pkcs7-signature"		└┬╴multipart/signed; protocol="application/pkcs7-signature"
	├─╴[protected part]		├─╴[protected part]
	└─╴application/pkcs7-signature		└─╴application/pkcs7-signature
	This MIME layer offers authentication and integrity.		This MIME layer offers authentication and integrity.
	4.1.1.2. S/MIME PKCS #7 signed-data Cryptographic Layer		4.1.1.2. S/MIME PKCS #7 signed-data Cryptographic Layer
	└─╴application/pkcs7-mime; smime-type="signed-data"		└┬╴application/pkcs7-mime; smime-type="signed-data"
	⇩ (unwraps to)		┴ (unwraps to)
	└─╴[protected part]		└─╴[protected part]
	This MIME layer offers authentication and integrity.		This MIME layer offers authentication and integrity.
	4.1.1.3. S/MIME PKCS #7 enveloped-data Cryptographic Layer		4.1.1.3. S/MIME PKCS #7 enveloped-data Cryptographic Layer
	└─╴application/pkcs7-mime; smime-type="enveloped-data"		└┬╴application/pkcs7-mime; smime-type="enveloped-data"
	↧ (decrypts to)		╧ (decrypts to)
	└─╴[protected part]		└─╴[protected part]
	This MIME layer offers confidentiality.		This MIME layer offers confidentiality.
	4.1.1.4. S/MIME PKCS #7 authEnveloped-data Cryptographic Layer		4.1.1.4. S/MIME PKCS #7 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 structures and very similar		(Section 4.1.1.4) have identical message structures and very similar
	confidentiality semantics. The only difference between the two is		confidentiality semantics. The only difference between the two is
	ciphertext malleability.		ciphertext malleability.
	The examples in this document only include enveloped-data, but the		The examples in this document only include enveloped-data, but the
	skipping to change at line 652 ¶		skipping to change at line 652 ¶
	└┬╴multipart/signed; protocol="application/pgp-signature"		└┬╴multipart/signed; protocol="application/pgp-signature"
	├─╴[protected part]		├─╴[protected part]
	└─╴application/pgp-signature		└─╴application/pgp-signature
	This MIME layer offers authenticity and integrity.		This MIME layer offers authenticity and integrity.
	4.1.2.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted)		4.1.2.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted)
	└┬╴multipart/encrypted		└┬╴multipart/encrypted
	├─╴application/pgp-encrypted		├─╴application/pgp-encrypted
	└─╴application/octet-stream		└┬╴application/octet-stream
	↧ (decrypts to)		╧ (decrypts to)
	└─╴[protected part]		└─╴[protected part]
	This MIME layer can offer:		This MIME layer can offer:
	* confidentiality (via a Symmetrically Encrypted Data Packet, see		* confidentiality (via a Symmetrically Encrypted Data Packet, see
	Section 5.7 of [RFC9580]; an MUA MUST NOT generate this form due		Section 5.7 of [RFC9580]; an MUA MUST NOT generate this form due
	to ciphertext malleability),		to ciphertext malleability),
	* confidentiality and integrity (via a Symmetrically Encrypted and		* confidentiality and integrity (via a Symmetrically Encrypted and
	Integrity Protected Data Packet (SEIPD); see Section 5.13 of		Integrity Protected Data Packet (SEIPD); see Section 5.13 of
	[RFC9580]), or		[RFC9580]), or
	* confidentiality, integrity, and authenticity all together (by		* confidentiality, integrity, and authenticity all together (by
	including an OpenPGP Signature Packet within the SEIPD).		including an OpenPGP Signature Packet, see Section 5.2 of
			[RFC9580], within the SEIPD).
	4.2. Cryptographic Envelope		4.2. Cryptographic Envelope
	The Cryptographic Envelope is the largest contiguous set of		The Cryptographic Envelope is the largest contiguous set of
	Cryptographic Layers of an email message starting with the outermost		Cryptographic Layers of an email message starting with the outermost
	MIME type (that is, with the Content-Type of the message itself).		MIME type (that is, with the Content-Type of the message itself).
	If the Content-Type of the message itself is not a Cryptographic		If the Content-Type of the message itself is not a Cryptographic
	Layer, then the message has no Cryptographic Envelope.		Layer, then the message has no Cryptographic Envelope.
	skipping to change at line 716 ¶		skipping to change at line 717 ¶
	by ensuring that the [RFC9580] Encrypted Message within the		by ensuring that the [RFC9580] Encrypted Message within the
	application/octet-stream part contains a [RFC9580] Signed Message		application/octet-stream part contains a [RFC9580] 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 and C.		Envelope are derived from the series A and 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 Cryptographic Layers		4.5. Errant Cryptographic Layers
	Due to confusion, malice, or well-intentioned tampering, a message		Due to confusion, malice, message forwarding, or well-intentioned
	may contain a Cryptographic Layer that is not part of the		tampering, a message may contain a Cryptographic Layer that is not
	Cryptographic Envelope. Such a layer is an Errant Cryptographic		part of the Cryptographic Envelope. Such a layer is an Errant
	Layer.		Cryptographic Layer.
	An Errant Cryptographic Layer MUST NOT contribute to the message's		An Errant Cryptographic Layer MUST NOT contribute to the message's
	overall cryptographic state.		overall cryptographic state.
	Guidance for dealing with Errant Cryptographic Layers can be found in		Guidance for dealing with Errant Cryptographic Layers can be found in
	Section 6.2.		Section 6.2.
	4.5.1. Mailing List Wrapping		4.5.1. Mailing List Wrapping
	Some mailing list software will rewrap a well-formed signed message		Some mailing list software will rewrap a well-formed signed message
	skipping to change at line 766 ¶		skipping to change at line 767 ¶
	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 email messages with this structure,		It is NOT RECOMMENDED to produce email messages with this structure,
	because a legacy MUA may present the data in part L as though it were		because a legacy MUA may present the data in part L 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 entire message is signed		particular, if the user believes that the entire message is signed
	but cannot distinguish L from J, then the author of L can effectively		but cannot distinguish L from J, then the author of L can effectively
	tamper with content of the signed message, breaking the user's		tamper with content of the signed message, breaking the user's
	expectation of integrity and authenticity.		expectation of integrity and authenticity.
			See also Section 6.2.1.1 for guidance on how a receiving MUA might
			deal with this common pattern.
	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 three Cryptographic Layers in such a message are rooted in parts		The three Cryptographic Layers in such a message are rooted in parts
	M, Q, and S. But the Cryptographic Envelope of the message consists		M, Q, and S. But the Cryptographic Envelope of the message consists
	skipping to change at line 821 ¶		skipping to change at line 825 ¶
	This section describes the ideal composition of an email message with		This section describes the ideal composition of an email message with
	end-to-end cryptographic protection. A message composed with this		end-to-end cryptographic protection. A message composed with this
	form is most likely to achieve its end-to-end security goals.		form is most likely to achieve its end-to-end security goals.
	5.1. Message Composition Algorithm		5.1. Message Composition Algorithm
	This section describes the steps that an MUA should use to compose a		This section describes the steps that an MUA should use to compose a
	cryptographically protected message, such that it has a proper		cryptographically protected message, such that it has a proper
	Cryptographic Envelope and Payload.		Cryptographic Envelope and Payload.
	The message composition algorithm takes three parameters:		The inputs to the algorithm are:
	origbody: The unprotected message body as a well-formed MIME tree		origbody: The unprotected message body as a well-formed MIME tree
	(possibly just a single MIME leaf part). As a well-formed MIME		(possibly just a single MIME leaf part). As a well-formed MIME
	tree, origbody already has Structural Header Fields present (see		tree, origbody already has Structural Header Fields present (see
	Section 1.1.1).		Section 1.1.1).
	origheaders: The intended Non-Structural Header Fields for the		origheaders: The intended Non-Structural Header Fields for the
	message, represented here as a list of (h,v) pairs, where h is a		message, represented here as a list of (h,v) pairs, where h is a
	header field name and v is the associated value.		header 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:
	1. Apply crypto to origbody, yielding MIME tree output.		1. Apply crypto to MIME part origbody, producing MIME tree output.
	2. For each header name and value (h,v) in origheaders:		2. For each header field name and value (h,v) in origheaders:
	a. Add header h to output with value v.		a. Add header field h to output with value v.
	3. Return output.		3. Return output.
	This is the classic algorithm. It only protects the Structural		This is the classic algorithm. It only protects the Structural
	Header Fields of the message body and leaves Non-Structural		Header Fields of the message body and leaves Non-Structural
	(including User-Facing) Header Fields unprotected.		(including User-Facing) Header Fields unprotected.
	Therefore, a conformant MUA MUST implement Header Protection as		Therefore, a conformant MUA MUST implement Header Protection as
	described in [RFC9788] (see Section 9.3).		described in [RFC9788] (see Section 9.3).
	5.2. Encryption Outside, Signature Inside		5.2. Encryption Outside, Signature Inside
	An email message that is both signed and encrypted is signed _inside_		An email message that is both signed and encrypted is signed _inside_
	the encryption and not the other way around. For example, when		the encryption and not the other way around. For example, when
	crafting an encrypted and signed message using a simple Cryptographic		crafting a signed-and-encrypted message using a simple Cryptographic
	Envelope of a single layer (Section 4.4.1) with PGP/MIME, the OpenPGP		Envelope of a single layer (Section 4.4.1) with PGP/MIME, the OpenPGP
	Encrypted Message object should contain an OpenPGP Signed Message.		Encrypted Message object should contain an OpenPGP Signed Message.
	Likewise, when using a multilayer Cryptographic Envelope		Likewise, when using a multilayer Cryptographic Envelope
	(Section 4.4.2), the outer layer should be an encryption layer and		(Section 4.4.2), the outer layer should be an encryption layer and
	the inner layer should be a signing layer.		the inner layer should be a signing layer.
	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 line 895 ¶		skipping to change at line 899 ¶
	protection is harmful: It may confuse the recipient and offer no		protection is harmful: It may confuse the recipient and offer no
	benefit.		benefit.
	* Signed-only: In other cases, signing a message is useful		* Signed-only: In other cases, signing a message is useful
	(authenticity and integrity are desirable), but encryption is		(authenticity and integrity are desirable), but encryption is
	either impossible (for example, if the sender does not know how to		either impossible (for example, if the sender does not know how to
	encrypt to all recipients) or meaningless (for example, an email		encrypt to all recipients) or meaningless (for example, an email
	message to a mailing list that is intended to be published to a		message to a mailing list that is intended to be published to a
	public archive).		public archive).
	* Signed-and-Encrypted: In other cases, full end-to-end		* Signed-and-encrypted: In other cases, full end-to-end
	confidentiality, authenticity, and integrity are desirable.		confidentiality, authenticity, and integrity are desirable.
	* Encrypted-only: There is no common use case for generating an		* Encrypted-only: There is no common use case for generating an
	email message with end-to-end confidentiality but without		email message with end-to-end confidentiality but without
	authenticity or integrity.		authenticity or integrity.
	- Additionally, some encryption schemes are malleable. This		- Additionally, some encryption schemes are malleable. This
	allows an attacker to tamper with the plaintext by modifying		allows an attacker to tamper with the plaintext by modifying
	the ciphertext (i.e., without decrypting it). One way to		the ciphertext (i.e., without decrypting it). One way to
	prevent this is to authenticate the ciphertext, e.g., using		prevent this is to authenticate the ciphertext, e.g., using
	skipping to change at line 1040 ¶		skipping to change at line 1044 ¶
	Cryptographic Summary that the message is signed. It MUST indicate		Cryptographic Summary that the message is signed. It MUST indicate
	that the message is Unprotected.		that the message is Unprotected.
	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 conformant MUA MAY decide to handle it as a special		contexts that a conformant MUA MAY decide to handle it as a special
	exception.		exception.
	If the MUA determines that the message comes from a mailing list (for		If the MUA determines that the message comes from a mailing list (for
	example, it has a List-ID header) and it has a structure that appends		example, it has a List-ID header field) and it has a structure that
	a footer to a signing-only Cryptographic Layer with a valid		appends a footer to a signing-only Cryptographic Layer with a valid
	signature, such as:		signature, such 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 Verified message		then the MUA MAY indicate to the user that this is a Verified 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.
	skipping to change at line 1117 ¶		skipping to change at line 1121 ¶
	When rendering, the MUA does not indicate that the message was		When rendering, the MUA does not indicate that the message was
	encrypted, even if some subpart of it was decrypted for rendering.		encrypted, even if some subpart of it was decrypted for rendering.
	When composing a reply to a message that has any encryption layer,		When composing a reply to a message that has any encryption layer,
	even an errant one, the reply message SHOULD be marked for		even an errant one, the reply message SHOULD be marked for
	encryption, unless quoted and attributed text is not included in the		encryption, unless quoted and attributed text is not included in the
	reply, as noted in Section 5.4.		reply, as noted in Section 5.4.
	When composing a reply to a message with an Errant Cryptographic		When composing a reply to a message with an Errant Cryptographic
	Layer, a conformant MUA MUST NOT decrypt any Errant Cryptographic		Layer, a conformant MUA MUST NOT quote or attribute text derived from
	Layers when generating quoted or attributed text. This will		the decryption of any Errant Cryptographic Layer. This will
	typically mean either leaving the ciphertext itself in the generated		typically mean either leaving the ciphertext itself in the generated
	reply message or simply not generating any quoted or attributed text		reply message or simply not generating any quoted or attributed text
	at all. This offers protection against the reply-based attacks		at all. This offers protection against the reply-based attacks
	described in [REPLY].		described in [REPLY].
	In all circumstances, if the reply message cannot be encrypted (or if		In all circumstances, if the reply message cannot be encrypted (or if
	the user elects to not encrypt the reply), the composed reply MUST		the user elects to not encrypt the reply), the composed reply MUST
	NOT include any material from the decrypted subpart.		NOT include any material from the decrypted subpart.
	6.2.3. Avoiding Non-MIME Cryptographic Mechanisms		6.2.3. Avoiding Non-MIME Cryptographic Mechanisms
	skipping to change at line 1181 ¶		skipping to change at line 1185 ¶
	An incoming email message may include an attached forwarded message,		An incoming email 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 [RFC6532].		[RFC5322] or Content-Type: message/global [RFC6532].
	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 Errant Cryptographic Layers with respect
	surrounding message -- they are simply layers that apply to the		to the surrounding message -- they are layers that only apply to the
	forwarded message itself.		forwarded message itself.
	A conformant rendering MUA MUST NOT conflate the cryptographic		A conformant rendering MUA MUST NOT conflate the cryptographic
	protections of the forwarded message with the cryptographic		protections of the forwarded message with the cryptographic
	protections of the incoming message.		protections of the incoming message.
	A conformant rendering MUA MAY render a Cryptographic Summary of the		A conformant rendering MUA MAY render a Cryptographic Summary of the
	protections afforded to the forwarded message by its own		protections afforded to the forwarded message by its own
	Cryptographic Envelope, as long as that rendering is unambiguously		Cryptographic Envelope, as long as that rendering is unambiguously
	tied to the forwarded message itself and cannot be spoofed by either		tied to the forwarded message itself and cannot be spoofed by either
	skipping to change at line 1208 ¶		skipping to change at line 1212 ¶
	receiving MUA that discovers a failed signature treats the message as		receiving MUA that discovers a failed signature treats the message as
	though the signature did not exist. This is similar to the standard		though the signature did not exist. This is similar to the standard
	guidance for failed DomainKeys Identified Mail (DKIM) signatures (see		guidance for failed DomainKeys Identified Mail (DKIM) signatures (see
	Section 6.1 of [RFC6376]).		Section 6.1 of [RFC6376]).
	A conformant MUA MUST NOT render a message with a failed signature as		A conformant MUA MUST NOT render a message with a failed signature as
	more dangerous or more dubious than a comparable message without any		more dangerous or more dubious than a comparable message without any
	signature at all. In both cases, the Cryptographic Summary should be		signature at all. In both cases, the Cryptographic Summary should be
	Unprotected.		Unprotected.
	A conformant MUA that encounters an encrypted-and-signed message		A conformant MUA that encounters a signed-and-encrypted message where
	where the signature is invalid SHOULD treat the message the same way		the signature is invalid SHOULD treat the message the same way that
	that it would treat a message that is encryption-only, unless the MUA		it would treat a message that is encryption-only, unless the MUA is
	is providing the user with debugging information.		providing the user with debugging information.
	These are some different ways that a signature may be invalid on a		These are some different ways that a signature may be invalid on a
	given message:		given message:
	* The signature is not cryptographically valid (the math fails).		* The signature is not cryptographically valid (the math fails).
	* The signature relies on suspect cryptographic primitives (e.g.,		* The signature relies on suspect cryptographic primitives (e.g.,
	over a deprecated digest algorithm, or was made by a weak key,		over a deprecated digest algorithm, or was made by a weak key,
	e.g., 1024-bit RSA); note that this requires the rendering MUA to		e.g., 1024-bit RSA); note that this requires the rendering MUA to
	have an explicit policy about what cryptographic primitives are		have an explicit policy about what cryptographic primitives are
	skipping to change at line 1398 ¶		skipping to change at line 1402 ¶
	the MTA operator may learn the number of attachments and the size		the MTA operator may learn the number of attachments and the size
	of each attachment.		of each attachment.
	These messages are unlikely to be usefully interoperable without		These messages are unlikely to be usefully interoperable without
	additional standardization work (see Appendix A.12).		additional standardization work (see Appendix A.12).
	7.3. MIME Part Examples		7.3. MIME Part Examples
	Consider a common message with the following MIME structure:		Consider a common message with the following MIME structure:
	M └─╴application/pkcs7-mime		M └┬╴application/pkcs7-mime
	↧ (decrypts to)		╧ (decrypts to)
	N └─╴application/pkcs7-mime		N └┬╴application/pkcs7-mime
	⇩ (unwraps to)		┴ (unwraps to)
	O └┬╴multipart/mixed		O └┬╴multipart/mixed
	P ├┬╴multipart/alternative		P ├┬╴multipart/alternative
	Q │├─╴text/plain		Q │├─╴text/plain
	R │└─╴text/html		R │└─╴text/html
	S └─╴image/png		S └─╴image/png
	Parts M and N comprise the Cryptographic Envelope.		Parts M and N comprise the Cryptographic Envelope.
	Parts Q and R are both Main Body Parts.		Parts Q and R are both Main Body Parts.
	If part S is Content-Disposition: attachment, then it is an		If part S is Content-Disposition: attachment, then it is an
	attachment. If part S has no Content-Disposition header, it is		attachment. If part S has no Content-Disposition header field, it is
	potentially ambiguous whether it is an attachment or not. If the		potentially ambiguous whether it is an attachment or not. If the
	sender prefers a specific behavior, it should explicitly set the		sender prefers a specific behavior, it should explicitly set the
	Content-Disposition header on part S to either inline or attachment		Content-Disposition header field on part S to either inline or
	as guidance to the receiving MUA.		attachment as guidance to the receiving MUA.
	Consider also this alternate structure:		Consider also this alternate structure:
	M └─╴application/pkcs7-mime		M └┬╴application/pkcs7-mime
	↧ (decrypts to)		╧ (decrypts to)
	N └─╴application/pkcs7-mime		N └┬╴application/pkcs7-mime
	⇩ (unwraps to)		┴ (unwraps to)
	O └┬╴multipart/alternative		O └┬╴multipart/alternative
	P ├─╴text/plain		P ├─╴text/plain
	Q └┬╴multipart/related		Q └┬╴multipart/related
	R ├─╴text/html		R ├─╴text/html
	S └─╴image/png		S └─╴image/png
	In this case, parts M and N still comprise the Cryptographic		In this case, parts M and N still comprise the Cryptographic
	Envelope.		Envelope.
	Parts P and R (the first two leaf nodes within each subtree of part		Parts P and R (the first two leaf nodes within each subtree of part
	skipping to change at line 1457 ¶		skipping to change at line 1461 ¶
	8.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. Detailed guidance about how to do this is beyond the scope
			of this document, but future revisions may bring it into scope (see
	Detailed guidance about how to do this is beyond the scope of this
	document, but future revisions may bring it into scope (see
	Appendix A.3).		Appendix A.3).
	8.1.1. Peer Certificate Selection		8.1.1. Peer Certificate Selection
	When composing an encrypted message, the MUA needs to select an		When composing an encrypted message, the MUA needs to select an
	encryption-capable certificate for each recipient.		encryption-capable certificate for each recipient.
	To select such a certificate for a given destination email address,		To select such a certificate for a given destination email 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.
	* It must have a subjectAltName of type rfc822Name whose contents		* It must have a subjectAltName of type rfc822Name (for all ASCII
	match the destination email address. In particular, the local-		email addresses) or SmtpUTF8Mailbox (for Internationalized Email
	part of the two addresses should be an exact bytewise match, and		Addresses) whose contents match the destination email address. In
	the domain parts of the two addresses should be matched by		particular, for rfc822Name, the local-part of the two addresses
	ensuring label equivalence across the full domain name, as		should be an exact bytewise match, and the domain parts of the two
	described in Section 2.3.2.4 of [RFC5890].		addresses should be matched by ensuring label equivalence across
			the full domain name, as described in Section 2.3.2.4 of
			[RFC5890]. Comparison with SmtpUTF8Mailbox is specified in
			Section 5 of [RFC9598].
	* The algorithm OID in the certificate's SubjectPublicKeyInfo (SPKI)		* The algorithm OID in the certificate's SubjectPublicKeyInfo (SPKI)
	is known to the MUA and capable of encryption. Examples include:		is known to the MUA and capable of encryption. Examples include:
	- rsaEncryption (OID 1.2.840.113549.1.1.1), with the keyUsage		- rsaEncryption (OID 1.2.840.113549.1.1.1), with the keyUsage
	(OID 2.5.29.15) extension present and the "key encipherment"		(OID 2.5.29.15) extension present and the "key encipherment"
	bit (value 32) set.		bit (value 32) set.
	- curveX25519 (OID 1.3.101.110), with the keyUsage extension		- curveX25519 (OID 1.3.101.110), with the keyUsage extension
	present and the "key agreement" bit (value 8) set.		present and the "key agreement" bit (value 8) set.
	skipping to change at line 1676 ¶		skipping to change at line 1681 ¶
	The mechanism for including these certificates, and which		The mechanism for including these certificates, and which
	certificates to include in the message, are protocol specific.		certificates to include in the message, are protocol specific.
	8.2.3.1. Shipping Certificates in S/MIME Messages		8.2.3.1. Shipping Certificates in S/MIME Messages
	In any S/MIME SignedData object, certificates can be shipped in the		In any S/MIME SignedData object, certificates can be shipped in the
	"certificates" member. In any S/MIME EnvelopedData object,		"certificates" member. In any S/MIME EnvelopedData object,
	certificates can be shipped in the "originatorInfo.certs" member.		certificates can be shipped in the "originatorInfo.certs" member.
	When a single S/MIME-protected email message is encrypted and signed,		When a single S/MIME-protected email message is signed-and-encrypted,
	it is usually sufficient to ship all the relevant certificates in the		it is usually sufficient to ship all the relevant certificates in the
	inner SignedData object's "certificates" member.		inner SignedData object's "certificates" member.
	The S/MIME certificates shipped in such a message SHOULD include:		The S/MIME certificates shipped in such a message SHOULD include:
	* the user's own S/MIME signing certificate, so that signature on		* the user's own S/MIME signing certificate, so that signature on
	the current message can be validated.		the current message can be validated.
	* the user's own S/MIME encryption-capable certificate, so that the		* the user's own S/MIME encryption-capable certificate, so that the
	recipient can reply in encrypted form.		recipient can reply in encrypted form.
	skipping to change at line 1816 ¶		skipping to change at line 1821 ¶
	9.3. Unprotected Message Header Fields		9.3. Unprotected Message Header Fields
	Many legacy cryptographically aware MUAs only apply cryptographic		Many legacy cryptographically aware MUAs only apply cryptographic
	protections to the body of the message but leave the header fields		protections to the body of the message but leave the header fields
	unprotected. This gives rise to vulnerabilities like information		unprotected. This gives rise to vulnerabilities like information
	leakage (e.g., the Subject line is visible to a passive intermediary)		leakage (e.g., the Subject line is visible to a passive intermediary)
	or message tampering (e.g., the Subject line is replaced, effectively		or message tampering (e.g., the Subject line is replaced, effectively
	changing the semantics of a signed message). These are not only		changing the semantics of a signed message). These are not only
	security vulnerabilities but also usability problems, because the		security vulnerabilities but also usability problems, because the
	distinction between what is a header and what is the body of a		distinction between what is part of the header section and what is
	message is unclear to many end users and requires a more complex		part of the body of a message is unclear to many end users and
	mental model than is necessary. Useful security comes from alignment		requires a more complex mental model than is necessary. Useful
	between simple mental models and tooling.		security comes from alignment between simple mental models and
			tooling.
	To avoid these concerns, a conformant MUA MUST implement Header		To avoid these concerns, a conformant MUA MUST implement Header
	Protection as described in [RFC9788].		Protection as described in [RFC9788].
	Note that some message header fields, such as List-*, Archived-At,		Note that some message header fields, such as List-*, Archived-At,
	and Resent-*, are typically added by an intervening MUA (see		and Resent-*, are typically added by an intervening MUA (see
	Section 9.8), not by one of the classic "ends" of an end-to-end email		Section 9.8), not by one of the classic "ends" of an end-to-end email
	exchange. A receiving MUA may choose to consider the contents of		exchange. A receiving MUA may choose to consider the contents of
	these header fields on an end-to-end protected message as markers		these header fields on an end-to-end protected message as markers
	added during message transit, even if they are not covered by the		added during message transit, even if they are not covered by the
	skipping to change at line 1874 ¶		skipping to change at line 1880 ¶
	variants of the message created while leaving a coherent view of the		variants of the message created while leaving a coherent view of the
	message itself:		message itself:
	* No Cryptographic Payload contains any Bcc header field.		* No Cryptographic Payload contains any Bcc header field.
	* The main copy of the message is signed and encrypted to all named		* The main copy of the message is signed and encrypted to all named
	recipients and to the sender. A copy of this message is also		recipients and to the sender. A copy of this message is also
	stored in the sender's Sent folder.		stored in the sender's Sent folder.
	* Each Bcc recipient receives a distinct copy of the message, with		* Each Bcc recipient receives a distinct copy of the message, with
	an identical Cryptographic Payload, and the message is signed and		an identical Cryptographic Payload (that is, the cleartext is
	encrypted to that specific recipient and all the named recipients.		identical), and the message is signed and encrypted to that
	These copies are not stored in the sender's Sent folder.		specific recipient and all the named recipients. These copies are
			not stored in the sender's Sent folder.
	* Any Bcc'ed recipient MUST NOT be taken into consideration when		* Any Bcc'ed recipient MUST NOT be taken into consideration when
	determining which certificates to include in the message. In		determining which certificates to include in the message. In
	particular, certificates for Bcc'ed recipients MUST NOT included		particular, certificates for Bcc'ed recipients MUST NOT included
	in any message.		in any message.
	9.4.1.1. Rationale		9.4.1.1. Rationale
	The approach described in Section 9.4.1 aligns the list of		The approach described in Section 9.4.1 aligns the list of
	cryptographic recipients as closely as possible with the set of named		cryptographic recipients as closely as possible with the set of named
	skipping to change at line 1935 ¶		skipping to change at line 1942 ¶
	in this way can be decrypted when the user wants to resume composing		in this way can be decrypted when the user wants to resume composing
	the message but cannot be read by anyone else, including a potential		the message but cannot be read by anyone else, including a potential
	intended recipient. Note that a draft message encrypted in this way		intended recipient. Note that a draft message encrypted in this way
	will only be resumable by another MUA attached to the same mailbox if		will only be resumable by another MUA attached to the same mailbox if
	that other MUA has access to the user's decryption-capable secret		that other MUA has access to the user's decryption-capable secret
	key. This shared access to key material is also likely necessary for		key. This shared access to key material is also likely necessary for
	useful interoperability but is beyond the scope of this document (see		useful interoperability but is beyond the scope of this document (see
	Appendix A.4.1).		Appendix A.4.1).
	A conformant MUA MUST NOT sign a message draft with the user's normal		A conformant MUA MUST NOT sign a message draft with the user's normal
	signing key. If draft signing is intended for cryptographic		signing key, because creating a non-repudiable signature implies a
	coordination between multiple MUAs of the same user, it should be		commitment from the sender. If a signed draft message were to leak
	negotiated with a different key (but see Appendix A.4.1).		to the user's "Drafts" folder on some untrustworthy server, the
			server operator could claim that the user had committed to something
			that they had not yet decided to commit to. If draft signing is
			intended for cryptographic coordination between multiple MUAs of the
			same user, it should be negotiated with a different key (but see
			Appendix A.4.1).
	The message should only be encrypted to its recipients upon actually		The message should only be encrypted to its recipients upon actually
	sending the message. No reasonable user expects their message's		sending the message. No reasonable user expects their message's
	intended recipients to be able to read a message that is not yet		intended recipients to be able to read a message that is not yet
	complete.		complete.
	9.6. Composing a Message to Heterogeneous Recipients		9.6. Composing a Message to Heterogeneous Recipients
	When sending a message that the user intends to be encrypted, it's		When sending a message that the user intends to be encrypted, it's
	possible that some recipients will be unable to receive an encrypted		possible that some recipients will be unable to receive an encrypted
	skipping to change at line 2136 ¶		skipping to change at line 2148 ¶
	* How are any errors or surprises communicated to the user?		* How are any errors or surprises communicated to the user?
	If the proxy passes any of this cryptographic status to the client in		If the proxy passes any of this cryptographic status to the client in
	an added header field, it must also ensure that no such header field		an added header field, it must also ensure that no such header field
	is present on the messages it receives before processing it. If it		is present on the messages it receives before processing it. If it
	were to allow such an unmodified header field through to any client		were to allow such an unmodified header field through to any client
	that is willing to trust its contents, an attacker could spoof the		that is willing to trust its contents, an attacker could spoof the
	field to make the user believe lies about the cryptographic status of		field to make the user believe lies about the cryptographic status of
	the message. In order for an MUA to be confident in such a header		the message. In order for an MUA to be confident in such a header
	field, it needs a guarantee from the proxy that any header it		field, it needs a guarantee from the proxy that any header field it
	produces will be safe. How does the MUA reliably negotiate this		produces will be safe. How does the MUA reliably negotiate this
	guarantee with the proxy? If the proxy can no longer offer this		guarantee with the proxy? If the proxy can no longer offer this
	guarantee, how will the MUA know that things have changed?		guarantee, how will the MUA know that things have changed?
	If such an inbound proxy handles certificate discovery in inbound		If such an inbound proxy handles certificate discovery in inbound
	messages (see Appendix A.3.1), it will also need to communicate the		messages (see Appendix A.3.1), it will also need to communicate the
	results of that discovery process to its corresponding outbound proxy		results of that discovery process to its corresponding outbound proxy
	for message composition (see Section 9.7.1).		for message composition (see Section 9.7.1).
	While an extension to IMAP (or POP or JMAP) might be able to express		While an extension to IMAP (or POP or JMAP) might be able to express
	skipping to change at line 2203 ¶		skipping to change at line 2215 ¶
	An intervening MUA should be aware of end-to-end cryptographic		An intervening MUA should be aware of end-to-end cryptographic
	protections that might already exist on messages that they resend.		protections that might already exist on messages that they resend.
	In particular, it is unclear what the "end-to-end" properties are of		In particular, it is unclear what the "end-to-end" properties are of
	a message that has been handled by an intervening MUA. For signed-		a message that has been handled by an intervening MUA. For signed-
	only messages, if the intervening MUA makes any substantive		only messages, if the intervening MUA makes any substantive
	modifications to the message as it passes it along, it may break the		modifications to the message as it passes it along, it may break the
	signature from the original sender. In many cases, breaking the		signature from the original sender. In many cases, breaking the
	original signature is the appropriate result, since the original		original signature is the appropriate result, since the original
	message has been modified, and the original sender has no control		message has been modified, and the original sender has no control
	over the modifications made by the intervening MUA. For encrypted-		over the modifications made by the intervening MUA. For signed-and-
	and-signed messages, if the intervening MUA is capable of decrypting		encrypted messages, if the intervening MUA is capable of decrypting
	the message, it must be careful when retransmitting the message.		the message, it must be careful when retransmitting the message.
	Will the new recipient be able to decrypt it? If not, will the		Will the new recipient be able to decrypt it? If not, will the
	message be useful to the recipient? If not, it may not make sense to		message be useful to the recipient? If not, it may not make sense to
	resend the message.		resend the message.
	Beyond the act of resending, an intervening MUA should not itself try		Beyond the act of resending, an intervening MUA should not itself try
	to apply end-to-end cryptographic protections on a message that it is		to apply end-to-end cryptographic protections on a message that it is
	resending unless directed otherwise by some future specification.		resending unless directed otherwise by some future specification.
	Additional layers of cryptographic protection added in an ad hoc way		Additional layers of cryptographic protection added in an ad hoc way
	by an intervening MUA are more likely to confuse the recipient and		by an intervening MUA are more likely to confuse the recipient and
	skipping to change at line 2247 ¶		skipping to change at line 2259 ¶
	For example, a signed email message with a text/html part that refers		For example, a signed email message with a text/html part that refers
	to an external image (i.e., via <img src="https://example.com/		to an external image (i.e., via <img src="https://example.com/
	img.png">) may render differently if the hosting web server decides		img.png">) may render differently if the hosting web server decides
	to serve different content at the source URL for the image. This		to serve different content at the source URL for the image. This
	effectively breaks the goals of integrity and authenticity that the		effectively breaks the goals of integrity and authenticity that the
	user should be able to rely on for signed messages, unless the		user should be able to rely on for signed messages, unless the
	external subresource has strict integrity guarantees (e.g., via		external subresource has strict integrity guarantees (e.g., via
	[SRI]).		[SRI]).
	Likewise, fetching an external subresource for an encrypted-and-		Likewise, fetching an external subresource for a signed-and-encrypted
	signed message effectively breaks goals of privacy and		message effectively breaks goals of privacy and confidentiality for
	confidentiality for the user.		the user.
	This is loosely analogous to security indicator problems that arose		This is loosely analogous to security indicator problems that arose
	for web browsers as described in [MIXED-CONTENT]. However, while		for web browsers as described in [MIXED-CONTENT]. However, while
	fetching the external subresource over https is sufficient to avoid a		fetching the external subresource over https is sufficient to avoid a
	"mixed content" warning from most browsers, it is insufficient for an		"mixed content" warning from most browsers, it is insufficient for an
	MUA that wants to offer its users true end-to-end guarantees for		MUA that wants to offer its users true end-to-end guarantees for
	email messages.		email messages.
	A conformant sending MUA that applies signing-only cryptographic		A conformant sending MUA that applies signing-only cryptographic
	protection to a new email message with an external subresource should		protection to a new email message with an external subresource should
	skipping to change at line 2336 ¶		skipping to change at line 2348 ¶
	[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>.
			[RFC9598] Melnikov, A., Chuang, W., and C. Bonnell,
			"Internationalized Email Addresses in X.509 Certificates",
			RFC 9598, DOI 10.17487/RFC9598, May 2024,
			<https://www.rfc-editor.org/info/rfc9598>.
	[RFC9788] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header		[RFC9788] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header
	Protection for Cryptographically Protected Email",		Protection for Cryptographically Protected Email",
	RFC 9788, DOI 10.17487/RFC9788, June 2025,		RFC 9788, DOI 10.17487/RFC9788, June 2025,
	<https://www.rfc-editor.org/info/rfc9788>.		<https://www.rfc-editor.org/info/rfc9788>.
	12.2. Informative References		12.2. Informative References
	[AUTOCRYPT]		[AUTOCRYPT]
	Autocrypt Team, "Autocrypt - Convenient End-to-End		Autocrypt Team, "Autocrypt - Convenient End-to-End
	Encryption for E-Mail", <https://autocrypt.org/>.		Encryption for E-Mail", <https://autocrypt.org/>.
	skipping to change at line 2904 ¶		skipping to change at line 2921 ¶
	Authors' Addresses		Authors' Addresses
	Daniel Kahn Gillmor (editor)		Daniel Kahn Gillmor (editor)
	American Civil Liberties Union		American Civil Liberties Union
	125 Broad St.		125 Broad St.
	New York, NY 10004		New York, NY 10004
	United States of America		United States of America
	Email: dkg@fifthhorseman.net		Email: dkg@fifthhorseman.net
	Bernie Hoeneisen (editor)
	pEp Project
	Oberer Graben 4
	CH-8400 Winterthur
	Switzerland
	Email: bernie@ietf.hoeneisen.ch
	URI: https://pep-project.org/
	Alexey Melnikov (editor)		Alexey Melnikov (editor)
	Isode Ltd		Isode Ltd
	14 Castle Mews		14 Castle Mews
	Hampton, Middlesex		Hampton, Middlesex
	TW12 2NP		TW12 2NP
	United Kingdom		United Kingdom
	Email: alexey.melnikov@isode.com		Email: alexey.melnikov@isode.com
			Bernie Hoeneisen (editor)
			pEp Project
			Oberer Graben 4
			CH-8400 Winterthur
			Switzerland
			Email: bernie@ietf.hoeneisen.ch
			URI: https://pep-project.org/
End of changes. 38 change blocks.
	91 lines changed or deleted		100 lines changed or added
This html diff was produced by rfcdiff 1.48.