rfc9788v7.txt   rfc9788.txt 
skipping to change at line 95 skipping to change at line 95
3.1.1. HCP Avoids Changing addr-spec of From Header Field 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. Rendering Guidance (Receiving Side)
4.1. Identifying That a Message Has Header Protection 4.1. Identifying That a Message Has Header Protection
4.2. Extracting Protected Header Fields From an Encrypted 4.2. Extracting Protected Header Fields From an Encrypted
Message Message
4.2.1. HeaderSetsFromMessage 4.2.1. HeaderSetsFromMessage
4.3. Updating the Cryptographic Summary 4.3. Updating the Cryptographic Summary
4.3.1. HeaderFieldProtection 4.3.1. HeaderFieldProtection
4.4. Handling Mismatch of From Header Fields 4.4. Handling Mismatch of From Header Fields
4.4.1. Definitions 4.4.1. Definitions
4.4.2. Warning for From Header Field Mismatch 4.4.2. Warning for From Header Field Mismatch
4.4.3. From Header Field Rendering 4.4.3. From Header Field Rendering
skipping to change at line 123 skipping to change at line 123
4.6. Implicitly Rendered Header Fields 4.6. Implicitly Rendered Header Fields
4.7. Handling Undecryptable Messages 4.7. Handling Undecryptable Messages
4.8. Guidance for Automated Message Handling 4.8. Guidance for Automated Message Handling
4.8.1. Only Interpret Protected Header Fields 4.8.1. Only Interpret Protected Header Fields
4.8.2. Ignore Legacy Display Elements 4.8.2. Ignore Legacy Display Elements
4.9. Affordances for Debugging and Troubleshooting 4.9. Affordances for Debugging and Troubleshooting
4.10. Handling RFC8551HP Messages (Backward Compatibility) 4.10. Handling RFC8551HP Messages (Backward Compatibility)
4.10.1. Identifying an RFC8551HP Message 4.10.1. Identifying an RFC8551HP Message
4.10.2. Rendering or Responding to an RFC8551HP Message 4.10.2. Rendering or Responding to an RFC8551HP Message
4.11. Rendering Other Schemes 4.11. Rendering Other Schemes
5. Sending Guidance 5. Composing Guidance (Sending Side)
5.1. Composing a Cryptographically Protected Message Without 5.1. Composing a Cryptographically Protected Message Without
Header Protection Header Protection
5.1.1. ComposeNoHeaderProtection 5.1.1. ComposeNoHeaderProtection
5.2. Composing a Message with Header Protection 5.2. Composing a Message with Header Protection
5.2.1. Compose 5.2.1. Compose
5.2.2. Adding a Legacy Display Element to a text/plain Part 5.2.2. Adding a Legacy Display Element to a text/plain Part
5.2.3. Adding a Legacy Display Element to a text/html Part 5.2.3. Adding a Legacy Display Element to a text/html Part
5.2.4. Only Add a Legacy Display Element to Main Body Parts 5.2.4. Only Add a Legacy Display Element to Main Body Parts
5.2.5. Do Not Add a Legacy Display Element to Other 5.2.5. Do Not Add a Legacy Display Element to Other
Content-Types Content-Types
skipping to change at line 307 skipping to change at line 307
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 into the Cryptographic Payload without using an intervening
message/rfc822 MIME object. In an encrypted message, some Header message/rfc822 MIME object. In an encrypted message, some Header
Fields can also be made confidential by removing or obscuring them Fields can also be made confidential by removing or obscuring them
from the Outer Header Section. from the Outer Header Section.
This specification also offers substantial security, privacy, and This specification also offers substantial security, privacy, and
usability guidance for sending and receiving MUAs that was not usability guidance for composing and rendering MUAs that was not
considered in [RFC8551]. considered in [RFC8551].
1.1.1. Problems with RFC 8551 Header Protection 1.1.1. Problems with RFC 8551 Header Protection
Several Legacy MUAs have difficulty rendering a message that uses Several Legacy MUAs have difficulty rendering a message that uses
RFC8551HP. These problems can appear on signed-only messages, as RFC8551HP. These problems can appear on signed-only messages, as
well as signed-and-encrypted messages. well as signed-and-encrypted messages.
In some cases, some MUAs cannot render message/rfc822 message In some cases, some MUAs cannot render message/rfc822 message
subparts at all, which is in violation of baseline MIME requirements subparts at all, which is in violation of baseline MIME requirements
skipping to change at line 338 skipping to change at line 338
assess the cryptographic properties of the message. Worse, for assess the cryptographic properties of the message. Worse, for
encrypted messages, interacting with the protected message in encrypted messages, interacting with the protected message in
isolation may leak contents of the cleartext, for example, if the isolation may leak contents of the cleartext, for example, if the
reply is not also encrypted. reply is not also encrypted.
Furthermore, RFC8551HP lacks any discussion of the following points, Furthermore, RFC8551HP lacks any discussion of the following points,
all of which are provided in this specification: all of which are provided in this specification:
* Which Header Fields should be given end-to-end cryptographic * Which Header Fields should be given end-to-end cryptographic
integrity and authenticity protections (this specification integrity and authenticity protections (this specification
mandates protection of all Header Fields that the sending MUA mandates protection of all Header Fields that the composing MUA
knows about). knows about).
* How to securely indicate the sender's intent to offer Header * How to securely indicate the composer's intent to offer Header
Protection and encryption, which lets a receiving MUA detect Protection and encryption, which lets a rendering MUA detect
messages whose cryptographic properties may have been modified in messages whose cryptographic properties may have been modified in
transit (see Section 2.1.1). transit (see Section 2.1.1).
* Which Header Fields should be given end-to-end cryptographic * Which Header Fields should be given end-to-end cryptographic
confidentiality protections in an encrypted message and how (see confidentiality protections in an encrypted message and how (see
Section 3). Section 3).
* How to securely indicate the sender's choices about which Header * How to securely indicate the composer's choices about which Header
Fields were made confidential, which lets a receiving MUA reply or Fields were made confidential, which lets a rendering MUA reply or
forward an encrypted message safely without accidentally leaking forward an encrypted message safely without accidentally leaking
confidential material (see Section 2.2). confidential material (see Section 2.2).
These stumbling blocks with Legacy MUAs, missing mechanisms, and These stumbling blocks with Legacy MUAs, missing mechanisms, and
missing guidance create a strong disincentive for existing MUAs to missing guidance create a strong disincentive for existing MUAs to
generate messages using RFC8551HP. Because few messages have been generate messages using RFC8551HP. Because few messages have been
produced, there has been little incentive for those MUAs capable of produced, there has been little incentive for those MUAs capable of
upgrading to bother interpreting them better. upgrading to bother interpreting them better.
In contrast, the mechanisms defined here are safe to adopt and In contrast, the mechanisms defined here are safe to adopt and
skipping to change at line 393 skipping to change at line 393
render the [...] anywhere the Subject is normally seen. This is the render the [...] anywhere the Subject is normally seen. This is the
only additional risk of producing an encrypted message according to only additional risk of producing an encrypted message according to
this specification (compared to producing an encrypted message this specification (compared to producing an encrypted message
without confidentiality for any Header Field). without confidentiality for any Header Field).
A workaround "Legacy Display" mechanism is provided in this A workaround "Legacy Display" mechanism is provided in this
specification (see Section 2.1.2). Legacy MUAs will render "Legacy specification (see Section 2.1.2). Legacy MUAs will render "Legacy
Display Elements" to the user, albeit not in the same location that Display Elements" to the user, albeit not in the same location that
the Header Fields would normally be rendered. the Header Fields would normally be rendered.
Alternately, if the sender of an encrypted message is particularly Alternately, if the composer 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
skipping to change at line 427 skipping to change at line 427
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 composing and rendering MUAs ensure that
protections cover the message Header Section as well as the message cryptographic protections cover the message Header Section as well as
Body, these attacks are defeated. the message 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 composing 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 composer cannot know what MUA (or MUAs) the recipient will use to
handle the message. Thus, an outbound message format that is handle the message. Thus, an outbound message format that is
backward compatible with as many legacy implementations as possible backward compatible with as many legacy implementations as possible
is a more effective vehicle for providing the whole-message is a more effective vehicle for providing the whole-message
cryptographic protections described above. cryptographic protections described above.
This document aims for backward compatibility with Legacy MUAs to the This document aims for backward compatibility with Legacy MUAs to the
extent possible. In some cases, like when a user-visible Header extent possible. In some cases, like when a user-visible Header
Field like the Subject is cryptographically hidden, a Legacy MUA will Field like the Subject is cryptographically hidden, a Legacy MUA will
not be able to render or reply to the message exactly the same way as not be able to render or reply to the message exactly the same way as
a conformant MUA would. But accommodations are described here (in a conformant MUA would. But accommodations are described here (in
skipping to change at line 487 skipping to change at line 487
email (spam). email (spam).
However, the DKIM+DMARC suite provides cryptographic protection at a However, the DKIM+DMARC suite provides cryptographic protection at a
different scope, as it is usually applied by and evaluated by a mail different scope, as it is usually applied by and evaluated by a mail
transport agent (MTA). DKIM+DMARC typically provide MTA-to-MTA transport agent (MTA). DKIM+DMARC typically provide MTA-to-MTA
protection, whereas this specification provides MUA-to-MUA protection, whereas this specification provides MUA-to-MUA
protection. This is because DKIM+DMARC are typically applied to protection. This is because DKIM+DMARC are typically applied to
messages by (and interpreted by) MTAs, whereas the mechanisms in this messages by (and interpreted by) MTAs, whereas the mechanisms in this
document are typically applied and interpreted by MUAs. document are typically applied and interpreted by MUAs.
A receiving MUA that relies on DKIM+DMARC for sender authenticity A rendering MUA that relies on DKIM+DMARC for sender authenticity
should note Section 10.1. should note Section 10.1.
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.
skipping to change at line 631 skipping to change at line 631
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 rendering MUA while providing actionable
cryptographic properties for modern receiving MUAs. cryptographic properties for modern rendering 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
The message composition guidance in this document (in Section 5.2) The message composition guidance in this document (in Section 5.2)
aims to provide minimal disruption for any Legacy MUA that receives aims to provide minimal disruption for any Legacy MUA that renders
such a message. However, by definition, a Legacy MUA does not such a message. However, by definition, a Legacy MUA does not
implement any of the guidance here. Therefore, the document does not implement any of the guidance here. Therefore, the document does not
attempt to provide guidance for Legacy MUAs directly. attempt to provide guidance for Legacy MUAs directly.
Furthermore, this document does not explicitly contemplate other Furthermore, this document does not explicitly contemplate other
variants of cryptographic message protections, including any of variants of cryptographic message protections, including any of
these: these:
* encrypted-only message (without a cryptographic signature; see * encrypted-only message (without a cryptographic signature; see
Section 5.3 of [RFC9787]) Section 5.3 of [RFC9787])
skipping to change at line 673 skipping to change at line 673
All such messages are out of scope of this document. All such messages are out of scope of this document.
1.9. Example 1.9. Example
This section gives an overview by providing an example of how MIME This section gives an overview by providing an example of how MIME
messages with Header Protection look. messages with Header Protection look.
Consider the following MIME message: Consider the following MIME message:
A └─╴application/pkcs7-mime; smime-type="enveloped-data" A └┬╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to) ╧ (decrypts to)
B └─╴application/pkcs7-mime; smime-type="signed-data" B └┬╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to) ┴ (unwraps to)
C └┬╴multipart/alternative; hp="cipher" C └┬╴multipart/alternative; hp="cipher"
D ├─╴text/plain; hp-legacy-display="1" D ├─╴text/plain; hp-legacy-display="1"
E └─╴text/html; hp-legacy-display="1" E └─╴text/html; hp-legacy-display="1"
Observe that: Observe that:
* Nodes A and B are collectively called the Cryptographic Envelope. * Nodes A and B are collectively called the Cryptographic Envelope.
Node C (including its subnodes D and E) is called the Node C (including its subnodes D and E) is called the
Cryptographic Payload [RFC9787]. Cryptographic Payload [RFC9787].
* Node A contains the (unprotected) outer Header Fields. Node C * Node A contains the (unprotected) outer Header Fields. Node C
contains the (protected) inner Header Fields. contains the (protected) inner Header Fields.
* The presence of the hp attribute (see Section 2.1.1) on the * The presence of the hp attribute (see Section 2.1.1) on the
Content-Type of node C allows the receiver to know that the sender Content-Type of node C allows the renderer to know that the
applied Header Protection. Its value allows the receiver to composer applied Header Protection. Its value allows the renderer
distinguish whether the sender intended for the message to be to distinguish whether the composer intended for the message to be
confidential (hp="cipher") or not (hp="clear"), since encryption confidential (hp="cipher") or not (hp="clear"), since encryption
may have been added in transit (see Section 10.2). may have been added in transit (see Section 10.2).
The Outer Header Section on node A looks as follows: The Outer Header Section on node A looks as follows:
Date: Wed, 11 Jan 2023 16:08:43 -0500 Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net> From: Bob <bob@example.net>
To: Alice <alice@example.net> To: Alice <alice@example.net>
Subject: [...] Subject: [...]
Message-ID: <20230111T210843Z.1234@lhp.example> Message-ID: <20230111T210843Z.1234@lhp.example>
skipping to change at line 731 skipping to change at line 731
HP-Outer: Message-ID: <20230111T210843Z.1234@lhp.example> HP-Outer: Message-ID: <20230111T210843Z.1234@lhp.example>
Observe that: Observe that:
* Between node C and node A, some Header Fields are copied as is * Between node C and node A, some Header Fields are copied as is
(Date, From, To, Message-ID), some are obscured (Subject), and (Date, From, To, Message-ID), some are obscured (Subject), and
some are removed (Keywords). some are removed (Keywords).
* The HP-Outer Header Fields (see Section 2.2) of node C contain a * The HP-Outer Header Fields (see Section 2.2) of node C contain a
protected copy of the Header Fields in node A. The copy allows protected copy of the Header Fields in node A. The copy allows
the receiver to recompute for which Header Fields the sender the renderer to recompute for which Header Fields the composer
provided confidentiality by removing or obscuring them. provided confidentiality by removing or obscuring them.
* The copying/removing/obscuring and the HP-Outer only apply to Non- * The copying/removing/obscuring and the HP-Outer only apply to Non-
Structural Header Fields, not to Structural Header Fields like Structural Header Fields, not to Structural Header Fields like
Content-Type or MIME-Version (see Section 1.1.1 of [RFC9787]). Content-Type or MIME-Version (see Section 1.1.1 of [RFC9787]).
* If the sender intends no confidentiality and doesn't encrypt the * If the composer intends no confidentiality and doesn't encrypt the
message, it doesn't remove or obscure Header Fields. All Non- message, it doesn't remove or obscure Header Fields. All Non-
Structural Header Fields are copied as is. No HP-Outer Header Structural Header Fields are copied as is. No HP-Outer Header
Fields are present. Fields are present.
Node D looks as follows: Node D looks as follows:
Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1";
Subject: Handling the Jones contract Subject: Handling the Jones contract
Keywords: Contract, Urgent Keywords: Contract, Urgent
skipping to change at line 761 skipping to change at line 761
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 composer adds the removed and obscured User-Facing Header
(see Section 1.1.2 of [RFC9787]) to the main Body (note the empty Fields (see Section 1.1.2 of [RFC9787]) to the main Body (note the
line after the Content-Type). This is called the Legacy Display empty line after the Content-Type). This is called the Legacy
Element. It allows a user with a Legacy MUA that doesn't Display 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 composer added a Legacy Display Element. This allows
receivers that implement this document to recognize the Legacy renderers 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 renderer 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).
For more examples, see Appendices D and E. For more examples, see Appendices D and E.
2. Internet Message Format Extensions 2. Internet Message Format Extensions
This section describes relevant, backward-compatible extensions to This section describes relevant, backward-compatible extensions to
skipping to change at line 798 skipping to change at line 798
This document introduces two parameters for the Content-Type Header This document introduces two parameters for the Content-Type Header
Field, which have distinct semantics and use cases. Field, which have distinct semantics and use cases.
2.1.1. Content-Type Parameter: hp 2.1.1. Content-Type Parameter: hp
This specification defines a parameter for the Content-Type Header This specification defines a parameter for the Content-Type Header
Field named hp (for Header Protection). This parameter is only Field named hp (for Header Protection). This parameter is only
relevant on the Content-Type Header Field at the root of the relevant on the Content-Type Header Field at the root of the
Cryptographic Payload. The presence of this parameter at the root of Cryptographic Payload. The presence of this parameter at the root of
the Cryptographic Payload indicates that the sender intends for this the Cryptographic Payload indicates that the composer intends for
message to have end-to-end cryptographic protections for the Header this message to have end-to-end cryptographic protections for the
Fields. Header Fields.
The parameter's defined values describe the sender's cryptographic The parameter's defined values describe the composer's cryptographic
intent when producing the message: intent when producing the message:
+========+==============+=========+=================+==============+ +========+==============+=========+=================+===============+
|hp Value| Authenticity |Integrity| Confidentiality | Description | |hp Value| Authenticity |Integrity| Confidentiality | Description |
+========+==============+=========+=================+==============+ +========+==============+=========+=================+===============+
|"clear" | yes |yes | no | This message | |"clear" | yes |yes | no | This |
| | | | | has been | | | | | | message has |
| | | | | signed by | | | | | | been signed |
| | | | | the sender, | | | | | | by the |
| | | | | with Header | | | | | | composer, |
| | | | | Protection. | | | | | | with Header |
+--------+--------------+---------+-----------------+--------------+ | | | | | Protection. |
|"cipher"| yes |yes | yes | This message | +--------+--------------+---------+-----------------+---------------+
| | | | | has been | |"cipher"| yes |yes | yes | This |
| | | | | signed by | | | | | | message has |
| | | | | the sender, | | | | | | been signed |
| | | | | with Header | | | | | | by the |
| | | | | Protection, | | | | | | composer, |
| | | | | and is | | | | | | with Header |
| | | | | encrypted to | | | | | | Protection, |
| | | | | the | | | | | | and is |
| | | | | recipients. | | | | | | encrypted |
+--------+--------------+---------+-----------------+--------------+ | | | | | to the |
| | | | | 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 composing implementation MUST NOT produce a Cryptographic Payload
with parameter hp="cipher" for an unencrypted message (that is, where with parameter hp="cipher" for an unencrypted message (that is, where
none of the Cryptographic Layers in the Cryptographic Envelope of the none of the Cryptographic Layers in the Cryptographic Envelope of the
message provide encryption). Likewise, if a sending implementation message provide encryption). Likewise, if a composing implementation
is sending an encrypted message with Header Protection, it MUST emit is constructing an encrypted message with Header Protection, it MUST
an hp="cipher" parameter, regardless of which Header Fields were made emit an hp="cipher" parameter, regardless of which Header Fields were
confidential. made 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 composer 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 rendering 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.
2.1.2. Content-Type Parameter: hp-legacy-display 2.1.2. Content-Type Parameter: hp-legacy-display
This specification also defines an hp-legacy-display parameter for This specification also defines an hp-legacy-display parameter for
the Content-Type Header Field. The only defined value for this the Content-Type Header Field. The only defined value for this
parameter is 1. parameter is 1.
This parameter is only relevant on a leaf MIME node of Content-Type This parameter is only relevant on a leaf MIME node of Content-Type
skipping to change at line 878 skipping to change at line 880
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 composer'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 composer put outside the Cryptographic Envelope. This
Header Field enables the MUA receiving the encrypted message to Header Field enables the MUA rendering the encrypted message to
reliably identify whether the sending MUA intended to make a Header reliably identify whether the composing MUA intended to make a Header
Field confidential (see also Section 11.3). Field confidential (see also Section 11.3).
The HP-Outer Header Fields in a message's Cryptographic Payload are The HP-Outer Header Fields in a message's Cryptographic Payload are
useful for ensuring that any confidential Header Field will not be useful for ensuring that any confidential Header Field will not be
automatically leaked in the clear if the user replies to or forwards automatically leaked in the clear if the user replies to or forwards
the message. They may also be useful for an MUA that indicates the the message. They may also be useful for an MUA that indicates the
confidentiality status of any given Header Field to the user. confidentiality status of any given Header Field to the user.
An implementation that composes encrypted email MUST include a copy An implementation that composes encrypted email MUST include a copy
of all Non-Structural Header Fields deliberately exposed to the of all Non-Structural Header Fields deliberately exposed to the
skipping to change at line 910 skipping to change at line 912
places. places.
Each instance of HP-Outer contains a Non-Structural Header Field name Each instance of HP-Outer contains a Non-Structural Header Field name
and the value that this Header Field was set to within the and the value that this Header Field was set to within the
(unprotected) Outer Header Section. The HP-Outer Header Field can (unprotected) Outer Header Section. The HP-Outer Header Field can
appear multiple times in the Header Section of a Cryptographic appear multiple times in the Header Section of a Cryptographic
Payload. 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 composer 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 composer at the time the message was injected into
mail system. the 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-
end confidentiality of a given Header Field from an encrypted message end confidentiality of a given Header Field from an encrypted message
with Header Protection using HP-Outer. See Section 6.1 for how an with Header Protection using HP-Outer. See Section 6.1 for how an
MUA can safely reply to (or forward) an encrypted message without MUA can safely reply to (or forward) an encrypted message without
leaking confidential Header Fields by default. leaking confidential Header Fields by default.
2.2.1. HP-Outer Header Field Definition 2.2.1. HP-Outer Header Field Definition
skipping to change at line 959 skipping to change at line 961
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.
Note that such a policy is only needed when the end-to-end Note that such a policy is only needed when the end-to-end
protections include encryption (confidentiality). No comparable protections include encryption (confidentiality). No comparable
policy is needed for other end-to-end cryptographic protections policy is needed for other end-to-end cryptographic protections
(integrity and authenticity), as they are simply uniformly applied so (integrity and authenticity), as they are simply uniformly applied so
that all Header Fields known by the sender have these protections. that all Header Fields known by the composer have these protections.
This asymmetry is a consequence of complexities in existing message This asymmetry is a consequence of complexities in existing message
delivery systems, some of which may reject, drop, or delay messages delivery systems, some of which may reject, drop, or delay messages
where all Header Fields are removed from the top-level MIME object. where all Header Fields are removed from the top-level MIME object.
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 composer's HCP via the HP-Outer
Fields (see Section 2.2). Header Fields (see Section 2.2).
3.1. HCP Definition 3.1. HCP Definition
In this document, we represent that HCP as a function hcp: In this document, we represent that HCP as 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 Field value val_out. arguments and returns a replacement Header Field value val_out.
If val_out is the special value null, it means that the Header If val_out is the special value null, it means that the Header
Field in question should be removed from the set of Header Fields Field in question should be removed from the set of Header Fields
skipping to change at line 1028 skipping to change at line 1030
pseudocode functions. If it alters the value, it MUST NOT include pseudocode functions. If it alters the value, it MUST NOT include
control or NUL characters in val_out. val_out SHOULD match the control or NUL characters in val_out. val_out SHOULD match the
expected ABNF for the Header Field identified by name. expected ABNF for the Header Field identified by name.
3.1.1. HCP Avoids Changing addr-spec of From Header Field 3.1.1. HCP Avoids Changing addr-spec of From Header Field
The From Header Field should also be treated specially by the HCP to The From Header Field should also be treated specially by the HCP to
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 composing MUA has additional knowledge
coordinated with the receiving MUA about more subtle addr-spec coordinated with the rendering MUA about more subtle addr-spec
equivalence or certificate validity. equivalence or certificate validity.
3.2. Initial Registered HCPs 3.2. Initial Registered HCPs
This document formally defines three Header Confidentiality Policies This document formally defines three Header Confidentiality Policies
with known and reasonably well-understood characteristics as a way to with known and reasonably well-understood characteristics as a way to
compare and contrast different possible behavioral choices for a compare and contrast different possible behavioral choices for a
composing MUA. These definitions are not meant to preclude the composing MUA. These definitions are not meant to preclude the
creation of other HCPs. creation of other HCPs.
skipping to change at line 1079 skipping to change at line 1081
hcp_baseline is the recommended default HCP, as it provides hcp_baseline is the recommended default HCP, as it provides
meaningful confidentiality protections and is unlikely to cause meaningful confidentiality protections and is unlikely to cause
deliverability or usability problems. deliverability or usability problems.
3.2.2. Shy Header Confidentiality Policy 3.2.2. Shy Header Confidentiality Policy
Alternately, a slightly more ambitious (and therefore more privacy- Alternately, a slightly more ambitious (and therefore more privacy-
preserving) HCP might avoid leaking human-interpretable data that preserving) HCP might avoid leaking human-interpretable data that
MTAs generally don't care about. The additional protected data isn't MTAs generally don't care about. The additional protected data isn't
related to message routing or transport but might reveal sensitive related to message routing or transport but might reveal sensitive
information about the sender or their relationship to the recipients. information about the composer or their relationship to the
This "shy" HCP builds on hcp_baseline but also: recipients. This "shy" HCP builds on hcp_baseline but also:
* avoids revealing the display-name of each identified email address * avoids revealing the display-name of each identified email address
and and
* avoids leaking the sender's locally configured time zone in the * avoids leaking the composer's locally configured time zone in the
Date Header Field. Date Header Field.
hcp_shy(name, val_in) → val_out: hcp_shy(name, val_in) → val_out:
if lower(name) is 'from': if lower(name) is 'from':
if val_in is an RFC 5322 mailbox: if val_in is an RFC 5322 mailbox:
return the RFC 5322 addr-spec part of val_in return the RFC 5322 addr-spec part of val_in
if lower(name) in ['to', 'cc']: if lower(name) in ['to', 'cc']:
if val_in is an RFC 5322 mailbox-list: if val_in is an RFC 5322 mailbox-list:
let val_out be an empty mailbox-list let val_out be an empty mailbox-list
for each mailbox in val_in: for each mailbox in val_in:
skipping to change at line 1196 skipping to change at line 1198
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 mitigable 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. Rendering Guidance (Receiving Side)
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 rendering MUA will render the message Body, render a selected
subset of Header Fields, and (as described in Section 3 of [RFC9787]) subset of Header Fields, and (as described in Section 3 of [RFC9787])
provide a summary of the cryptographic properties of the message. provide a summary of the cryptographic properties of the message.
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 1261 skipping to change at line 1263
* The Cryptographic Payload has parameter hp set to "clear" or * The Cryptographic Payload has parameter hp set to "clear" or
"cipher". See Section 4.5 for rendering guidance. "cipher". See Section 4.5 for rendering guidance.
When consuming a message, an MUA MUST ignore the hp parameter to When consuming a message, an MUA MUST ignore the hp parameter to
Content-Type when it encounters it anywhere other than the root of Content-Type when it encounters it anywhere other than the root of
the message's Cryptographic Payload. the message's Cryptographic Payload.
4.2. Extracting Protected Header Fields From an Encrypted Message 4.2. Extracting Protected Header Fields From an Encrypted Message
When a message is encrypted and uses Header Protection, the receiving When a message is encrypted and uses Header Protection, the rendering
MUA extracts two lists of Header Fields (names and values): MUA extracts two lists of Header Fields (names and values):
* The list of Header Fields that the sending MUA applied to the * The list of Header Fields that the composing MUA applied to the
protected message. protected message.
* Those Header Fields added by the sending MUA to the (unprotected) * Those Header Fields added by the composing MUA to the
Outer Header Section of the message, intended for interpretation (unprotected) Outer Header Section of the message, intended for
by MTAs and Legacy MUAs. interpretation by MTAs and Legacy MUAs.
The following algorithm takes referenced message refmsg as input, The following algorithm takes referenced message refmsg as input,
which is encrypted with Header Protection as described in this which is encrypted with Header Protection as described in this
document (that is, the Cryptographic Envelope includes a document (that is, the Cryptographic Envelope includes a
Cryptographic Layer that provides encryption, and the hp parameter Cryptographic Layer that provides encryption, and the hp parameter
for the Content-Type Header Field of the Cryptographic Payload is for the Content-Type Header Field of the Cryptographic Payload is
cipher). It produces as output a pair of lists of (h,v) Header cipher). It produces as output a pair of lists of (h,v) Header
Fields. Fields.
4.2.1. HeaderSetsFromMessage 4.2.1. HeaderSetsFromMessage
skipping to change at line 1395 skipping to change at line 1397
* If the signature fails validation, the MUA lowers the affected * If the signature fails validation, the MUA lowers the affected
state to unprotected or encrypted-only without any additional state to unprotected or encrypted-only without any additional
warning to the user (see also Section 3.1 of [RFC9787]). warning to the user (see also Section 3.1 of [RFC9787]).
* Data from signed-and-encrypted and encrypted-only Header Fields * Data from signed-and-encrypted and encrypted-only Header Fields
may still not be fully private (see Section 11.2). may still not be fully private (see Section 11.2).
* Encryption may have been added in transit to an originally signed- * Encryption may have been added in transit to an originally signed-
only message. Thus, only consider Header Fields to be only message. Thus, only consider Header Fields to be
confidential if the sender indicates it with the hp="cipher" confidential if the composer indicates it with the hp="cipher"
parameter. parameter.
* The protection state of a Header Field may be weaker than that of * The protection state of a Header Field may be weaker than that of
the message Body. For example, a message Body can be signed-and- the message Body. For example, a message Body can be signed-and-
encrypted, but a Header Field that is copied unmodified to the encrypted, but a Header Field that is copied unmodified to the
Outer Header Section is signed-only. Outer Header Section is signed-only.
If the message has Header Protection, the Header Fields that are not If the message has Header Protection, the Header Fields that are not
in refprotected (e.g., because they were added in transit) are in refprotected (e.g., because they were added in transit) are
unprotected. unprotected.
skipping to change at line 1454 skipping to change at line 1456
"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 * 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 rendering 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-
skipping to change at line 1484 skipping to change at line 1486
* 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 rendering MUA that depends on its MTA to authenticate
the (unprotected) outer From Header Field SHOULD render the outer the (unprotected) outer From Header Field SHOULD render the outer
From Header Field (as an exception to the guidance in the beginning From Header Field (as an exception to the guidance in the beginning
of Section 4) if both of the following conditions are met: of Section 4) if both of the following conditions are met:
* From Header Field Mismatch (as defined in Section 4.4.1.1) and * From Header Field Mismatch (as defined in Section 4.4.1.1) and
* No Valid and Correctly Bound Signature (as defined in * No Valid and Correctly Bound Signature (as defined in
Section 4.4.1.2) Section 4.4.1.2)
An MUA MAY apply a local preference to render a different display An MUA MAY apply a local preference to render a different display
skipping to change at line 1541 skipping to change at line 1543
converted to the A-label form as described in [RFC5891]. We call a converted to the A-label form as described in [RFC5891]. We call a
domain converted in this way (or the original domain if it didn't domain converted in this way (or the original domain if it didn't
contain any U-label) "the ASCII version of the domain part". Second, contain any U-label) "the ASCII version of the domain part". Second,
the MUA MUST compare the ASCII version of the domain part of the two the MUA MUST compare the ASCII version of the domain part of the two
addr-specs by standard DNS comparison: Assume ASCII text and compare addr-specs by standard DNS comparison: Assume ASCII text and compare
alphabetic characters case-insensitively, as described in Section 3.1 alphabetic characters case-insensitively, as described in Section 3.1
of [RFC1035]. If the domain parts match, then the two local-parts of [RFC1035]. If the domain parts match, then the two local-parts
are matched against each other. The simplest and most common are matched against each other. The simplest and most 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 rendering 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 content of the Cryptographic Payload the Body that is rendered is the content of the Cryptographic Payload
itself. 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
skipping to change at line 1589 skipping to change at line 1591
Legacy Display Element. Legacy Display Element.
The MUA should ignore Header Fields from part A for the purposes of The MUA should ignore Header Fields from part A for the purposes of
rendering. rendering.
4.5.2. Example Signed-and-Encrypted Message 4.5.2. Example Signed-and-Encrypted 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:
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
skipping to change at line 1633 skipping to change at line 1635
rendering. rendering.
4.5.3. Do Not Render Legacy Display Elements 4.5.3. Do Not Render Legacy Display Elements
As described in Section 2.1.2, a message with cryptographic As described in Section 2.1.2, a message with cryptographic
confidentiality protection MAY include Legacy Display Elements for confidentiality protection MAY include Legacy Display Elements for
backward compatibility with Legacy MUAs. These Legacy Display backward compatibility with Legacy MUAs. These Legacy Display
Elements are strictly decorative and unambiguously identifiable and Elements are strictly decorative and unambiguously identifiable and
will be discarded by compliant implementations. will be discarded by compliant implementations.
The receiving MUA MUST completely avoid rendering the identified The rendering MUA MUST completely avoid rendering the identified
Legacy Display Elements to the user, since it is aware of Header Legacy Display Elements to the user, since it is aware of Header
Protection and can render the actual protected Header Fields. Protection and can render the actual protected Header Fields.
If a text/html or text/plain part within the Cryptographic Envelope If a text/html or text/plain part within the Cryptographic Envelope
is identified as containing Legacy Display Elements, those elements is identified as containing Legacy Display Elements, those elements
MUST be hidden when rendering and MUST be dropped when generating a MUST be hidden when rendering and MUST be dropped when generating a
draft reply or inline forwarded message. Whenever a message or a draft reply or inline forwarded message. Whenever a message or a
MIME subtree is exported, downloaded, or otherwise further processed, MIME subtree is exported, downloaded, or otherwise further processed,
if there is no need to retain a valid cryptographic signature, the if there is no need to retain a valid cryptographic signature, the
implementer MAY drop the Legacy Display Elements. implementer MAY drop the Legacy Display Elements.
4.5.3.1. Identifying a Part with Legacy Display Elements 4.5.3.1. Identifying a Part with Legacy Display Elements
A receiving MUA acting on a message that contains an encrypting A rendering MUA acting on a message that contains an encrypting
Cryptographic Layer identifies a MIME subpart within the Cryptographic Layer identifies a MIME subpart within the
Cryptographic Payload as containing Legacy Display Elements based on Cryptographic Payload as containing Legacy Display Elements based on
the Content-Type of the subpart. The subpart's Content-Type: the Content-Type of the subpart. The subpart's Content-Type:
* contains a parameter hp-legacy-display with value set to 1 and * contains a parameter hp-legacy-display with value set to 1 and
* is either text/plain (see Section 4.5.3.2) or text/html (see * is either text/plain (see Section 4.5.3.2) or text/html (see
Section 4.5.3.3). Section 4.5.3.3).
Note that the term "subpart" above is used in the general sense: If Note that the term "subpart" above is used in the general sense: If
skipping to change at line 1885 skipping to change at line 1887
* The message that constitutes the Cryptographic Payload does not * The message that constitutes the Cryptographic Payload does not
itself have a well-formed Cryptographic Envelope; that is, its itself have a well-formed Cryptographic Envelope; that is, its
outermost MIME object is not a Cryptographic Layer. outermost MIME object is not a Cryptographic Layer.
* No Content-Type parameter of hp= is set on either the * No Content-Type parameter of hp= is set on either the
Cryptographic Payload or its immediate MIME child. Cryptographic Payload or its immediate MIME child.
Here is the MIME structure of an example signed-and-encrypted Here is the MIME structure of an example signed-and-encrypted
RFC8551HP message: RFC8551HP message:
A └─╴application/pkcs7-mime; smime-type="enveloped-data" A └┬╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to) ╧ (decrypts to)
B └─╴application/pkcs7-mime; smime-type="signed-data" B └┬╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to) ┴ (unwraps to)
C └┬╴message/rfc822 [Cryptographic Payload] C └┬╴message/rfc822 [Cryptographic Payload]
D └┬╴multipart/alternative [Rendered Body] D └┬╴multipart/alternative [Rendered Body]
E ├─╴text/plain E ├─╴text/plain
F └─╴text/html F └─╴text/html
This meets the definition of an RFC8551HP message because: This meets the definition of an RFC8551HP message because:
* Cryptographic Layers A and B form the Cryptographic Envelope. * Cryptographic Layers A and B form the Cryptographic Envelope.
* The Cryptographic Payload, rooted in part C, has Content-Type: * The Cryptographic Payload, rooted in part C, has Content-Type:
skipping to change at line 1928 skipping to change at line 1930
* 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 composer's
intent from the structure of the message. cryptographic 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
Header Section (those Header Fields found in part A in the example Header Section (those Header Fields found in part A in the example
above) rather than looking for HP-Outer Header Fields with the above) rather than looking for HP-Outer Header Fields with the
other protected Header Fields. That is, infer Header Field other protected Header Fields. That is, infer Header Field
confidentiality based on the unprotected Header Fields. confidentiality based on the unprotected Header Fields.
The inferences in the above modifications are not based on any strong The inferences in the above modifications are not based on any strong
end-to-end guarantees. An intervening MTA may tamper with the end-to-end guarantees. An intervening MTA may tamper with the
skipping to change at line 1957 skipping to change at line 1959
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
rendering an existing message that appears to use some other scheme rendering an existing message that appears to use some other scheme
not documented here. Pointers to some known other schemes can be not documented here. Pointers to some known other schemes can be
found in Appendix F. found in Appendix F.
5. Sending Guidance 5. Composing Guidance (Sending Side)
This section describes the process an MUA should use to apply This section describes the process an MUA should use to apply
cryptographic protection to an email message with Header Protection. cryptographic protection to an email message with Header Protection.
When composing a message with end-to-end cryptographic protections, When composing a message with end-to-end cryptographic protections,
an MUA SHOULD apply Header Protection. an MUA SHOULD apply Header Protection.
When generating such a message, an MUA MUST add the hp parameter (see When generating such a message, an MUA MUST add the hp parameter (see
Section 2.1.1) only to the Content-Type Header Field at the root of Section 2.1.1) only to the Content-Type Header Field at the root of
the message's Cryptographic Payload. The value of the parameter MUST the message's Cryptographic Payload. The value of the parameter MUST
skipping to change at line 2302 skipping to change at line 2304
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 rendering MUA and as a composing MUA. For
example, the user of an MUA viewing any given message might take an example, the user of an MUA viewing any given message might take an
action like "Reply", "Reply All", "Forward", or some comparable action like "Reply", "Reply All", "Forward", or some comparable
action to start the composition of a new message. The new message action to start the composition of a new message. The new message
created this way effectively references the original message that was created this way effectively references the original message that was
viewed at the time. viewed at the time.
For encrypted messages, special guidance applies, because information For encrypted messages, special guidance applies, because information
can leak in at least two ways: leaking previously confidential Header can leak in at least two ways: leaking previously confidential Header
Fields and leaking the entire message by sending the reply or forward Fields and leaking the entire message by sending the reply or forward
to the wrong party. to the wrong party.
skipping to change at line 2345 skipping to change at line 2347
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 referenced message. For example, the To Header Header Field in the referenced message. For example, the To Header
Field is typically derived from the referenced message's Reply-To or Field is typically derived from the referenced message's Reply-To or
From Header Fields. When generating this Header Field for the Outer From Header Fields. When generating this Header Field for the Outer
Header Section, the composing MUA first applies its own HCP. If the Header Section, the composing MUA first applies its own HCP. If the
Header Field's value is changed by that HCP, then the resulting value Header Field's value is changed by that HCP, then the resulting value
is used for the Outer Header Section. If the Header Field's value is is used for the Outer Header Section. If the Header Field's value is
unchanged, the composing MUA re-generates the Header Field using the unchanged, the composing MUA re-generates the Header Field using the
Header Fields that had been in the Outer Header Section of the Header Fields that had been in the Outer Header Section of the
original message at sending time. These are inferred from the HP- original message at composition time. These are inferred from the
Outer Header Fields located within the Cryptographic Payload of the HP-Outer Header Fields located within the Cryptographic Payload of
referenced message. If the value is itself different than the the referenced message. If the value is itself different than the
protected value, then it is applied to the Outer Header Section. If protected value, then it is applied to the Outer Header Section. If
the value is the same as the protected value, then it is simply the value is the same as the protected value, then it is simply
copied to the Outer Header Section directly. As long as the copied to the Outer Header Section directly. As long as the
resulting value is not null, it is noted (whether identical to the resulting value is not null, it is noted (whether identical to the
protected value or not) in the protected Header Section using HP- protected value or not) in the protected Header Section using HP-
Outer, as described in Section 2.2.1. Outer, as described in Section 2.2.1.
See Appendix D.2 for a simple worked example of this process. See Appendix D.2 for a simple worked example of this process.
Below we describe a supporting algorithm to handle this. It produces Below we describe a supporting algorithm to handle this. It produces
a list of Header Fields that should be obscured or removed in the new a list of Header Fields that should be obscured or removed in the new
message even if the sender's choice of HCP wouldn't normally remove message even if the composer's choice of HCP wouldn't normally remove
or obscure the Header Field in question. This is effectively a or obscure the Header Field in question. This is effectively a
single-use HCP. The normal sending guidance in Section 5.2 applies single-use HCP. The normal composing guidance in Section 5.2 applies
this single-use HCP to implement the high-level guidance above. this single-use HCP to implement the high-level guidance above.
6.1.1. The Respond Function 6.1.1. The Respond Function
The mechanism described below depends on an abstraction referred to The mechanism described below depends on an abstraction referred to
in this document as a Respond Function. in this document as a Respond Function.
The Respond Function takes a list of Header Fields from a referenced The Respond Function takes a list of Header Fields from a referenced
message as input and generates a list of initial candidate message message as input and generates a list of initial candidate message
Header Field names and values that are used to populate the message Header Field names and values that are used to populate the message
skipping to change at line 2447 skipping to change at line 2449
8. Return a new HCP from confmap that tests whether the 8. Return a new HCP from confmap that tests whether the
(name,val_in) tuple is in confmap; if so, return (name,val_in) tuple is in confmap; if so, return
confmap[(name,val_in)]; otherwise, return val_in. confmap[(name,val_in)]; otherwise, return val_in.
Note that the key idea here is to reuse the MUA's existing Respond Note that the key idea here is to reuse the MUA's existing Respond
Function. The algorithm simulates how the MUA would pre-populate a Function. The algorithm simulates how the MUA would pre-populate a
reply to (or forward of) two messages whose Header Fields have the reply to (or forward of) two messages whose Header Fields have the
values refouter and refprotected, respectively (independent of any values refouter and refprotected, respectively (independent of any
cryptographic protections). Then, it uses the difference to derive a cryptographic protections). Then, it uses the difference to derive a
one-time HCP. This HCP takes into account both the referenced one-time HCP. This HCP takes into account both the referenced
message's sender's preferences and the derivations that can happen to message's composer's preferences and the derivations that can happen
Header Field values when responding. Note that while some of these to Header Field values when responding. Note that while some of
derivations are straightforward (e.g., In-Reply-To is usually derived these derivations are straightforward (e.g., In-Reply-To is usually
from Message-ID), others are non-trivial. For example, the From derived from Message-ID), others are non-trivial. For example, the
address may be derived from To, Cc, or the MUA's local address From address may be derived from To, Cc, or the MUA's local address
preference (especially when the MUA received the referenced message preference (especially when the MUA received the referenced message
via Bcc). Similarly, To may be derived from To, From, and/or Cc via Bcc). Similarly, To may be derived from To, From, and/or Cc
Header Fields depending on the MUA implementation and depending on Header Fields depending on the MUA implementation and depending on
whether the user clicked "Reply", "Reply All", "Forward", or any whether the user clicked "Reply", "Reply All", "Forward", or any
other action that generates a response to a message. Reusing the other action that generates a response to a message. Reusing the
MUA's existing Respond Function incorporates these nuances without MUA's existing Respond Function incorporates these nuances without
requiring any extra configuration choices or additional maintenance requiring any extra configuration choices or additional maintenance
burden. burden.
6.2. Avoid Misdirected Replies 6.2. Avoid Misdirected Replies
skipping to change at line 2488 skipping to change at line 2490
message's (unprotected) Outer Header Section. message's (unprotected) Outer Header Section.
If Bob knows Mallory's certificate already, and he replies to such a If Bob knows Mallory's certificate already, and he replies to such a
message without following the guidance in this section, it's likely message without following the guidance in this section, it's likely
that his MUA will encrypt the cleartext of the message directly to that his MUA will encrypt the cleartext of the message directly to
Mallory. Mallory.
7. Unprotected Header Fields Added in Transit 7. Unprotected Header Fields Added in Transit
Some Header Fields are legitimately added in transit and could not Some Header Fields are legitimately added in transit and could not
have been known to the sender at message composition time. have been known to the composer at message composition time.
The most common of these Header Fields are Received and DKIM- The most common of these Header Fields are Received and DKIM-
Signature, neither of which are typically rendered, either explicitly Signature, neither of which are typically rendered, either explicitly
or implicitly. or implicitly.
If a receiving MUA has specific knowledge about a given Header Field, If a rendering MUA has specific knowledge about a given Header Field,
including that: including that:
* the Header Field would not have been known to the original sender * the Header Field would not have been known to the original
and composer and
* the Header Field might be rendered explicitly or implicitly, * the Header Field might be rendered explicitly or implicitly,
then the MUA MAY decide to operate on the value of that Header Field then the MUA MAY decide to operate on the value of that Header Field
from the Outer Header Section, even though the message has Header from the Outer Header Section, even though the message has Header
Protection. Protection.
The MUA MAY prefer to verify that the Header Fields in question have The MUA MAY prefer to verify that the Header Fields in question have
additional transit-derived cryptographic protections before rendering additional transit-derived cryptographic protections before rendering
or acting on them. For example, the MUA could verify whether these or acting on them. For example, the MUA could verify whether these
skipping to change at line 2540 skipping to change at line 2542
* List-Help * List-Help
* List-Post * List-Post
* Archived-At * Archived-At
Some MUAs render these Header Fields implicitly by providing buttons Some MUAs render these Header Fields implicitly by providing buttons
for actions like "Subscribe", "View Archived Version", "Reply List", for actions like "Subscribe", "View Archived Version", "Reply List",
"List Info", etc. "List Info", etc.
An MUA that receives a message with Header Protection that contains An MUA rendering a message with Header Protection that contains any
any of these Header Fields in the Outer Header Section and that has of these Header Fields in the Outer Header Section and that has
reason to believe the message is coming through a mailing list MAY reason to believe the message arrived through a mailing list MAY
decide to render them to the user (explicitly or implicitly) even decide to render them to the user (explicitly or implicitly) even
though they 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
skipping to change at line 2579 skipping to change at line 2581
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 rendering 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
indicating capability of handling messages with Header Protection indicating capability of handling messages with Header Protection
might be placed in the user's cryptographic certificate or in might be placed in the user's cryptographic certificate or in
outbound messages. outbound messages.
This document does not attempt to define the syntax or semantics of This document does not attempt to define the syntax or semantics of
such a signal. such a signal.
8.2. More Ambitious Default HCP 8.2. More Ambitious Default HCP
skipping to change at line 2652 skipping to change at line 2654
render a signed-only message that has no Header Protection the same render a signed-only message that has no Header Protection the same
as an unprotected message. And a signed-and-encrypted message as an unprotected message. And a signed-and-encrypted message
without Header Protection could likewise be marked as not fully without Header Protection could likewise be marked as not fully
protected. protected.
These stricter rules could be adopted immediately for all messages. These stricter rules could be adopted immediately for all messages.
Or an MUA developer could roll them out immediately for any new Or an MUA developer could roll them out immediately for any new
message but still treat an old message (based on the Date Header message but still treat an old message (based on the Date Header
Field and cryptographic signature timestamp) more leniently. Field and cryptographic signature timestamp) more leniently.
A decision like this by any popular receiving MUA could drive A decision like this by any popular rendering MUA could drive
adoption of this standard for sending MUAs. adoption of this standard for composing MUAs.
9. Usability Considerations 9. Usability Considerations
This section describes concerns for MUAs that are interested in easy This section describes concerns for MUAs that are interested in easy
adoption of Header Protection by normal users. adoption of Header Protection by normal users.
While they are not protocol-level artifacts, these concerns motivate While they are not protocol-level artifacts, these concerns motivate
the protocol features described in this document. the protocol features described in this document.
See also the usability commentary in Section 2 of [RFC9787]. See also the usability commentary in Section 2 of [RFC9787].
skipping to change at line 2763 skipping to change at line 2765
Message Syntax (CMS)), and Section 14 of [RFC5652] (CMS more broadly) Message Syntax (CMS)), and Section 14 of [RFC5652] (CMS more broadly)
continue to apply. Likewise, for any MUA that offers PGP/MIME continue to apply. Likewise, for any MUA that offers PGP/MIME
cryptographic protections, the security considerations from Section 8 cryptographic protections, the security considerations from Section 8
of [RFC3156] (PGP with MIME) as well as Section 13 of [RFC9580] of [RFC3156] (PGP with MIME) as well as Section 13 of [RFC9580]
(OpenPGP itself) continue to apply. In addition, these underlying (OpenPGP itself) continue to apply. In addition, these underlying
security considerations are now also applicable to the contents of security considerations are now also applicable to the contents of
the message Header Section, not just the message Body. the message Header Section, not just the message Body.
10.1. From Address Spoofing 10.1. From Address Spoofing
For a receiving MUA that depends on its MTA to authenticate the For a rendering MUA that depends on its MTA to authenticate the
origin of the message, applying this specification could enable origin of the message, applying this specification could enable
sender address spoofing. sender address spoofing.
To prevent sender spoofing, many receiving MUAs implicitly rely on To prevent sender spoofing, many rendering MUAs implicitly rely on
their receiving MTA to inspect the Outer Header Section and verify their receiving MTA to inspect the Outer Header Section and verify
that the From Header Field is authentic. If a receiving MUA displays that the From Header Field is authentic. If a rendering MUA displays
a From address (from the protected part) that doesn't match the From a From address (from the protected part) that doesn't match the From
address the MTA used to authenticate and/or filter (see also address the MTA used to authenticate and/or filter (see also
Section 4.4.1.1), the MUA may be vulnerable to spoofing. Section 4.4.1.1), the MUA may be vulnerable to spoofing.
Consider a malicious MUA that sets the following Header Fields on an Consider a malicious MUA that sets the following Header Fields on an
encrypted message with Header Protection: encrypted message with Header Protection:
* Outer: From: <alice@example.com> * Outer: From: <alice@example.com>
* Inner: HP-Outer: From: <alice@example.com> * Inner: HP-Outer: From: <alice@example.com>
* Inner: From: <bob@example.org> * Inner: From: <bob@example.org>
During sending, the MTA of example.com validates that the sending MUA During sending, the MTA of example.com validates that the sending MUA
is authorized to send from alice@example.com. Since the message is is authorized to send from alice@example.com. Since the message is
encrypted, the sending and receiving MTAs cannot see the protected encrypted, the sending and receiving MTAs cannot see the protected
Header Fields. A naive receiving MUA might follow the algorithms in Header Fields. A naive rendering MUA might follow the algorithms in
this document without special consideration for the From Header this document without special consideration for the From Header
Field. Such an MUA might display the email as coming from Field. Such an MUA might display the email as coming from
bob@example.org to the user, resulting in a spoofed address. bob@example.org to the user, resulting in a spoofed address.
This problem applies both between domains and within a domain. This problem applies both between domains and within a domain.
This problem always applies to signed-and-encrypted messages. This This problem always applies to signed-and-encrypted messages. This
problem also applies to signed-only messages because MTAs typically problem also applies to signed-only messages because MTAs typically
do not look at the protected Header Fields when confirming From do not look at the protected Header Fields when confirming From
address authenticity. address authenticity.
skipping to change at line 2810 skipping to change at line 2812
* Sender authenticity: relevant for rendering the message (which * Sender authenticity: relevant for rendering the message (which
address to show the user?) address to show the user?)
* Message confidentiality: relevant when replying to a message (a * Message confidentiality: relevant when replying to a message (a
reply to the wrong address can leak the message contents) reply to the wrong address can leak the message contents)
10.1.1. From Rendering Reasoning 10.1.1. From Rendering Reasoning
Section 4.4.3 provides guidance for rendering the From Header Field. Section 4.4.3 provides guidance for rendering the From Header Field.
It recommends a receiving MUA that depends on its MTA to authenticate It recommends a rendering MUA that depends on its MTA to authenticate
the (unprotected) outer From Header Field to render the outer From the (unprotected) outer From Header Field to render the outer From
Header Field if both of the following conditions are met: Header Field if both of the following conditions are met:
* From Header Field Mismatch (as defined in Section 4.4.1.1) and * From Header Field Mismatch (as defined in Section 4.4.1.1) and
* No Valid and Correctly Bound Signature (as defined in * No Valid and Correctly Bound Signature (as defined in
Section 4.4.1.2) Section 4.4.1.2)
Note: The second condition effectively means that the inner (expected Note: The second condition effectively means that the inner (expected
to be protected) From Header Field appears to have insufficient to be protected) From Header Field appears to have insufficient
protection. protection.
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
argument as to why this guidance makes sense. argument as to why this guidance makes sense.
We proceed by case distinction: We proceed by case distinction:
* Case 1: Malicious sending MUA. * Case 1: Malicious composing MUA.
- Attack situation: The sending MUA puts a different inner From - Attack situation: The composing MUA puts a different inner From
Header Field to spoof the sender address. Header Field to spoof the sender address.
- In this case, it is "better" to fall back and render the outer - In this case, it is "better" to fall back and render the outer
From Header Field because this is what the receiving MTA can From Header Field because this is what the receiving MTA can
validate. Otherwise, this document would introduce a new way validate. Otherwise, this document would introduce a new way
for senders to spoof the From address of the message. for senders to spoof the From address of the message.
- This does not preclude a future document from updating this - This does not preclude a future document from updating this
document to specify a protocol for legitimate sender address document to specify a protocol for legitimate sender address
hiding. hiding.
* Case 2: Malicious sending/transiting/receiving MTA (or anyone * Case 2: Malicious sending/transiting/receiving MTA (or anyone
meddling between MTAs). meddling between MTAs).
- Attack situation: An on-path attacker changes the outer From - Attack situation: An on-path attacker changes the outer From
Header Field (possibly with other meddling to invalidate the Header Field (possibly with other meddling to invalidate the
signature; see below). Their goal is to get the receiving MUA signature; see below). Their goal is to get the rendering MUA
to show a different From address than the sending MUA intended to show a different From address than the composing MUA
(breaking MUA-to-MUA sender authenticity). intended (breaking MUA-to-MUA sender authenticity).
- Case 2.a: The sending MUA submitted an unsigned or encrypted- - Case 2.a: The composing MUA submitted an unsigned or encrypted-
only message to the email system. In this case, there can be only message to the email system. In this case, there can be
no sender authenticity anyway. no sender authenticity anyway.
- Case 2.b: The sending MUA submitted a signed-only message to - Case 2.b: The composing MUA submitted a signed-only message to
the email system. the email system.
o Case 2.b.i: The attacker removes or invalidates the o Case 2.b.i: The attacker removes or invalidates the
signature. In this case, the attacker can also modify the signature. In this case, the attacker can also modify the
inner From Header Field to their liking. inner From Header Field to their liking.
o Case 2.b.ii: The signature is valid, but the receiving MUA o Case 2.b.ii: The signature is valid, but the rendering MUA
does not see any valid binding between the signing does not see any valid binding between the signing
certificate and the addr-spec of the inner From Header certificate and the addr-spec of the inner From Header
Field. In this case, there can be no sender authenticity Field. In this case, there can be no sender authenticity
anyways (the certificate could have been generated by the anyways (the certificate could have been generated by the
on-path attacker). This case is indistinguishable from a on-path attacker). This case is indistinguishable from a
malicious sending MUA; hence, it is "better" to fall back to malicious composing MUA; hence, it is "better" to fall back
the outer From Header Field that the MTA can validate. Note to the outer From Header Field that the MTA can validate.
that once the binding is validated (e.g., after an out-of- Note that once the binding is validated (e.g., after an out-
band comparison), the rendering may change from showing the of-band comparison), the rendering may change from showing
outer From address (and a warning) to showing the inner, now the outer From address (and a warning) to showing the inner,
validated From address. In some cases, the binding may be now validated From address. In some cases, the binding may
instantly validated even for previously unseen certificates be instantly validated even for previously unseen
(e.g., if the certificate is issued by a trusted certificates (e.g., if the certificate is issued by a
certification authority). trusted certification authority).
- Case 2.c: The sending MUA submitted a signed-and-encrypted - Case 2.c: The composing MUA submitted a signed-and-encrypted
message to the email system. message to the email system.
o Case 2.c.i: The attacker removes or invalidates the o Case 2.c.i: The attacker removes or invalidates the
signature. Note that the signature is inside the ciphertext signature. Note that the signature is inside the ciphertext
(see Section 5.2 of [RFC9787]). Thus, assuming the (see Section 5.2 of [RFC9787]). Thus, assuming the
encryption is non-malleable, any on-path attacker cannot encryption is non-malleable, any on-path attacker cannot
invalidate the signature while ensuring that the message invalidate the signature while ensuring that the message
still decrypts successfully. still decrypts successfully.
o Case 2.c.ii: The signature is valid, but the receiving MUA o Case 2.c.ii: The signature is valid, but the rendering MUA
does not see any valid binding between the signing does not see any valid binding between the signing
certificate and the addr-spec of the inner From Header certificate and the addr-spec of the inner From Header
Field. See case 2.b.ii. Field. See case 2.b.ii.
As the case distinction shows, the outer From Header Field is either As the case distinction shows, the outer From Header Field is either
the preferred fallback (in particular, to avoid introducing a new the preferred fallback (in particular, to avoid introducing a new
spoofing channel) or just as good (because just as modifiable) as the spoofing channel) or just as good (because just as modifiable) as the
inner From Header Field. inner From Header Field.
Rendering the outer From Header Field does carry the risk of a Rendering the outer From Header Field does carry the risk of a
skipping to change at line 2930 skipping to change at line 2932
10.2. Avoid Cryptographic Summary Confusion from the hp Parameter 10.2. Avoid Cryptographic Summary Confusion from the hp Parameter
When parsing a message, the recipient MUA infers the message's When parsing a message, the recipient MUA infers the message's
Cryptographic Status from the Cryptographic Layers, as described in Cryptographic Status from the Cryptographic Layers, as described in
Section 4.6 of [RFC9787]. Section 4.6 of [RFC9787].
The Cryptographic Layers that make up the Cryptographic Envelope The Cryptographic Layers that make up the Cryptographic Envelope
describe an ordered list of cryptographic properties as present in describe an ordered list of cryptographic properties as present in
the message after it has been delivered. By contrast, the hp the message after it has been delivered. By contrast, the hp
parameter to the Content-Type Header Field contains a simpler parameter to the Content-Type Header Field contains a simpler
indication: whether the sender originally tried to encrypt the indication: whether the composer originally tried to encrypt the
message or not (see Section 2.1.1). In particular, for a message message or not (see Section 2.1.1). In particular, for a message
with Header Protection, the Cryptographic Payload MUST have a hp with Header Protection, the Cryptographic Payload MUST have a hp
parameter of cipher if the message is encrypted (in addition to parameter of cipher if the message is encrypted (in addition to
signed) and clear if no encryption is present (that is, the message signed) and clear if no encryption is present (that is, the message
is signed-only). is signed-only).
As noted in Section 2.1.1, the receiving implementation MUST NOT As noted in Section 2.1.1, the rendering implementation MUST NOT
inflate its estimation of the confidentiality of the message or its inflate its estimation of the confidentiality of the message or its
Header Fields based on the sender's intent if it can see that the Header Fields based on the composer's intent if it can see that the
message was not actually encrypted. A signed-only message that message was not actually encrypted. A signed-only message that
happens to have an hp parameter of cipher is still signed-only. happens to have an hp parameter of cipher is still signed-only.
Conversely, since the encrypting Cryptographic Layer is typically Conversely, since the encrypting Cryptographic Layer is typically
outside the signature layer (see Section 5.2 of [RFC9787]), an outside the signature layer (see Section 5.2 of [RFC9787]), an
originally signed-only message could have been wrapped in an originally signed-only message could have been wrapped in an
encryption layer by an intervening party before receipt to appear encryption layer by an intervening party before receipt to appear
encrypted. encrypted.
If a message appears to be wrapped in an encryption layer, and the hp If a message appears to be wrapped in an encryption layer, and the hp
parameter is present but is not set to cipher, then it is likely that parameter is present but is not set to cipher, then it is likely that
the encryption layer was not added by the original sender. For such the encryption layer was not added by the original composer. For
a message, the lack of any HP-Outer Header Field (see Section 2.2) in such a message, the lack of any HP-Outer Header Field (see
the Header Section of the Cryptographic Payload MUST NOT be used to Section 2.2) in the Header Section of the Cryptographic Payload MUST
infer that all Header Fields were removed from the Outer Header NOT be used to infer that all Header Fields were removed from the
Section by the original sender. In such a case, the receiving MUA Outer Header Section by the original composer. In such a case, the
SHOULD treat every Header Field as though it was not confidential. rendering MUA SHOULD treat every Header Field as though it was not
confidential.
10.3. Caution About Composing with Legacy Display Elements 10.3. Caution About Composing with Legacy Display Elements
When composing a message, it's possible for a Legacy Display Element When composing a message, it's possible for a Legacy Display Element
(see Section 2.1.2) to contain risky data that could trigger errors (see Section 2.1.2) to contain risky data that could trigger errors
in a rendering client. in a rendering client.
For example, if the value for a Header Field to be included in a For example, if the value for a Header Field to be included in a
Legacy Display Element within a given Body part contains folding Legacy Display Element within a given Body part contains folding
whitespace, it SHOULD be "unfolded" before generating the Legacy whitespace, it SHOULD be "unfolded" before generating the Legacy
Display Element: All contiguous folding whitespace SHOULD be replaced Display Element: All contiguous folding whitespace SHOULD be replaced
with a single space character. Likewise, if the Header Field value with a single space character. Likewise, if the Header Field value
was originally encoded per [RFC2047], it SHOULD be decoded first to a was originally encoded per [RFC2047], it SHOULD be decoded first to a
standard string and re-encoded using the charset appropriate to the standard string and re-encoded using the charset appropriate to the
target part. target part.
When including a Legacy Display Element in a text/plain part (see When including a Legacy Display Element in a text/plain part (see
Section 5.2.2), if the decoded Subject Header Field contains a pair Section 5.2.2), if the decoded Subject Header Field contains a pair
of newlines (e.g., if it is broken across multiple lines by encoded of newlines (e.g., if it is broken across multiple lines by encoded
newlines), the sending MUA MUST strip any newline from the Legacy newlines), the composing MUA MUST strip any newline from the Legacy
Display Element. If the pair of newlines is not stripped, a Display Element. If the pair of newlines is not stripped, a
receiving MUA that follows the guidance in Section 4.5.3.2 might rendering MUA that follows the guidance in Section 4.5.3.2 might
leave the later part of the Legacy Display Element in the rendered leave the later part of the Legacy Display Element in the rendered
message. message.
When including a Legacy Display Element in a text/html part (see When including a Legacy Display Element in a text/html part (see
Section 5.2.3), any material in the Header Field values MUST be Section 5.2.3), any material in the Header Field values MUST be
explicitly HTML escaped to avoid being rendered as part of the HTML. explicitly HTML escaped to avoid being rendered as part of the HTML.
At a minimum, the characters <, >, ', ", and & MUST be escaped to At a minimum, the characters <, >, ', ", and & MUST be escaped to
&lt;, &gt;, &apos;, &quot;, and &amp;, respectively (for example, see &lt;, &gt;, &apos;, &quot;, and &amp;, respectively (for example, see
[HTML-ESCAPES]). If unescaped characters from removed or obscured [HTML-ESCAPES]). If unescaped characters from removed or obscured
Header Field values end up in the Legacy Display Element, a receiving Header Field values end up in the Legacy Display Element, a rendering
MUA that follows the guidance in Section 4.5.3.3 might fail to MUA that follows the guidance in Section 4.5.3.3 might fail to
identify the boundaries of the Legacy Display Element, cutting out identify the boundaries of the Legacy Display Element, cutting out
more than it should or leaving remnants visible. And a Legacy MUA more than it should or leaving remnants visible. And a Legacy MUA
parsing such a message might misrender the entire HTML stream, parsing such a message might misrender the entire HTML stream,
depending on the content of the removed or obscured Header Field depending on the content of the removed or obscured Header Field
values. 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
skipping to change at line 3032 skipping to change at line 3035
11. Privacy Considerations 11. Privacy Considerations
11.1. Leaks When Replying 11.1. Leaks When Replying
The encrypted Header Fields of a message may accidentally leak when The encrypted Header Fields of a message may accidentally leak when
replying to the message. See the guidance in Section 6. replying to the message. See the guidance in Section 6.
11.2. Encrypted Header Fields Are Not Always Private 11.2. Encrypted Header Fields Are Not Always Private
For encrypted messages, depending on the sender's HCP, some Header For encrypted messages, depending on the composer's HCP, some Header
Fields may appear both within the Cryptographic Envelope and on the Fields may appear both within the Cryptographic Envelope and on the
outside of the message (e.g., Date might exist identically in both outside of the message (e.g., Date might exist identically in both
places). Section 4.3 identifies such a Header Field as signed-only. places). Section 4.3 identifies such a Header Field as signed-only.
These Header Fields are clearly _not_ private at all, despite a copy These Header Fields are clearly _not_ private at all, despite a copy
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 composer isn't
the message contents or session keys can leak in many ways that are careful, the message contents or session keys can leak in many ways
beyond the scope of this document. The message recipient has no way that are beyond the scope of this document. The message recipient
in principle to tell whether the apparent confidentiality of any has no way in principle to tell whether the apparent confidentiality
given piece of encrypted content has been broken via channels that of any given piece of encrypted content has been broken via channels
they cannot perceive. Additionally, an active intermediary aware of that they cannot perceive. Additionally, an active intermediary
the recipient's public key can always encrypt a cleartext message in aware of the recipient's public key can always encrypt a cleartext
transit to give the recipient a false sense of security (see also message in transit to give the recipient a false sense of security
Section 10.2). (see also Section 10.2).
11.2.1. Encrypted Header Fields Can Leak Unwanted Information to the 11.2.1. Encrypted Header Fields Can Leak Unwanted Information to the
Recipient Recipient
For an encrypted message, even with an ambitious HCP that For an encrypted message, even with an ambitious HCP that
successfully obscures most Header Fields from all transport agents, successfully obscures most Header Fields from all transport agents,
Header Fields will be ultimately visible to each intended recipient. Header Fields will be ultimately visible to each intended recipient.
This can be especially problematic for a Header Field that is not This can be especially problematic for a Header Field that is not
User-Facing; the sender may not expect such a Header Field to be User-Facing; the composer may not expect such a Header Field to be
injected by their MUA. Consider the three following examples: injected by their MUA. Consider the three following examples:
* The MUA may inject a User-Agent Header Field that describes itself * The MUA may inject a User-Agent Header Field that describes itself
to every recipient, even though the sender may not want a to every recipient, even though the composer may not want a
recipient to know the exact version of their OS, hardware recipient to know the exact version of their OS, hardware
platform, or MUA. platform, or MUA.
* The MUA may have an idiosyncratic way of generating a Message-ID * The MUA may have an idiosyncratic way of generating a Message-ID
Header Field, which could embed the choice of MUA, time zone, Header Field, which could embed the choice of MUA, time zone,
hostname, or other subtle information to a knowledgeable hostname, or other subtle information to a knowledgeable
recipient. recipient.
* The MUA may erroneously include a Bcc Header Field in the * The MUA may erroneously include a Bcc Header Field in the
origheaders of a copy of a message sent to a named recipient, origheaders of a copy of a message sent to a named recipient,
skipping to change at line 3139 skipping to change at line 3142
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.
11.3. A Naive Recipient May Overestimate the Cryptographic Status of a 11.3. A Naive Recipient May Overestimate the Cryptographic Status of a
Header Field in an Encrypted Message Header Field in an Encrypted Message
When an encrypted (or signed-and-encrypted) message is in transit, an When an encrypted (or signed-and-encrypted) message is in transit, an
active intermediary can strip or tamper with any Header Field that active intermediary can strip or tamper with any Header Field that
appears outside the Cryptographic Envelope. A receiving MUA that appears outside the Cryptographic Envelope. A rendering MUA that
naively infers cryptographic status from differences between the naively infers cryptographic status from differences between the
external Header Fields and those found in the Cryptographic Envelope external Header Fields and those found in the Cryptographic Envelope
could be tricked into overestimating the protections afforded to some could be tricked into overestimating the protections afforded to some
Header Fields. Header Fields.
For example, if the original sender's HCP passes through the Cc For example, if the original composer's HCP passes through the Cc
Header Field unchanged, a cleanly delivered message would indicate Header Field unchanged, a cleanly delivered message would indicate
that the Cc Header Field has a cryptographic status of signed. But that the Cc Header Field has a cryptographic status of signed. But
if an intermediary attacker simply removes the Header Field from the if an intermediary attacker simply removes the Header Field from the
Outer Header Section before forwarding the message, then the naive Outer Header Section before forwarding the message, then the naive
recipient might believe that the field has a cryptographic status of recipient might believe that the field has a cryptographic status of
signed-and-encrypted. signed-and-encrypted.
This document offers protection against such an attack by way of the This document offers protection against such an attack by way of the
HP-Outer Header Fields (see Section 2.2) that can be found on the HP-Outer Header Fields (see Section 2.2) that can be found on the
Cryptographic Payload. If a Header Field appears to have been Cryptographic Payload. If a Header Field appears to have been
obscured by inspection of the Outer Header Section but an HP-Outer obscured by inspection of the Outer Header Section but an HP-Outer
Header Field matches it exactly, then the receiving MUA can indicate Header Field matches it exactly, then the rendering MUA can indicate
to the user that the Header Field in question may not have been to the user that the Header Field in question may not have been
confidential. confidential.
In such a case, a cautious MUA may render the Header Field in In such a case, a cautious MUA may render the Header Field in
question as signed (because the sender did not hide it) but still question as signed (because the composer did not hide it) but still
treat it as signed-and-encrypted during reply to avoid accidental treat it as signed-and-encrypted during reply to avoid accidental
leakage of the cleartext value in the reply message, as described in leakage of the cleartext value in the reply message, as described in
Section 6.1. Section 6.1.
11.4. Privacy and Deliverability Risks with Bcc and Encrypted Messages 11.4. Privacy and Deliverability Risks with Bcc and Encrypted Messages
As noted in Section 9.3 of [RFC9787], handling Bcc when generating an As noted in Section 9.3 of [RFC9787], handling Bcc when generating an
encrypted email message can be particularly tricky. With Header encrypted email message can be particularly tricky. With Header
Protection, there is an additional wrinkle. When an encrypted email Protection, there is an additional wrinkle. When an encrypted email
message with Header Protection has a Bcc'ed recipient, and the message with Header Protection has a Bcc'ed recipient, and the
skipping to change at line 3531 skipping to change at line 3534
| | 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 an MUA, the user might experience many different possible rendered by an 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.
In this section, the authors enumerate different kinds of failures we In this section, the authors enumerate different kinds of failures we
have observed when reviewing, rendering, and replying to messages have observed when reviewing, rendering, and replying to messages
with different forms of Header Protection in different Legacy MUAs. with different forms of Header Protection in different Legacy MUAs.
Different Legacy MUAs demonstrate different subsets of these Different Legacy MUAs demonstrate different subsets of these
problems. problems.
A conformant MUA would not exhibit any of these problems. An A conformant MUA would not exhibit any of these problems. An
skipping to change at line 3706 skipping to change at line 3709
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
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
Subject: smime-one-part Subject: smime-one-part
Message-ID: <smime-one-part@example> Message-ID: <smime-one-part@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
skipping to change at line 3915 skipping to change at line 3918
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:
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"
Subject: smime-signed-enc Subject: smime-signed-enc
Message-ID: <smime-signed-enc@example> Message-ID: <smime-signed-enc@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
skipping to change at line 4209 skipping to change at line 4212
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
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 4519 skipping to change at line 4522
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
│└─╴text/html 390 bytes │└─╴text/html 390 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 4841 skipping to change at line 4844
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 RFC 9788. scheme from RFC 9788.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 4189 bytes └┬╴application/pkcs7-mime [smime.p7m] 4189 bytes
⇩ (unwraps to) ┴ (unwraps to)
└─╴text/plain 232 bytes └─╴text/plain 232 bytes
Its contents are: Its contents are:
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="signed-data" smime-type="signed-data"
Subject: smime-one-part-hp Subject: smime-one-part-hp
Message-ID: <smime-one-part-hp@example> Message-ID: <smime-one-part-hp@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
skipping to change at line 5068 skipping to change at line 5071
C.2.3. S/MIME Signed-Only signedData over a Complex Message, Header C.2.3. S/MIME Signed-Only signedData over a Complex 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 multipart/alternative message with an inline image/png payload is a multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788. attachment. It uses the Header Protection scheme from RFC 9788.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 5643 bytes └┬╴application/pkcs7-mime [smime.p7m] 5643 bytes
⇩ (unwraps to) ┴ (unwraps to)
└┬╴multipart/mixed 1568 bytes └┬╴multipart/mixed 1568 bytes
├┬╴multipart/alternative 932 bytes ├┬╴multipart/alternative 932 bytes
│├─╴text/plain 286 bytes │├─╴text/plain 286 bytes
│└─╴text/html 381 bytes │└─╴text/html 381 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 5399 skipping to change at line 5402
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
│└─╴text/html 394 bytes │└─╴text/html 394 bytes
└─╴image/png inline 232 bytes └─╴image/png inline 232 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
skipping to change at line 5747 skipping to change at line 5750
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 RFC 9788 with the message. It uses the Header Protection scheme from RFC 9788 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] 7825 bytes └┬╴application/pkcs7-mime [smime.p7m] 7825 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 4786 bytes └┬╴application/pkcs7-mime [smime.p7m] 4786 bytes
⇩ (unwraps to) ┴ (unwraps to)
└─╴text/plain 330 bytes └─╴text/plain 330 bytes
Its contents are: Its contents are:
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"
Subject: [...] Subject: [...]
Message-ID: <smime-signed-enc-hp-baseline@example> Message-ID: <smime-signed-enc-hp-baseline@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
skipping to change at line 6015 skipping to change at line 6018
Protection with hcp_baseline (+ Legacy Display) Protection with hcp_baseline (+ Legacy Display)
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 RFC 9788 with the message. It uses the Header Protection scheme from RFC 9788 with the
hcp_baseline Header Confidentiality Policy with a "Legacy Display" hcp_baseline Header Confidentiality Policy with a "Legacy Display"
element. element.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8085 bytes └┬╴application/pkcs7-mime [smime.p7m] 8085 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 4972 bytes └┬╴application/pkcs7-mime [smime.p7m] 4972 bytes
⇩ (unwraps to) ┴ (unwraps to)
└─╴text/plain 418 bytes └─╴text/plain 418 bytes
Its contents are: Its contents are:
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"
Subject: [...] Subject: [...]
Message-ID: <smime-signed-enc-hp-baseline-legacy@example> Message-ID: <smime-signed-enc-hp-baseline-legacy@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
skipping to change at line 6295 skipping to change at line 6298
C.3.3. S/MIME Signed-and-Encrypted over a Simple Message, Header C.3.3. S/MIME Signed-and-Encrypted over a Simple Message, Header
Protection with hcp_shy Protection with hcp_shy
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 RFC 9788 with the message. It uses the Header Protection scheme from RFC 9788 with the
hcp_shy Header Confidentiality Policy. hcp_shy Header Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 7760 bytes └┬╴application/pkcs7-mime [smime.p7m] 7760 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 4732 bytes └┬╴application/pkcs7-mime [smime.p7m] 4732 bytes
⇩ (unwraps to) ┴ (unwraps to)
└─╴text/plain 320 bytes └─╴text/plain 320 bytes
Its contents are: Its contents are:
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"
Subject: [...] Subject: [...]
Message-ID: <smime-signed-enc-hp-shy@example> Message-ID: <smime-signed-enc-hp-shy@example>
From: alice@smime.example From: alice@smime.example
skipping to change at line 6561 skipping to change at line 6564
Protection with hcp_shy (+ Legacy Display) Protection with hcp_shy (+ Legacy Display)
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 RFC 9788 with the message. It uses the Header Protection scheme from RFC 9788 with the
hcp_shy Header Confidentiality Policy with a "Legacy Display" hcp_shy Header Confidentiality Policy with a "Legacy Display"
element. element.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8190 bytes └┬╴application/pkcs7-mime [smime.p7m] 8190 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 5050 bytes └┬╴application/pkcs7-mime [smime.p7m] 5050 bytes
⇩ (unwraps to) ┴ (unwraps to)
└─╴text/plain 506 bytes └─╴text/plain 506 bytes
Its contents are: Its contents are:
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"
Subject: [...] Subject: [...]
Message-ID: <smime-signed-enc-hp-shy-legacy@example> Message-ID: <smime-signed-enc-hp-shy-legacy@example>
From: alice@smime.example From: alice@smime.example
skipping to change at line 6845 skipping to change at line 6848
C.3.5. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header C.3.5. S/MIME Signed-and-Encrypted Reply 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 RFC 9788 with the message. It uses the Header Protection scheme from RFC 9788 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] 8300 bytes └┬╴application/pkcs7-mime [smime.p7m] 8300 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 5136 bytes └┬╴application/pkcs7-mime [smime.p7m] 5136 bytes
⇩ (unwraps to) ┴ (unwraps to)
└─╴text/plain 336 bytes └─╴text/plain 336 bytes
Its contents are: Its contents are:
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"
Subject: [...] Subject: [...]
Message-ID: <smime-signed-enc-hp-baseline-reply@example> Message-ID: <smime-signed-enc-hp-baseline-reply@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
skipping to change at line 7132 skipping to change at line 7135
Protection with hcp_baseline (+ Legacy Display) Protection with hcp_baseline (+ Legacy Display)
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 RFC 9788 with the message. It uses the Header Protection scheme from RFC 9788 with the
hcp_baseline Header Confidentiality Policy with a "Legacy Display" hcp_baseline Header Confidentiality Policy with a "Legacy Display"
element. element.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8625 bytes └┬╴application/pkcs7-mime [smime.p7m] 8625 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 5376 bytes └┬╴application/pkcs7-mime [smime.p7m] 5376 bytes
⇩ (unwraps to) ┴ (unwraps to)
└─╴text/plain 430 bytes └─╴text/plain 430 bytes
Its contents are: Its contents are:
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"
Subject: [...] Subject: [...]
Message-ID: <smime-signed-enc-hp-baseline-legacy-reply@example> Message-ID: <smime-signed-enc-hp-baseline-legacy-reply@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
skipping to change at line 7435 skipping to change at line 7438
C.3.7. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header C.3.7. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header
Protection with hcp_shy Protection with hcp_shy
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 RFC 9788 with the message. It uses the Header Protection scheme from RFC 9788 with the
hcp_shy Header Confidentiality Policy. hcp_shy Header Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8190 bytes └┬╴application/pkcs7-mime [smime.p7m] 8190 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 5054 bytes └┬╴application/pkcs7-mime [smime.p7m] 5054 bytes
⇩ (unwraps to) ┴ (unwraps to)
└─╴text/plain 326 bytes └─╴text/plain 326 bytes
Its contents are: Its contents are:
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"
Subject: [...] Subject: [...]
Message-ID: <smime-signed-enc-hp-shy-reply@example> Message-ID: <smime-signed-enc-hp-shy-reply@example>
From: alice@smime.example From: alice@smime.example
skipping to change at line 7718 skipping to change at line 7721
Protection with hcp_shy (+ Legacy Display) Protection with hcp_shy (+ Legacy Display)
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 RFC 9788 with the message. It uses the Header Protection scheme from RFC 9788 with the
hcp_shy Header Confidentiality Policy with a "Legacy Display" hcp_shy Header Confidentiality Policy with a "Legacy Display"
element. element.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8690 bytes └┬╴application/pkcs7-mime [smime.p7m] 8690 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 5422 bytes └┬╴application/pkcs7-mime [smime.p7m] 5422 bytes
⇩ (unwraps to) ┴ (unwraps to)
└─╴text/plain 518 bytes └─╴text/plain 518 bytes
Its contents are: Its contents are:
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"
Subject: [...] Subject: [...]
Message-ID: <smime-signed-enc-hp-shy-legacy-reply@example> Message-ID: <smime-signed-enc-hp-shy-legacy-reply@example>
From: alice@smime.example From: alice@smime.example
skipping to change at line 8024 skipping to change at line 8027
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 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
Header Protection scheme from RFC 9788 with the hcp_baseline Header Header Protection scheme from RFC 9788 with the hcp_baseline Header
Confidentiality Policy. Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 10035 bytes └┬╴application/pkcs7-mime [smime.p7m] 10035 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 6416 bytes └┬╴application/pkcs7-mime [smime.p7m] 6416 bytes
⇩ (unwraps to) ┴ (unwraps to)
└┬╴multipart/mixed 2054 bytes └┬╴multipart/mixed 2054 bytes
├┬╴multipart/alternative 1126 bytes ├┬╴multipart/alternative 1126 bytes
│├─╴text/plain 384 bytes │├─╴text/plain 384 bytes
│└─╴text/html 479 bytes │└─╴text/html 479 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 8393 skipping to change at line 8396
Protection with hcp_baseline (+ Legacy Display) Protection with hcp_baseline (+ Legacy Display)
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
Header Protection scheme from RFC 9788 with the hcp_baseline Header Header Protection scheme from RFC 9788 with the hcp_baseline Header
Confidentiality Policy with a "Legacy Display" element. Confidentiality Policy with a "Legacy Display" element.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 10640 bytes └┬╴application/pkcs7-mime [smime.p7m] 10640 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 6870 bytes └┬╴application/pkcs7-mime [smime.p7m] 6870 bytes
⇩ (unwraps to) ┴ (unwraps to)
└┬╴multipart/mixed 2373 bytes └┬╴multipart/mixed 2373 bytes
├┬╴multipart/alternative 1423 bytes ├┬╴multipart/alternative 1423 bytes
│├─╴text/plain 480 bytes │├─╴text/plain 480 bytes
│└─╴text/html 640 bytes │└─╴text/html 640 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 8791 skipping to change at line 8794
Protection with hcp_shy Protection with hcp_shy
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
Header Protection scheme from RFC 9788 with the hcp_shy Header Header Protection scheme from RFC 9788 with the hcp_shy Header
Confidentiality Policy. Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 9945 bytes └┬╴application/pkcs7-mime [smime.p7m] 9945 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 6346 bytes └┬╴application/pkcs7-mime [smime.p7m] 6346 bytes
⇩ (unwraps to) ┴ (unwraps to)
└┬╴multipart/mixed 2005 bytes └┬╴multipart/mixed 2005 bytes
├┬╴multipart/alternative 1106 bytes ├┬╴multipart/alternative 1106 bytes
│├─╴text/plain 374 bytes │├─╴text/plain 374 bytes
│└─╴text/html 469 bytes │└─╴text/html 469 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 9156 skipping to change at line 9159
Protection with hcp_shy (+ Legacy Display) Protection with hcp_shy (+ Legacy Display)
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
Header Protection scheme from RFC 9788 with the hcp_shy Header Header Protection scheme from RFC 9788 with the hcp_shy Header
Confidentiality Policy with a "Legacy Display" element. Confidentiality Policy with a "Legacy Display" element.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 10945 bytes └┬╴application/pkcs7-mime [smime.p7m] 10945 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 7084 bytes └┬╴application/pkcs7-mime [smime.p7m] 7084 bytes
⇩ (unwraps to) ┴ (unwraps to)
└┬╴multipart/mixed 2525 bytes └┬╴multipart/mixed 2525 bytes
├┬╴multipart/alternative 1605 bytes ├┬╴multipart/alternative 1605 bytes
│├─╴text/plain 568 bytes │├─╴text/plain 568 bytes
│└─╴text/html 740 bytes │└─╴text/html 740 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 9566 skipping to change at line 9569
Header Protection with hcp_baseline 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
Header Protection scheme from RFC 9788 with the hcp_baseline Header Header Protection scheme from RFC 9788 with the hcp_baseline Header
Confidentiality Policy. Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 10575 bytes └┬╴application/pkcs7-mime [smime.p7m] 10575 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 6820 bytes └┬╴application/pkcs7-mime [smime.p7m] 6820 bytes
⇩ (unwraps to) ┴ (unwraps to)
└┬╴multipart/mixed 2343 bytes └┬╴multipart/mixed 2343 bytes
├┬╴multipart/alternative 1138 bytes ├┬╴multipart/alternative 1138 bytes
│├─╴text/plain 390 bytes │├─╴text/plain 390 bytes
│└─╴text/html 485 bytes │└─╴text/html 485 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 9957 skipping to change at line 9960
Header Protection with hcp_baseline (+ Legacy Display) Header Protection with hcp_baseline (+ Legacy Display)
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
Header Protection scheme from RFC 9788 with the hcp_baseline Header Header Protection scheme from RFC 9788 with the hcp_baseline Header
Confidentiality Policy with a "Legacy Display" element. Confidentiality Policy with a "Legacy Display" element.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 11205 bytes └┬╴application/pkcs7-mime [smime.p7m] 11205 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 7286 bytes └┬╴application/pkcs7-mime [smime.p7m] 7286 bytes
⇩ (unwraps to) ┴ (unwraps to)
└┬╴multipart/mixed 2668 bytes └┬╴multipart/mixed 2668 bytes
├┬╴multipart/alternative 1427 bytes ├┬╴multipart/alternative 1427 bytes
│├─╴text/plain 482 bytes │├─╴text/plain 482 bytes
│└─╴text/html 642 bytes │└─╴text/html 642 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 10383 skipping to change at line 10386
Header Protection with hcp_shy Header Protection with hcp_shy
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
Header Protection scheme from RFC 9788 with the hcp_shy Header Header Protection scheme from RFC 9788 with the hcp_shy Header
Confidentiality Policy. Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 10445 bytes └┬╴application/pkcs7-mime [smime.p7m] 10445 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 6720 bytes └┬╴application/pkcs7-mime [smime.p7m] 6720 bytes
⇩ (unwraps to) ┴ (unwraps to)
└┬╴multipart/mixed 2273 bytes └┬╴multipart/mixed 2273 bytes
├┬╴multipart/alternative 1118 bytes ├┬╴multipart/alternative 1118 bytes
│├─╴text/plain 380 bytes │├─╴text/plain 380 bytes
│└─╴text/html 475 bytes │└─╴text/html 475 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 10768 skipping to change at line 10771
Header Protection with hcp_shy (+ Legacy Display) Header Protection with hcp_shy (+ Legacy Display)
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
Header Protection scheme from RFC 9788 with the hcp_shy Header Header Protection scheme from RFC 9788 with the hcp_shy Header
Confidentiality Policy with a "Legacy Display" element. Confidentiality Policy with a "Legacy Display" element.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 11530 bytes └┬╴application/pkcs7-mime [smime.p7m] 11530 bytes
↧ (decrypts to) ╧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 7520 bytes └┬╴application/pkcs7-mime [smime.p7m] 7520 bytes
⇩ (unwraps to) ┴ (unwraps to)
└┬╴multipart/mixed 2834 bytes └┬╴multipart/mixed 2834 bytes
├┬╴multipart/alternative 1629 bytes ├┬╴multipart/alternative 1629 bytes
│├─╴text/plain 580 bytes │├─╴text/plain 580 bytes
│└─╴text/html 752 bytes │└─╴text/html 752 bytes
└─╴image/png inline 236 bytes └─╴image/png inline 236 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
skipping to change at line 11203 skipping to change at line 11206
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
├┬╴multipart/alternative 1168 bytes ├┬╴multipart/alternative 1168 bytes
│├─╴text/plain 393 bytes │├─╴text/plain 393 bytes
│└─╴text/html 491 bytes │└─╴text/html 491 bytes
└─╴image/png inline 232 bytes └─╴image/png inline 232 bytes
Its contents are: Its contents are:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
skipping to change at line 11809 skipping to change at line 11812
This example assumes that Alice's MUA uses hcp_no_confidentiality, This example assumes that Alice's MUA uses hcp_no_confidentiality,
not hcp_baseline. That is, by default, it does not obscure or remove not hcp_baseline. That is, by default, it does not obscure or remove
any Header Fields, even when encrypting. any Header Fields, even when encrypting.
However, it follows the guidance in Section 6.1 and will make use of However, it follows the guidance in Section 6.1 and will make use of
the HP-Outer field in the Cryptographic Payload of Bob's original the HP-Outer field in the Cryptographic Payload of Bob's original
message (Appendix D.1.2.1) to determine what to obscure. message (Appendix D.1.2.1) to determine what to obscure.
When crafting the Cryptographic Payload, its baseline HCP When crafting the Cryptographic Payload, its baseline HCP
(hcp_no_confidentiality) leaves each field untouched. To uphold the (hcp_no_confidentiality) leaves each field untouched. To uphold the
confidentiality of the sender's values when replying, the MUA confidentiality of the composer's values when replying, the MUA
executes the following steps (for brevity, only Subject and Message- executes the following steps (for brevity, only Subject and Message-
ID/In-Reply-To are shown): ID/In-Reply-To are shown):
* Extract the referenced Header Fields (see Section 4.2): * Extract the referenced Header Fields (see Section 4.2):
- refouter contains: - refouter contains:
o Date: Wed, 11 Jan 2023 16:08:43 -0500 o Date: Wed, 11 Jan 2023 16:08:43 -0500
o From: Bob <bob@example.net> o From: Bob <bob@example.net>
skipping to change at line 12061 skipping to change at line 12064
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
implementation, known problems with legacy interoperability (in implementation, known problems with legacy interoperability (in
particular with rendering), lack of clear signaling of sender intent, particular with rendering), lack of clear signaling of composer
and/or incomplete cryptographic protections. This section lists such intent, and/or incomplete cryptographic protections. This section
schemes known at the time of the publication of this document out of lists such schemes known at the time of the publication of this
historical interest. document out of historical interest.
F.1. Original RFC 8551 Header Protection F.1. Original RFC 8551 Header Protection
S/MIME [RFC8551] (as well as its predecessors [RFC5751] and S/MIME [RFC8551] (as well as its predecessors [RFC5751] and
[RFC3851]) defined a form of cryptographic Header Protection that has [RFC3851]) defined a form of cryptographic Header Protection that has
never reached wide adoption and has significant drawbacks compared to never reached wide adoption and has significant drawbacks compared to
the mechanism in this document. See Section 1.1.1 for more the mechanism in this document. See Section 1.1.1 for more
discussion of the differences and Section 4.10 for guidance on how to discussion of the differences and Section 4.10 for guidance on how to
handle such a message. handle such a message.
skipping to change at line 12097 skipping to change at line 12100
of PEF-2 (in which case, it typically renders badly). This is due to of PEF-2 (in which case, it typically renders badly). This is due to
signaling mechanism limitations. signaling mechanism limitations.
As the PEF-2 scheme is an enhanced variant of the RFC8551HP scheme As the PEF-2 scheme is an enhanced variant of the RFC8551HP scheme
(with an additional MIME Layer), it is similar to the RFC8551HP (with an additional MIME Layer), it is similar to the RFC8551HP
scheme (see Section 4.10). The basic PEF-2 MIME structure looks as scheme (see Section 4.10). The basic PEF-2 MIME structure looks as
follows: follows:
A └┬╴multipart/encrypted [Outer Message] A └┬╴multipart/encrypted [Outer Message]
B ├─╴application/pgp-encrypted B ├─╴application/pgp-encrypted
C └─╴application/octet-stream inline [Cryptographic Payload] C └┬╴application/octet-stream inline [Cryptographic Payload]
D ↧ (decrypts to) D ╧ (decrypts to)
E └┬╴multipart/mixed E └┬╴multipart/mixed
F ├─╴text/plain F ├─╴text/plain
G ├┬╴message/rfc822 G ├┬╴message/rfc822
H │└─╴[Inner Message] H │└─╴[Inner Message]
I └─╴application/pgp-keys I └─╴application/pgp-keys
The MIME structure at part H contains the Inner Message to be The MIME structure at part H contains the Inner Message to be
rendered to the user. rendered to the user.
It is possible for a normal MUA to accidentally produce a message It is possible for a normal MUA to accidentally produce a message
skipping to change at line 12135 skipping to change at line 12138
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
Section 2.1.1) means the recipient of an encrypted message as Section 2.1.1) means the recipient of an encrypted message as
described in [PROTECTED-HEADERS] cannot be cryptographically certain described in [PROTECTED-HEADERS] cannot be cryptographically certain
whether the sender intended for the message to be confidential or whether the composer intended for the message to be confidential or
not. The lack of a mechanism comparable to HP-Outer (see not. The lack of a mechanism comparable to HP-Outer (see
Section 2.2) makes it impossible for the recipient of an encrypted Section 2.2) makes it impossible for the recipient of an encrypted
message as described in [PROTECTED-HEADERS] to safely determine which message as described in [PROTECTED-HEADERS] to safely determine which
Header Fields are confidential or not while forwarding or replying to Header Fields are confidential or not while forwarding or replying to
a message (see Section 6). a message (see Section 6).
Acknowledgements Acknowledgements
Alexander Krotov identified the risk of From address spoofing (see Alexander Krotov identified the risk of From address spoofing (see
Section 10.1) and helped provide guidance to MUAs. Section 10.1) and helped provide guidance to MUAs.
 End of changes. 122 change blocks. 
276 lines changed or deleted 279 lines changed or added

This html diff was produced by rfcdiff 1.48.