rfc9788v1.txt		rfc9788.txt
	skipping to change at line 85 ¶		skipping to change at line 85 ¶
	1.8.2. Out of Scope		1.8.2. Out of Scope
	1.9. Example		1.9. Example
	2. Internet Message Format Extensions		2. Internet Message Format Extensions
	2.1. Content-Type Parameters		2.1. Content-Type Parameters
	2.1.1. Content-Type Parameter: hp		2.1.1. Content-Type Parameter: hp
	2.1.2. Content-Type Parameter: hp-legacy-display		2.1.2. Content-Type Parameter: hp-legacy-display
	2.2. HP-Outer Header Field		2.2. HP-Outer Header Field
	2.2.1. HP-Outer Header Field Definition		2.2.1. HP-Outer Header Field Definition
	3. Header Confidentiality Policy		3. Header Confidentiality Policy
	3.1. HCP Definition		3.1. HCP Definition
	3.1.1. HCP Avoids Changing from addr-spec		3.1.1. HCP Avoids Changing From Header Field addr-spec
	3.2. Initial Registered HCPs		3.2. Initial Registered HCPs
	3.2.1. Baseline Header Confidentiality Policy		3.2.1. Baseline Header Confidentiality Policy
	3.2.2. Shy Header Confidentiality Policy		3.2.2. Shy Header Confidentiality Policy
	3.2.3. No Header Confidentiality Policy		3.2.3. No Header Confidentiality Policy
	3.3. Default Header Confidentiality Policy		3.3. Default Header Confidentiality Policy
	3.4. HCP Evolution		3.4. HCP Evolution
	3.4.1. Offering More Ambitious Header Confidentiality		3.4.1. Offering More Ambitious Header Confidentiality
	3.4.2. Expert Guidance for Registering Header Confidentiality		3.4.2. Expert Guidance for Registering Header Confidentiality
	Policies		Policies
	4. Receiving Guidance		4. Receiving Guidance
	skipping to change at line 316 ¶		skipping to change at line 316 ¶
	This specification also offers substantial security, privacy, and		This specification also offers substantial security, privacy, and
	usability guidance for sending and receiving MUAs that was not		usability guidance for sending and receiving MUAs that was not
	considered in [RFC8551].		considered in [RFC8551].
	1.1.1. Problems with RFC 8551 Header Protection		1.1.1. Problems with RFC 8551 Header Protection
	Several Legacy MUAs have difficulty rendering a message that uses		Several Legacy MUAs have difficulty rendering a message that uses
	RFC8551HP. These problems can appear on signed-only messages, as		RFC8551HP. These problems can appear on signed-only messages, as
	well as signed-and-encrypted messages.		well as signed-and-encrypted messages.
	In some cases, some mail user agents cannot render message/rfc822		In some cases, some MUAs cannot render message/rfc822 message
	message subparts at all, which is in violation of baseline MIME		subparts at all, which is in violation of baseline MIME requirements
	requirements as defined in Section 2 of [RFC2049]. A message using		as defined in Section 2 of [RFC2049]. A message using RFC8551HP is
	RFC8551HP is unreadable by any recipient using such an MUA.		unreadable by any recipient using such an MUA.
	In other cases, the user sees an attachment suggesting a forwarded		In other cases, the user sees an attachment suggesting a forwarded
	email message that -- in fact -- contains the protected email message		email message that -- in fact -- contains the protected email message
	that should be rendered directly. In most of these cases, the user		that should be rendered directly. In most of these cases, the user
	can click on the attachment to view the protected message.		can click on the attachment to view the protected message.
	However, viewing the protected message as an attachment in isolation		However, viewing the protected message as an attachment in isolation
	may strip it of any security indications, leaving the user unable to		may strip it of any security indications, leaving the user unable to
	assess the cryptographic properties of the message. Worse, for		assess the cryptographic properties of the message. Worse, for
	encrypted messages, interacting with the protected message in		encrypted messages, interacting with the protected message in
	skipping to change at line 525 ¶		skipping to change at line 525 ¶
	document.		document.
	1.6. Requirements Language		1.6. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The policies "Specification Required" and "IETF Review" that appear
	in this document when used to describe namespace allocation are to be
	interpreted as described in [RFC8126].
	1.7. Terms		1.7. Terms
	The following terms are defined for the scope of this document:		The following terms are defined for the scope of this document:
	S/MIME: Secure/Multipurpose Internet Mail Extensions (see [RFC8551])		S/MIME: Secure/Multipurpose Internet Mail Extensions (see [RFC8551])
	PGP/MIME: Pretty Good Privacy with MIME (see [RFC3156])		PGP/MIME: Pretty Good Privacy with MIME (see [RFC3156])
	Message: An email message consisting of Header Fields (collectively		Message: An email message consisting of Header Fields (collectively
	called "the Header Section of the message") optionally followed by		called "the Header Section of the message") optionally followed by
	skipping to change at line 600 ¶		skipping to change at line 596 ¶
	Ordinary User: A user of an MUA who follows a simple and minimal		Ordinary User: A user of an MUA who follows a simple and minimal
	experience, focused on sending and receiving emails. A user who		experience, focused on sending and receiving emails. A user who
	opts into advanced configuration, expert mode, or the like is not		opts into advanced configuration, expert mode, or the like is not
	an "Ordinary User".		an "Ordinary User".
	Additionally, Cryptographic Layer, Cryptographic Payload,		Additionally, Cryptographic Layer, Cryptographic Payload,
	Cryptographic Envelope, Cryptographic Summary, Structural Header		Cryptographic Envelope, Cryptographic Summary, Structural Header
	Fields, Main Body Part, User-Facing Header Fields, and MUA are all		Fields, Main Body Part, User-Facing Header Fields, and MUA are all
	used as defined in [RFC9787].		used as defined in [RFC9787].
			The policies "Specification Required" and "IETF Review" that appear
			in this document when used to describe namespace allocation are to be
			interpreted as described in [RFC8126].
	1.8. Document Scope		1.8. Document Scope
	This document describes sensible, simple behavior for a program that		This document describes sensible, simple behavior for a program that
	generates an email message with standard end-to-end cryptographic		generates an email message with standard end-to-end cryptographic
	protections, following the guidance in [RFC9787]. An implementation		protections, following the guidance in [RFC9787]. An implementation
	conformant to this document will produce messages that have		conformant to this document will produce messages that have
	cryptographic protection that covers the message's Header Fields as		cryptographic protection that covers the message's Header Fields as
	well as its body.		well as its body.
	1.8.1. In Scope		1.8.1. In Scope
	skipping to change at line 1006 ¶		skipping to change at line 1006 ¶
	* a sequence of whitespace (that is, space or tab) and printable		* a sequence of whitespace (that is, space or tab) and printable
	7-bit, clean ASCII characters (of course, non-ASCII text can be		7-bit, clean ASCII characters (of course, non-ASCII text can be
	encoded as ASCII using the encoded-word construct from [RFC2047])		encoded as ASCII using the encoded-word construct from [RFC2047])
	The HCP can compute val_out using any technique describable in		The HCP can compute val_out using any technique describable in
	pseudocode, such as copying a fixed string or invocations of other		pseudocode, such as copying a fixed string or invocations of other
	pseudocode functions. If it alters the value, it MUST NOT include		pseudocode functions. If it alters the value, it MUST NOT include
	control or NUL characters in val_out. val_out SHOULD match the		control or NUL characters in val_out. val_out SHOULD match the
	expected ABNF for the Header Field identified by name.		expected ABNF for the Header Field identified by name.
	3.1.1. HCP Avoids Changing from addr-spec		3.1.1. HCP Avoids Changing From Header Field addr-spec
	The From Header Field should also be treated specially by the HCP to		The From Header Field should also be treated specially by the HCP to
	enable defense against possible email address spoofing (see		enable defense against possible email address spoofing (see
	Section 10.1). In particular, for hcp("From", val_in), the addr-spec		Section 10.1). In particular, for hcp("From", val_in), the addr-spec
	of val_in and the addr-spec of val_out SHOULD match according to		of val_in and the addr-spec of val_out SHOULD match according to
	Section 4.4.5, unless the sending MUA has additional knowledge		Section 4.4.5, unless the sending MUA has additional knowledge
	coordinated with the receiving MUA about more subtle addr-spec		coordinated with the receiving MUA about more subtle addr-spec
	equivalence or certificate validity.		equivalence or certificate validity.
	3.2. Initial Registered HCPs		3.2. Initial Registered HCPs
	skipping to change at line 1646 ¶		skipping to change at line 1646 ¶
	the Cryptographic Payload is a single part, that part itself may		the Cryptographic Payload is a single part, that part itself may
	contain a Legacy Display Element if it is marked with the hp-legacy-		contain a Legacy Display Element if it is marked with the hp-legacy-
	display="1" parameter.		display="1" parameter.
	4.5.3.2. Omitting Legacy Display Elements from text/plain		4.5.3.2. Omitting Legacy Display Elements from text/plain
	If a text/plain part within the Cryptographic Payload has the		If a text/plain part within the Cryptographic Payload has the
	Content-Type parameter hp-legacy-display="1", it should be processed		Content-Type parameter hp-legacy-display="1", it should be processed
	before rendering in the following fashion:		before rendering in the following fashion:
	* Discard the leading lines of the body of the part up to and		* Discard the leading lines of the body part up to and including the
	including the first entirely blank line.		first entirely blank line.
	Note that implementing this strategy is dependent on the charset used		Note that implementing this strategy is dependent on the charset used
	by the MIME part.		by the MIME part.
	See Appendix E.1 for an example.		See Appendix E.1 for an example.
	4.5.3.3. Omitting Legacy Display Elements from text/html		4.5.3.3. Omitting Legacy Display Elements from text/html
	If a text/html part within the Cryptographic Payload has the Content-		If a text/html part within the Cryptographic Payload has the Content-
	Type parameter hp-legacy-display="1", it should be processed before		Type parameter hp-legacy-display="1", it should be processed before
	skipping to change at line 3493 ¶		skipping to change at line 3493 ¶
	| | cryptographic | |		| | cryptographic | |
	| | protections including | |		| | protections including | |
	| | header protection | |		| | header protection | |
	+---------------------------+-------------------------+-----------+		+---------------------------+-------------------------+-----------+
	Table 5: Table of Pseudocode Listings		Table 5: Table of Pseudocode Listings
	Appendix B. Possible Problems with Legacy MUAs		Appendix B. Possible Problems with Legacy MUAs
	When an email message with end-to-end cryptographic protection is		When an email message with end-to-end cryptographic protection is
	received by a mail user agent, the user might experience many		received by a MUA, the user might experience many different possible
	different possible problematic interactions. A message with Header		problematic interactions. A message with Header Protection may
	Protection may introduce new forms of user experience failure.		introduce new forms of user experience failure.
	In this section, the authors enumerate different kinds of failures we		In this section, the authors enumerate different kinds of failures we
	have observed when reviewing, rendering, and replying to messages		have observed when reviewing, rendering, and replying to messages
	with different forms of Header Protection in different Legacy MUAs.		with different forms of Header Protection in different Legacy MUAs.
	Different Legacy MUAs demonstrate different subsets of these		Different Legacy MUAs demonstrate different subsets of these
	problems.		problems.
	A conformant MUA would not exhibit any of these problems. An		A conformant MUA would not exhibit any of these problems. An
	implementer updating their Legacy MUA to be compliant with this		implementer updating their Legacy MUA to be compliant with this
	specification should consider these concerns and try to avoid them.		specification should consider these concerns and try to avoid them.
End of changes. 7 change blocks.
	15 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48.