rfc9788v2.txt   rfc9788.txt 
skipping to change at line 85 skipping to change at line 85
1.8.2. Out of Scope 1.8.2. Out of Scope
1.9. Example 1.9. Example
2. Internet Message Format Extensions 2. Internet Message Format Extensions
2.1. Content-Type Parameters 2.1. Content-Type Parameters
2.1.1. Content-Type Parameter: hp 2.1.1. Content-Type Parameter: hp
2.1.2. Content-Type Parameter: hp-legacy-display 2.1.2. Content-Type Parameter: hp-legacy-display
2.2. HP-Outer Header Field 2.2. HP-Outer Header Field
2.2.1. HP-Outer Header Field Definition 2.2.1. HP-Outer Header Field Definition
3. Header Confidentiality Policy 3. Header Confidentiality Policy
3.1. HCP Definition 3.1. HCP Definition
3.1.1. HCP Avoids Changing From Header Field addr-spec 3.1.1. HCP Avoids Changing addr-spec of From Header Field
3.2. Initial Registered HCPs 3.2. Initial Registered HCPs
3.2.1. Baseline Header Confidentiality Policy 3.2.1. Baseline Header Confidentiality Policy
3.2.2. Shy Header Confidentiality Policy 3.2.2. Shy Header Confidentiality Policy
3.2.3. No Header Confidentiality Policy 3.2.3. No Header Confidentiality Policy
3.3. Default Header Confidentiality Policy 3.3. Default Header Confidentiality Policy
3.4. HCP Evolution 3.4. HCP Evolution
3.4.1. Offering More Ambitious Header Confidentiality 3.4.1. Offering More Ambitious Header Confidentiality
3.4.2. Expert Guidance for Registering Header Confidentiality 3.4.2. Expert Guidance for Registering Header Confidentiality
Policies Policies
4. Receiving Guidance 4. Receiving Guidance
skipping to change at line 264 skipping to change at line 264
D.2.2. Encrypted with hcp_no_confidentiality and Legacy D.2.2. Encrypted with hcp_no_confidentiality and Legacy
Display Display
Appendix E. Rendering Examples Appendix E. Rendering Examples
E.1. Example text/plain Cryptographic Payload with Legacy E.1. Example text/plain Cryptographic Payload with Legacy
Display Elements Display Elements
E.2. Example text/html Cryptographic Payload with Legacy Display E.2. Example text/html Cryptographic Payload with Legacy Display
Elements Elements
Appendix F. Other Header Protection Schemes Appendix F. Other Header Protection Schemes
F.1. Original RFC 8551 Header Protection F.1. Original RFC 8551 Header Protection
F.2. Pretty Easy Privacy (pEp) F.2. Pretty Easy Privacy (pEp)
F.3. Protected Email Headers F.3. Autocrypt Protected Headers
Acknowledgements Acknowledgements
Index Index
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
Privacy and security issues regarding email Header Protection in S/ Privacy and security issues regarding email Header Protection in S/
MIME and PGP/MIME have been identified for some time. Most current MIME and PGP/MIME have been identified for some time. Most current
implementations of cryptographically protected email protect only the implementations of cryptographically protected email protect only the
body of the message, which leaves significant room for attacks Body of the message, which leaves significant room for attacks
against otherwise-protected messages. For example, lack of Header against otherwise-protected messages. For example, lack of Header
Protection allows an attacker to substitute the message subject and/ Protection allows an attacker to substitute the message subject and/
or author. or author.
This document describes how to cryptographically protect message This document describes how to cryptographically protect message
headers and provides guidance for the implementer of a Mail User headers and provides guidance for the implementer of a Mail User
Agent (MUA) that generates, interprets, and replies to such a Agent (MUA) that generates, interprets, and replies to such a
message. It uses the term "Legacy MUA" to refer to an MUA that does message. It uses the term "Legacy MUA" to refer to an MUA that does
not implement this specification. This document takes particular not implement this specification. This document takes particular
care to ensure that messages interact reasonably well with Legacy care to ensure that messages interact reasonably well with Legacy
skipping to change at line 304 skipping to change at line 304
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 message/
rfc822 MIME object. In an encrypted message, some Header Fields can rfc822 MIME object. In an encrypted message, some Header Fields can
also be made confidential by removing or obscuring them from the also be made confidential by removing or obscuring them from the
outer Header Section. 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 376 skipping to change at line 376
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 is risk
free. Such a message will render in the same way on any Legacy MUA free. Such a message will render in the same way on any Legacy MUA
as a Legacy Signed Message (that is, a signed message without Header as a Legacy Signed Message (that is, a signed message without Header
Protection). An MUA conformant to this specification that encounters Protection). An MUA conformant to this specification that encounters
such a message will be able to gain the benefits of end-to-end such a message will be able to gain the benefits of end-to-end
cryptographic integrity and authenticity for all Header Fields. 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 risk of producing an encrypted message according to this
specification. specification.
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
Section 3.2.3). A signed-and-encrypted message composed using the No Section 3.2.3). A signed-and-encrypted message composed using the No
Header Confidentiality Policy offers no usability risk for a reader Header Confidentiality Policy offers no usability risk for a reader
using a Legacy MUA and retains end-to-end cryptographic integrity and using a Legacy MUA and retains end-to-end cryptographic integrity and
authenticity properties for all Header Fields for any reader using a authenticity properties for all Header Fields for any reader using a
conformant MUA. Of course, such a message has the same (non- conformant MUA. Of course, such a message has the same (non-
existent) confidentiality properties for all Header Fields as a existent) confidentiality properties for all Header Fields as a
Legacy Encrypted Message (that is, an encrypted message made without Legacy Encrypted Message (that is, an encrypted message made without
Header Protection). Header Protection).
1.3. Motivation 1.3. Motivation
Users generally do not understand the distinction between message Ordinary Users generally do not understand the distinction between
body and message header. When an email message has cryptographic email message Body and Header Section. When an email message has
protections that cover the message body but not the Header Fields, cryptographic protections that cover the message Body but not the
several attacks become possible. Header Fields, several attacks become possible.
For example, a Legacy Signed Message has a signature that covers the For example, a Legacy Signed Message has a signature that covers the
body but not the Header Fields. An attacker can therefore modify the Body but not the Header Fields. An attacker can therefore modify the
Header Fields (including Subject) without invalidating the signature. Header Fields (including Subject) without invalidating the signature.
Since most readers consider a message body in the context of the Since most readers consider a message Body in the context of the
message's Subject, the meaning of the message itself could change message's Subject, the meaning of the message itself could change
drastically (under the attacker's control) while still retaining the drastically (under the attacker's control) while still retaining the
same cryptographic indicators of integrity and authenticity. same cryptographic indicators of integrity and authenticity.
In another example, a Legacy Encrypted Message has its body In another example, a Legacy Encrypted Message has its Body
effectively hidden from an adversary that snoops on the message. But effectively hidden from an adversary that snoops on the message. But
if the Header Fields are not also encrypted, significant information if the Header Fields are not also encrypted, significant information
about the message (such as the message Subject) will leak to the about the message (such as the message Subject) will leak to the
inspecting adversary. inspecting adversary.
However, if the sending and receiving MUAs ensure that cryptographic However, if the sending and receiving MUAs ensure that cryptographic
protections cover the message Header Section as well as the message protections cover the message Header Section as well as the message
body, these attacks are defeated. Body, these attacks are defeated.
1.3.1. Backward Compatibility 1.3.1. Backward Compatibility
If the sending MUA is unwilling to generate such a fully protected If the sending MUA is unwilling to generate such a fully protected
message due to the potential for rendering, usability, message due to the potential for rendering, usability,
deliverability, or security issues, these defenses cannot be deliverability, or security issues, these defenses cannot be
realized. realized.
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 like extent possible. In some cases, like when a user-visible Header
the Subject is cryptographically hidden, a Legacy MUA will not be Field like the Subject is cryptographically hidden, a Legacy MUA will
able to render or reply to the message exactly the same way as a not be able to render or reply to the message exactly the same way as
conformant MUA would. But accommodations are described here that a conformant MUA would. But accommodations are described here that
ensure a rough semantic equivalence for a Legacy MUA even in these ensure a rough semantic equivalence for a Legacy MUA even in these
cases. 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.
skipping to change at line 496 skipping to change at line 496
Furthermore, the DKIM+DMARC suite only provides cryptographic Furthermore, the DKIM+DMARC suite only provides cryptographic
integrity and authentication, not encryption. So cryptographic integrity and authentication, not encryption. So cryptographic
confidentiality is not available from that suite. confidentiality is not available from that suite.
The DKIM+DMARC suite can be used on any message, including messages The DKIM+DMARC suite can be used on any message, including messages
formed as defined in this document. There should be no conflict formed as defined in this document. There should be no conflict
between DKIM+DMARC and the specification here. between DKIM+DMARC and the specification here.
Though not strictly email, similar protections have been in use on Though not strictly email, similar protections have been in use on
Usenet for the signing and verification of message headers for years. Usenet for the signing and verification of message Header Fields for
See [PGPCONTROL] and [PGPVERIFY-FORMAT] for more details. Like DKIM, years. See [PGPCONTROL] and [PGPVERIFY-FORMAT] for more details.
these Usenet control protections offer only integrity and Like DKIM, these Usenet control protections offer only integrity and
authentication, not confidentiality. authentication, not confidentiality.
1.5. Applicability to PGP/MIME 1.5. Applicability to PGP/MIME
This document specifies end-to-end cryptographic protections for This document specifies end-to-end cryptographic protections for
email messages in reference to S/MIME [RFC8551]. email messages in reference to S/MIME [RFC8551].
Comparable end-to-end cryptographic protections can also be provided Comparable end-to-end cryptographic protections can also be provided
by PGP/MIME [RFC3156]. by PGP/MIME [RFC3156].
skipping to change at line 535 skipping to change at line 535
1.7. Terms 1.7. Terms
The following terms are defined for the scope of this document: The following terms are defined for the scope of this document:
S/MIME: Secure/Multipurpose Internet Mail Extensions (see [RFC8551]) S/MIME: Secure/Multipurpose Internet Mail Extensions (see [RFC8551])
PGP/MIME: Pretty Good Privacy with MIME (see [RFC3156]) PGP/MIME: Pretty Good Privacy with MIME (see [RFC3156])
Message: An email message consisting of Header Fields (collectively Message: An email message consisting of Header Fields (collectively
called "the Header Section of the message") optionally followed by called "the Header Section of the message") optionally followed by
a message body; see [RFC5322]. a message Body; see [RFC5322].
Note: To avoid ambiguity, this document avoids using the terms Note: To avoid ambiguity, this document avoids using the terms
"Header" or "Headers" in isolation, but instead always uses "Header" or "Headers" in isolation, but instead always uses
"Header Field" to refer to the individual field and "Header "Header Field" to refer to the individual field and "Header
Section" to refer to the entire collection. 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.
Body: The body is the part of a message that follows the Header Outer Header Section: The unprotected Header Section that MTAs and
MUAs unaware of Header Protection treat as the Header Section of
the Message.
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.
Legacy MUA: An MUA that does not understand Header Protection as Legacy MUA: An MUA that does not understand Header Protection as
defined in this document. A Legacy Non-Crypto MUA is incapable of defined in this document. A Legacy Non-Crypto MUA is incapable of
doing any end-to-end cryptographic operations. A Legacy Crypto doing any end-to-end cryptographic operations. A Legacy Crypto
MUA is capable of doing cryptographic operations but does not MUA is capable of doing cryptographic operations but does not
skipping to change at line 593 skipping to change at line 597
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".
Additionally, Cryptographic Layer, Cryptographic Payload, Additionally, Cryptographic Layer, Cryptographic Payload,
Cryptographic Envelope, Cryptographic Summary, Structural Header Cryptographic Envelope, Cryptographic Summary, Structural Header
Fields, Main Body Part, User-Facing Header Fields, and MUA are all Fields, Non-Structural Header Fields, Main Body Part, User-Facing
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].
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
This document also describes sensible, simple behavior for a program This document also describes sensible, simple behavior for a program
that interprets such a message in a way that can take advantage of that interprets such a message in a way that can take advantage of
these protections covering the Header Fields as well as the body. these protections covering the Header Fields as well as the Body.
The message generation guidance aims to minimize negative The message generation guidance aims to minimize negative
interactions with any Legacy receiving MUA while providing actionable interactions with any Legacy receiving MUA while providing actionable
cryptographic properties for modern receiving clients. cryptographic properties for modern receiving MUAs.
In particular, this document focuses on two standard types of In particular, this document focuses on two standard types of
cryptographic protection that cover the entire message: cryptographic protection that cover the entire message:
* a cleartext message with a single signature and * a cleartext message with a single signature and
* an encrypted message that contains a single cryptographic * an encrypted message that contains a single cryptographic
signature. signature.
1.8.2. Out of Scope 1.8.2. Out of Scope
skipping to change at line 747 skipping to change at line 751
Thanks, Thanks,
Bob Bob
-- --
Bob Gonzalez Bob Gonzalez
ACME, Inc. ACME, Inc.
Observe that: Observe that:
* The sender adds the removed and obscured User-Facing Header Fields * The sender adds the removed and obscured User-Facing Header Fields
(see Section 1.1.2 of [RFC9787]) to the main body (note the empty (see Section 1.1.2 of [RFC9787]) to the main Body (note the empty
line after the Content-Type). This is called the Legacy Display line after the Content-Type). This is called the Legacy Display
Element. It allows a user with a Legacy MUA that doesn't Element. It allows a user with a Legacy MUA that doesn't
implement this document to understand the message, since the implement this document to understand the message, since the
Header Fields will be shown as part of the main body. Header Fields will be shown as part of the main Body.
* The hp-legacy-display="1" attribute (see Section 2.1.2) indicates * The hp-legacy-display="1" attribute (see Section 2.1.2) indicates
that the sender added a Legacy Display Element. This allows that the sender added a Legacy Display Element. This allows
receivers that implement this document to recognize the Legacy receivers that implement this document to recognize the Legacy
Display Element and distinguish it from user-added content. The Display Element and distinguish it from user-added content. The
receiver then hides the Legacy Display Element and doesn't display receiver then hides the Legacy Display Element and doesn't display
it to the user. it to the user.
* hp-legacy-display is added to the node to which it applies, not on * hp-legacy-display is added to the node to which it applies, not on
any outer nodes (e.g., not to node C). any outer nodes (e.g., not to node C).
skipping to change at line 815 skipping to change at line 819
| | | | | Protection, | | | | | | Protection, |
| | | | | and is | | | | | | and is |
| | | | | encrypted to | | | | | | encrypted to |
| | | | | the | | | | | | the |
| | | | | recipients. | | | | | | recipients. |
+--------+--------------+---------+-----------------+--------------+ +--------+--------------+---------+-----------------+--------------+
Table 1: hp Parameter for Content-Type Header Field Table 1: hp Parameter for Content-Type Header Field
A sending implementation MUST NOT produce a Cryptographic Payload A sending implementation MUST NOT produce a Cryptographic Payload
with parameter hp="cipher" for a non-encrypted message (that is, with parameter hp="cipher" for an unencrypted message (that is, where
where none of the Cryptographic Layers in the Cryptographic Envelope none of the Cryptographic Layers in the Cryptographic Envelope of the
of the message provide encryption). Likewise, if a sending message provide encryption). Likewise, if a sending implementation
implementation is sending an encrypted message with Header is sending an encrypted message with Header Protection, it MUST emit
Protection, it MUST emit an hp="cipher" parameter, regardless of an hp="cipher" parameter, regardless of which Header Fields were made
which Header Fields were made confidential. confidential.
Note that hp="cipher" indicates that the message itself has been Note that hp="cipher" indicates that the message itself has been
encrypted by the sender to the recipients but makes no assertions encrypted by the sender to the recipients but makes no assertions
about which Header Fields have been removed or obscured. This can be about which Header Fields have been removed or obscured. This can be
derived from the Cryptographic Payload itself (see Section 4.2). derived from the Cryptographic Payload itself (see Section 4.2).
A receiving implementation MUST NOT mistake the presence of an A receiving implementation MUST NOT mistake the presence of an
hp="cipher" parameter in the Cryptographic Payload for the actual hp="cipher" parameter in the Cryptographic Payload for the actual
presence of a Cryptographic Layer that provides encryption. presence of a Cryptographic Layer that provides encryption.
skipping to change at line 849 skipping to change at line 853
cryptographic protections. Its presence indicates that the MIME node cryptographic protections. Its presence indicates that the MIME node
it is attached to contains a decorative "Legacy Display Element". it is attached to contains a decorative "Legacy Display Element".
The Legacy Display Element itself is used for backward-compatible The Legacy Display Element itself is used for backward-compatible
visibility of any removed or obscured User-Facing Header Field in a visibility of any removed or obscured User-Facing Header Field in a
Legacy MUA. Legacy MUA.
Such a Legacy Display Element need not be rendered to the user of an Such a Legacy Display Element need not be rendered to the user of an
MUA that implements this specification, because the MUA already knows MUA that implements this specification, because the MUA already knows
the correct Header Field information and can render it to the user in the correct Header Field information and can render it to the user in
the appropriate part of the MUA's user interface rather than in the the appropriate part of the MUA's user interface rather than in the
body of the message. Body of the message.
See Section 5.2.2 for how to insert a Legacy Display Element into a See Section 5.2.2 for how to insert a Legacy Display Element into a
text/plain Main Body Part. See Section 5.2.3 for how to insert a text/plain Main Body Part. See Section 5.2.3 for how to insert a
Legacy Display Element into a text/html Main Body Part. See Legacy Display Element into a text/html Main Body Part. See
Section 4.5.3 for how to avoid rendering a Legacy Display Element. Section 4.5.3 for how to avoid rendering a Legacy Display Element.
2.2. HP-Outer Header Field 2.2. HP-Outer Header Field
This document also specifies a new Header Field: HP-Outer. This document also specifies a new Header Field: HP-Outer.
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 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 in within the outer and the value that this Header Field was set in within the outer
(unprotected) Header Section. The HP-Outer Header Field can appear (unprotected) Header Section. The HP-Outer Header Field can appear
multiple times in the Header Section of a Cryptographic Payload. 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.
See Section 5.2 for how to insert HP-Outer Header Fields into an See Section 5.2 for how to insert HP-Outer Header Fields into an
encrypted message. See Section 4.3 for how to determine the end-to- encrypted message. See Section 4.3 for how to determine the end-to-
skipping to change at line 928 skipping to change at line 932
Note that hp-outer-value is the same as unstructured from Note that hp-outer-value is the same as unstructured from
Section 3.2.5 of [RFC5322] but without the obsolete obs-unstruct Section 3.2.5 of [RFC5322] but without the obsolete obs-unstruct
option. option.
3. Header Confidentiality Policy 3. Header Confidentiality Policy
An MUA composing an encrypted message according to this specification An MUA composing an encrypted message according to this specification
may make any given Header Field confidential by removing it from the may make any given Header Field confidential by removing it from the
Header Section outside the Cryptographic Envelope or by obscuring it Header Section outside the Cryptographic Envelope or by obscuring it
by rewriting it to a different value in that outer Header Section. by rewriting it to a different value in that Outer Header Section.
The composing MUA faces a choice for any new message: Which Header The composing MUA faces a choice for any new message: Which Header
Fields should be made confidential, and how? Fields should be made confidential, and how?
This section defines the "Header Confidentiality Policy" (or HCP) as This section defines the "Header Confidentiality Policy" (or HCP) as
a well-defined abstraction to encourage MUA developers to consider, a well-defined abstraction to encourage MUA developers to consider,
document, and share reasonable policies across the community. It document, and share reasonable policies across the community. It
establishes a registry of known HCPs, defines a small number of establishes a registry of known HCPs, defines a small number of
simple HCPs in that registry, and makes a recommendation for a simple HCPs in that registry, and makes a recommendation for a
reasonable default. reasonable default.
skipping to change at line 959 skipping to change at line 963
Note that no representation of the HCP itself ever appears "on the Note that no representation of the HCP itself ever appears "on the
wire". However, the consumer of the encrypted message can see the wire". However, the consumer of the encrypted message can see the
decisions that were made by the sender's HCP via the HP-Outer Header decisions that were made by the sender's HCP via the HP-Outer Header
Fields (see Section 2.2). Fields (see Section 2.2).
3.1. HCP Definition 3.1. HCP Definition
In this document, we represent that Header Confidentiality Policy as In this document, we represent that Header Confidentiality Policy as
a function hcp: a function hcp:
* hcp(name, val_in) -> val_out: This function takes a non-structural * hcp(name, val_in) -> val_out: This function takes a Non-Structural
Header Field identified by name with the initial value val_in as Header Field identified by name with the initial value val_in as
arguments and returns a replacement header value val_out. If arguments and returns a replacement Header Field value val_out.
val_out is the special value null, it means that the Header Field If val_out is the special value null, it means that the Header
in question should be removed from the set of Header Fields Field in question should be removed from the set of Header Fields
visible outside the Cryptographic Envelope. visible outside the Cryptographic Envelope.
In the pseudocode descriptions of various choices of HCP in this In the pseudocode descriptions of various choices of HCP in this
document, any comparison with the name input is done case- document, any comparison with the name input is done case-
insensitively. This is appropriate for Header Field names, as insensitively. This is appropriate for Header Field names, as
described in [RFC5322]. described in [RFC5322].
Note that hcp is only applied to non-structural Header Fields. When Note that hcp is only applied to Non-Structural Header Fields. When
composing a message, Structural Header Fields are dealt with composing a message, Structural Header Fields are dealt with
separately, as described in Section 5.2. separately, as described in Section 5.2.
As an example, an MUA that obscures the Subject Header Field by As an example, an MUA that obscures the Subject Header Field by
replacing it with the literal string "[...]" hides all Cc'ed replacing it with the literal string "[...]" hides all Cc'ed
recipients and does not offer confidentiality to any other Header recipients and does not offer confidentiality to any other Header
Fields that would be represented as (in pseudocode): Fields that would be represented as (in pseudocode):
hcp_example_hide_cc(name, val_in) → val_out: hcp_example_hide_cc(name, val_in) → val_out:
if lower(name) is 'subject': if lower(name) is 'subject':
skipping to change at line 1006 skipping to change at line 1010
* a sequence of whitespace (that is, space or tab) and printable * a sequence of whitespace (that is, space or tab) and printable
7-bit, clean ASCII characters (of course, non-ASCII text can be 7-bit, clean ASCII characters (of course, non-ASCII text can be
encoded as ASCII using the encoded-word construct from [RFC2047]) encoded as ASCII using the encoded-word construct from [RFC2047])
The HCP can compute val_out using any technique describable in The HCP can compute val_out using any technique describable in
pseudocode, such as copying a fixed string or invocations of other pseudocode, such as copying a fixed string or invocations of other
pseudocode functions. If it alters the value, it MUST NOT include pseudocode functions. If it alters the value, it MUST NOT include
control or NUL characters in val_out. val_out SHOULD match the control or NUL characters in val_out. val_out SHOULD match the
expected ABNF for the Header Field identified by name. expected ABNF for the Header Field identified by name.
3.1.1. HCP Avoids Changing From Header Field addr-spec 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
enable defense against possible email address spoofing (see enable defense against possible email address spoofing (see
Section 10.1). In particular, for hcp("From", val_in), the addr-spec Section 10.1). In particular, for hcp("From", val_in), the addr-spec
of val_in and the addr-spec of val_out SHOULD match according to of val_in and the addr-spec of val_out SHOULD match according to
Section 4.4.5, unless the sending MUA has additional knowledge Section 4.4.5, unless the sending MUA has additional knowledge
coordinated with the receiving MUA about more subtle addr-spec coordinated with the receiving MUA about more subtle addr-spec
equivalence or certificate validity. equivalence or certificate validity.
3.2. Initial Registered HCPs 3.2. Initial Registered HCPs
skipping to change at line 1118 skipping to change at line 1122
3.3. Default Header Confidentiality Policy 3.3. Default Header Confidentiality Policy
An MUA MUST have a default Header Confidentiality Policy that offers An MUA MUST have a default Header Confidentiality Policy that offers
confidentiality for the Subject Header Field at least. Local policy confidentiality for the Subject Header Field at least. Local policy
and configuration may alter this default, but the MUA SHOULD NOT and configuration may alter this default, but the MUA SHOULD NOT
require the user to select an HCP. require the user to select an HCP.
hcp_baseline provides confidentiality for the Subject Header Field by hcp_baseline provides confidentiality for the Subject Header Field by
replacing it with the literal string "[...]". It also provides replacing it with the literal string "[...]". It also provides
confidentiality for the other less common Informational Header Fields confidentiality for the other less common Informational Header Fields
(Comments and Keywords) by removing them entirely from the outer (Comments and Keywords) by removing them entirely from the Outer
Header Section. This is a sensible default because most users treat Header Section. This is a sensible default because most users treat
the Informational Fields of a message (particularly the Subject) the the Informational Fields of a message (particularly the Subject) the
same way that they treat the body, and they are surprised to find same way that they treat the Body, and they are surprised to find
that the Subject of an encrypted message is visible. that the Subject of an encrypted message is visible.
3.4. HCP Evolution 3.4. HCP Evolution
This document does not mandate any particular Header Confidentiality This document does not mandate any particular Header Confidentiality
Policy, though it offers guidance for MUA implementers in selecting Policy, though it offers guidance for MUA implementers in selecting
one in Section 3.3. Future documents may recommend or mandate such a one in Section 3.3. Future documents may recommend or mandate such a
policy for an MUA with specific needs. Such a recommendation might policy for an MUA with specific needs. Such a recommendation might
be motivated by descriptions of metadata-derived attacks, stem from be motivated by descriptions of metadata-derived attacks, stem from
research about message deliverability, or describe new signaling research about message deliverability, or describe new signaling
skipping to change at line 1177 skipping to change at line 1181
challenges and possible mitigations). challenges and possible mitigations).
When the proposed HCP produces any non-null output for a given Header When the proposed HCP produces any non-null output for a given Header
Field name, val_out SHOULD match the expected ABNF for that Header Field name, val_out SHOULD match the expected ABNF for that Header
Field. If the proposed HCP does not match the expected ABNF for that Field. If the proposed HCP does not match the expected ABNF for that
Header Field, the documentation should explicitly identify the Header Field, the documentation should explicitly identify the
relevant circumstances and provide a justification for the deviation. relevant circumstances and provide a justification for the deviation.
An entry should not be marked as "Recommended" unless it has been An entry should not be marked as "Recommended" unless it has been
shown to offer confidentiality or privacy improvements over the shown to offer confidentiality or privacy improvements over the
status quo and have minimal or mitigatory negative impact on messages status quo and have minimal or mitigable negative impact on messages
to which it is applied, considering factors such as message to which it is applied, considering factors such as message
deliverability and security. Only one entry in the table deliverability and security. Only one entry in the table
(hcp_baseline) is initially marked as "Recommended". In the future, (hcp_baseline) is initially marked as "Recommended". In the future,
more than one entry may be marked as "Recommended". more than one entry may be marked as "Recommended".
4. Receiving Guidance 4. Receiving Guidance
An MUA that receives a cryptographically protected email will render An MUA that receives a cryptographically protected email will render
it for the user. it for the user.
The receiving MUA will render the message body, render a selected The receiving MUA will render the message Body, render a selected
subset of Header Fields, and provide a summary of the cryptographic subset of Header Fields, and provide a summary of the cryptographic
properties of the message (as described in Section 3 of [RFC9787]). properties of the message (as described in Section 3 of [RFC9787]).
Most MUAs only render a subset of Header Fields by default. For Most MUAs only render a subset of Header Fields by default. For
example, most MUAs render the From, To, Cc, Date, and Subject Header example, most MUAs render the From, To, Cc, Date, and Subject Header
Fields to the user, but few render Message-Id or Received. Fields to the user, but few render Message-Id or Received.
An MUA that knows how to handle a message with Header Protection An MUA that knows how to handle a message with Header Protection
makes the following four changes to its behavior when rendering a makes the following four changes to its behavior when rendering a
message: message:
skipping to change at line 1220 skipping to change at line 1224
does render the value, the MUA SHOULD indicate that the does render the value, the MUA SHOULD indicate that the
rendered value is unprotected. For an exception to this, see rendered value is unprotected. For an exception to this, see
Section 7 for a discussion of some specific Header Fields that Section 7 for a discussion of some specific Header Fields that
are known to be added in transit and therefore are not expected are known to be added in transit and therefore are not expected
to have end-to-end cryptographic protections. to have 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 a message with confidential Header Fields, the
replying MUA avoids leaking any Header Fields that were replying MUA avoids leaking any Header Fields that were
confidential in the original into the cleartext of the reply. It confidential in the original into the cleartext of the reply. It
does this even if its own Header Confidentiality Policy would not does this even if its own Header Confidentiality Policy would not
have treated those Header Fields as confidential. See Section 6 have treated those Header Fields as confidential. See Section 6
for more details. 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
skipping to change at line 1259 skipping to change at line 1263
extracts a list of protected Header Fields (names and values), as extracts a list of protected Header Fields (names and values), as
well as a list of Header Fields that were added by the original 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 message sender in unprotected form to the outside of the message's
Cryptographic Envelope. Cryptographic Envelope.
The following algorithm takes reference message refmsg as input, The following algorithm takes reference 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 outputs a pair of lists of (h,v) Header Fields. cipher). It produces as output a pair of lists of (h,v) Header
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.
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.
skipping to change at line 1345 skipping to change at line 1350
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
Payload of msg. Payload of msg.
2. Compute (refouter, refprotected) from HeaderSetsFromMessage(msg). 2. Compute (refouter, refprotected) from HeaderSetsFromMessage(msg).
3. If (h, v) is not in refprotected: 3. If (h, v) is not in refprotected:
i. Abort, v is not a valid value for header h. i. Abort, v is not a valid value for Header Field h.
4. Let is_sig_valid be false. 4. Let is_sig_valid be false.
5. If the message is signed: 5. If the message is signed:
i. Let is_sig_valid be the result of validating the signature. i. Let is_sig_valid be the result of validating the signature.
6. If the message is encrypted, ct has a parameter hp="cipher", and 6. If the message is encrypted, and if ct has a parameter
(h,v) is not in refouter: hp="cipher", and if (h,v) is not in refouter:
i. Return signed-and-encrypted if is_sig_valid is otherwise i. Return signed-and-encrypted if is_sig_valid, otherwise return
encrypted-only. encrypted-only.
7. Return signed-only if is_sig_valid is otherwise unprotected. 7. Return signed-only if is_sig_valid, otherwise return unprotected.
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
skipping to change at line 1381 skipping to change at line 1386
* 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
unprotected Header Section is signed-only. unprotected Header Section is signed-only.
If the message has Header Protection, Header Fields that are not in If the message has Header Protection, Header Fields that are not in
refprotected (e.g., because they were added in transit) are 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
skipping to change at line 1431 skipping to change at line 1436
the actual outer Header Field (as seen by the MTA), not the value the actual outer Header Field (as seen by the MTA), not the value
indicated by any potential inner HP-Outer. indicated by any potential inner HP-Outer.
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
* the message has a broken signature, or * the message has a broken signature
* the message has a valid signature, but the receiving MUA does not * the message has a valid signature, but the receiving MUA does not
see any valid binding between the signing certificate and the see any valid binding between the signing certificate and the
addr-spec of the inner From Header Field. addr-spec of the inner From Header Field
Note: There are many possible ways that an MUA could choose to Note: There are many possible ways that an MUA could choose to
validate a certificate-to-address binding. For example, the MUA validate a certificate-to-address binding. For example, the MUA
could ensure the certificate is issued by one of a set of trusted could ensure the certificate is issued by one of a set of trusted
certification authorities, it could rely on the user to do a manual certification authorities, it could rely on the user to do a manual
out-of-band comparison, it could rely on a DNSSEC signal ([RFC7929] out-of-band comparison, it could rely on a DNSSEC signal ([RFC7929]
or [RFC8162]), and so on. It is beyond the scope of this document to or [RFC8162]), and so on. It is beyond the scope of this document to
describe all possible ways an MUA might validate the certificate-to- describe all possible ways an MUA might validate the certificate-to-
address binding or to choose among them. address binding or to choose among them.
4.4.2. Warning for From Header Field Mismatch 4.4.2. Warning for From Header Field Mismatch
To mitigate the above described risk of sender address spoofing, an To mitigate the above described risk of sender address spoofing, an
MUA SHOULD warn the user whenever both of the following conditions MUA SHOULD warn the user whenever both of the following conditions
are met: are met:
* From Header Field Mismatch (as defined in Section 4.4.1.1) * 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)
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) * 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.
skipping to change at line 1511 skipping to change at line 1516
change caused by a Reply-To in a Legacy Message does. change caused by a Reply-To in a Legacy Message does.
4.4.5. Matching addr-specs 4.4.5. Matching addr-specs
When generating (Section 3.1.1) or consuming (Section 4.4) a When generating (Section 3.1.1) or consuming (Section 4.4) a
protected From Header Field, the MUA considers the equivalence of two protected From Header Field, the MUA considers the equivalence of two
different addr-spec values. different addr-spec values.
First, the MUA MUST check whether the domain part of an addr-spec First, the MUA MUST check whether the domain part of an addr-spec
being compared contains a U-label [RFC5890]. If it does, it MUST be being compared contains a U-label [RFC5890]. If it does, it MUST be
converted to the A-label form, which is described in [RFC5891]. We converted to the A-label form as described in [RFC5891]. We call a
call a domain converted in this way (or the original domain if it domain converted in this way (or the original domain if it didn't
didn't contain any U-label) "the ASCII version of the domain part". contain any U-label) "the ASCII version of the domain part". Second,
Second, the MUA MUST compare the ASCII version of the domain part of the MUA MUST compare the ASCII version of the domain part of the two
the two addr-specs by standard DNS comparison: Assume ASCII text and addr-specs by standard DNS comparison: Assume ASCII text and compare
compare alphabetic characters case-insensitively, as described in alphabetic characters case-insensitively, as described in Section 3.1
Section 3.1 of [RFC1035]. If the domain parts match, then the two of [RFC1035]. If the domain parts match, then the two local-parts
local-parts are matched against each other. The simplest and most are matched against each other. The simplest and most common
common comparison for the local-part is also an ASCII-based, case- comparison for the local-part is also an ASCII-based, case-
insensitive match. If the MUA has special knowledge about the domain insensitive match. If the MUA has special knowledge about the domain
and, when composing, it can reasonably expect the receiving MUAs to and, when composing, it can reasonably expect the receiving MUAs to
have the same information, it MAY match the local-part using a more have the same information, it MAY match the local-part using a more
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 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
D └─╴text/html D └─╴text/html
The message body should be rendered the same way as this message: The message Body should be rendered the same way as this message:
B └┬╴multipart/alternative B └┬╴multipart/alternative
C ├─╴text/plain C ├─╴text/plain
D └─╴text/html D └─╴text/html
The MUA should render Header Fields taken from part B. The MUA should render Header Fields taken from part B.
Its Cryptographic Summary should indicate that the message was signed Its Cryptographic Summary should indicate that the message was signed
and all rendered Header Fields were included in the signature. and all rendered Header Fields were included in the signature.
skipping to change at line 1576 skipping to change at line 1581
validate the cryptographic signature: validate the cryptographic signature:
E └─╴application/pkcs7-mime; smime-type="enveloped-data" E └─╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to) ↧ (decrypts to)
F └─╴application/pkcs7-mime; smime-type="signed-data" F └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to) ⇩ (unwraps to)
G └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] G └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
H ├─╴text/plain H ├─╴text/plain
I └─╴text/html I └─╴text/html
The message body should be rendered the same way as this message: The message Body should be rendered the same way as this message:
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.
skipping to change at line 1646 skipping to change at line 1651
the Cryptographic Payload is a single part, that part itself may the Cryptographic Payload is a single part, that part itself may
contain a Legacy Display Element if it is marked with the hp-legacy- contain a Legacy Display Element if it is marked with the hp-legacy-
display="1" parameter. display="1" parameter.
4.5.3.2. Omitting Legacy Display Elements from text/plain 4.5.3.2. Omitting Legacy Display Elements from text/plain
If a text/plain part within the Cryptographic Payload has the If a text/plain part within the Cryptographic Payload has the
Content-Type parameter hp-legacy-display="1", it should be processed Content-Type parameter hp-legacy-display="1", it should be processed
before rendering in the following fashion: before rendering in the following fashion:
* Discard the leading lines of the body part up to and including the * Discard the leading lines of the Body part up to and including the
first entirely blank line. first entirely blank line.
Note that implementing this strategy is dependent on the charset used Note that implementing this strategy is dependent on the charset used
by the MIME part. by the MIME part.
See Appendix E.1 for an example. See Appendix E.1 for an example.
4.5.3.3. Omitting Legacy Display Elements from text/html 4.5.3.3. Omitting Legacy Display Elements from text/html
If a text/html part within the Cryptographic Payload has the Content- If a text/html part within the Cryptographic Payload has the Content-
skipping to change at line 1682 skipping to change at line 1687
While the From, To, Cc, Subject, and Date Header Fields are often While the From, To, Cc, Subject, and Date Header Fields are often
explicitly rendered to the user, some Header Fields do affect message explicitly rendered to the user, some Header Fields do affect message
display without being explicitly rendered. display without being explicitly rendered.
For example, the Message-Id, References, and In-Reply-To Header For example, the Message-Id, References, and In-Reply-To Header
Fields may collectively be used to place a message in a "thread" or Fields may collectively be used to place a message in a "thread" or
series of messages. series of messages.
In another example, Section 6.2 notes that the value of the Reply-To In another example, Section 6.2 notes that the value of the Reply-To
field can influence the draft reply message. So while the user may Header Field can influence the draft reply message. So while the
never see the Reply-To Header Field directly, it is implicitly user may never see the Reply-To Header Field directly, it is
"rendered" when the user interacts with the message by replying to implicitly "rendered" when the user interacts with the message by
it. replying to it.
An MUA that depends on any implicitly rendered Header Field in a An MUA that depends on any implicitly rendered Header Field in a
message with Header Protection MUST use the value from the protected message with Header Protection MUST use the value from the protected
Header Field and SHOULD NOT use any value found outside the Header Field and SHOULD NOT use any value found outside the
cryptographic protection unless it is known to be a Header Field cryptographic protection unless it is known to be a Header Field
added in transit, as specified in Section 7. added in transit, as specified in Section 7.
4.7. Handling Undecryptable Messages 4.7. Handling Undecryptable Messages
An MUA might receive an apparently encrypted message that it cannot An MUA might receive an apparently encrypted message that it cannot
skipping to change at line 1719 skipping to change at line 1724
might change if, say, References or In-Reply-To have been removed or might change if, say, References or In-Reply-To have been removed or
obscured (see Section 4.6). obscured (see Section 4.6).
Additionally, if the MUA does not retain access to the decrypting Additionally, if the MUA does not retain access to the decrypting
secret key, and it drops the decrypted form of a message, the secret key, and it drops the decrypted form of a message, the
message's rendering may revert to the encrypted form. For example, message's rendering may revert to the encrypted form. For example,
if an MUA follows this behavior, the Subject Header Field in a if an MUA follows this behavior, the Subject Header Field in a
mailbox summary might change from the real message subject back to mailbox summary might change from the real message subject back to
[...]. Or the message might be displayed outside of its current [...]. Or the message might be displayed outside of its current
thread if the MUA loses access to a removed References or In-Reply-To thread if the MUA loses access to a removed References or In-Reply-To
header. Header Field.
These behaviors are likely to surprise the user. However, an MUA has These behaviors are likely to surprise the user. However, an MUA has
several possible ways of reducing or avoiding all of these surprises, several possible ways of reducing or avoiding all of these surprises,
including: including:
* Ensuring that the MUA always has access to decryption-capable * Ensuring that the MUA always has access to decryption-capable
secret key material. secret key material.
* Rendering undecrypted messages in a special quarantine view until * Rendering undecrypted messages in a special quarantine view until
the decryption-capable secret key material is available. the decryption-capable secret key material is available.
skipping to change at line 1791 skipping to change at line 1796
the protected To Header Field does not contain that address, or there the protected To Header Field does not contain that address, or there
is no protected To Header Field, then the mailing list logs or is no protected To Header Field, then the mailing list logs or
reports the error and does not act on that control message. reports the error and does not act on that control message.
4.8.2. Ignore Legacy Display Elements 4.8.2. Ignore Legacy Display Elements
Consider the situation where an email-based control channel expects Consider the situation where an email-based control channel expects
to receive an end-to-end encrypted message -- for example, where the to receive an end-to-end encrypted message -- for example, where the
control messages need confidentiality guarantees -- and where the control messages need confidentiality guarantees -- and where the
action taken depends on the contents of some MIME part within the action taken depends on the contents of some MIME part within the
message body. message Body.
In this case, the automated system that decrypts the incoming In this case, the automated system that decrypts the incoming
messages and scans the relevant MIME part MUST identify when the MIME messages and scans the relevant MIME part MUST identify when the MIME
part contains a Legacy Display Element (see Section 4.5.3.1), and it part contains a Legacy Display Element (see Section 4.5.3.1), and it
MUST parse the relevant MIME part with the Legacy Display Element MUST parse the relevant MIME part with the Legacy Display Element
removed. removed.
For example, consider an administrative interface of a confidential For example, consider an administrative interface of a confidential
issue tracking software. An authorized user can confidentially issue tracking software. An authorized user can confidentially
adjust the status of a tracked issue by a specially formatted first adjust the status of a tracked issue by a specially formatted first
line of the message body (for example, severity #183 serious). When line of the message Body (for example, severity #183 serious). When
the user's MUA encrypts a plaintext control message to this issue the user's MUA encrypts a plaintext control message to this issue
tracker, depending on the MUA's HCP and its choice of legacy value, tracker, depending on the MUA's HCP and its choice of legacy value,
it may add a Legacy Display Element. If it does so, then the first it may add a Legacy Display Element. If it does so, then the first
line of the message body will contain a decorative copy of the line of the message Body will contain a decorative copy of the
confidential Subject Header Field. The issue tracking software confidential Subject Header Field. The issue tracking software
decrypts the incoming control message, identifies that there is a decrypts the incoming control message, identifies that there is a
Legacy Display Element in the part (see Section 4.5.3.1), strips the Legacy Display Element in the part (see Section 4.5.3.1), strips the
lines comprising the Legacy Display Element (including the first lines comprising the Legacy Display Element (including the first
blank line), and only then parses the remaining top line to look for blank line), and only then parses the remaining top line to look for
the expected special formatting. the expected special formatting.
4.9. Affordances for Debugging and Troubleshooting 4.9. Affordances for Debugging and Troubleshooting
Note that advanced users of an MUA may need access to the original Note that advanced users of an MUA may need access to the original
skipping to change at line 1891 skipping to change at line 1896
* Neither part C nor part D have any hp parameters set on their * Neither part C nor part D have any hp parameters set on their
Content-Type. Content-Type.
4.10.2. Rendering or Responding to an RFC8551HP Message 4.10.2. Rendering or Responding to an RFC8551HP Message
When an MUA has precisely identified a message as an RFC8551HP When an MUA has precisely identified a message as an RFC8551HP
message, the MUA MAY render or respond to that message as though it message, the MUA MAY render or respond to that message as though it
were a message with Header Protection as defined in this document by were a message with Header Protection as defined in this document by
making the following adjustments: making the following adjustments:
* Rather than rendering the message body as the Cryptographic * Rather than rendering the message Body as the Cryptographic
Payload itself (part C in the example above), render the RFC8551HP Payload itself (part C in the example above), render the RFC8551HP
message's body as the MIME subtree that is the Cryptographic message's Body as the MIME subtree that is the Cryptographic
Payload's immediate child (part D). Payload's immediate child (part D).
* Make a comparable modification to HeaderSetsFromMessage * Make a comparable modification to HeaderSetsFromMessage
(Section 4.2.1) and HeaderFieldProtection (Section 4.3.1): Both (Section 4.2.1) and HeaderFieldProtection (Section 4.3.1): Both
algorithms currently look for the protected Header Fields on the algorithms currently look for the protected Header Fields on the
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) message Header Fields (those found in part A in the example above)
rather than looking for HP-Outer Header Fields with the other rather than looking for HP-Outer Header Fields with the other
protected Header Fields. That is, infer Header Field protected Header Fields. That is, infer Header Field
confidentiality based on the unprotected headers. 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
Other MUAs may have generated different structures of messages that Other MUAs may have generated different structures of messages that
aim to offer end-to-end cryptographic protections that include Header aim to offer end-to-end cryptographic protections that include Header
Protection. This document is not normative for those schemes, and it Protection. This document is not normative for those schemes, and it
is NOT RECOMMENDED to generate these other schemes, as they can is NOT RECOMMENDED to generate these other schemes, as they can
either have structural flaws or simply render poorly on Legacy MUAs. either have structural flaws or simply render poorly on Legacy MUAs.
A conformant MUA MAY attempt to infer Header Protection when A conformant MUA MAY attempt to infer Header Protection when
skipping to change at line 1958 skipping to change at line 1963
5.1. Composing a Cryptographically Protected Message Without Header 5.1. Composing a Cryptographically Protected Message Without Header
Protection Protection
For contrast, we first consider the typical message composition For contrast, we first consider the typical message composition
process of a Legacy Crypto MUA, which does not provide any Header process of a Legacy Crypto MUA, which does not provide any Header
Protection. Protection.
This process is described in Section 5.1 of [RFC9787]. We replicate This process is described in Section 5.1 of [RFC9787]. We replicate
it here for reference. The inputs to the algorithm are: it here for reference. The inputs to the algorithm are:
* origbody: The traditional unprotected message body as a well- * origbody: The traditional unprotected message Body as a well-
formed MIME tree (possibly just a single MIME leaf part). As a formed MIME tree (possibly just a single MIME leaf part). As a
well-formed MIME tree, origbody already has structural Header well-formed MIME tree, origbody already has Structural Header
Fields (Content-*) present. Fields (Content-*) present.
* origheaders: The intended non-structural Header Fields for the * origheaders: The intended Non-Structural Header Fields for the
message, represented here as a list of (h,v) pairs, where h is a message, represented here as a list of (h,v) pairs, where h is a
Header Field name and v is the associated value. Note that these Header Field name and v is the associated value. Note that these
are Header Fields that the MUA intends to be visible to the are Header Fields that the MUA intends to be visible to the
recipient of the message. In particular, if the MUA uses the Bcc recipient of the message. In particular, if the MUA uses the Bcc
Header Field during composition but plans to omit it from the Header Field during composition but plans to omit it from the
message (see Section 3.6.3 of [RFC5322]), it will not be in message (see Section 3.6.3 of [RFC5322]), it will not be in
origheaders. origheaders.
* crypto: The series of cryptographic protections to apply (for * crypto: The series of cryptographic protections to apply (for
example, "sign with the secret key corresponding to X.509 example, "sign with the secret key corresponding to X.509
certificate X, then encrypt to X.509 certificates X and Y"). This certificate X, then encrypt to X.509 certificates X and Y"). This
is a routine that accepts a MIME tree as input (the Cryptographic is a routine that accepts a MIME tree as input (the Cryptographic
Payload), wraps the input in the appropriate Cryptographic Payload), wraps the input in the appropriate Cryptographic
Envelope, and returns the resultant MIME tree as output. Envelope, and returns the resultant MIME tree as output.
The algorithm returns a MIME object that is ready to be injected into The algorithm returns a MIME object that is ready to be injected into
the mail system. the mail system.
5.1.1. ComposeNoHeaderProtection 5.1.1. ComposeNoHeaderProtection
Method Signature: Method signature:
ComposeNoHeaderProtection(origbody, origheaders, crypto) -> ComposeNoHeaderProtection(origbody, origheaders, crypto) ->
mime_message mime_message
Procedure: Procedure:
1. Apply crypto to MIME part origbody, producing MIME tree output. 1. Apply crypto to MIME part origbody, producing MIME tree output.
2. For each Header Field name and value (h,v) in origheaders: 2. For each Header Field name and value (h,v) in origheaders:
skipping to change at line 2037 skipping to change at line 2042
two mechanisms for such a decorative adjustment: one for a text/html two mechanisms for such a decorative adjustment: one for a text/html
Main Body Part of the email message and one for a text/plain Main Main Body Part of the email message and one for a text/plain Main
Body Part. This document does not recommend adding a Legacy Display Body Part. This document does not recommend adding a Legacy Display
Element to any other part. 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
Procedure: Procedure:
1. Let newbody be a copy of origbody. 1. Let newbody be a copy of origbody.
2. If crypto contains encryption and legacy is true: 2. If crypto contains encryption and legacy is true:
skipping to change at line 2061 skipping to change at line 2066
a. If h is User-Facing (see Section 1.1.2 of [RFC9787]): a. If h is User-Facing (see Section 1.1.2 of [RFC9787]):
I. If hcp(h,v) is not v: I. If hcp(h,v) is not v:
A. Add (h,v) to ldlist. A. Add (h,v) to ldlist.
iii. If ldlist is not empty: iii. If ldlist is not empty:
a. Identify each leaf MIME part of newbody that represents a. Identify each leaf MIME part of newbody that represents
the "main body" of the message. the "main Body" of the message.
b. For each "Main Body Part" bodypart of type text/plain b. For each "Main Body Part" bodypart of type text/plain
or text/html: or text/html:
I. Adjust bodypart by inserting a Legacy Display I. Adjust bodypart by inserting a Legacy Display
Element header list ldlist into its content and Element Header Field list ldlist into its content
adding a Content-Type parameter hp-legacy-display and adding a Content-Type parameter hp-legacy-
with value 1 (see Section 5.2.2 for text/plain and display with value 1 (see Section 5.2.2 for text/
Section 5.2.3 for text/html). plain and Section 5.2.3 for text/html).
3. For each Header Field name and value (h,v) in origheaders: 3. For each Header Field name and value (h,v) in origheaders:
i. Add Header Field h to MIME part newbody with value v. i. Add Header Field h to MIME part newbody with value v.
4. If crypto does not contain encryption: 4. If crypto does not contain 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 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. If refmsg is not null, respond is not null, and refmsg
itself is encrypted with header protection: itself is encrypted with Header Protection:
a. Let response_hcp be a single-use HCP derived from a. Let response_hcp be a single-use HCP derived from
respond and refmsg (see Section 6.1). respond and refmsg (see Section 6.1).
iii. Else (if this is not a response to an encrypted, header- iii. Else (if this is not a response to an encrypted, header-
protected message): protected message):
a. Set response_hcp to hcp_no_confidentiality. a. Set response_hcp to hcp_no_confidentiality.
iv. Create a new empty list of Header Field names and values iv. 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: v. 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: vi. 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
skipping to change at line 2142 skipping to change at line 2147
ignored if crypto does not contain encryption. This is by design, ignored if crypto does not contain encryption. This is by design,
because they are irrelevant for signed-only cryptographic because they are irrelevant for signed-only cryptographic
protections. protections.
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
For a list of obscured and removed User-Facing Header Fields For a list of obscured and removed User-Facing Header Fields
represented as (header, value) pairs, concatenate them as a set of represented as (header, value) pairs, concatenate them as a set of
lines, with one newline at the end of each pair. Add an additional lines, with one newline at the end of each pair. Add an additional
trailing newline after the resultant text, and prepend the entire trailing newline after the resultant text, and prepend the entire
list to the body of the text/plain part. list to the Body of the text/plain part.
The MUA MUST also add a Content-Type parameter of hp-legacy-display The MUA MUST also add a Content-Type parameter of hp-legacy-display
with value 1 to the MIME part to indicate that a Legacy Display with value 1 to the MIME part to indicate that a Legacy Display
Element was added. Element was added.
For example, if the list of obscured Header Fields was [("Cc", For example, if the list of obscured Header Fields was [("Cc",
"alice@example.net"), ("Subject", "Thursday's meeting")], then a "alice@example.net"), ("Subject", "Thursday's meeting")], then a
text/plain Main Body Part that originally looked like this: text/plain Main Body Part that originally looked like this:
Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset=UTF-8
skipping to change at line 2165 skipping to change at line 2170
would become: would become:
Content-Type: text/plain; charset=UTF-8; hp-legacy-display=1 Content-Type: text/plain; charset=UTF-8; hp-legacy-display=1
Subject: Thursday's meeting Subject: Thursday's meeting
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 Elements (the lines beginning with Note that the Legacy Display Element (the lines beginning with
Subject: and Cc:) are part of the body of the MIME part in question. Subject: and Cc:) is part of the Body of the MIME part in 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 no
additional Header Fields have been injected into the MIME part in additional Header Fields have been injected into the MIME part in
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
skipping to change at line 2277 skipping to change at line 2282
not descend via the first child of any of its multipart/mixed or not descend via the first child of any of its multipart/mixed or
multipart/related ancestors, it is not a Main Body Part and MUST NOT multipart/related ancestors, it is not a Main Body Part and MUST NOT
be modified. be modified.
See Section 7.1 of [RFC9787] for more guidance about common ways to See Section 7.1 of [RFC9787] for more guidance about common ways to
distinguish Main Body Parts from other MIME parts in a message. distinguish Main Body Parts from other MIME parts in a message.
5.2.5. Do Not Add a Legacy Display Element to Other Content-Types 5.2.5. Do Not Add a Legacy Display Element to Other Content-Types
The purpose of injecting a Legacy Display Element into each Main Body The purpose of injecting a Legacy Display Element into each Main Body
MIME part is to enable rendering of otherwise obscured Header Fields Part is to enable rendering of otherwise obscured Header Fields in
in Legacy MUAs that are capable of message decryption but don't know Legacy MUAs that are capable of message decryption but don't know how
how to follow the rest of the guidance in this document. to follow the rest of the guidance in this document.
The authors are unaware of any Legacy MUA that would render any MIME The authors are unaware of any Legacy MUA that would render any MIME
part type other than text/plain and text/html as the Main Body. A part type other than text/plain and text/html as the Main Body. A
generating MUA SHOULD NOT add a Legacy Display Element to any MIME generating MUA SHOULD NOT add a Legacy Display Element to any MIME
part with any other Content-Type. part with any other Content-Type.
6. Replying and Forwarding Guidance 6. Replying and Forwarding Guidance
An MUA might create a new message in response to another message, An MUA might create a new message in response to another message,
thus acting both as a receiving MUA and as a sending MUA. For thus acting both as a receiving MUA and as a sending MUA. For
skipping to change at line 2328 skipping to change at line 2333
that Header Fields derived from the reference message do not leak in that Header Fields derived from the reference message do not leak in
the reply. the reply.
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 reference message. For example, the To Header
Field is typically derived from the reference message's Reply-To or Field is typically derived from the reference message's Reply-To or
From Header Fields. When generating the outer copy of the Header From Header Fields. When generating the outer copy of the Header
Field, the composing MUA first applies its own Header Confidentiality Field, the composing MUA first applies its own Header Confidentiality
Policy. If the Header Field's value is changed by the HCP, then it Policy. If the Header Field's value is changed by the HCP, then it
is applied to the outside header. If the Header Field's value is is applied to the Outer Header Section. If the Header Field's value
unchanged, the composing MUA regenerates the Header Field using the is unchanged, the composing MUA re-generates the Header Field using
Header Fields that had been on the outside of the original message at the Header Fields that had been on the outside of the original
sending time. These can be inferred from the HP-Outer Header Fields message at sending time. These can be inferred from the HP-Outer
located within the Cryptographic Payload of the referenced message. Header Fields located within the Cryptographic Payload of the
If that value is itself different than the protected value, then it referenced message. If that value is itself different than the
is applied to the outside header. If the value is the same as the protected value, then it is applied to the Outer Header Section. If
protected value, then it is simply copied to the outside header the value is the same as the protected value, then it is simply
directly. Whether it was changed or not, it is noted in the copied to the Outer Header Section directly. Whether it was changed
protected Header Section using HP-Outer, as described in or not, it is noted in the protected Header Section using HP-Outer,
Section 2.2.1. 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 Header Confidentiality Policy message even if the sender's choice of Header Confidentiality Policy
wouldn't normally remove or obscure the Header Field in question. wouldn't normally remove or obscure the Header Field in question.
This is effectively a single-use HCP. The normal sending guidance in This is effectively a single-use HCP. The normal sending guidance in
Section 5.2 applies this single-use HCP to implement the high-level Section 5.2 applies this single-use HCP to implement the high-level
guidance above. guidance above.
6.1.1. ReferenceHCP 6.1.1. ReferenceHCP
The algorithm takes two inputs: The algorithm takes two inputs:
* A single referenced message refmsg * A single referenced message refmsg
* A built-in MUA respond function associated with the user's action. * A built-in MUA respond function associated with the user's action.
The respond function takes a list of headers from a referenced The respond function takes a list of Header Fields from a
message as input and generates a list of initial candidate message referenced message as input and generates a list of initial
Header Field names and values that are used to populate the candidate message Header Field names and values that are used to
message composition interface. Something like this function populate the message composition interface. Something like this
already exists in most MUAs, though it may differ across function already exists in most MUAs, though it may differ across
responsive actions. For example, the respond function that responsive actions. For example, the respond function that
implements "Reply All" is likely to be a different from the implements "Reply All" is likely to be a different from the
respond that implements "Reply". respond that implements "Reply".
As an output, it produces an ephemeral single-use Header As an output, it produces an ephemeral single-use Header
Confidentiality Policy, specific to this kind of response to this Confidentiality Policy, specific to this kind of response to this
specific message. specific message.
Method signature: Method signature:
skipping to change at line 2518 skipping to change at line 2523
* List-Post * List-Post
* Archived-At * Archived-At
For some MUAs, these Header Fields are implicitly rendered by For some MUAs, these Header Fields are implicitly rendered by
providing buttons for actions like "Subscribe", "View Archived providing buttons for actions like "Subscribe", "View Archived
Version", "Reply List", "List Info", etc. Version", "Reply List", "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 unprotected section and that has reason to these Header Fields in the unprotected Header Section and that has
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 2547 skipping to change at line 2552
8.1. Dropping Legacy Display Elements 8.1. Dropping Legacy Display Elements
Any decorative Legacy Display Element added to an encrypted message Any decorative Legacy Display Element added to an encrypted message
that uses Header Protection is present strictly for enabling Header that uses Header Protection is present strictly for enabling Header
Field visibility (most importantly, the Subject Header Field) when Field visibility (most importantly, the Subject Header Field) when
the message is viewed with a decryption-capable Legacy MUA. the message is viewed with a decryption-capable Legacy MUA.
Eventually, the hope is that most decryption-capable MUAs will Eventually, the hope is that most decryption-capable MUAs will
conform to this specification and there will be no need for injection conform to this specification and there will be no need for injection
of Legacy Display Elements in the message body. A survey of widely of Legacy Display Elements in the message Body. A survey of widely
used decryption-capable MUAs might be able to establish when most of used decryption-capable MUAs might be able to establish when most of
them do support this specification. them do support this specification.
At that point, a composing MUA could set the legacy parameter defined At that point, a composing MUA could set the legacy parameter defined
in Section 5.2 to false by default or could even hard-code it to in Section 5.2 to false by default or could even hard-code it to
false, yielding a much simpler message construction set. false, yielding a much simpler message construction set.
Until that point, an end user might want to signal that their Until that point, an end user might want to signal that their
receiving MUAs are conformant to this document so that a peer receiving MUAs are conformant to this document so that a peer
composing a message to them can set legacy to false. A signal composing a message to them can set legacy to false. A signal
skipping to change at line 2736 skipping to change at line 2741
The security considerations from Section 6 of [RFC8551] continue to The security considerations from Section 6 of [RFC8551] continue to
apply for any MUA that offers S/MIME cryptographic protections, as apply for any MUA that offers S/MIME cryptographic protections, as
well as Section 3 of [RFC5083] (Authenticated-Enveloped-Data in well as Section 3 of [RFC5083] (Authenticated-Enveloped-Data in
Cryptographic Message Syntax (CMS)) and Section 14 of [RFC5652] (CMS Cryptographic Message Syntax (CMS)) and Section 14 of [RFC5652] (CMS
more broadly). Likewise, the security considerations from Section 8 more broadly). Likewise, the security considerations from Section 8
of [RFC3156] continue to apply for any MUA that offers PGP/MIME of [RFC3156] continue to apply for any MUA that offers PGP/MIME
cryptographic protections, as well as Section 13 of [RFC9580] cryptographic protections, as well as Section 13 of [RFC9580]
(OpenPGP itself). In addition, these underlying security (OpenPGP itself). In addition, these underlying security
considerations are now also applicable to the contents of the message considerations are now also applicable to the contents of the message
header, not just the message body. Header Section, not just the message Body.
10.1. From Address Spoofing 10.1. From Address Spoofing
If the From Header Field was treated like any other protected Header If the From Header Field was treated like any other protected Header
Field by the receiving MUA, this scheme would enable sender address Field by the receiving MUA, this scheme would enable sender address
spoofing. 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 unprotected Header Section and their receiving MTA to inspect the unprotected Header Section and
verify that the From Header Field is authentic. If a receiving MUA verify that the From Header Field is authentic. If a receiving MUA
skipping to change at line 2791 skipping to change at line 2796
* 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) * 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.
This may seem surprising since it causes the MUA to render a mix of This may seem surprising since it causes the MUA to render a mix of
both protected and unprotected values. This section provides an both protected and unprotected values. This section provides an
skipping to change at line 2941 skipping to change at line 2946
sender. In such a case, the receiving MUA SHOULD treat every Header sender. In such a case, the receiving MUA SHOULD treat every Header
Field as though it was not confidential. 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 to contain risky data that could trigger errors in a rendering
client. 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 value was with a single space character. Likewise, if the Header Field value
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), any newline MUST be stripped from the Legacy Display
Element. If the pair of newlines is not stripped, a receiving MUA Element. If the pair of newlines is not stripped, a receiving MUA
that follows the guidance in Section 4.5.3.2 might leave the later that follows the guidance in Section 4.5.3.2 might leave the later
part of the Legacy Display Element in the rendered message. 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 values should be Section 5.2.3), any material in the Header Field values should 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 & should be escaped to &lt;,
&gt;, and &amp;, respectively (for example, see [HTML-ESCAPES]). If &gt;, and &amp;, respectively (for example, see [HTML-ESCAPES]). If
unescaped characters from removed or obscured header values end up in unescaped characters from removed or obscured Header Field values end
the Legacy Display Element, a receiving MUA that follows the guidance up in the Legacy Display Element, a receiving MUA that follows the
in Section 4.5.3.3 might fail to identify the boundaries of the guidance in Section 4.5.3.3 might fail to identify the boundaries of
Legacy Display Element, cutting out more than it should or leaving the Legacy Display Element, cutting out more than it should or
remnants visible. And a Legacy MUA parsing such a message might leaving remnants visible. And a Legacy MUA parsing such a message
misrender the entire HTML stream, depending on the content of the might misrender the entire HTML stream, depending on the content of
removed or obscured header values. 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
headers 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 headers increases the amount of known plaintext. Since some of those Header
in a reply will be derived from the message being replied to, this Fields in a reply will be derived from the message being replied to,
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.
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 3020 skipping to change at line 3025
being inside the Cryptographic Envelope. being inside the Cryptographic Envelope.
A Header Field whose name and value are not matched verbatim by any A Header Field whose name and value are not matched verbatim by any
HP-Outer Header Field from the same part will have an encrypted-only HP-Outer Header Field from the same part will have an encrypted-only
or signed-and-encrypted status. But even Header Fields with these or signed-and-encrypted status. But even Header Fields with these
stronger levels of cryptographic confidentiality protection might not stronger levels of cryptographic confidentiality protection might not
be as private as the user would like. be as private as the user would like.
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.
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 encrypted messages, even with an ambitious HCP that successfully
obscures most Header Fields from all transport agents, Header Fields obscures most Header Fields from all transport agents, Header Fields
will be ultimately visible to all intended recipients. This can be will be ultimately visible to all intended recipients. This can be
especially problematic for Header Fields that are not user-facing, especially problematic for Header Fields that are not User-Facing;
which the sender may not expect to be injected by their MUA. the sender may not expect such Header Fields to be injected by their
Consider the three following examples: 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 the
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, which could embed the choice of MUA, time zone, hostname, Header Field, which could embed the choice of MUA, time zone,
or other subtle information to a knowledgeable recipient. hostname, or other subtle information to a knowledgeable
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 the 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 the
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 the
skipping to change at line 3085 skipping to change at line 3091
Furthermore, encrypted message ciphertext may hint at the recipients: Furthermore, encrypted message ciphertext may hint at the recipients:
For S/MIME messages, the RecipientInfo, and for PGP/MIME messages, For S/MIME messages, the RecipientInfo, and for PGP/MIME messages,
the key ID in the Public Key Encrypted Session Key (PKESK) packets the key ID in the Public Key Encrypted Session Key (PKESK) packets
will all hint at a specific set of recipients. Additionally, an MTA will all hint at a specific set of recipients. Additionally, an MTA
that handles the message may add a Received Header Field (or some that handles the message may add a Received Header Field (or some
other custom Header Field) that leaks some information about the other custom Header Field) that leaks some information about the
nature of the delivery. nature of the delivery.
11.2.3. Encrypted Header Fields May Not Be Fully Masked by HCP 11.2.3. Encrypted Header Fields May Not Be Fully Masked by HCP
In another example, if the HCP modifies the Date header to mask out In another example, if the HCP modifies the Date Header Field to mask
high-resolution timestamps (e.g., rounding to the most recent hour), out high-resolution timestamps (e.g., rounding to the most recent
some information about the date of delivery will still be attached to hour), some information about the date of delivery will still be
the email. At the very least, the low-resolution, global version of attached to the email. At the very least, the low-resolution, global
the date will be present on the message. Additionally, Header Fields version of the date will be present on the message. Additionally,
like Received that are added during message delivery might include Header Fields like Received that are added during message delivery
higher-resolution timestamps. And if the message lands in a mailbox might include higher-resolution timestamps. And if the message lands
that is ordered by time of receipt, even its placement in the mailbox in a mailbox that is ordered by time of receipt, even its placement
and the unobscured Date Header Fields of the surrounding messages in the mailbox and the unobscured Date Header Fields of the
could leak this information. surrounding messages could leak this information.
Some Header Fields like From may be impossible to fully obscure, as Some Header Fields like From may be impossible to fully obscure, as
many modern message delivery systems depend on at least domain many modern message delivery systems depend on at least domain
information in the From Header Field for determining whether a information in the From Header Field for determining whether a
message is coming from a domain with "good reputation" (that is, from message is coming from a domain with "good reputation" (that is, from
a domain that is not known for leaking spam). So even if an a domain that is not known for leaking spam). So even if an
ambitious HCP opts to remove the human-readable part from any From ambitious HCP opts to remove the human-readable part from any From
Header Field and to standardize/genericize the local part of the From Header Field and to standardize/genericize the local part of the From
address, the domain will still leak. address, the domain will still leak.
skipping to change at line 3191 skipping to change at line 3197
+===================+==========+==========+===============+ +===================+==========+==========+===============+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+===================+==========+==========+===============+ +===================+==========+==========+===============+
| HP-Outer | mail | standard | Section 2.2.1 | | HP-Outer | mail | standard | Section 2.2.1 |
| | | | of RFC 9788 | | | | | of RFC 9788 |
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
Table 2: Addition to the Permanent Message Header Field Table 2: Addition to the Permanent Message Header Field
Names Registry Names Registry
The Author/Change Controller of these two entries (Section 4.5 of Note that the Template and Trace columns are empty and therefore not
[RFC3864]) should be the IETF itself. included in the table.
The Author/Change Controller (Section 4.5 of [RFC3864]) for this
entry is the IETF.
12.2. Reference Update for the Content-Type Header Field 12.2. Reference Update for the Content-Type Header Field
This document defines the Content-Type parameters known as hp (in This document defines the Content-Type parameters known as hp (in
Section 2.1.1) and hp-legacy-display (in Section 2.1.2). Section 2.1.1) and hp-legacy-display (in Section 2.1.2).
Consequently, this document has been added as a reference for Consequently, IANA has added this document as a reference for
Content-Type in the "Permanent Message Header Field Names" registry Content-Type in the "Permanent Message Header Field Names" registry
as shown below. as shown below.
+===================+==========+========================+ +===================+==========+========================+
| Header Field Name | Protocol | Reference | | Header Field Name | Protocol | Reference |
+===================+==========+========================+ +===================+==========+========================+
| Content-Type | MIME | [RFC4021] and RFC 9788 | | Content-Type | MIME | [RFC4021] and RFC 9788 |
+-------------------+----------+------------------------+ +-------------------+----------+------------------------+
Table 3: Permanent Message Header Field Names Registry Table 3: Permanent Message Header Field Names Registry
Note that the Template and Trace columns are empty and therefore not
included in the table.
12.3. New Mail Header Confidentiality Policies Registry 12.3. New Mail Header Confidentiality Policies Registry
IANA has created a new registry titled "Mail Header Confidentiality IANA has created a new registry titled "Mail Header Confidentiality
Policies" within the "MAIL Parameters" registry group Policies" within the "MAIL Parameters" registry group
<https://www.iana.org/assignments/mail-parameters/> with the <https://www.iana.org/assignments/mail-parameters/> with the
following content: following content:
+========================+=================+=============+=========+ +========================+=================+=============+=========+
| Header Confidentiality | Description | Recommended |Reference| | Header Confidentiality | Description | Recommended |Reference|
| Policy Name | | | | | Policy Name | | | |
skipping to change at line 3475 skipping to change at line 3487
| 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.1 |
| | 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 |
| | end-to-end | 5.2.1 | | | end-to-end | 5.2.1 |
| | cryptographic | | | | cryptographic | |
| | protections including | | | | protections including | |
| | header protection | | | | Header Protection | |
+---------------------------+-------------------------+-----------+ +---------------------------+-------------------------+-----------+
Table 5: Table of Pseudocode Listings Table 5: Table of Pseudocode Listings
Appendix B. Possible Problems with Legacy MUAs Appendix B. Possible Problems with Legacy MUAs
When an email message with end-to-end cryptographic protection is When an email message with end-to-end cryptographic protection is
received by a MUA, the user might experience many different possible received by a MUA, the user might experience many different possible
problematic interactions. A message with Header Protection may problematic interactions. A message with Header Protection may
introduce new forms of user experience failure. introduce new forms of user experience failure.
skipping to change at line 3522 skipping to change at line 3534
* 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
* Unprotected Subject is visible * Unprotected Subject is visible
* Protected Subject (on its own) is visible in the body * Protected Subject (on its own) is visible in the Body
* Protected Subject, Date, From, and To Header Fields are visible in * Protected Subject, Date, From, and To Header Fields are visible in
the body the Body
* User interaction needed to view the whole message * User interaction needed to view the whole message
* User interaction needed to view the message body * User interaction needed to view the message Body
* User interaction needed to view the protected Subject * User interaction needed to view the protected Subject
* Impossible to view the protected Subject * Impossible to view the protected Subject
* Nuisance alarms during user interaction * Nuisance alarms during user interaction
* Impossible to view the message body * Impossible to view the message Body
* Appears as a forwarded message * Appears as a forwarded message
* Appears as an attachment * Appears as an attachment
* Security indicators not visible * Security indicators not visible
* Security indicators do not identify the protection status of * Security indicators do not identify the protection status of
Header Fields Header Fields
* User has multiple different methods to reply (e.g., reply to * User has multiple different methods to reply (e.g., reply to
outer, reply to inner) outer, reply to inner)
* User sees English "Subject:" in body despite message itself being * User sees English "Subject:" in Body despite message itself being
in non-English in non-English
* Security indicators do not identify the protection status of * Security indicators do not identify the protection status of
Header Fields Header Fields
* Header Fields in the body render with local Header Field names * Header Fields in the Body render with local Header Field names
(e.g., showing "Betreff" instead of "Subject") and dates (TZ, (e.g., showing "Betreff" instead of "Subject") and dates (TZ,
locale) locale)
B.3. Problems When Replying to a Message B.3. Problems When Replying to a Message
Note that the use case here is: Note that the use case here is:
* User views a message, to the point where they can read it * User views a message, to the point where they can read it
* User then replies to the message, and they are shown a message * User then replies to the message, and they are shown a message
skipping to change at line 3586 skipping to change at line 3598
* Unprotected Subject is in UI:subject (instead of the protected * Unprotected Subject is in UI:subject (instead of the protected
Subject) Subject)
* Protected Subject is quoted in UI:body (from Legacy Display * Protected Subject is quoted in UI:body (from Legacy Display
Element) Element)
* Protected Subject leaks when the reply is serialized into MIME * Protected Subject leaks when the reply is serialized into MIME
* Protected Subject is not anywhere in UI * Protected Subject is not anywhere in UI
* Message body is _not_ visible/quoted in UI:body * Message Body is _not_ visible/quoted in UI:body
* User cannot reply while viewing protected message * User cannot reply while viewing protected message
* Reply is not encrypted by default (but is for legacy signed-and- * Reply is not encrypted by default (but is for legacy signed-and-
encrypted messages without Header Protection) encrypted messages without Header Protection)
* Unprotected From or Reply-To Header Field is in UI:To (instead of * Unprotected From or Reply-To Header Field is in UI:To (instead of
the protected From or Reply-To Header Field) the protected From or Reply-To Header Field)
* User's locale (lang, TZ) leaks in quoted body * User's locale (lang, TZ) leaks in quoted Body
* Header Fields not protected (and in particular, Subject is not * Header Fields not protected (and in particular, Subject is not
obscured) by default obscured) by default
Appendix C. Test Vectors Appendix C. Test Vectors
This section contains sample messages using the specification defined This section contains sample messages using the specification defined
above. Each sample contains a MIME object, a textual and above. Each sample contains a MIME object, a textual and
diagrammatic view of its structure, and examples of how an MUA might diagrammatic view of its structure, and examples of how an MUA might
render it. render it.
skipping to change at line 3623 skipping to change at line 3635
authenticate to this read-only IMAP mailbox). authenticate to this read-only IMAP mailbox).
Copies of these test vectors can also be downloaded separately at Copies of these test vectors can also be downloaded separately at
<https://header-protection.cmrg.net>. <https://header-protection.cmrg.net>.
If any of the messages downloaded differ from those offered here, If any of the messages downloaded differ from those offered here,
this document is the canonical source. this document is the canonical source.
C.1. Baseline Messages C.1. Baseline Messages
These messages offer no header protection at all and can be used as a These messages offer no Header Protection at all and can be used as a
baseline. They are provided in this document as a counterexample. baseline. They are provided in this document as a counterexample.
An MUA implementer can use these messages to verify that the reported An MUA implementer can use these Messages to verify that the reported
cryptographic summary of the message indicates no header protection. Cryptographic Summary of the Message indicates no Header Protection.
C.1.1. No Cryptographic Protections over a Simple Message C.1.1. No Cryptographic Protections over a Simple Message
This message uses no cryptographic protection at all. Its body is a This message uses no cryptographic protection at all. Its Body is a
text/plain message. text/plain message.
It has the following structure: It has the following structure:
└─╴text/plain 152 bytes └─╴text/plain 152 bytes
Its contents are: Its contents are:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8" Content-Type: text/plain; charset="utf-8"
skipping to change at line 3664 skipping to change at line 3676
is a text/plain message. is a text/plain message.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.1.2. S/MIME Signed-Only signedData over a Simple Message, No Header C.1.2. S/MIME Signed-Only signedData over a Simple Message, No Header
Protection Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a text/plain message. It uses no header protection. payload is a text/plain message. It uses no Header Protection.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 3856 bytes └─╴application/pkcs7-mime [smime.p7m] 3856 bytes
⇩ (unwraps to) ⇩ (unwraps to)
└─╴text/plain 206 bytes └─╴text/plain 206 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
skipping to change at line 3770 skipping to change at line 3782
-- --
Alice Alice
alice@smime.example alice@smime.example
C.1.3. S/MIME Signed-Only multipart/signed over a Simple Message, No C.1.3. S/MIME Signed-Only multipart/signed over a Simple Message, No
Header Protection Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature This is a signed-only S/MIME message via PKCS#7 detached signature
(multipart/signed). The payload is a text/plain message. It uses no (multipart/signed). The payload is a text/plain message. It uses no
header protection. Header Protection.
It has the following structure: It has the following structure:
└┬╴multipart/signed 4187 bytes └┬╴multipart/signed 4187 bytes
├─╴text/plain 224 bytes ├─╴text/plain 224 bytes
└─╴application/pkcs7-signature [smime.p7s] 3429 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes
Its contents are: Its contents are:
MIME-Version: 1.0 MIME-Version: 1.0
skipping to change at line 3873 skipping to change at line 3885
WqmOyrup6DH4Gb84By+0IMk3vflrOyAw3kbsj6Ij+zymAlH61YypnAvddFBIuZPL WqmOyrup6DH4Gb84By+0IMk3vflrOyAw3kbsj6Ij+zymAlH61YypnAvddFBIuZPL
2LYdIHPLmq8KGrzcgjkjP+Y58hf9U+6gp0KPuS8DAGOvxYs0 2LYdIHPLmq8KGrzcgjkjP+Y58hf9U+6gp0KPuS8DAGOvxYs0
--253-- --253--
C.1.4. S/MIME Signed and Encrypted over a Simple Message, No Header C.1.4. S/MIME Signed and Encrypted over a Simple Message, No Header
Protection Protection
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses no header protection. message. It uses no Header Protection.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 6720 bytes └─╴application/pkcs7-mime [smime.p7m] 6720 bytes
↧ (decrypts to) ↧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 3960 bytes └─╴application/pkcs7-mime [smime.p7m] 3960 bytes
⇩ (unwraps to) ⇩ (unwraps to)
└─╴text/plain 241 bytes └─╴text/plain 241 bytes
Its contents are: Its contents are:
skipping to change at line 4093 skipping to change at line 4105
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses no header protection. message. It uses no header protection.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.1.5. No Cryptographic Protections over a Complex Message C.1.5. No Cryptographic Protections over a Complex Message
This message uses no cryptographic protection at all. Its body is a This message uses no cryptographic protection at all. Its Body is a
multipart/alternative message with an inline image/png attachment. multipart/alternative message with an inline image/png attachment.
It has the following structure: It has the following structure:
└┬╴multipart/mixed 1402 bytes └┬╴multipart/mixed 1402 bytes
├┬╴multipart/alternative 794 bytes ├┬╴multipart/alternative 794 bytes
│├─╴text/plain 206 bytes │├─╴text/plain 206 bytes
│└─╴text/html 304 bytes │└─╴text/html 304 bytes
└─╴image/png inline 232 bytes └─╴image/png inline 232 bytes
skipping to change at line 4167 skipping to change at line 4179
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--e68-- --e68--
C.1.6. S/MIME Signed-Only signedData over a Complex Message, No Header C.1.6. S/MIME Signed-Only signedData over a Complex Message, No Header
Protection Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a multipart/alternative message with an inline image/png payload is a multipart/alternative message with an inline image/png
attachment. It uses no header protection. attachment. It uses no Header Protection.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 5253 bytes └─╴application/pkcs7-mime [smime.p7m] 5253 bytes
⇩ (unwraps to) ⇩ (unwraps to)
└┬╴multipart/mixed 1288 bytes └┬╴multipart/mixed 1288 bytes
├┬╴multipart/alternative 882 bytes ├┬╴multipart/alternative 882 bytes
│├─╴text/plain 260 bytes │├─╴text/plain 260 bytes
│└─╴text/html 355 bytes │└─╴text/html 355 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
skipping to change at line 4333 skipping to change at line 4345
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--533-- --533--
C.1.7. S/MIME Signed-Only multipart/signed over a Complex Message, No C.1.7. S/MIME Signed-Only multipart/signed over a Complex Message, No
Header Protection Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature This is a signed-only S/MIME message via PKCS#7 detached signature
(multipart/signed). The payload is a multipart/alternative message (multipart/signed). The payload is a multipart/alternative message
with an inline image/png attachment. It uses no header protection. with an inline image/png attachment. It uses no Header Protection.
It has the following structure: It has the following structure:
└┬╴multipart/signed 5230 bytes └┬╴multipart/signed 5230 bytes
├┬╴multipart/mixed 1344 bytes ├┬╴multipart/mixed 1344 bytes
│├┬╴multipart/alternative 938 bytes │├┬╴multipart/alternative 938 bytes
││├─╴text/plain 278 bytes ││├─╴text/plain 278 bytes
││└─╴text/html 376 bytes ││└─╴text/html 376 bytes
│└─╴image/png inline 232 bytes │└─╴image/png inline 232 bytes
└─╴application/pkcs7-signature [smime.p7s] 3429 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes
skipping to change at line 4477 skipping to change at line 4489
6NdLvgw4mZmSSiOyOlfKo3cgo4rZuN6CeLCgqZ0GjIJS43v+ 6NdLvgw4mZmSSiOyOlfKo3cgo4rZuN6CeLCgqZ0GjIJS43v+
--4e5-- --4e5--
C.1.8. S/MIME Signed and Encrypted over a Complex Message, No Header C.1.8. S/MIME Signed and Encrypted over a Complex Message, No Header
Protection Protection
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses no alternative message with an inline image/png attachment. It uses no
header protection. Header Protection.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8710 bytes └─╴application/pkcs7-mime [smime.p7m] 8710 bytes
↧ (decrypts to) ↧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 5434 bytes └─╴application/pkcs7-mime [smime.p7m] 5434 bytes
⇩ (unwraps to) ⇩ (unwraps to)
└┬╴multipart/mixed 1356 bytes └┬╴multipart/mixed 1356 bytes
├┬╴multipart/alternative 950 bytes ├┬╴multipart/alternative 950 bytes
│├─╴text/plain 295 bytes │├─╴text/plain 295 bytes
skipping to change at line 4790 skipping to change at line 4802
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--508-- --508--
C.2. Signed-Only Messages C.2. Signed-Only Messages
These messages are signed-only, using different schemes of header These messages are signed-only, using different schemes of Header
protection and different S/MIME structures. They use no Header Protection and different S/MIME structures. They use no Header
Confidentiality Policy because the HCP is only relevant when a Confidentiality Policy because the HCP is only relevant when a
message is encrypted. message is encrypted.
C.2.1. S/MIME Signed-Only signedData over a Simple Message, Header C.2.1. S/MIME Signed-Only signedData over a Simple Message, Header
Protection Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a text/plain message. It uses the Header Protection payload is a text/plain message. It uses the Header Protection
scheme from the draft. scheme from the draft.
skipping to change at line 5357 skipping to change at line 5369
Ee7uoUREekXvLmj8C6B3z8fiTfiWlqENU7J2BkrVF0KgW5X9ANwhekNROEx6X05R Ee7uoUREekXvLmj8C6B3z8fiTfiWlqENU7J2BkrVF0KgW5X9ANwhekNROEx6X05R
NVcBYNKNxCxuKMbHcE47Ytt8AuV4NoDWk2yumc8T6sM0Wkue NVcBYNKNxCxuKMbHcE47Ytt8AuV4NoDWk2yumc8T6sM0Wkue
--ba4-- --ba4--
C.2.5. S/MIME Signed-Only signedData over a Complex Message, Legacy RFC C.2.5. S/MIME Signed-Only signedData over a Complex Message, Legacy RFC
8551 Header Protection 8551 Header Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a multipart/alternative message with an inline image/png payload is a multipart/alternative message with an inline image/png
attachment. It uses the legacy RFC 8551 header protection attachment. It uses the legacy RFC 8551 Header Protection
(RFC8551HP) scheme. (RFC8551HP) scheme.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 5696 bytes └─╴application/pkcs7-mime [smime.p7m] 5696 bytes
⇩ (unwraps to) ⇩ (unwraps to)
└┬╴message/rfc822 1660 bytes └┬╴message/rfc822 1660 bytes
└┬╴multipart/mixed 1612 bytes └┬╴multipart/mixed 1612 bytes
├┬╴multipart/alternative 974 bytes ├┬╴multipart/alternative 974 bytes
│├─╴text/plain 296 bytes │├─╴text/plain 296 bytes
skipping to change at line 5544 skipping to change at line 5556
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--e68-- --e68--
C.2.6. S/MIME Signed-Only multipart/signed over a Complex Message, C.2.6. S/MIME Signed-Only multipart/signed over a Complex Message,
Legacy RFC 8551 Header Protection Legacy RFC 8551 Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature This is a signed-only S/MIME message via PKCS#7 detached signature
(multipart/signed). The payload is a multipart/alternative message (multipart/signed). The payload is a multipart/alternative message
with an inline image/png attachment. It uses the legacy RFC 8551 with an inline image/png attachment. It uses the legacy RFC 8551
header protection (RFC8551HP) scheme. Header Protection (RFC8551HP) scheme.
It has the following structure: It has the following structure:
└┬╴multipart/signed 5624 bytes └┬╴multipart/signed 5624 bytes
├┬╴message/rfc822 1718 bytes ├┬╴message/rfc822 1718 bytes
│└┬╴multipart/mixed 1670 bytes │└┬╴multipart/mixed 1670 bytes
│ ├┬╴multipart/alternative 1030 bytes │ ├┬╴multipart/alternative 1030 bytes
│ │├─╴text/plain 324 bytes │ │├─╴text/plain 324 bytes
│ │└─╴text/html 422 bytes │ │└─╴text/html 422 bytes
│ └─╴image/png inline 232 bytes │ └─╴image/png inline 232 bytes
skipping to change at line 5697 skipping to change at line 5709
3GpwQPjfjauEVAplxnIeLdtUbwJJvaColBr6bPHUibtvXS14JqfHvEu7uTgHlxpv 3GpwQPjfjauEVAplxnIeLdtUbwJJvaColBr6bPHUibtvXS14JqfHvEu7uTgHlxpv
KFZ/VEXf+Lx62gINfpie22d6UC3Nxif6EwPEDLmIjOYILjfMf9McQ2KzAPr6t6x/ KFZ/VEXf+Lx62gINfpie22d6UC3Nxif6EwPEDLmIjOYILjfMf9McQ2KzAPr6t6x/
hrz6NDG3LeTeLegQ4+onLotaBFsa0QPat0nSFjcaH8j9hFb4RB4avMbT1/5nRR6/ hrz6NDG3LeTeLegQ4+onLotaBFsa0QPat0nSFjcaH8j9hFb4RB4avMbT1/5nRR6/
B49YO28fRuAztMvesvs4M8kW6DAJjYj2fFAgT87CdWErzM7r B49YO28fRuAztMvesvs4M8kW6DAJjYj2fFAgT87CdWErzM7r
--a61-- --a61--
C.3. Signed-and-Encrypted Messages C.3. Signed-and-Encrypted Messages
These messages are signed and encrypted. They use PKCS#7 signedData These messages are signed and encrypted. They use PKCS#7 signedData
inside envelopedData, with different header protection schemes and inside envelopedData, with different Header Protection schemes and
different Header Confidentiality Policies. different Header Confidentiality Policies.
C.3.1. S/MIME Signed and Encrypted over a Simple Message, Header C.3.1. S/MIME Signed and Encrypted over a Simple Message, Header
Protection with hcp_baseline Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft with message. It uses the Header Protection scheme from the draft with
the hcp_baseline Header Confidentiality Policy. the hcp_baseline Header Confidentiality Policy.
skipping to change at line 11158 skipping to change at line 11170
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--d37-- --d37--
C.3.17. S/MIME Signed and Encrypted over a Complex Message, Legacy RFC C.3.17. S/MIME Signed and Encrypted over a Complex Message, Legacy RFC
8551 Header Protection with hcp_baseline 8551 Header Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses the alternative message with an inline image/png attachment. It uses the
legacy RFC 8551 header protection (RFC8551HP) scheme with the legacy RFC 8551 Header Protection (RFC8551HP) scheme with the
hcp_baseline Header Confidentiality Policy. hcp_baseline Header Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 9580 bytes └─╴application/pkcs7-mime [smime.p7m] 9580 bytes
↧ (decrypts to) ↧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 6082 bytes └─╴application/pkcs7-mime [smime.p7m] 6082 bytes
⇩ (unwraps to) ⇩ (unwraps to)
└┬╴message/rfc822 1876 bytes └┬╴message/rfc822 1876 bytes
└┬╴multipart/mixed 1828 bytes └┬╴multipart/mixed 1828 bytes
skipping to change at line 11518 skipping to change at line 11530
--266-- --266--
Appendix D. Composition Examples Appendix D. Composition Examples
This section offers step-by-step examples of message composition. This section offers step-by-step examples of message composition.
D.1. New Message Composition D.1. New Message Composition
A typical MUA composition interface offers the user a place to A typical MUA composition interface offers the user a place to
indicate the message recipients, subject, and body. Consider a indicate the message recipients, subject, and Body. Consider a
composition window filled out by the user like so: composition window filled out by the user like so:
.------------------------------------------------------. .------------------------------------------------------.
| Composing New Message .----. | | Composing New Message .----. |
| +---------------------------------+ | Send | | | +---------------------------------+ | Send | |
| To: | Alice <alice@example.net> | '----' | | To: | Alice <alice@example.net> | '----' |
| +---------------------------------+---------+ | | +---------------------------------+---------+ |
| Subject: | Handling the Jones contract | | | Subject: | Handling the Jones contract | |
| +-------------------------------------------+ | | +-------------------------------------------+ |
+--------------------------------------------------------+ +--------------------------------------------------------+
skipping to change at line 11544 skipping to change at line 11556
| | | |
| -- | | -- |
| Bob Gonzalez | | Bob Gonzalez |
| ACME, Inc. | | ACME, Inc. |
| | | |
+--------------------------------------------------------+ +--------------------------------------------------------+
Figure 1: Example Message Composition Interface Figure 1: Example Message Composition Interface
When Bob clicks "Send", his MUA generates values for the Message-ID, When Bob clicks "Send", his MUA generates values for the Message-ID,
From, and Date Header Fields and converts the message body into the From, and Date Header Fields and converts the message Body into the
appropriate format. appropriate format.
D.1.1. Unprotected Message D.1.1. Unprotected Message
The resulting message would look something like this if it was sent The resulting message would look something like this if it was sent
without cryptographic protections: without cryptographic protections:
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>
skipping to change at line 11645 skipping to change at line 11657
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-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="enveloped-data" smime-type="enveloped-data"
MIME-Version: 1.0 MIME-Version: 1.0
Note that the Subject Header Field has been obscured appropriately by Note that the Subject Header Field has been obscured appropriately by
hcp_baseline. The output of the CMS enveloping operation is base64 hcp_baseline. The output of the CMS enveloping operation is base64
encoded and forms the body of the message. encoded and forms the Body of the message.
D.2. Composing a Reply D.2. Composing a Reply
Next, we consider a typical MUA reply interface, where we see Alice Next, we consider a typical MUA reply interface, where we see Alice
replying to Bob's message from Appendix D.1. replying to Bob's message from Appendix D.1.
When Alice clicks "Reply" to Bob's signed-and-encrypted message with When Alice clicks "Reply" to Bob's signed-and-encrypted message with
Header Protection, she might see something like this: Header Protection, she might see something like this:
.--------------------------------------------------------. .--------------------------------------------------------.
skipping to change at line 11684 skipping to change at line 11696
| | | |
| -- | | -- |
| Alice Jenkins | | Alice Jenkins |
| ACME, Inc. | | ACME, Inc. |
| | | |
+----------------------------------------------------------+ +----------------------------------------------------------+
Figure 2: Example Message Reply Interface (Unedited) Figure 2: Example Message Reply Interface (Unedited)
Note that because Alice's MUA is aware of Header Protection, it knows Note that because Alice's MUA is aware of Header Protection, it knows
what the correct Subject header is, even though it was obscured. It what the correct Subject Header Field is, even though it was
also knows to avoid including the Legacy Display Element in the obscured. It also knows to avoid including the Legacy Display
quoted/attributed text that it includes in the draft reply. Element in the quoted/attributed text that it includes in the draft
reply.
Once Alice has edited the reply message, it might look something like Once Alice has edited the reply message, it might look something like
this: this:
.--------------------------------------------------------. .--------------------------------------------------------.
| Replying to Bob ("Handling the Jones Contract") .----. | | Replying to Bob ("Handling the Jones Contract") .----. |
| +-----------------------------------+ | Send | | | +-----------------------------------+ | Send | |
| To: | Bob <bob@example.net> | '----' | | To: | Bob <bob@example.net> | '----' |
| +-----------------------------------+---------+ | | +-----------------------------------+---------+ |
| Subject: | Re: Handling the Jones contract | | | Subject: | Re: Handling the Jones contract | |
skipping to change at line 11719 skipping to change at line 11732
| -- | | -- |
| Alice Jenkins | | Alice Jenkins |
| ACME, Inc. | | ACME, Inc. |
| | | |
+----------------------------------------------------------+ +----------------------------------------------------------+
Figure 3: Example Message Reply Interface (Edited) Figure 3: Example Message Reply Interface (Edited)
When Alice clicks "Send", the MUA generates values for the Message- When Alice clicks "Send", the MUA generates values for the Message-
ID, From, and Date Header Fields, populates the In-Reply-To and ID, From, and Date Header Fields, populates the In-Reply-To and
References Header Fields, and also converts the reply body into the References Header Fields, and also converts the reply Body into the
appropriate format. appropriate format.
D.2.1. Unprotected Message D.2.1. Unprotected Message
The resulting message would look something like this if it were to be The resulting message would look something like this if it were to be
sent without any cryptographic protections: sent without any cryptographic protections:
Date: Wed, 11 Jan 2023 16:48:22 -0500 Date: Wed, 11 Jan 2023 16:48:22 -0500
From: Alice <alice@example.net> From: Alice <alice@example.net>
To: Bob <bob@example.net> To: Bob <bob@example.net>
skipping to change at line 11826 skipping to change at line 11839
o To: Bob <bob@example.net> o To: Bob <bob@example.net>
o Subject: Re: Handling the Jones contract o Subject: Re: Handling the Jones contract
o In-Reply-To: <20230111T210843Z.1234@lhp.example> o In-Reply-To: <20230111T210843Z.1234@lhp.example>
o References: <20230111T210843Z.1234@lhp.example> o References: <20230111T210843Z.1234@lhp.example>
* Compute the ephemeral response_hcp (see Section 6.1): * Compute the ephemeral response_hcp (see Section 6.1):
- Note that all headers except Subject are the same. - Note that all Header Fields except Subject are the same.
- confmap contains only ("Subject", "Re: Handling the Jones - confmap contains only ("Subject", "Re: Handling the Jones
contract") -> "Re: [...]" contract") -> "Re: [...]"
Thus, all Header Fields that were signed are passed through Thus, all Header Fields that were signed are passed through
untouched. The reply's Subject is obscured as Subject: Re: [...] if untouched. The reply's Subject is obscured as Subject: Re: [...] if
and only if the user does not edit the Subject line from that and only if the user does not edit the Subject line from that
initially proposed by the MUA's reply interface. If the user edits initially proposed by the MUA's reply interface. If the user edits
the Subject line, e.g., to Subject: Re: Handling the Jones contract the Subject line, e.g., to Subject: Re: Handling the Jones contract
ASAP, the response_hcp will _not_ obscure it and instead pass it ASAP, the response_hcp will _not_ obscure it and instead pass it
skipping to change at line 11920 skipping to change at line 11933
In-Reply-To: <20230111T210843Z.1234@lhp.example> In-Reply-To: <20230111T210843Z.1234@lhp.example>
References: <20230111T210843Z.1234@lhp.example> References: <20230111T210843Z.1234@lhp.example>
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="enveloped-data" smime-type="enveloped-data"
MIME-Version: 1.0 MIME-Version: 1.0
Note that the Subject Header Field has been obscured appropriately Note that the Subject Header Field has been obscured appropriately
even though hcp_no_confidentiality would not have touched it by even though hcp_no_confidentiality would not have touched it by
default. The output of the CMS enveloping operation is base64 default. The output of the CMS enveloping operation is base64
encoded and forms the body of the message. encoded and forms the Body of the message.
Appendix E. Rendering Examples Appendix E. Rendering Examples
This section offers example Cryptographic Payloads (the content This section offers example Cryptographic Payloads (the content
within the Cryptographic Envelope) that contain Legacy Display within the Cryptographic Envelope) that contain Legacy Display
Elements. Elements.
E.1. Example text/plain Cryptographic Payload with Legacy Display E.1. Example text/plain Cryptographic Payload with Legacy Display
Elements Elements
Here is a simple one-part Cryptographic Payload (Header Section and Here is a simple one-part Cryptographic Payload (Header Section and
body) of a message that includes Legacy Display Elements: Body) of a message that includes Legacy Display Elements:
Date: Fri, 21 Jan 2022 20:40:48 -0500 Date: Fri, 21 Jan 2022 20:40:48 -0500
From: Alice <alice@example.net> From: Alice <alice@example.net>
To: Bob <bob@example.net> To: Bob <bob@example.net>
Subject: Dinner plans Subject: Dinner plans
Message-ID: <text-plain-legacy-display@lhp.example> Message-ID: <text-plain-legacy-display@lhp.example>
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1";
hp="cipher" hp="cipher"
HP-Outer: Date: Fri, 21 Jan 2022 20:40:48 -0500 HP-Outer: Date: Fri, 21 Jan 2022 20:40:48 -0500
skipping to change at line 11954 skipping to change at line 11967
HP-Outer: To: Bob <bob@example.net> HP-Outer: To: Bob <bob@example.net>
HP-Outer: Subject: [...] HP-Outer: Subject: [...]
HP-Outer: Message-ID: <text-plain-legacy-display@lhp.example> HP-Outer: Message-ID: <text-plain-legacy-display@lhp.example>
Subject: Dinner plans Subject: Dinner plans
Let's meet at Rama's Roti Shop at 8pm and go to the park Let's meet at Rama's Roti Shop at 8pm and go to the park
from there. from there.
A compatible MUA will recognize the hp-legacy-display="1" parameter A compatible MUA will recognize the hp-legacy-display="1" parameter
and render the body of the message as: and render the Body of the message as:
Let's meet at Rama's Roti Shop at 8pm and go to the park Let's meet at Rama's Roti Shop at 8pm and go to the park
from there. from there.
A legacy decryption-capable MUA that is unaware of this mechanism A legacy decryption-capable MUA that is unaware of this mechanism
will ignore the hp-legacy-display="1" parameter and instead render will ignore the hp-legacy-display="1" parameter and instead render
the body including the Legacy Display Elements: the Body including the Legacy Display Elements:
Subject: Dinner plans Subject: Dinner plans
Let's meet at Rama's Roti Shop at 8pm and go to the park Let's meet at Rama's Roti Shop at 8pm and go to the park
from there. from there.
E.2. Example text/html Cryptographic Payload with Legacy Display E.2. Example text/html Cryptographic Payload with Legacy Display
Elements Elements
Here is a modern one-part Cryptographic Payload (Header Section and Here is a modern one-part Cryptographic Payload (Header Section and
body) of a message that includes Legacy Display Elements: Body) of a message that includes Legacy Display Elements:
Date: Fri, 21 Jan 2022 20:40:48 -0500 Date: Fri, 21 Jan 2022 20:40:48 -0500
From: Alice <alice@example.net> From: Alice <alice@example.net>
To: Bob <bob@example.net> To: Bob <bob@example.net>
Subject: Dinner plans Subject: Dinner plans
Message-ID: <text-html-legacy-display@lhp.example> Message-ID: <text-html-legacy-display@lhp.example>
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: text/html; charset="us-ascii"; hp-legacy-display="1"; Content-Type: text/html; charset="us-ascii"; hp-legacy-display="1";
hp="cipher" hp="cipher"
HP-Outer: Date: Fri, 21 Jan 2022 20:40:48 -0500 HP-Outer: Date: Fri, 21 Jan 2022 20:40:48 -0500
skipping to change at line 12000 skipping to change at line 12013
<pre>Subject: Dinner plans</pre> <pre>Subject: Dinner plans</pre>
</div> </div>
<p> <p>
Let's meet at Rama's Roti Shop at 8pm and go to the park Let's meet at Rama's Roti Shop at 8pm and go to the park
from there. from there.
</p> </p>
</body> </body>
</html> </html>
A compatible MUA will recognize the hp-legacy-display="1" parameter A compatible MUA will recognize the hp-legacy-display="1" parameter
and mask out the Legacy Display div, rendering the body of the and mask out the Legacy Display div, rendering the Body of the
message as a simple paragraph: message as a simple paragraph:
Let's meet at Rama's Roti Shop at 8pm and go to the park Let's meet at Rama's Roti Shop at 8pm and go to the park
from there. from there.
A legacy decryption-capable MUA that is unaware of this mechanism A legacy decryption-capable MUA that is unaware of this mechanism
will ignore the hp-legacy-display="1" parameter and instead render will ignore the hp-legacy-display="1" parameter and instead render
the body including the Legacy Display Elements: the Body including the Legacy Display Elements:
Subject: Dinner plans Subject: Dinner plans
Let's meet at Rama's Roti Shop at 8pm and go to the park Let's meet at Rama's Roti Shop at 8pm and go to the park
from there. from there.
Appendix F. Other Header Protection Schemes Appendix F. Other Header Protection Schemes
Other Header Protection schemes have been proposed in the past. Other Header Protection schemes have been proposed in the past.
However, those typically have drawbacks such as sparse However, those typically have drawbacks such as sparse
skipping to change at line 12081 skipping to change at line 12094
The lack of a mechanism comparable to HP-Outer (see Section 2.2) The lack of a mechanism comparable to HP-Outer (see Section 2.2)
makes it impossible for the recipient of a PEF-2 message to safely makes it impossible for the recipient of a PEF-2 message to safely
determine which Header Fields are confidential or not while determine which Header Fields are confidential or not while
forwarding or replying to a message (see Section 6). forwarding or replying to a message (see Section 6).
Note: As this document is not normative for PEF-2 messages, it does Note: As this document is not normative for PEF-2 messages, it does
not provide any guidance for handling them. Please see [PEP-EMAIL] not provide any guidance for handling them. Please see [PEP-EMAIL]
for more guidance. for more guidance.
F.3. Protected Email Headers F.3. Autocrypt Protected Headers
[PROTECTED-HEADERS] describes a scheme similar to the Header [PROTECTED-HEADERS] describes a scheme similar to the Header
Protection scheme specified in this document. However, instead of Protection scheme specified in this document. However, instead of
adding Legacy Display Elements to existing MIME parts (see adding Legacy Display Elements to existing MIME parts (see
Section 5.2.2), [PROTECTED-HEADERS] suggests injecting a new MIME Section 5.2.2), [PROTECTED-HEADERS] suggests injecting a new MIME
element "Legacy Display Part", thus modifying the MIME structure of element "Legacy Display Part", thus modifying the MIME structure of
the Cryptographic Payload. These modified Cryptographic Payloads the Cryptographic Payload. These modified Cryptographic Payloads
cause significant rendering problems on some common Legacy MUAs. cause significant rendering problems on some common Legacy MUAs.
The lack of a mechanism comparable to hp="cipher" and hp="clear" (see The lack of a mechanism comparable to hp="cipher" and hp="clear" (see
 End of changes. 137 change blocks. 
213 lines changed or deleted 226 lines changed or added

This html diff was produced by rfcdiff 1.48.