rfc9788v6.txt   rfc9788.txt 
Internet Engineering Task Force (IETF) D. K. Gillmor Internet Engineering Task Force (IETF) D. K. Gillmor
Request for Comments: 9788 American Civil Liberties Union Request for Comments: 9788 American Civil Liberties Union
Updates: 8551 B. Hoeneisen Updates: 8551 B. Hoeneisen
Category: Standards Track pEp Project Category: Standards Track pEp Project
ISSN: 2070-1721 A. Melnikov ISSN: 2070-1721 A. Melnikov
Isode Ltd Isode Ltd
June 2025 July 2025
Header Protection for Cryptographically Protected Email Header Protection for Cryptographically Protected Email
Abstract Abstract
S/MIME version 3.1 introduced a mechanism to provide end-to-end S/MIME version 3.1 introduced a mechanism to provide end-to-end
cryptographic protection of email message headers. However, few cryptographic protection of email message headers. However, few
implementations generate messages using this mechanism, and several implementations generate messages using this mechanism, and several
legacy implementations have revealed rendering or security issues legacy implementations have revealed rendering or security issues
when handling such a message. when handling such a message.
skipping to change at line 97 skipping to change at line 97
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
4.1. Identifying That a Message Has Header Protection 4.1. Identifying That a Message Has Header Protection
4.2. Extracting Protected and Unprotected ("Outer") Header 4.2. Extracting Protected Header Fields From an Encrypted
Fields Message
4.2.1. HeaderSetsFromMessage 4.2.1. HeaderSetsFromMessage
4.3. Updating the Cryptographic Summary 4.3. Updating the Cryptographic Summary
4.3.1. HeaderFieldProtection 4.3.1. HeaderFieldProtection
4.4. Handling Mismatch of From Header Fields 4.4. Handling Mismatch of From Header Fields
4.4.1. Definitions 4.4.1. Definitions
4.4.2. Warning for From Header Field Mismatch 4.4.2. Warning for From Header Field Mismatch
4.4.3. From Header Field Rendering 4.4.3. From Header Field Rendering
4.4.4. Handling the Protected From Header Field When 4.4.4. Handling the Protected From Header Field When
Responding Responding
4.4.5. Matching addr-specs 4.4.5. Matching addr-specs
skipping to change at line 137 skipping to change at line 137
5.2. Composing a Message with Header Protection 5.2. Composing a Message with Header Protection
5.2.1. Compose 5.2.1. Compose
5.2.2. Adding a Legacy Display Element to a text/plain Part 5.2.2. Adding a Legacy Display Element to a text/plain Part
5.2.3. Adding a Legacy Display Element to a text/html Part 5.2.3. Adding a Legacy Display Element to a text/html Part
5.2.4. Only Add a Legacy Display Element to Main Body Parts 5.2.4. Only Add a Legacy Display Element to Main Body Parts
5.2.5. Do Not Add a Legacy Display Element to Other 5.2.5. Do Not Add a Legacy Display Element to Other
Content-Types Content-Types
6. Replying and Forwarding Guidance 6. Replying and Forwarding Guidance
6.1. Avoid Leaking Encrypted Header Fields in Replies and 6.1. Avoid Leaking Encrypted Header Fields in Replies and
Forwards Forwards
6.1.1. ReferenceHCP 6.1.1. The Respond Function
6.1.2. ReferenceHCP
6.2. Avoid Misdirected Replies 6.2. Avoid Misdirected Replies
7. Unprotected Header Fields Added in Transit 7. Unprotected Header Fields Added in Transit
7.1. Mailing List Header Fields: List-* and Archived-At 7.1. Mailing List Header Fields: List-* and Archived-At
8. Email Ecosystem Evolution 8. Email Ecosystem Evolution
8.1. Dropping Legacy Display Elements 8.1. Dropping Legacy Display Elements
8.2. More Ambitious Default HCP 8.2. More Ambitious Default HCP
8.3. Deprecation of Messages Without Header Protection 8.3. Deprecation of Messages Without Header Protection
9. Usability Considerations 9. Usability Considerations
9.1. Mixed Protections Within a Message Are Hard to Understand 9.1. Mixed Protections Within a Message Are Hard to Understand
9.2. Users Should Not Have to Choose a Header Confidentiality 9.2. Users Should Not Have to Choose a Header Confidentiality
skipping to change at line 300 skipping to change at line 301
a Cryptographic Envelope around the message to protect it. This a Cryptographic Envelope around the message to protect it. This
document refers to that scheme as "RFC 8551 Header Protection", or document refers to that scheme as "RFC 8551 Header Protection", or
"RFC8551HP". Substantial testing has shown that RFC8551HP does not "RFC8551HP". Substantial testing has shown that RFC8551HP does not
interact well with some Legacy MUAs (see Section 1.1.1). interact well with some Legacy MUAs (see Section 1.1.1).
This specification supersedes RFC8551HP, effectively replacing the This specification supersedes RFC8551HP, effectively replacing the
final two paragraphs of Section 3.1 of [RFC8551]. final two paragraphs of Section 3.1 of [RFC8551].
In this specification, all Header Fields gain end-to-end In this specification, all Header Fields gain end-to-end
cryptographic integrity and authenticity by being copied directly cryptographic integrity and authenticity by being copied directly
into the Cryptographic Payload without using an intervening message/ into the Cryptographic Payload without using an intervening
rfc822 MIME object. In an encrypted message, some Header Fields can message/rfc822 MIME object. In an encrypted message, some Header
also be made confidential by removing or obscuring them from the Fields can also be made confidential by removing or obscuring them
Outer Header Section. from the Outer Header Section.
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.
skipping to change at line 367 skipping to change at line 368
produced, there has been little incentive for those MUAs capable of produced, there has been little incentive for those MUAs capable of
upgrading to bother interpreting them better. upgrading to bother interpreting them better.
In contrast, the mechanisms defined here are safe to adopt and In contrast, the mechanisms defined here are safe to adopt and
produce messages with very few problems for Legacy MUAs. And produce messages with very few problems for Legacy MUAs. And
Section 4.10 provides useful guidance for rendering and replying to Section 4.10 provides useful guidance for rendering and replying to
RFC8551HP messages. RFC8551HP messages.
1.2. Risks of Header Protection for Legacy MUA Recipients 1.2. Risks of Header Protection for Legacy MUA Recipients
Producing a signed-only message using this specification is risk Producing a signed-only message using this specification has no
free. Such a message will render in the same way on any Legacy MUA additional risks (compared to producing a signed-only message without
as a Legacy Signed Message (that is, a signed message without Header Header Protection). Such a message will render in the same way on
Protection). An MUA conformant to this specification that encounters any Legacy MUA as a Legacy Signed Message (that is, a signed message
such a message will be able to gain the benefits of end-to-end without Header Protection). An MUA conformant to this specification
cryptographic integrity and authenticity for all Header Fields. that encounters such a message will be able to gain the benefits of
end-to-end cryptographic integrity and authenticity for all Header
Fields.
An encrypted message produced according to this specification that An encrypted message produced according to this specification that
has some User-Facing Header Fields removed or obscured may not render has some User-Facing Header Fields removed or obscured may not render
as desired in a Legacy MUA. In particular, those Header Fields that as desired in a Legacy MUA. In particular, those Header Fields that
were made confidential will not be visible to the user of a Legacy were made confidential will not be visible to the user of a Legacy
MUA. For example, if the Subject Header Field outside the MUA. For example, if the Subject Header Field outside the
Cryptographic Envelope is replaced with [...], a Legacy MUA will Cryptographic Envelope is replaced with [...], a Legacy MUA will
render the [...] anywhere the Subject is normally seen. This is the render the [...] anywhere the Subject is normally seen. This is the
only risk of producing an encrypted message according to this only additional risk of producing an encrypted message according to
specification. this specification (compared to producing an encrypted message
without confidentiality for any Header Field).
A workaround "Legacy Display" mechanism is provided in this A workaround "Legacy Display" mechanism is provided in this
specification (see Section 2.1.2). Legacy MUAs will render "Legacy specification (see Section 2.1.2). Legacy MUAs will render "Legacy
Display Elements" to the user, albeit not in the same location that Display Elements" to the user, albeit not in the same location that
the Header Fields would normally be rendered. the Header Fields would normally be rendered.
Alternately, if the sender of an encrypted message is particularly Alternately, if the sender of an encrypted message is particularly
concerned about the experience of a recipient using a Legacy MUA, and concerned about the experience of a recipient using a Legacy MUA, and
they are willing to accept leaking the User-Facing Header Fields, they are willing to accept leaking the User-Facing Header Fields,
they can simply adopt the No Header Confidentiality Policy (see they can simply adopt the No Header Confidentiality Policy (see
skipping to change at line 444 skipping to change at line 448
The sender cannot know what MUA (or MUAs) the recipient will use to The sender cannot know what MUA (or MUAs) the recipient will use to
handle the message. Thus, an outbound message format that is handle the message. Thus, an outbound message format that is
backward compatible with as many legacy implementations as possible backward compatible with as many legacy implementations as possible
is a more effective vehicle for providing the whole-message is a more effective vehicle for providing the whole-message
cryptographic protections described above. cryptographic protections described above.
This document aims for backward compatibility with Legacy MUAs to the This document aims for backward compatibility with Legacy MUAs to the
extent possible. In some cases, like when a user-visible Header extent possible. In some cases, like when a user-visible Header
Field like the Subject is cryptographically hidden, a Legacy MUA will Field like the Subject is cryptographically hidden, a Legacy MUA will
not be able to render or reply to the message exactly the same way as not be able to render or reply to the message exactly the same way as
a conformant MUA would. But accommodations are described here that a conformant MUA would. But accommodations are described here (in
ensure a rough semantic equivalence for a Legacy MUA even in these particular, Section 2.1.2) that ensure a rough semantic equivalence
cases. for a Legacy MUA even in these cases.
1.3.2. Deliverability 1.3.2. Deliverability
A message with perfect cryptographic protections that cannot be A message with perfect cryptographic protections that cannot be
delivered is less useful than a message with imperfect cryptographic delivered is less useful than a message with imperfect cryptographic
protections that can be delivered. Senders want their messages to protections that can be delivered. Senders want their messages to
reach the intended recipients. reach the intended recipients.
Given the current state of the Internet mail ecosystem, encrypted Given the current state of the Internet mail ecosystem, encrypted
messages in particular cannot shield all of their Header Fields from messages in particular cannot shield all of their Header Fields from
skipping to change at line 536 skipping to change at line 540
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
a message Body; see [RFC5322]. a message Body; see [RFC5322].
Note: To avoid ambiguity, this document avoids using the terms
"Header" or "Headers" in isolation, but instead always uses
"Header Field" to refer to the individual field and "Header
Section" to refer to the entire collection.
Header Field: A Header Field includes a field name, followed by a Header Field: A Header Field includes a field name, followed by a
colon (":"), followed by a field Body (value), and is terminated colon (":"), followed by a field Body (value), and is terminated
by CRLF; see Section 2.2 of [RFC5322] for more details. by CRLF; see Section 2.2 of [RFC5322] for more details.
Header Section: The Header Section is a sequence of lines of Header Section: The Header Section is a sequence of lines of
characters with special syntax as defined in [RFC5322]. The characters with special syntax as defined in [RFC5322]. The
Header Section of a message contains the Header Fields associated Header Section of a message contains the Header Fields associated
with the message itself. The Header Section of a MIME part (that with the message itself. The Header Section of a MIME part (that
is, a subpart of a message) typically contains Header Fields is, a subpart of a message) typically contains Header Fields
associated with that particular MIME part. associated with that particular MIME part.
Outer Header Section: The unprotected Header Section that MTAs and Outer Header Section: The unprotected Header Section that MTAs and
MUAs unaware of Header Protection treat as the Header Section of MUAs unaware of Header Protection treat as the Header Section of
the Message. the Message.
Inner Header Section: The Header Section at the root of the
Cryptographic Payload. An MUA that implements Header Protection
renders Header Fields from this section for the user.
Body: The Body is the part of a message that follows the Header Body: The Body is the part of a message that follows the Header
Section and is separated from the Header Section by an empty line Section and is separated from the Header Section by an empty line
(that is, a line with nothing preceding the CRLF); see [RFC5322]. (that is, a line with nothing preceding the CRLF); see [RFC5322].
It is the (bottom) section of a message containing the payload of It is the (bottom) section of a message containing the payload of
a message. Typically, the Body consists of a (possibly multipart) a message. Typically, the Body consists of a (possibly multipart)
MIME [RFC2045] construct. MIME [RFC2045] construct.
Header Protection (HP): The cryptographic protection of email Header Header Protection (HP): The cryptographic protection of email Header
Sections (or parts of it) by means of signatures and/or Sections (or parts of it) by means of signatures and/or
encryption. encryption.
skipping to change at line 594 skipping to change at line 597
an encrypted message with Header Protection. An HCP is considered an encrypted message with Header Protection. An HCP is considered
more "conservative" when it removes or obscures fewer Header more "conservative" when it removes or obscures fewer Header
Fields. When it removes or obscures more Header Fields, it is Fields. When it removes or obscures more Header Fields, it is
more "ambitious". See Section 3. more "ambitious". See Section 3.
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".
Respond Function: A function found in most MUAs that defines how to
pre-populate the Header Fields of a new message in response to
another message. See Section 6.1.1.
Additionally, Cryptographic Layer, Cryptographic Payload, Additionally, Cryptographic Layer, Cryptographic Payload,
Cryptographic Envelope, Cryptographic Summary, Structural Header Cryptographic Envelope, Cryptographic Summary, Structural Header
Fields, Non-Structural Header Fields, Main Body Part, User-Facing Fields, Non-Structural Header Fields, Main Body Part, User-Facing
Header Fields, and MUA are all used as defined in [RFC9787]. Header Fields, and MUA are all used as defined in [RFC9787].
The policies "Specification Required" and "IETF Review" that appear The policies "Specification Required" and "IETF Review" that appear
in this document when used to describe namespace allocation are to be in this document when used to describe namespace allocation are to be
interpreted as described in [RFC8126]. interpreted as described in [RFC8126].
Note: To avoid ambiguity, this document avoids using the terms
"Header" or "Headers" in isolation, but instead always uses "Header
Field" to refer to the individual field and "Header Section" to refer
to the entire collection.
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 675 skipping to change at line 687
C └┬╴multipart/alternative; hp="cipher" C └┬╴multipart/alternative; hp="cipher"
D ├─╴text/plain; hp-legacy-display="1" D ├─╴text/plain; hp-legacy-display="1"
E └─╴text/html; hp-legacy-display="1" E └─╴text/html; hp-legacy-display="1"
Observe that: Observe that:
* Nodes A and B are collectively called the Cryptographic Envelope. * Nodes A and B are collectively called the Cryptographic Envelope.
Node C (including its subnodes D and E) is called the Node C (including its subnodes D and E) is called the
Cryptographic Payload [RFC9787]. Cryptographic Payload [RFC9787].
* Node A contains the unprotected ("outer") Header Fields. Node C * Node A contains the (unprotected) outer Header Fields. Node C
contains the protected ("inner") Header Fields. contains the (protected) inner Header Fields.
* The presence of the hp attribute (see Section 2.1.1) on the * The presence of the hp attribute (see Section 2.1.1) on the
Content-Type of node C allows the receiver to know that the sender Content-Type of node C allows the receiver to know that the sender
applied Header Protection. Its value allows the receiver to applied Header Protection. Its value allows the receiver to
distinguish whether the sender intended for the message to be distinguish whether the sender intended for the message to be
confidential (hp="cipher") or not (hp="clear"), since encryption confidential (hp="cipher") or not (hp="clear"), since encryption
may have been added in transit (see Section 10.2). may have been added in transit (see Section 10.2).
The "outer" Header Section on node A looks as follows: The Outer Header Section on node A looks as follows:
Date: Wed, 11 Jan 2023 16:08:43 -0500 Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net> From: Bob <bob@example.net>
To: Alice <alice@example.net> To: Alice <alice@example.net>
Subject: [...] Subject: [...]
Message-ID: <20230111T210843Z.1234@lhp.example> Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Type: application/pkcs7-mime; smime-type="enveloped-data" Content-Type: application/pkcs7-mime; smime-type="enveloped-data"
MIME-Version: 1.0 MIME-Version: 1.0
The "inner" Header Section on node C looks as follows: The Inner Header Section on node C looks as follows:
Date: Wed, 11 Jan 2023 16:08:43 -0500 Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net> From: Bob <bob@example.net>
To: Alice <alice@example.net> To: Alice <alice@example.net>
Subject: Handling the Jones contract Subject: Handling the Jones contract
Keywords: Contract, Urgent Keywords: Contract, Urgent
Message-ID: <20230111T210843Z.1234@lhp.example> Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Type: multipart/alternative; hp="cipher" Content-Type: multipart/alternative; hp="cipher"
MIME-Version: 1.0 MIME-Version: 1.0
HP-Outer: Date: Wed, 11 Jan 2023 16:08:43 -0500 HP-Outer: Date: Wed, 11 Jan 2023 16:08:43 -0500
skipping to change at line 724 skipping to change at line 736
(Date, From, To, Message-ID), some are obscured (Subject), and (Date, From, To, Message-ID), some are obscured (Subject), and
some are removed (Keywords). some are removed (Keywords).
* The HP-Outer Header Fields (see Section 2.2) of node C contain a * The HP-Outer Header Fields (see Section 2.2) of node C contain a
protected copy of the Header Fields in node A. The copy allows protected copy of the Header Fields in node A. The copy allows
the receiver to recompute for which Header Fields the sender the receiver to recompute for which Header Fields the sender
provided confidentiality by removing or obscuring them. provided confidentiality by removing or obscuring them.
* The copying/removing/obscuring and the HP-Outer only apply to Non- * The copying/removing/obscuring and the HP-Outer only apply to Non-
Structural Header Fields, not to Structural Header Fields like Structural Header Fields, not to Structural Header Fields like
Content-Type or MIME-Version (see Section 1.1 of [RFC9787]). Content-Type or MIME-Version (see Section 1.1.1 of [RFC9787]).
* If the sender intends no confidentiality and doesn't encrypt the * If the sender intends no confidentiality and doesn't encrypt the
message, it doesn't remove or obscure Header Fields. All Non- message, it doesn't remove or obscure Header Fields. All Non-
Structural Header Fields are copied as is. No HP-Outer Header Structural Header Fields are copied as is. No HP-Outer Header
Fields are present. Fields are present.
Node D looks as follows: Node D looks as follows:
Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1";
skipping to change at line 872 skipping to change at line 884
This Header Field is used only in the Header Section of the This Header Field is used only in the Header Section of the
Cryptographic Payload of an encrypted message. It is not relevant Cryptographic Payload of an encrypted message. It is not relevant
for signed-only messages. It documents, with the same cryptographic for signed-only messages. It documents, with the same cryptographic
guarantees shared by the rest of the message, the sender's choices guarantees shared by the rest of the message, the sender's choices
about Header Field confidentiality. It does so by embedding a copy about Header Field confidentiality. It does so by embedding a copy
within the Cryptographic Envelope of every Non-Structural Header within the Cryptographic Envelope of every Non-Structural Header
Field that the sender put outside the Cryptographic Envelope. This Field that the sender put outside the Cryptographic Envelope. This
Header Field enables the MUA receiving the encrypted message to Header Field enables the MUA receiving the encrypted message to
reliably identify whether the sending MUA intended to make a Header reliably identify whether the sending MUA intended to make a Header
Field confidential (see Section 11.3). Field confidential (see also Section 11.3).
The HP-Outer Header Fields in a message's Cryptographic Payload are The HP-Outer Header Fields in a message's Cryptographic Payload are
useful for ensuring that any confidential Header Field will not be useful for ensuring that any confidential Header Field will not be
automatically leaked in the clear if the user replies to or forwards automatically leaked in the clear if the user replies to or forwards
the message. They may also be useful for an MUA that indicates the the message. They may also be useful for an MUA that indicates the
confidentiality status of any given Header Field to the user. confidentiality status of any given Header Field to the user.
An implementation that composes encrypted email MUST include a copy An implementation that composes encrypted email MUST include a copy
of all Non-Structural Header Fields deliberately exposed to the of all Non-Structural Header Fields deliberately exposed to the
outside of the Cryptographic Envelope using a series of HP-Outer outside of the Cryptographic Envelope using a series of HP-Outer
Header Fields within the Cryptographic Payload. These HP-Outer MIME Header Fields within the Cryptographic Payload. These HP-Outer MIME
Header Fields should only ever appear directly within the Header Header Fields should only ever appear directly within the Header
Section of the Cryptographic Payload of a Cryptographic Envelope Section of the Cryptographic Payload of a Cryptographic Envelope
offering confidentiality. They MUST be ignored for the purposes of offering confidentiality. They MUST be ignored for the purposes of
evaluating the message's Header Protection if they appear in other evaluating the message's Header Protection if they appear in other
places. places.
Each instance of HP-Outer contains a Non-Structural Header Field name Each instance of HP-Outer contains a Non-Structural Header Field name
and the value that this Header Field was set to within the outer and the value that this Header Field was set to within the
(unprotected) Header Section. The HP-Outer Header Field can appear (unprotected) Outer Header Section. The HP-Outer Header Field can
multiple times in the Header Section of a Cryptographic Payload. appear multiple times in the Header Section of a Cryptographic
Payload.
If a Non-Structural Header Field named Z is present in Header If a Non-Structural Header Field named Z is present in Header
Section of the Cryptographic Payload but doesn't appear in an HP- Section of the Cryptographic Payload but doesn't appear in an HP-
Outer Header Field value at all, then the sender is effectively Outer Header Field value at all, then the sender is effectively
asserting that every instance of Z was made confidential by removal asserting that every instance of Z was made confidential by removal
from the Outer Header Section. Specifically, it means that no Header from the Outer Header Section. Specifically, it means that no Header
Field Z was included on the outside of the message's Cryptographic Field Z was included on the outside of the message's Cryptographic
Envelope by the sender at the time the message was injected into the Envelope by the sender at the time the message was injected into the
mail system. mail system.
skipping to change at line 998 skipping to change at line 1011
return val_in return val_in
For alignment with common practice as well as the ABNF in For alignment with common practice as well as the ABNF in
Section 2.2.1 for HP-Outer, val_out MUST be one of the following: Section 2.2.1 for HP-Outer, val_out MUST be one of the following:
* identical to val_in, * identical to val_in,
* the special value null (meaning that the Header Field will be * the special value null (meaning that the Header Field will be
removed from the outside of the message), or removed from the outside of the message), or
* a sequence of whitespace (that is, space or tab) and printable * a sequence of printable 7-bit clean ASCII characters (of course,
7-bit clean ASCII characters (of course, non-ASCII text can be non-ASCII text can be encoded as ASCII using the encoded-word
encoded as ASCII using the encoded-word construct from [RFC2047]) construct from [RFC2047]) and ASCII whitespace (specifically,
space (0x20) and tab (0x09)).
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 addr-spec of From Header Field 3.1.1. HCP Avoids Changing addr-spec of From Header Field
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
skipping to change at line 1055 skipping to change at line 1069
from the Outer Header Section. from the Outer Header Section.
hcp_baseline(name, val_in) → val_out: hcp_baseline(name, val_in) → val_out:
if lower(name) is 'subject': if lower(name) is 'subject':
return '[...]' return '[...]'
else if lower(name) is in ['comments', 'keywords']: else if lower(name) is in ['comments', 'keywords']:
return null return null
else: else:
return val_in return val_in
hcp_baseline is the recommended default HCP for a new implementation, hcp_baseline is the recommended default HCP, as it provides
as it provides meaningful confidentiality protections and is unlikely meaningful confidentiality protections and is unlikely to cause
to cause deliverability or usability problems. deliverability or usability problems.
3.2.2. Shy Header Confidentiality Policy 3.2.2. Shy Header Confidentiality Policy
Alternately, a slightly more ambitious (and therefore more privacy- Alternately, a slightly more ambitious (and therefore more privacy-
preserving) HCP might avoid leaking human-interpretable data that preserving) HCP might avoid leaking human-interpretable data that
MTAs generally don't care about. The additional protected data isn't MTAs generally don't care about. The additional protected data isn't
related to message routing or transport but might reveal sensitive related to message routing or transport but might reveal sensitive
information about the sender or their relationship to the recipients. information about the sender or their relationship to the recipients.
This "shy" HCP builds on hcp_baseline but also: This "shy" HCP builds on hcp_baseline but also:
skipping to change at line 1094 skipping to change at line 1108
if lower(name) is 'date': if lower(name) is 'date':
if val_in is an RFC 5322 date-time: if val_in is an RFC 5322 date-time:
return the UTC form of val_in return the UTC form of val_in
else if lower(name) is 'subject': else if lower(name) is 'subject':
return '[...]' return '[...]'
else if lower(name) is in ['comments', 'keywords']: else if lower(name) is in ['comments', 'keywords']:
return null return null
return val_in return val_in
hcp_shy requires more sophisticated parsing and Header Field hcp_shy requires more sophisticated parsing and Header Field
manipulation and is not recommended as a default HCP for new manipulation and is not recommended as a default HCP.
implementations.
3.2.3. No Header Confidentiality Policy 3.2.3. No Header Confidentiality Policy
Legacy MUAs can be conceptualized as offering a "No Header Legacy MUAs can be conceptualized as offering a "No Header
Confidentiality" Policy, which offers no confidentiality protection Confidentiality" Policy, which offers no confidentiality protection
to any Header Field: to any Header Field:
hcp_no_confidentiality(name, val_in) → val_out: hcp_no_confidentiality(name, val_in) → val_out:
return val_in return val_in
skipping to change at line 1223 skipping to change at line 1236
to be added in transit and therefore are not expected to have to be added in transit and therefore are not expected to have
end-to-end cryptographic protections. end-to-end cryptographic protections.
* The MUA SHOULD include information in the message's Cryptographic * The MUA SHOULD include information in the message's Cryptographic
Summary to indicate the types of protection that applied to each Summary to indicate the types of protection that applied to each
rendered Header Field (if any). rendered Header Field (if any).
* If any Legacy Display Elements are present in the Body of the * If any Legacy Display Elements are present in the Body of the
message, it does not render them. message, it does not render them.
* When replying to a message with confidential Header Fields, the * When replying to (or forwarding) a message with confidential
replying MUA avoids leaking any Header Fields that were Header Fields, the replying (or forwarding) MUA avoids leaking any
confidential in the original into the cleartext of the reply. It Header Fields that were confidential in the original into the
does this even if its own HCP would not have treated those Header cleartext of the reply (or forwarded message). It does this even
Fields as confidential. See Section 6 for more details. if its own HCP would not have treated those Header Fields as
confidential. See Section 6 for more details.
Note that an MUA that handles a message with Header Protection does Note that an MUA that handles a message with Header Protection does
_not_ need to render any new Header Fields that it did not render _not_ need to render any new Header Fields that it did not render
before. before.
4.1. Identifying That a Message Has Header Protection 4.1. Identifying That a Message Has Header Protection
An incoming message can be identified as having Header Protection An incoming message can be identified as having Header Protection
using the following test: using the following test:
* The Cryptographic Payload has parameter hp set to "clear" or * The Cryptographic Payload has parameter hp set to "clear" or
"cipher". See Section 4.5 for rendering guidance. "cipher". See Section 4.5 for rendering guidance.
When consuming a message, an MUA MUST ignore the hp parameter to When consuming a message, an MUA MUST ignore the hp parameter to
Content-Type when it encounters it anywhere other than the root of Content-Type when it encounters it anywhere other than the root of
the message's Cryptographic Payload. the message's Cryptographic Payload.
4.2. Extracting Protected and Unprotected ("Outer") Header Fields 4.2. Extracting Protected Header Fields From an Encrypted Message
When a message is encrypted and uses Header Protection, an MUA When a message is encrypted and uses Header Protection, the receiving
extracts a list of protected Header Fields (names and values), as MUA extracts two lists of Header Fields (names and values):
well as a list of Header Fields that were added by the original
message sender in unprotected form to the outside of the message's
Cryptographic Envelope.
The following algorithm takes reference message refmsg as input, * The list of Header Fields that the sending MUA applied to the
protected message.
* Those Header Fields added by the sending MUA to the (unprotected)
Outer Header Section of the message, intended for interpretation
by MTAs and Legacy MUAs.
The following algorithm takes referenced message refmsg as input,
which is encrypted with Header Protection as described in this which is encrypted with Header Protection as described in this
document (that is, the Cryptographic Envelope includes a document (that is, the Cryptographic Envelope includes a
Cryptographic Layer that provides encryption, and the hp parameter Cryptographic Layer that provides encryption, and the hp parameter
for the Content-Type Header Field of the Cryptographic Payload is for the Content-Type Header Field of the Cryptographic Payload is
cipher). It produces as output a pair of lists of (h,v) Header cipher). It produces as output a pair of lists of (h,v) Header
Fields. Fields.
4.2.1. HeaderSetsFromMessage 4.2.1. HeaderSetsFromMessage
Method signature: Method signature:
HeaderSetsFromMessage(refmsg) -> (refouter, refprotected) HeaderSetsFromMessage(refmsg) -> (refouter, refprotected)
Procedure: Procedure:
1. Let refheaders be the list of (h,v) protected Header Fields found 1. Let refheaders be the list of (h,v) protected Header Fields found
in the root of the Cryptographic Payload. in the root of the Cryptographic Payload of refmsg.
2. Let refouter be an empty list of Header Field names and values. 2. Let refouter be an empty list of Header Field names and values.
3. Let refprotected be an empty list of Header Field names and 3. Let refprotected be an empty list of Header Field names and
values. values.
4. For each (h,v) in refheaders: 4. For each (h,v) in refheaders:
i. If h is HP-Outer: i. If h is HP-Outer:
skipping to change at line 1292 skipping to change at line 1310
any amount of whitespace. any amount of whitespace.
b. Append (h1,v1) to refouter. b. Append (h1,v1) to refouter.
ii. Else: ii. Else:
a. Append (h,v) to refprotected. a. Append (h,v) to refprotected.
5. Return refouter, refprotected. 5. Return refouter, refprotected.
Note that this algorithm is independent of the unprotected Header Note that this algorithm is independent of the Outer Header Section.
Fields. It derives its output only from the normal Header Fields and It derives its output only from the normal Header Fields and the HP-
the HP-Outer Header Fields, both contained inside the Cryptographic Outer Header Fields, both contained inside the Cryptographic Payload.
Payload.
4.3. Updating the Cryptographic Summary 4.3. Updating the Cryptographic Summary
Regardless of whether a cryptographically protected message has Regardless of whether a cryptographically protected message has
protected Header Fields, the Cryptographic Summary of the message protected Header Fields, the Cryptographic Summary of the message
should be modified to indicate what protections the Header Fields should be modified to indicate what protections the Header Fields
have. This field-by-field status is complex and isn't necessarily have. This field-by-field status is complex and isn't necessarily
intended to be presented in full to the user. Rather, it represents intended to be presented in full to the user. Rather, it represents
the state of the message internally within the MUA and may be used to the state of the message internally within the MUA and may be used to
influence behavior like replying to the message (see Section 6.1). influence behavior like replying to or forwarding the message (see
Section 6.1).
Each Header Field individually has exactly one of the following Each Header Field individually has exactly one of the following
protection states: protection states:
* unprotected (has no Header Protection) * unprotected (has no Header Protection)
* signed-only (bound into the same validated signature as the * signed-only (bound into the same validated signature as the
enclosing message, but also visible in transit) enclosing message, but also visible in transit)
* encrypted-only (only appears within the Cryptographic Payload; the * encrypted-only (only appears within the Cryptographic Payload; the
skipping to change at line 1328 skipping to change at line 1346
* signed-and-encrypted (same as encrypted-only, but additionally is * signed-and-encrypted (same as encrypted-only, but additionally is
under a validated signature) under a validated signature)
If the message does not have Header Protection (as determined by If the message does not have Header Protection (as determined by
Section 4.1), then all of the Header Fields are by definition Section 4.1), then all of the Header Fields are by definition
unprotected. unprotected.
If the message has Header Protection, an MUA SHOULD use the following If the message has Header Protection, an MUA SHOULD use the following
algorithm to compute the protection state of a protected Header Field algorithm to compute the protection state of a protected Header Field
(h,v) (that is, an element of refprotected from Section 4.2): (h,v):
4.3.1. HeaderFieldProtection 4.3.1. HeaderFieldProtection
Method signature: Method signature:
HeaderFieldProtection(msg, h, v) -> protection_state HeaderFieldProtection(msg, h, v) -> protection_state
Procedure: Procedure:
1. Let ct be the Content-Type of the root of the Cryptographic 1. Let ct be the Content-Type of the root of the Cryptographic
skipping to change at line 1370 skipping to change at line 1388
Note that: Note that:
* This algorithm is independent of the unprotected Header Fields. * This algorithm is independent of the unprotected Header Fields.
It derives the protection state only from (h,v) and the set of HP- It derives the protection state only from (h,v) and the set of HP-
Outer Header Fields, both of which are inside the Cryptographic Outer Header Fields, both of which are inside the Cryptographic
Envelope. Envelope.
* If the signature fails validation, the MUA lowers the affected * If the signature fails validation, the MUA lowers the affected
state to unprotected or encrypted-only without any additional state to unprotected or encrypted-only without any additional
warning to the user, as specified by Section 3.1 of [RFC9787]. warning to the user (see also Section 3.1 of [RFC9787]).
* Data from signed-and-encrypted and encrypted-only Header Fields * Data from signed-and-encrypted and encrypted-only Header Fields
may still not be fully private (see Section 11.2). may still not be fully private (see Section 11.2).
* Encryption may have been added in transit to an originally signed- * Encryption may have been added in transit to an originally signed-
only message. Thus, only consider Header Fields to be only message. Thus, only consider Header Fields to be
confidential if the sender indicates it with the hp="cipher" confidential if the sender indicates it with the hp="cipher"
parameter. parameter.
* The protection state of a Header Field may be weaker than that of * The protection state of a Header Field may be weaker than that of
the message Body. For example, a message Body can be signed-and- the message Body. For example, a message Body can be signed-and-
encrypted, but a Header Field that is copied unmodified to the encrypted, but a Header Field that is copied unmodified to the
Outer Header Section is signed-only. Outer Header Section is signed-only.
If the message has Header Protection, Header Fields that are not in If the message has Header Protection, the Header Fields that are not
refprotected (e.g., because they were added in transit) are in refprotected (e.g., because they were added in transit) are
unprotected. unprotected.
Rendering the cryptographic status of each Header Field is likely to Rendering the cryptographic status of each Header Field is likely to
be complex and messy -- users may not understand it. It is beyond be complex and messy -- users may not understand it. It is beyond
the scope of this document to suggest any specific graphical the scope of this document to suggest any specific graphical
affordances or user experience. Future work should include examples affordances or user experience. Future work should include examples
of successful rendering of this information. of successful rendering of this information.
4.4. Handling Mismatch of From Header Fields 4.4. Handling Mismatch of From Header Fields
skipping to change at line 1421 skipping to change at line 1439
4.4.1. Definitions 4.4.1. Definitions
4.4.1.1. From Header Field Mismatch 4.4.1.1. From Header Field Mismatch
"From Header Field Mismatch" is defined as follows: "From Header Field Mismatch" is defined as follows:
The addr-spec of the inner From Header Field doesn't match the addr- The addr-spec of the inner From Header Field doesn't match the addr-
spec of the outer From Header Field (see Section 4.4.5). spec of the outer From Header Field (see Section 4.4.5).
Note: The unprotected From Header Field used in this comparison is Note: The unprotected From Header Field used in this comparison is
the actual outer Header Field (as seen by the MTA), not the value the actual Header Field found in the Outer Header Section (as seen by
indicated by any potential inner HP-Outer. the MTA), not the value indicated by any potential inner HP-Outer
Header Field.
4.4.1.2. No Valid and Correctly Bound Signature 4.4.1.2. No Valid and Correctly Bound Signature
"No Valid and Correctly Bound Signature" is defined as follows: "No Valid and Correctly Bound Signature" is defined as follows:
There is no valid signature made by a certificate for which the MUA There is no valid signature made by a certificate for which the MUA
has a valid binding to the protected From address. This includes: has a valid binding to the protected From address. This includes:
* the message has no signature * the message has no signature
skipping to change at line 1466 skipping to change at line 1485
* No Valid and Correctly Bound Signature (as defined in * No Valid and Correctly Bound Signature (as defined in
Section 4.4.1.2) Section 4.4.1.2)
This warning should be comparable to the MUA's warning about messages This warning should be comparable to the MUA's warning about messages
that are likely spam or phishing, and it SHOULD show both of the non- that are likely spam or phishing, and it SHOULD show both of the non-
matching From Header Fields. matching From Header Fields.
4.4.3. From Header Field Rendering 4.4.3. From Header Field Rendering
Furthermore, a receiving MUA that depends on its MTA to authenticate Furthermore, a receiving MUA that depends on its MTA to authenticate
the unprotected (outer) From Header Field SHOULD render the outer the (unprotected) outer From Header Field SHOULD render the outer
From Header Field (as an exception to the guidance in the beginning From Header Field (as an exception to the guidance in the beginning
of Section 4) if both of the following conditions are met: of Section 4) if both of the following conditions are met:
* From Header Field Mismatch (as defined in Section 4.4.1.1) and * From Header Field Mismatch (as defined in Section 4.4.1.1) and
* No Valid and Correctly Bound Signature (as defined in * No Valid and Correctly Bound Signature (as defined in
Section 4.4.1.2) Section 4.4.1.2)
An MUA MAY apply a local preference to render a different display An MUA MAY apply a local preference to render a different display
name (e.g., from an address book). name (e.g., from an address book).
See Section 10.1.1 for a detailed explanation of this rendering See Section 10.1.1 for a detailed explanation of this rendering
guidance. guidance.
4.4.4. Handling the Protected From Header Field When Responding 4.4.4. Handling the Protected From Header Field When Responding
When responding to a message, an MUA has different ways to populate When responding to a message, an MUA has different ways to populate
the recipients of the new message. Depending on whether it is a the recipients of the new message. Depending on whether it is a
Reply, a Reply All, or a Forward, an MUA may populate the composer Reply, a Reply All, or a Forward, an MUA may populate the composer
view using a combination of the referenced message's From, To, Cc, view using a combination of the referenced message's From, To, Cc,
Reply-To, or Mail-Followup-To Header Fields or any other signals. Reply-To, or Mail-Followup-To Header Fields as well as any other
signals.
When responding to a message with Header Protection, an MUA MUST only When responding to a message with Header Protection, an MUA MUST only
use the protected Header Fields when populating the recipients of the use the protected Header Fields when populating the recipients of the
new message. new message.
This avoids compromise of message confidentiality when a machine-in- This avoids compromise of message confidentiality when a machine-in-
the-middle (MITM) attacker modifies the unprotected From address of the-middle (MITM) attacker modifies the unprotected From address of
an encrypted message, attempting to learn the contents through a an encrypted message, attempting to learn the contents through a
misdirected reply. Note that with the rendering guidance above, a misdirected reply. Note that with the rendering guidance above, a
MITM attacker can cause the unprotected From Header Field to be MITM attacker can cause the unprotected From Header Field to be
skipping to change at line 1533 skipping to change at line 1553
sophisticated and inclusive matching algorithm. sophisticated and inclusive matching algorithm.
It is beyond the scope of this document to recommend a more It is beyond the scope of this document to recommend a more
sophisticated and inclusive matching algorithm. sophisticated and inclusive matching algorithm.
4.5. Rendering a Message with Header Protection 4.5. Rendering a Message with Header Protection
When the Cryptographic Payload's Content-Type has the parameter hp When the Cryptographic Payload's Content-Type has the parameter hp
set to "clear" or "cipher", the values of the protected Header Fields set to "clear" or "cipher", the values of the protected Header Fields
are drawn from the Header Fields of the Cryptographic Payload, and are drawn from the Header Fields of the Cryptographic Payload, and
the Body that is rendered is the Cryptographic Payload itself. the Body that is rendered is the content of the Cryptographic Payload
itself.
4.5.1. Example Signed-Only Message 4.5.1. Example Signed-Only Message
Consider a message with this structure, where the MUA is able to Consider a message with this structure, where the MUA is able to
validate the cryptographic signature: validate the cryptographic signature:
A └─╴application/pkcs7-mime; smime-type="signed-data" A └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to) ⇩ (unwraps to)
B └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] B └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
C ├─╴text/plain C ├─╴text/plain
skipping to change at line 1588 skipping to change at line 1609
G └┬╴multipart/alternative G └┬╴multipart/alternative
H ├─╴text/plain H ├─╴text/plain
I └─╴text/html I └─╴text/html
It should render Header Fields taken from part G. It should render Header Fields taken from part G.
Its Cryptographic Summary should indicate that the message is signed- Its Cryptographic Summary should indicate that the message is signed-
and-encrypted. and-encrypted.
When rendering the Cryptographic Status of a Header Field and when When rendering the Cryptographic Status of a Header Field and when
composing a reply, each Header Field found in G should be considered composing a reply (or forward), each Header Field found in G should
against all HP-Outer Header Fields found in G. If an HP-Outer Header be considered against all HP-Outer Header Fields found in G. If an
Field that matches both the name and value is found, the Header HP-Outer Header Field that matches both the name and value is found,
Field's Cryptographic Status is just signed-only, even though the the Header Field's Cryptographic Status is just signed-only, even
message itself is signed-and-encrypted. If no matching HP-Outer though the message itself is signed-and-encrypted. If no matching
Header Field is found, the Header Field's Cryptographic Status is HP-Outer Header Field is found, the Header Field's Cryptographic
signed-and-encrypted, like the rest of the message. Status is signed-and-encrypted, like the rest of the message (see
Section 4.3).
If any of the User-Facing Header Fields are removed or obscured, the If any of the User-Facing Header Fields are removed or obscured, the
composer of this message may have placed Legacy Display Elements in composer of this message may have placed Legacy Display Elements in
parts H and I. parts H and I.
The MUA should ignore Header Fields from part E for the purposes of The MUA should ignore Header Fields from part E for the purposes of
rendering. rendering.
4.5.3. Do Not Render Legacy Display Elements 4.5.3. Do Not Render Legacy Display Elements
skipping to change at line 1618 skipping to change at line 1640
Elements are strictly decorative and unambiguously identifiable and Elements are strictly decorative and unambiguously identifiable and
will be discarded by compliant implementations. will be discarded by compliant implementations.
The receiving MUA MUST completely avoid rendering the identified The receiving MUA MUST completely avoid rendering the identified
Legacy Display Elements to the user, since it is aware of Header Legacy Display Elements to the user, since it is aware of Header
Protection and can render the actual protected Header Fields. Protection and can render the actual protected Header Fields.
If a text/html or text/plain part within the Cryptographic Envelope If a text/html or text/plain part within the Cryptographic Envelope
is identified as containing Legacy Display Elements, those elements is identified as containing Legacy Display Elements, those elements
MUST be hidden when rendering and MUST be dropped when generating a MUST be hidden when rendering and MUST be dropped when generating a
draft reply or inline forwarded message. Whenever a Message or MIME draft reply or inline forwarded message. Whenever a message or a
subtree is exported, downloaded, or otherwise further processed, if MIME subtree is exported, downloaded, or otherwise further processed,
there is no need to retain a valid cryptographic signature, the if there is no need to retain a valid cryptographic signature, the
implementer MAY drop the Legacy Display Elements. implementer MAY drop the Legacy Display Elements.
4.5.3.1. Identifying a Part with Legacy Display Elements 4.5.3.1. Identifying a Part with Legacy Display Elements
A receiving MUA acting on a message that contains an encrypting A receiving MUA acting on a message that contains an encrypting
Cryptographic Layer identifies a MIME subpart within the Cryptographic Layer identifies a MIME subpart within the
Cryptographic Payload as containing Legacy Display Elements based on Cryptographic Payload as containing Legacy Display Elements based on
the Content-Type of the subpart. The subpart's Content-Type: the Content-Type of the subpart. The subpart's Content-Type:
* contains a parameter hp-legacy-display with value set to 1 and * contains a parameter hp-legacy-display with value set to 1 and
* is either text/html (see Section 4.5.3.3) or text/plain (see * is either text/plain (see Section 4.5.3.2) or text/html (see
Section 4.5.3.2). Section 4.5.3.3).
Note that the term "subpart" above is used in the general sense: If Note that the term "subpart" above is used in the general sense: If
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
skipping to change at line 1839 skipping to change at line 1861
4.10. Handling RFC8551HP Messages (Backward Compatibility) 4.10. Handling RFC8551HP Messages (Backward Compatibility)
Section 1.1.1 describes some drawbacks to the Header Protection Section 1.1.1 describes some drawbacks to the Header Protection
scheme defined in [RFC8551], referred to here as RFC8551HP. An MUA scheme defined in [RFC8551], referred to here as RFC8551HP. An MUA
MUST NOT generate an RFC8551HP message. However, for backward MUST NOT generate an RFC8551HP message. However, for backward
compatibility, an MUA MAY try to render or respond to such a message compatibility, an MUA MAY try to render or respond to such a message
as though the message has standard Header Protection. as though the message has standard Header Protection.
The following two sections contain guidance for identifying, The following two sections contain guidance for identifying,
rendering, and replying to RFC8551HP messages. Corresponding test rendering, replying to, and forwarding RFC8551HP messages.
vectors are provided in Appendices C.2.5, C.2.6, and C.3.17. Corresponding test vectors are provided in Appendices C.2.5, C.2.6,
and C.3.17.
4.10.1. Identifying an RFC8551HP Message 4.10.1. Identifying an RFC8551HP Message
An RFC8551HP message can be identified by its MIME structure, given An RFC8551HP message can be identified by its MIME structure, given
that all of the following conditions are met: that all of the following conditions are met:
* It has a well-formed Cryptographic Envelope consisting of at least * It has a well-formed Cryptographic Envelope consisting of at least
one Cryptographic Layer as the outermost MIME object. one Cryptographic Layer as the outermost MIME object.
* The Cryptographic Payload is a single message/rfc822 object. * The Cryptographic Payload is a single message/rfc822 object.
skipping to change at line 1909 skipping to change at line 1932
Cryptographic Payload (part C), but they should instead look at Cryptographic Payload (part C), but they should instead look at
the Cryptographic Payload's immediate child (part D). the Cryptographic Payload's immediate child (part D).
* If the Cryptographic Envelope is signed-only, behave as though * If the Cryptographic Envelope is signed-only, behave as though
there is an hp="clear" parameter for the Cryptographic Payload; if there is an hp="clear" parameter for the Cryptographic Payload; if
the Envelope contains encryption, behave as though there is an the Envelope contains encryption, behave as though there is an
hp="cipher" parameter. That is, infer the sender's cryptographic hp="cipher" parameter. That is, infer the sender's cryptographic
intent from the structure of the message. intent from the structure of the message.
* If the Cryptographic Envelope contains encryption, further modify * If the Cryptographic Envelope contains encryption, further modify
HeaderSetsFromMessage to derive refouter from the actual outer HeaderSetsFromMessage to derive refouter from the actual Outer
message Header Fields (those found in part A in the example above) Header Section (those Header Fields found in part A in the example
rather than looking for HP-Outer Header Fields with the other above) rather than looking for HP-Outer Header Fields with the
protected Header Fields. That is, infer Header Field other protected Header Fields. That is, infer Header Field
confidentiality based on the unprotected Header Fields. confidentiality based on the unprotected Header Fields.
The inferences in the above modifications are not based on any strong The inferences in the above modifications are not based on any strong
end-to-end guarantees. An intervening MTA may tamper with the end-to-end guarantees. An intervening MTA may tamper with the
message's Outer Header Section or wrap the message in an encryption message's Outer Header Section or wrap the message in an encryption
layer to undetectably change the recipient's understanding of the layer to undetectably change the recipient's understanding of the
confidentiality of the message's Header Fields or the message Body confidentiality of the message's Header Fields or the message Body
itself. itself.
4.11. Rendering Other Schemes 4.11. Rendering Other Schemes
skipping to change at line 2008 skipping to change at line 2031
5.2. Composing a Message with Header Protection 5.2. Composing a Message with Header Protection
To compose a message using Header Protection, the composing MUA uses To compose a message using Header Protection, the composing MUA uses
the following inputs: the following inputs:
* all the inputs described in Section 5.1 * all the inputs described in Section 5.1
* hcp: an HCP, as defined in Section 3 * hcp: an HCP, as defined in Section 3
* respond: if the new message is a response to another message * respond: if the new message is a response to another message, the
(e.g., "Reply", "Reply All", "Forward", etc.), the MUA function MUA's Respond Function corresponding to the user's action (see
corresponding to the user's action (see Section 6.1), otherwise Section 6.1.1), otherwise null
null
* refmsg: if the new message is a response to another message, the * refmsg: if the new message is a response to another message, the
message being responded to, otherwise null message being responded to, otherwise null
* legacy: a boolean value, indicating whether any recipient of the * legacy: a boolean value, indicating whether any recipient of the
message is believed to have a Legacy MUA. If all recipients are message is believed to have a Legacy MUA. If all recipients are
known to implement this document, legacy should be set to false. known to implement this document, legacy should be set to false.
(How an MUA determines the value of legacy is out of scope for (How an MUA determines the value of legacy is out of scope for
this document; an initial implementation can simply set it to this document; an initial implementation can simply set it to
true.) true.)
To enable visibility of User-Facing but now removed/obscured Header To enable visibility of User-Facing but now removed/obscured Header
Fields for decryption-capable Legacy MUAs, the Header Fields are Fields for decryption-capable Legacy MUAs, the Header Fields are
included as a decorative Legacy Display Element in specially marked included as a decorative Legacy Display Element in specially marked
parts of the message (see Section 2.1.2). This document recommends parts of the message (see Section 2.1.2). This document recommends
two mechanisms for such a decorative adjustment: one for a text/html two mechanisms for such a decorative adjustment: one for a text/plain
Main Body Part of the email message and one for a text/plain Main Main Body Part (see Section 5.2.2) and one for a text/html Main Body
Body Part. This document does not recommend adding a Legacy Display Part (see Section 5.2.3) of the email message. This document does
Element to any other part. not recommend adding a Legacy Display Element to any other part.
Please see Section 7.1 of [RFC9787] for guidance on identifying the Please see Section 7.1 of [RFC9787] for guidance on identifying the
parts of a message that are a Main Body Part. parts of a message that are a Main Body Part.
5.2.1. Compose 5.2.1. Compose
Method signature: Method signature:
Compose(origbody, origheaders, crypto, hcp, respond, refmsg, legacy) Compose(origbody, origheaders, crypto, hcp, respond, refmsg, legacy)
-> mime_message -> mime_message
skipping to change at line 2088 skipping to change at line 2110
i. Set the hp parameter on the Content-Type of MIME part i. Set the hp parameter on the Content-Type of MIME part
newbody to clear. newbody to clear.
ii. Let newheaders be a copy of origheaders. ii. Let newheaders be a copy of origheaders.
5. Else (if crypto contains encryption): 5. Else (if crypto contains encryption):
i. Set the hp parameter on the Content-Type of MIME part i. Set the hp parameter on the Content-Type of MIME part
newbody to cipher. newbody to cipher.
ii. If refmsg is not null, respond is not null, and refmsg ii. Let response_hcp be an ephemeral HCP, the output of
itself is encrypted with Header Protection: ReferenceHCP(refmsg, respond) (see Section 6.1.2).
a. Let response_hcp be a single-use HCP derived from
respond and refmsg (see Section 6.1).
iii. Else (if this is not a response to an encrypted, header-
protected message):
a. Set response_hcp to hcp_no_confidentiality.
iv. Create a new empty list of Header Field names and values iii. Create a new empty list of Header Field names and values
newheaders. newheaders.
v. For each Header Field name and value (h,v) in origheaders: iv. For each Header Field name and value (h,v) in origheaders:
a. Let newval be hcp(h,v). a. Let newval be hcp(h,v).
b. If newval is v: b. If newval is v:
I. Let newval be response_hcp(h,v). I. Let newval be response_hcp(h,v).
c. If newval is not null: c. If newval is not null:
I. Add (h,newval) to newheaders. I. Add (h,newval) to newheaders.
vi. For each Header Field name and value (h,v) in newheaders: v. For each Header Field name and value (h,v) in newheaders:
a. Let string record be the concatenation of h, a literal a. Let string record be the concatenation of h, a literal
": " (ASCII colon (0x3A) followed by ASCII space ": " (ASCII colon (0x3A) followed by ASCII space
(0x20)), and v. (0x20)), and v.
b. Add Header Field "HP-Outer" to MIME part newbody with b. Add Header Field "HP-Outer" to MIME part newbody with
value record. value record.
6. Apply crypto to MIME part newbody, producing MIME tree output. 6. Apply crypto to MIME part newbody, producing MIME tree output.
skipping to change at line 2171 skipping to change at line 2185
Cc: alice@example.net Cc: alice@example.net
I think we should skip the meeting. I think we should skip the meeting.
Note that the Legacy Display Element (the lines beginning with Note that the Legacy Display Element (the lines beginning with
Subject: and Cc:) is part of the content of the MIME part in Subject: and Cc:) is part of the content of the MIME part in
question. question.
This example assumes that the Main Body Part in question is not the This example assumes that the Main Body Part in question is not the
root of the Cryptographic Payload. For instance, it could be a leaf root of the Cryptographic Payload. For instance, it could be a leaf
of a multipart/alternative Cryptographic Payload. This is why no of a multipart/alternative Cryptographic Payload. This is why there
additional Header Fields have been injected into the MIME part in are no additional Header Fields in the MIME part of this example.
this example.
5.2.3. Adding a Legacy Display Element to a text/html Part 5.2.3. Adding a Legacy Display Element to a text/html Part
Adding a Legacy Display Element to a text/html part is similar to how Adding a Legacy Display Element to a text/html part is similar to how
it is added to a text/plain part (see Section 5.2.2). Instead of it is added to a text/plain part (see Section 5.2.2). Instead of
adding the obscured or removed User-Facing Header Fields to a block adding the obscured or removed User-Facing Header Fields to a block
of text delimited by a blank line, the composing MUA injects them in of text delimited by a blank line, the composing MUA injects them in
an HTML <div> element annotated with a class attribute of header- an HTML <div> element annotated with a class attribute of header-
protection-legacy-display. protection-legacy-display.
skipping to change at line 2222 skipping to change at line 2235
<html><head><title></title></head><body> <html><head><title></title></head><body>
<div class="header-protection-legacy-display"> <div class="header-protection-legacy-display">
<pre>Subject: Thursday's meeting <pre>Subject: Thursday's meeting
Cc: alice@example.net</pre></div> Cc: alice@example.net</pre></div>
<p>I think we should skip the meeting.</p> <p>I think we should skip the meeting.</p>
</body></html> </body></html>
This example assumes that the Main Body Part in question is not the This example assumes that the Main Body Part in question is not the
root of the Cryptographic Payload. For instance, it could be a leaf root of the Cryptographic Payload. For instance, it could be a leaf
of a multipart/alternative Cryptographic Payload. This is why no of a multipart/alternative Cryptographic Payload. This is why there
additional Header Fields have been injected into the MIME part in are no additional Header Fields in the MIME part of this example.
this example.
5.2.3.1. Step-by-Step Example for Inserting a Legacy Display Element 5.2.3.1. Step-by-Step Example for Inserting a Legacy Display Element
into text/html into text/html
A composing MUA MAY insert the Legacy Display Element anywhere A composing MUA MAY insert the Legacy Display Element anywhere
reasonable within the message as long as it prioritizes visibility reasonable within the message as long as it prioritizes visibility
for the reader using a Legacy MUA that is capable of decryption. for the reader using a Legacy MUA that is capable of decryption.
This decision may take into account special message-specific HTML This decision may take into account special message-specific HTML
formatting expectations if the MUA is aware of them. However, some formatting expectations if the MUA is aware of them. However, some
MUAs may not have any special insight into the user's preferred HTML MUAs may not have any special insight into the user's preferred HTML
skipping to change at line 2309 skipping to change at line 2321
Fields and leaking the entire message by sending the reply or forward Fields and leaking the entire message by sending the reply or forward
to the wrong party. to the wrong party.
6.1. Avoid Leaking Encrypted Header Fields in Replies and Forwards 6.1. Avoid Leaking Encrypted Header Fields in Replies and Forwards
As noted in Section 5.4 of [RFC9787], an MUA in this position MUST As noted in Section 5.4 of [RFC9787], an MUA in this position MUST
NOT leak previously encrypted content in the clear in a follow-up NOT leak previously encrypted content in the clear in a follow-up
message. The same is true for protected Header Fields. message. The same is true for protected Header Fields.
Values from any Header Field that was identified as either encrypted- Values from any Header Field that was identified as either encrypted-
only or signed-and-encrypted based on the steps outlined above MUST only or signed-and-encrypted based on the steps outlined in
NOT be placed in cleartext output when generating a message. Section 4.3 MUST NOT be sent in cleartext in a reply or forwarded
message.
In particular, if Subject was encrypted, and it is copied into the For example, if Subject was encrypted, and it is copied into the
draft encrypted reply, the replying MUA MUST obscure the unprotected draft encrypted reply's Subject, the replying MUA will automatically
(cleartext) Subject Header Field. obscure the reply's Subject Header Field.
When crafting the Header Fields for a reply or forwarded message, the When crafting the Header Fields for a reply or forwarded message, the
composing MUA SHOULD make use of the HP-Outer Header Fields from composing MUA SHOULD make use of the HP-Outer Header Fields from
within the Cryptographic Envelope of the reference message to ensure within the Cryptographic Envelope of the referenced message to ensure
that Header Fields derived from the reference message do not leak in that Header Fields derived from the referenced message do not leak in
the reply. the reply or forwarded message.
On a high level, this can be achieved as follows: Consider a Header On a high level, this can be achieved as follows: Consider a Header
Field in a reply message that is generated by derivation from a Field in a reply message that is generated by derivation from a
Header Field in the reference message. For example, the To Header Header Field in the referenced message. For example, the To Header
Field is typically derived from the reference message's Reply-To or Field is typically derived from the referenced message's Reply-To or
From Header Fields. When generating the outer copy of the Header From Header Fields. When generating this Header Field for the Outer
Field, the composing MUA first applies its own HCP. If the Header Header Section, the composing MUA first applies its own HCP. If the
Field's value is changed by the HCP, then it is applied to the Outer Header Field's value is changed by that HCP, then the resulting value
Header Section. If the Header Field's value is unchanged, the is used for the Outer Header Section. If the Header Field's value is
composing MUA re-generates the Header Field using the Header Fields unchanged, the composing MUA re-generates the Header Field using the
that had been on the outside of the original message at sending time. Header Fields that had been in the Outer Header Section of the
These can be inferred from the HP-Outer Header Fields located within original message at sending time. These are inferred from the HP-
the Cryptographic Payload of the referenced message. If that value Outer Header Fields located within the Cryptographic Payload of the
is itself different than the protected value, then it is applied to referenced message. If the value is itself different than the
the Outer Header Section. If the value is the same as the protected protected value, then it is applied to the Outer Header Section. If
value, then it is simply copied to the Outer Header Section directly. the value is the same as the protected value, then it is simply
Whether it was changed or not, it is noted in the protected Header copied to the Outer Header Section directly. As long as the
Section using HP-Outer, as described in Section 2.2.1. resulting value is not null, it is noted (whether identical to the
protected value or not) in the protected Header Section using HP-
Outer, as described in Section 2.2.1.
See Appendix D.2 for a simple worked example of this process. See Appendix D.2 for a simple worked example of this process.
Below we describe a supporting algorithm to handle this. It produces Below we describe a supporting algorithm to handle this. It produces
a list of Header Fields that should be obscured or removed in the new a list of Header Fields that should be obscured or removed in the new
message even if the sender's choice of HCP wouldn't normally remove message even if the sender's choice of HCP wouldn't normally remove
or obscure the Header Field in question. This is effectively a or obscure the Header Field in question. This is effectively a
single-use HCP. The normal sending guidance in Section 5.2 applies single-use HCP. The normal sending guidance in Section 5.2 applies
this single-use HCP to implement the high-level guidance above. this single-use HCP to implement the high-level guidance above.
6.1.1. ReferenceHCP 6.1.1. The Respond Function
The mechanism described below depends on an abstraction referred to
in this document as a Respond Function.
The Respond Function takes a list of Header Fields from a referenced
message as input and generates a list of initial candidate message
Header Field names and values that are used to populate the message
composition interface.
Something like this function already exists in most MUAs, though it
may differ across responsive actions. For example, the Respond
Function that implements "Reply All" is likely to be different from
the Respond Function that implements "Reply", which is in turn
different from the Respond Function that implements "Forward".
6.1.2. ReferenceHCP
The algorithm takes two inputs: The algorithm takes two inputs:
* A single referenced message refmsg * refmsg: a single referenced message
* A built-in MUA respond function associated with the user's action. * respond: the MUA's Respond Function associated with the user's
The respond function takes a list of Header Fields from a action (see Section 6.1.1)
referenced message as input and generates a list of initial
candidate message Header Field names and values that are used to
populate the message composition interface. Something like this
function already exists in most MUAs, though it may differ across
responsive actions. For example, the respond function that
implements "Reply All" is likely to be a different from the
respond function that implements "Reply".
As an output, it produces an ephemeral single-use HCP, specific to As an output, it produces an ephemeral single-use HCP, specific to
this kind of response to this specific message. this kind of response to this specific message.
Method signature: Method signature:
ReferenceHCP(refmsg, respond) -> ephemeral_hcp ReferenceHCP(refmsg, respond) -> response_hcp
Procedure: Procedure:
1. If refmsg is not encrypted with Header Protection: 1. If respond is null, refmsg is null, or refmsg is not encrypted
with Header Protection:
i. Return hcp_no_confidentiality (there is no header i. Return hcp_no_confidentiality (there is no header
confidentiality in the reference message that needs confidentiality in any referenced message that needs
protection). protection).
2. Extract refouter, refprotected from refmsg as described in 2. Extract refouter, refprotected from refmsg as described in
Section 4.2. Section 4.2.
3. Let genprotected be a list of (h,v) pairs generated by 3. Let genprotected be a list of (h,v) pairs generated by
respond(refprotected). respond(refprotected).
4. Let genouter be a list of (h,v) pairs generated by 4. Let genouter be a list of (h,v) pairs generated by
respond(refouter). respond(refouter).
skipping to change at line 2416 skipping to change at line 2441
a. If h1 is h: a. If h1 is h:
I. Set result to v1. I. Set result to v1.
iii. Insert (h,v) -> result into confmap. iii. Insert (h,v) -> result into confmap.
8. Return a new HCP from confmap that tests whether the 8. Return a new HCP from confmap that tests whether the
(name,val_in) tuple is in confmap; if so, return (name,val_in) tuple is in confmap; if so, return
confmap[(name,val_in)]; otherwise, return val_in. confmap[(name,val_in)]; otherwise, return val_in.
Note that the key idea here is to reuse the MUA's existing respond Note that the key idea here is to reuse the MUA's existing Respond
function. The algorithm simulates how the MUA would pre-populate a Function. The algorithm simulates how the MUA would pre-populate a
reply to two messages whose Header Fields have the values refouter reply to (or forward of) two messages whose Header Fields have the
and refprotected, respectively (independent of any cryptographic values refouter and refprotected, respectively (independent of any
protections). Then, it uses the difference to derive a one-time HCP. cryptographic protections). Then, it uses the difference to derive a
This HCP takes into account both the referenced message's sender's one-time HCP. This HCP takes into account both the referenced
preferences and the derivations that can happen to Header Field message's sender's preferences and the derivations that can happen to
values when responding. Note that while some of these derivations Header Field values when responding. Note that while some of these
are straightforward (e.g., In-Reply-To is usually derived from derivations are straightforward (e.g., In-Reply-To is usually derived
Message-ID), others are non-trivial. For example, the From address from Message-ID), others are non-trivial. For example, the From
may be derived from To, Cc, or the MUA's local address preference address may be derived from To, Cc, or the MUA's local address
(especially when the MUA received the referenced message via Bcc). preference (especially when the MUA received the referenced message
Similarly, To may be derived from To, From, and/or Cc Header Fields via Bcc). Similarly, To may be derived from To, From, and/or Cc
depending on the MUA implementation and depending on whether the user Header Fields depending on the MUA implementation and depending on
clicked "Reply", "Reply All", "Forward", or any other action that whether the user clicked "Reply", "Reply All", "Forward", or any
generates a response to a message. Reusing the MUA's existing other action that generates a response to a message. Reusing the
respond function incorporates these nuances without requiring any MUA's existing Respond Function incorporates these nuances without
extra configuration choices or additional maintenance burden. requiring any extra configuration choices or additional maintenance
burden.
6.2. Avoid Misdirected Replies 6.2. Avoid Misdirected Replies
When replying to a message, the composing MUA typically decides who When replying to a message, the composing MUA typically decides who
to send the reply to based on: to send the reply to based on:
* the Reply-To, Mail-Followup-To, or From Header Fields * the Reply-To, Mail-Followup-To, or From Header Fields
* optionally, the other To or Cc Header Fields (if the user chose to * optionally, the other To or Cc Header Fields (if the user chose to
"Reply All") "Reply All")
When a message has Header Protection, the replying MUA MUST populate When a message has Header Protection, the replying MUA MUST populate
the destination fields of the draft message using the protected the destination fields of the draft message using the protected
Header Fields and ignore any unprotected Header Fields. Header Fields and ignore any unprotected Header Fields.
This mitigates against an attack where Mallory gets a copy of an This mitigates against an attack where Mallory gets a copy of an
encrypted message from Alice to Bob and then replays the message to encrypted message from Alice to Bob and then replays the message to
Bob with an additional Cc to Mallory's own email address in the Bob with an additional Cc to Mallory's own email address in the
message's outer (unprotected) Header Section. message's (unprotected) Outer Header Section.
If Bob knows Mallory's certificate already, and he replies to such a If Bob knows Mallory's certificate already, and he replies to such a
message without following the guidance in this section, it's likely message without following the guidance in this section, it's likely
that his MUA will encrypt the cleartext of the message directly to that his MUA will encrypt the cleartext of the message directly to
Mallory. Mallory.
7. Unprotected Header Fields Added in Transit 7. Unprotected Header Fields Added in Transit
Some Header Fields are legitimately added in transit and could not Some Header Fields are legitimately added in transit and could not
have been known to the sender at message composition time. have been known to the sender at message composition time.
skipping to change at line 2487 skipping to change at line 2513
from the Outer Header Section, even though the message has Header from the Outer Header Section, even though the message has Header
Protection. Protection.
The MUA MAY prefer to verify that the Header Fields in question have The MUA MAY prefer to verify that the Header Fields in question have
additional transit-derived cryptographic protections before rendering additional transit-derived cryptographic protections before rendering
or acting on them. For example, the MUA could verify whether these or acting on them. For example, the MUA could verify whether these
Header Fields are covered by an appropriate and valid ARC- Header Fields are covered by an appropriate and valid ARC-
Authentication-Results (see [RFC8617]) or DKIM-Signature (see Authentication-Results (see [RFC8617]) or DKIM-Signature (see
[RFC6376]) Header Field. [RFC6376]) Header Field.
Specific examples of Header Fields that are meaningful to the user Specific examples of Header Fields added in transit that are
and are commonly added by MTAs appear below. meaningful to the user can be found in the following section.
7.1. Mailing List Header Fields: List-* and Archived-At 7.1. Mailing List Header Fields: List-* and Archived-At
If the message arrives through a mailing list, the list manager If the message arrives through a mailing list, the list manager
itself may inject Header Fields (most have a List- prefix) in the itself may inject Header Fields (most have a List- prefix) in the
message: message. Header Fields commonly added by list managers include:
* List-Archive * List-Archive
* List-Subscribe * List-Subscribe
* List-Unsubscribe * List-Unsubscribe
* List-Id * List-Id
* List-Help * List-Help
* List-Post * List-Post
* Archived-At * Archived-At
For some MUAs, these Header Fields are implicitly rendered by Some MUAs render these Header Fields implicitly by providing buttons
providing buttons for actions like "Subscribe", "View Archived for actions like "Subscribe", "View Archived Version", "Reply List",
Version", "Reply List", "List Info", etc. "List Info", etc.
An MUA that receives a message with Header Protection that contains An MUA that receives a message with Header Protection that contains
these Header Fields in the Outer Header Section and that has reason any of these Header Fields in the Outer Header Section and that has
to believe the message is coming through a mailing list MAY decide to reason to believe the message is coming through a mailing list MAY
render them to the user (explicitly or implicitly) even though they decide to render them to the user (explicitly or implicitly) even
are not protected. though they are not protected.
8. Email Ecosystem Evolution 8. Email Ecosystem Evolution
The email ecosystem is the set of client-side and server-side The email ecosystem is the set of client-side and server-side
software and policies that are used in the creation, transmission, software and policies that are used in the creation, transmission,
storage, rendering, and indexing of email over the Internet. storage, rendering, and indexing of email over the Internet.
This document is intended to offer tooling needed to improve the This document is intended to offer tooling needed to improve the
state of the email ecosystem in a way that can be deployed without state of the email ecosystem in a way that can be deployed without
significant disruption. Some elements of this specification are significant disruption. Some elements of this specification are
skipping to change at line 2573 skipping to change at line 2599
This document defines a few different forms of HCP. An MUA This document defines a few different forms of HCP. An MUA
implementing an HCP for the first time SHOULD deploy hcp_baseline as implementing an HCP for the first time SHOULD deploy hcp_baseline as
recommended in Section 3.3. This HCP offers the most commonly recommended in Section 3.3. This HCP offers the most commonly
expected protection (obscuring the Subject Header Field) without expected protection (obscuring the Subject Header Field) without
risking deliverability or rendering issues. risking deliverability or rendering issues.
The HCPs proposed in this document are relatively conservative and The HCPs proposed in this document are relatively conservative and
still leak a significant amount of metadata for encrypted messages. still leak a significant amount of metadata for encrypted messages.
This is largely done to ensure deliverability (see Section 1.3.2) and This is largely done to ensure deliverability (see Section 1.3.2) and
usability, as messages without some critical Header Fields are more usability (see Section 2 of [RFC9787] and Section 9), as messages
likely to not reach their intended recipient. without some critical Header Fields are more likely to not reach
their intended recipient.
In the future, some mail transport systems may accept and deliver In the future, some mail transport systems may accept and deliver
messages with even less publicly visible metadata. Many MTA messages with even less publicly visible metadata. Many MTA
operators today would ask for additional guarantees about such a operators today would ask for additional guarantees about such a
message to limit the risks associated with abusive or spam mail. message to limit the risks associated with abusive or spam mail.
This specification offers the HCP formalism itself as a way for MUA This specification offers the HCP formalism itself as a way for MUA
developers and MTA operators to describe their expectations around developers and MTA operators to describe their expectations around
message deliverability. MUA developers can propose a more ambitious message deliverability. MUA developers can propose a more ambitious
default HCP and ask MTA operators (or simply test) whether their MTAs default HCP and ask MTA operators (or simply test) whether their MTAs
skipping to change at line 2723 skipping to change at line 2750
and integrity. and integrity.
Nevertheless, helping the user distinguish between cryptographic Nevertheless, helping the user distinguish between cryptographic
protections of various messages remains a security challenge for protections of various messages remains a security challenge for
MUAs. This is exacerbated by the fact that many existing messages MUAs. This is exacerbated by the fact that many existing messages
with cryptographic protections do not employ Header Protection. MUAs with cryptographic protections do not employ Header Protection. MUAs
encountering these messages (e.g., in an archive) will need to handle encountering these messages (e.g., in an archive) will need to handle
older forms (without Header Protection) for quite some time, possibly older forms (without Header Protection) for quite some time, possibly
forever. forever.
The security considerations from Section 6 of [RFC8551] continue to For any MUA that offers S/MIME cryptographic protections, the
apply for any MUA that offers S/MIME cryptographic protections, as security considerations from Section 6 of [RFC8551] (S/MIME),
well as Section 3 of [RFC5083] (Authenticated-Enveloped-Data in Section 3 of [RFC5083] (Authenticated-Enveloped-Data in Cryptographic
Cryptographic Message Syntax (CMS)) and Section 14 of [RFC5652] (CMS Message Syntax (CMS)), and Section 14 of [RFC5652] (CMS more broadly)
more broadly). Likewise, the security considerations from Section 8 continue to apply. Likewise, for any MUA that offers PGP/MIME
of [RFC3156] continue to apply for any MUA that offers PGP/MIME cryptographic protections, the security considerations from Section 8
cryptographic protections, as well as Section 13 of [RFC9580] of [RFC3156] (PGP with MIME) as well as Section 13 of [RFC9580]
(OpenPGP itself). In addition, these underlying security (OpenPGP itself) continue to apply. In addition, these underlying
considerations are now also applicable to the contents of the message security considerations are now also applicable to the contents of
Header Section, not just the message Body. the message Header Section, not just the message Body.
10.1. From Address Spoofing 10.1. From Address Spoofing
If the From Header Field were treated like any other protected Header For a receiving MUA that depends on its MTA to authenticate the
Field by the receiving MUA, this scheme would enable sender address origin of the message, applying this specification could enable
spoofing. sender address spoofing.
To prevent sender spoofing, many receiving MUAs implicitly rely on To prevent sender spoofing, many receiving MUAs implicitly rely on
their receiving MTA to inspect the Outer Header Section and verify their receiving MTA to inspect the Outer Header Section and verify
that the From Header Field is authentic. If a receiving MUA displays that the From Header Field is authentic. If a receiving MUA displays
a From address that doesn't match the From address that the receiving a From address (from the protected part) that doesn't match the From
and/or sending MTAs filtered on, the MUA may be vulnerable to address the MTA used to authenticate and/or filter (see also
spoofing. Section 4.4.1.1), the MUA may be vulnerable to spoofing.
Consider a malicious MUA that sets the following Header Fields on an Consider a malicious MUA that sets the following Header Fields on an
encrypted message with Header Protection: encrypted message with Header Protection:
* Outer: From: <alice@example.com> * Outer: From: <alice@example.com>
* Inner: HP-Outer: From: <alice@example.com> * Inner: HP-Outer: From: <alice@example.com>
* Inner: From: <bob@example.org> * Inner: From: <bob@example.org>
skipping to change at line 2784 skipping to change at line 2811
* Sender authenticity: relevant for rendering the message (which * Sender authenticity: relevant for rendering the message (which
address to show the user?) address to show the user?)
* Message confidentiality: relevant when replying to a message (a * Message confidentiality: relevant when replying to a message (a
reply to the wrong address can leak the message contents) reply to the wrong address can leak the message contents)
10.1.1. From Rendering Reasoning 10.1.1. From Rendering Reasoning
Section 4.4.3 provides guidance for rendering the From Header Field. Section 4.4.3 provides guidance for rendering the From Header Field.
It recommends a receiving MUA that depends on its MTA to authenticate It recommends a receiving MUA that depends on its MTA to authenticate
the unprotected (outer) From Header Field to render the outer From the (unprotected) outer From Header Field to render the outer From
Header Field if both of the following conditions are met: Header Field if both of the following conditions are met:
* From Header Field Mismatch (as defined in Section 4.4.1.1) and * From Header Field Mismatch (as defined in Section 4.4.1.1) and
* No Valid and Correctly Bound Signature (as defined in * No Valid and Correctly Bound Signature (as defined in
Section 4.4.1.2) Section 4.4.1.2)
Note: The second condition effectively means that the inner (expected Note: The second condition effectively means that the inner (expected
to be protected) From Header Field appears to have insufficient to be protected) From Header Field appears to have insufficient
protection. protection.
skipping to change at line 2820 skipping to change at line 2847
for senders to spoof the From address of the message. for senders to spoof the From address of the message.
- This does not preclude a future document from updating this - This does not preclude a future document from updating this
document to specify a protocol for legitimate sender address document to specify a protocol for legitimate sender address
hiding. hiding.
* Case 2: Malicious sending/transiting/receiving MTA (or anyone * Case 2: Malicious sending/transiting/receiving MTA (or anyone
meddling between MTAs). meddling between MTAs).
- Attack situation: An on-path attacker changes the outer From - Attack situation: An on-path attacker changes the outer From
Header Field (possibly with other meddling to break the Header Field (possibly with other meddling to invalidate the
signature; see below). Their goal is to get the receiving MUA signature; see below). Their goal is to get the receiving MUA
to show a different From address than the sending MUA intended to show a different From address than the sending MUA intended
(breaking MUA-to-MUA sender authenticity). (breaking MUA-to-MUA sender authenticity).
- Case 2.a: The sending MUA submitted an unsigned or encrypted- - Case 2.a: The sending MUA submitted an unsigned or encrypted-
only message to the email system. In this case, there can be only message to the email system. In this case, there can be
no sender authenticity anyway. no sender authenticity anyway.
- Case 2.b: The sending MUA submitted a signed-only message to - Case 2.b: The sending MUA submitted a signed-only message to
the email system. the email system.
o Case 2.b.i: The attacker removes or breaks the signature. o Case 2.b.i: The attacker removes or invalidates the
In this case, the attacker can also modify the inner From signature. In this case, the attacker can also modify the
Header Field to their liking. inner From Header Field to their liking.
o Case 2.b.ii: The signature is valid, but the receiving MUA o Case 2.b.ii: The signature is valid, but the receiving MUA
does not see any valid binding between the signing does not see any valid binding between the signing
certificate and the addr-spec of the inner From Header certificate and the addr-spec of the inner From Header
Field. In this case, there can be no sender authenticity Field. In this case, there can be no sender authenticity
anyways (the certificate could have been generated by the anyways (the certificate could have been generated by the
on-path attacker). This case is indistinguishable from a on-path attacker). This case is indistinguishable from a
malicious sending MUA; hence, it is "better" to fall back to malicious sending MUA; hence, it is "better" to fall back to
the outer From Header Field that the MTA can validate. Note the outer From Header Field that the MTA can validate. Note
that once the binding is validated (e.g., after an out-of- that once the binding is validated (e.g., after an out-of-
band comparison), the rendering may change from showing the band comparison), the rendering may change from showing the
outer From address (and a warning) to showing the inner, now outer From address (and a warning) to showing the inner, now
validated From address. In some cases, the binding may be validated From address. In some cases, the binding may be
instantly validated even for previously unseen certificates instantly validated even for previously unseen certificates
(e.g., if the certificate is issued by a trusted (e.g., if the certificate is issued by a trusted
certification authority). certification authority).
- Case 2.c: The sending MUA submitted a signed-and-encrypted - Case 2.c: The sending MUA submitted a signed-and-encrypted
message to the email system. message to the email system.
o Case 2.c.i: The attacker removes or breaks the signature. o Case 2.c.i: The attacker removes or invalidates the
Note that the signature is inside the ciphertext (see signature. Note that the signature is inside the ciphertext
Section 5.2 of [RFC9787]). Thus, assuming the encryption is (see Section 5.2 of [RFC9787]). Thus, assuming the
non-malleable, any on-path attacker cannot break the encryption is non-malleable, any on-path attacker cannot
signature while ensuring that the message still decrypts invalidate the signature while ensuring that the message
successfully. still decrypts successfully.
o Case 2.c.ii: The signature is valid, but the receiving MUA o Case 2.c.ii: The signature is valid, but the receiving MUA
does not see any valid binding between the signing does not see any valid binding between the signing
certificate and the addr-spec of the inner From Header certificate and the addr-spec of the inner From Header
Field. See case 2.b.ii. Field. See case 2.b.ii.
As the case distinction shows, the outer From Header Field is either As the case distinction shows, the outer From Header Field is either
the preferred fallback (in particular, to avoid introducing a new the preferred fallback (in particular, to avoid introducing a new
spoofing channel) or just as good (because just as modifiable) as the spoofing channel) or just as good (because just as modifiable) as the
inner From Header Field. inner From Header Field.
skipping to change at line 2904 skipping to change at line 2931
When parsing a message, the recipient MUA infers the message's When parsing a message, the recipient MUA infers the message's
Cryptographic Status from the Cryptographic Layers, as described in Cryptographic Status from the Cryptographic Layers, as described in
Section 4.6 of [RFC9787]. Section 4.6 of [RFC9787].
The Cryptographic Layers that make up the Cryptographic Envelope The Cryptographic Layers that make up the Cryptographic Envelope
describe an ordered list of cryptographic properties as present in describe an ordered list of cryptographic properties as present in
the message after it has been delivered. By contrast, the hp the message after it has been delivered. By contrast, the hp
parameter to the Content-Type Header Field contains a simpler parameter to the Content-Type Header Field contains a simpler
indication: whether the sender originally tried to encrypt the indication: whether the sender originally tried to encrypt the
message or not. In particular, for a message with Header Protection, message or not (see Section 2.1.1). In particular, for a message
the Cryptographic Payload should have a hp parameter of cipher if the with Header Protection, the Cryptographic Payload MUST have a hp
message is encrypted (in addition to signed) and clear if no parameter of cipher if the message is encrypted (in addition to
encryption is present (that is, the message is signed-only). signed) and clear if no encryption is present (that is, the message
is signed-only).
As noted in Section 2.1.1, the receiving implementation should not As noted in Section 2.1.1, the receiving implementation MUST NOT
inflate its estimation of the confidentiality of the message or its inflate its estimation of the confidentiality of the message or its
Header Fields based on the sender's intent if it can see that the Header Fields based on the sender's intent if it can see that the
message was not actually encrypted. A signed-only message that message was not actually encrypted. A signed-only message that
happens to have an hp parameter of cipher is still signed-only. happens to have an hp parameter of cipher is still signed-only.
Conversely, since the encrypting Cryptographic Layer is typically Conversely, since the encrypting Cryptographic Layer is typically
outside the signature layer (see Section 5.2 of [RFC9787]), an outside the signature layer (see Section 5.2 of [RFC9787]), an
originally signed-only message could have been wrapped in an originally signed-only message could have been wrapped in an
encryption layer by an intervening party before receipt to appear encryption layer by an intervening party before receipt to appear
encrypted. encrypted.
If a message appears to be wrapped in an encryption layer, and the hp If a message appears to be wrapped in an encryption layer, and the hp
parameter is present but is not set to cipher, then it is likely that parameter is present but is not set to cipher, then it is likely that
the encryption layer was not added by the original sender. For such the encryption layer was not added by the original sender. For such
a message, the lack of any HP-Outer Header Field in the Header a message, the lack of any HP-Outer Header Field (see Section 2.2) in
Section of the Cryptographic Payload MUST NOT be used to infer that the Header Section of the Cryptographic Payload MUST NOT be used to
all Header Fields were removed from the message by the original infer that all Header Fields were removed from the Outer Header
sender. In such a case, the receiving MUA SHOULD treat every Header Section by the original sender. In such a case, the receiving MUA
Field as though it was not confidential. SHOULD treat every Header Field as though it was not confidential.
10.3. Caution About Composing with Legacy Display Elements 10.3. Caution About Composing with Legacy Display Elements
When composing a message, it's possible for a Legacy Display Element When composing a message, it's possible for a Legacy Display Element
to contain risky data that could trigger errors in a rendering (see Section 2.1.2) to contain risky data that could trigger errors
client. in a rendering client.
For example, if the value for a Header Field to be included in a For example, if the value for a Header Field to be included in a
Legacy Display Element within a given Body part contains folding Legacy Display Element within a given Body part contains folding
whitespace, it should be "unfolded" before generating the Legacy whitespace, it SHOULD be "unfolded" before generating the Legacy
Display Element: All contiguous folding whitespace should be replaced Display Element: All contiguous folding whitespace SHOULD be replaced
with a single space character. Likewise, if the Header Field value with a single space character. Likewise, if the Header Field value
was originally encoded per [RFC2047], it should be decoded first to a was originally encoded per [RFC2047], it SHOULD be decoded first to a
standard string and re-encoded using the charset appropriate to the standard string and re-encoded using the charset appropriate to the
target part. target part.
When including a Legacy Display Element in a text/plain part (see When including a Legacy Display Element in a text/plain part (see
Section 5.2.2), if the decoded Subject Header Field contains a pair Section 5.2.2), if the decoded Subject Header Field contains a pair
of newlines (e.g., if it is broken across multiple lines by encoded of newlines (e.g., if it is broken across multiple lines by encoded
newlines), any newline MUST be stripped from the Legacy Display newlines), the sending MUA MUST strip any newline from the Legacy
Element. If the pair of newlines is not stripped, a receiving MUA Display Element. If the pair of newlines is not stripped, a
that follows the guidance in Section 4.5.3.2 might leave the later receiving MUA that follows the guidance in Section 4.5.3.2 might
part of the Legacy Display Element in the rendered message. leave the later part of the Legacy Display Element in the rendered
message.
When including a Legacy Display Element in a text/html part (see When including a Legacy Display Element in a text/html part (see
Section 5.2.3), any material in the Header Field values should be Section 5.2.3), any material in the Header Field values MUST be
explicitly HTML escaped to avoid being rendered as part of the HTML. explicitly HTML escaped to avoid being rendered as part of the HTML.
At a minimum, the characters <, >, and & should be escaped to &lt;, At a minimum, the characters <, >, ', ", and & MUST be escaped to
&gt;, and &amp;, respectively (for example, see [HTML-ESCAPES]). If &lt;, &gt;, &apos;, &quot;, and &amp;, respectively (for example, see
unescaped characters from removed or obscured Header Field values end [HTML-ESCAPES]). If unescaped characters from removed or obscured
up in the Legacy Display Element, a receiving MUA that follows the Header Field values end up in the Legacy Display Element, a receiving
guidance in Section 4.5.3.3 might fail to identify the boundaries of MUA that follows the guidance in Section 4.5.3.3 might fail to
the Legacy Display Element, cutting out more than it should or identify the boundaries of the Legacy Display Element, cutting out
leaving remnants visible. And a Legacy MUA parsing such a message more than it should or leaving remnants visible. And a Legacy MUA
might misrender the entire HTML stream, depending on the content of parsing such a message might misrender the entire HTML stream,
the removed or obscured Header Field values. depending on the content of the removed or obscured Header Field
values.
The Legacy Display Element is a decorative addition solely to enable The Legacy Display Element is a decorative addition solely to enable
visibility of obscured or removed Header Fields in decryption-capable visibility of obscured or removed Header Fields in decryption-capable
Legacy MUAs. When it is produced, it should be generated minimally Legacy MUAs. When it is produced, it should be generated minimally
and strictly, as described above, to avoid damaging the rest of the and strictly, as described above, to avoid damaging the rest of the
message. message.
10.4. Plaintext Attacks 10.4. Plaintext Attacks
An encrypted email message using S/MIME or PGP/MIME tends to have An encrypted email message using S/MIME or PGP/MIME tends to have
some amount of predictable plaintext. For example, the standard MIME some amount of predictable plaintext. For example, the standard MIME
Header Fields of the Cryptographic Payload of a message are often a Header Fields of the Cryptographic Payload of a message are often a
predictable sequence of bytes, even without Header Protection, when predictable sequence of bytes, even without Header Protection, when
they only include the Structural Header Fields MIME-Version and they only include the Structural Header Fields MIME-Version and
Content-Type. This is a potential risk for known-plaintext attacks. Content-Type. This is a potential risk for known-plaintext attacks.
Including protected Header Fields as defined in this document Including protected Header Fields as defined in this document
increases the amount of known plaintext. Since some of those Header increases the amount of known plaintext. Since some of those Header
Fields in a reply will be derived from the message being replied to, Fields in a reply will be derived from the message being replied to,
this also creates a potential risk for chosen-plaintext attacks, in this also creates a potential risk for chosen-plaintext attacks, in
addition to known-plaintext attacks. addition to known-plaintext attacks. This potential risk also
applies in a similar manner to forwarded messages.
Modern message encryption mechanisms are expected to be secure Modern message encryption mechanisms are expected to be secure
against both known-plaintext attacks and chosen-plaintext attacks. against both known-plaintext attacks and chosen-plaintext attacks.
An MUA composing an encrypted message should ensure that it is using An MUA composing an encrypted message should ensure that it is using
such a mechanism, regardless of whether it does Header Protection. such a mechanism, regardless of whether it does Header Protection.
11. Privacy Considerations 11. Privacy Considerations
11.1. Leaks When Replying 11.1. Leaks When Replying
skipping to change at line 3024 skipping to change at line 3055
See the examples below. See the examples below.
This concern is true for any encrypted data, including the Body of This concern is true for any encrypted data, including the Body of
the message, not just the Header Fields: If the sender isn't careful, the message, not just the Header Fields: If the sender isn't careful,
the message contents or session keys can leak in many ways that are the message contents or session keys can leak in many ways that are
beyond the scope of this document. The message recipient has no way beyond the scope of this document. The message recipient has no way
in principle to tell whether the apparent confidentiality of any in principle to tell whether the apparent confidentiality of any
given piece of encrypted content has been broken via channels that given piece of encrypted content has been broken via channels that
they cannot perceive. Additionally, an active intermediary aware of they cannot perceive. Additionally, an active intermediary aware of
the recipient's public key can always encrypt a cleartext message in the recipient's public key can always encrypt a cleartext message in
transit to give the recipient a false sense of security. transit to give the recipient a false sense of security (see also
Section 10.2).
11.2.1. Encrypted Header Fields Can Leak Unwanted Information to the 11.2.1. Encrypted Header Fields Can Leak Unwanted Information to the
Recipient Recipient
For encrypted messages, even with an ambitious HCP that successfully For an encrypted message, even with an ambitious HCP that
obscures most Header Fields from all transport agents, Header Fields successfully obscures most Header Fields from all transport agents,
will be ultimately visible to all intended recipients. This can be Header Fields will be ultimately visible to each intended recipient.
especially problematic for Header Fields that are not User-Facing; This can be especially problematic for a Header Field that is not
the sender may not expect such Header Fields to be injected by their User-Facing; the sender may not expect such a Header Field to be
MUA. Consider the three following examples: injected by their MUA. Consider the three following examples:
* The MUA may inject a User-Agent Header Field that describes itself * The MUA may inject a User-Agent Header Field that describes itself
to every recipient, even though the sender may not want the to every recipient, even though the sender may not want a
recipient to know the exact version of their OS, hardware recipient to know the exact version of their OS, hardware
platform, or MUA. platform, or MUA.
* The MUA may have an idiosyncratic way of generating a Message-ID * The MUA may have an idiosyncratic way of generating a Message-ID
Header Field, which could embed the choice of MUA, time zone, Header Field, which could embed the choice of MUA, time zone,
hostname, or other subtle information to a knowledgeable hostname, or other subtle information to a knowledgeable
recipient. recipient.
* The MUA may erroneously include a Bcc Header Field in the * The MUA may erroneously include a Bcc Header Field in the
origheaders of a copy of a message sent to the named recipient, origheaders of a copy of a message sent to a named recipient,
defeating the purpose of using Bcc instead of Cc (see Section 11.4 defeating the purpose of using Bcc instead of Cc (see Section 11.4
for more details about risks related to Bcc). for more details about risks related to Bcc).
Clearly, no end-to-end cryptographic protection of any Header Field Clearly, no end-to-end cryptographic protection of any Header Field
as defined in this document will hide such a sensitive field from the as defined in this document will hide such a sensitive field from an
intended recipient. Instead, the composing MUA MUST populate the intended recipient. Instead, the composing MUA MUST populate the
origheaders list for any outbound message with only information the origheaders list for any outbound message with only information each
recipient should have access to. This is true for messages without recipient should have access to. This is true for any message
any cryptographic protection as well, of course, and it is even worse without any cryptographic protection as well, of course, and it is
there: Such a leak is exposed to the transport agents as well as the even worse there: Such a leak is exposed to the transport agents as
recipient. An encrypted message with Header Protection and a more well as all recipients. An encrypted message with Header Protection
ambitious HCP avoids these leaks that expose information to the and a more ambitious HCP avoids these leaks that expose information
transport agents, but it cannot defend against such a leak to the to the transport agents, but it cannot defend against such a leak to
recipient. a recipient.
11.2.2. Encrypted Header Fields Can Be Inferred from External or 11.2.2. Encrypted Header Fields Can Be Inferred from External or
Internal Metadata Internal Metadata
For example, if the To and Cc Header Fields are removed from the For example, if the To and Cc Header Fields are removed from the
Outer Header Section, the values in those fields might still be Outer Header Section, the values in those fields might still be
inferred with high probability by an adversary who looks at the inferred with high probability by an adversary who looks at the
message either in transit or at rest. For example, if the message is message either in transit or at rest. For example, if the message is
found in a mailbox, or being delivered to a mailbox, and the mailbox found in a mailbox, or being delivered to a mailbox, and the mailbox
is known to be associated with the email address bob@example.org, is known to be associated with the email address bob@example.org,
skipping to change at line 3122 skipping to change at line 3154
For example, if the original sender's HCP passes through the Cc For example, if the original sender's HCP passes through the Cc
Header Field unchanged, a cleanly delivered message would indicate Header Field unchanged, a cleanly delivered message would indicate
that the Cc Header Field has a cryptographic status of signed. But that the Cc Header Field has a cryptographic status of signed. But
if an intermediary attacker simply removes the Header Field from the if an intermediary attacker simply removes the Header Field from the
Outer Header Section before forwarding the message, then the naive Outer Header Section before forwarding the message, then the naive
recipient might believe that the field has a cryptographic status of recipient might believe that the field has a cryptographic status of
signed-and-encrypted. signed-and-encrypted.
This document offers protection against such an attack by way of the This document offers protection against such an attack by way of the
HP-Outer Header Fields that can be found on the Cryptographic HP-Outer Header Fields (see Section 2.2) that can be found on the
Payload. If a Header Field appears to have been obscured by Cryptographic Payload. If a Header Field appears to have been
inspection of the outer message but an HP-Outer Header Field matches obscured by inspection of the Outer Header Section but an HP-Outer
it exactly, then the receiving MUA can indicate to the user that the Header Field matches it exactly, then the receiving MUA can indicate
Header Field in question may not have been confidential. to the user that the Header Field in question may not have been
confidential.
In such a case, a cautious MUA may render the Header Field in In such a case, a cautious MUA may render the Header Field in
question as signed (because the sender did not hide it) but still question as signed (because the sender did not hide it) but still
treat it as signed-and-encrypted during reply to avoid accidental treat it as signed-and-encrypted during reply to avoid accidental
leakage of the cleartext value in the reply message, as described in leakage of the cleartext value in the reply message, as described in
Section 6.1. Section 6.1.
11.4. Privacy and Deliverability Risks with Bcc and Encrypted Messages 11.4. Privacy and Deliverability Risks with Bcc and Encrypted Messages
As noted in Section 9.3 of [RFC9787], handling Bcc when generating an As noted in Section 9.3 of [RFC9787], handling Bcc when generating an
skipping to change at line 3162 skipping to change at line 3195
cause the intervening transport agent to drop the message entirely. cause the intervening transport agent to drop the message entirely.
This is why Bcc is not explicitly stripped in hcp_baseline. This is why Bcc is not explicitly stripped in hcp_baseline.
On the other hand, if deliverability to a Bcc'ed recipient is not a On the other hand, if deliverability to a Bcc'ed recipient is not a
concern, the most privacy-preserving option is to simply omit the Bcc concern, the most privacy-preserving option is to simply omit the Bcc
Header Field from the protected Header Section in the first place. Header Field from the protected Header Section in the first place.
An MUA that is capable of receiving and processing such a message can An MUA that is capable of receiving and processing such a message can
infer that since their user's address was not mentioned in any To or infer that since their user's address was not mentioned in any To or
Cc Header Field, they were likely a Bcc recipient. Cc Header Field, they were likely a Bcc recipient.
Please also see Section 9.3 of [RFC9787] for more discussion about Please also see Section 9.4 of [RFC9787] for more discussion about
Bcc and encrypted messages. Bcc and encrypted messages.
12. IANA Considerations 12. IANA Considerations
This document registers an email Header Field, describes parameters This document registers an email Header Field, describes parameters
for the Content-Type Header Field, and establishes a registry for for the Content-Type Header Field, and establishes a registry for
Header Confidentiality Policies to facilitate HCP evolution. Header Confidentiality Policies to facilitate HCP evolution.
12.1. Registration of the HP-Outer Header Field 12.1. Registration of the HP-Outer Header Field
skipping to change at line 3245 skipping to change at line 3278
| | Keywords and | | | | | Keywords and | | |
| | Comments are | | | | | Comments are | | |
| | removed | | | | | removed | | |
+------------------------+-----------------+-------------+---------+ +------------------------+-----------------+-------------+---------+
| hcp_shy | Obscure | N |Section | | hcp_shy | Obscure | N |Section |
| | Subject, remove | |3.2.2 of | | | Subject, remove | |3.2.2 of |
| | Keywords and | |RFC 9788 | | | Keywords and | |RFC 9788 |
| | Comments, | | | | | Comments, | | |
| | remove the time | | | | | remove the time | | |
| | zone from Date, | | | | | zone from Date, | | |
| | and obscure | | | | | and remove | | |
| | display-names | | | | | display-names | | |
| | from From, To, | | |
| | and Cc | | |
+------------------------+-----------------+-------------+---------+ +------------------------+-----------------+-------------+---------+
Table 4: Mail Header Confidentiality Policies Registry Table 4: Mail Header Confidentiality Policies Registry
Note that hcp_example_hide_cc is offered as an example in Section 3 Note that hcp_example_hide_cc is offered as an example in Section 3.1
but is not formally registered by this document. but is not formally registered by this document.
The following textual note has been added to this registry: The following textual note has been added to this registry:
| Adding an entry to this registry with an N in the "Recommended" | Adding an entry to this registry with an N in the "Recommended"
| column follows the registration policy of Specification Required. | column follows the registration policy of Specification Required.
| Adding an entry to this registry with a Y in the "Recommended" | Adding an entry to this registry with a Y in the "Recommended"
| column or changing the "Recommended" column in an existing entry | column or changing the "Recommended" column in an existing entry
| (from N to Y or vice versa) requires IETF Review. | (from N to Y or vice versa) requires IETF Review.
skipping to change at line 3474 skipping to change at line 3509
| | "protected" sets of | 4.2.1 | | | "protected" sets of | 4.2.1 |
| | Header Fields from a | | | | Header Fields from a | |
| | given message | | | | given message | |
+---------------------------+-------------------------+-----------+ +---------------------------+-------------------------+-----------+
| HeaderFieldProtection | Calculate cryptographic | Section | | HeaderFieldProtection | Calculate cryptographic | Section |
| | protections for a | 4.3.1 | | | protections for a | 4.3.1 |
| | Header Field in a given | | | | Header Field in a given | |
| | message | | | | message | |
+---------------------------+-------------------------+-----------+ +---------------------------+-------------------------+-----------+
| ReferenceHCP | Produce an ephemeral | Section | | ReferenceHCP | Produce an ephemeral | Section |
| | HCP to use when | 6.1.1 | | | HCP to use when | 6.1.2 |
| | responding to a given | | | | responding to a given | |
| | message | | | | message | |
+---------------------------+-------------------------+-----------+ +---------------------------+-------------------------+-----------+
| ComposeNoHeaderProtection | Legacy Message | Section | | ComposeNoHeaderProtection | Legacy Message | Section |
| | composition with end- | 5.1.1 | | | composition with end- | 5.1.1 |
| | to-end cryptographic | | | | to-end cryptographic | |
| | protections (but no | | | | protections (but no | |
| | Header Protection) | | | | Header Protection) | |
+---------------------------+-------------------------+-----------+ +---------------------------+-------------------------+-----------+
| Compose | Compose a message with | Section | | Compose | Compose a message with | Section |
skipping to change at line 3510 skipping to change at line 3545
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.
Recall that "protected" refers to the "inner" values, e.g., the real Recall that "protected" refers to the values of the inner Header
Subject, and "unprotected" refers to the "outer" values, e.g., the Fields, e.g., the real Subject, and "unprotected" refers to the
replacement Subject. values of the outer Header Fields, e.g., the replacement Subject.
B.1. Problems Viewing Messages in a List View B.1. Problems Viewing Messages in a List View
* Unprotected Subject, Date, From, and To Header Fields are visible * Unprotected Subject, Date, From, and To Header Fields are visible
(instead of being replaced by protected values) (instead of being replaced by protected values)
* Threading is not visible * Threading is not visible
B.2. Problems When Rendering a Message B.2. Problems When Rendering a Message
skipping to change at line 12050 skipping to change at line 12085
F.2. Pretty Easy Privacy (pEp) F.2. Pretty Easy Privacy (pEp)
The pretty Easy privacy (pEp) [PEP-GENERAL] project specifies two The pretty Easy privacy (pEp) [PEP-GENERAL] project specifies two
different MIME schemes that include Header Protection for Signed-and- different MIME schemes that include Header Protection for Signed-and-
Encrypted email messages in [PEP-EMAIL]: One scheme -- referred as Encrypted email messages in [PEP-EMAIL]: One scheme -- referred as
pEp Email Format 1 (PEF-1) -- is generated towards MUAs not known to pEp Email Format 1 (PEF-1) -- is generated towards MUAs not known to
be pEp-capable, while the other scheme -- referred as PEF-2 -- is be pEp-capable, while the other scheme -- referred as PEF-2 -- is
used between MUAs discovered to be compatible with pEp. Signed-only used between MUAs discovered to be compatible with pEp. Signed-only
messages are not recommended in pEp. messages are not recommended in pEp.
Although the PEF-2 scheme is only meant to be used between PEF- Although the PEF-2 scheme is only meant to be used between MUAs
2-compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 compatible with PEF-2, a PEF-2 message may end up at an MUA unaware
(in which case, they typically render badly). This is due to of PEF-2 (in which case, it typically renders badly). This is due to
signaling mechanism limitations. signaling mechanism limitations.
As the PEF-2 scheme is an enhanced variant of the RFC8551HP scheme As the PEF-2 scheme is an enhanced variant of the RFC8551HP scheme
(with an additional MIME Layer), it is similar to the RFC8551HP (with an additional MIME Layer), it is similar to the RFC8551HP
scheme (see Section 4.10). The basic PEF-2 MIME structure looks as scheme (see Section 4.10). The basic PEF-2 MIME structure looks as
follows: follows:
A └┬╴multipart/encrypted [Outer Message] A └┬╴multipart/encrypted [Outer Message]
B ├─╴application/pgp-encrypted B ├─╴application/pgp-encrypted
C └─╴application/octet-stream inline [Cryptographic Payload] C └─╴application/octet-stream inline [Cryptographic Payload]
 End of changes. 95 change blocks. 
271 lines changed or deleted 306 lines changed or added

This html diff was produced by rfcdiff 1.48.