Header Protection for Cryptographically Protected Email
RFC 9788
Daniel Kahn Gillmor
American Civil Liberties Union
Bernie Hoeneisen
pEp Project
Alexey Melnikov
Isode Ltd
2025-08
SEC
lamps
Header Protection
Header Confidentiality Policy
HCP
cryptographic email
email encryption
encryption
encrypt
signature
sign
S/MIME
PGP/MIME
Legacy Display
Legacy Display Element
MIME
Privacy
HP-Outer
hp-legacy-display
hp
S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of email message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message.
This document updates the S/MIME specification (RFC 8551) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit usability, privacy, and security guidance for clients when generating or handling email messages with cryptographic protection of message headers.
The Header Protection scheme defined here is also applicable to messages with PGP/MIME (Pretty Good Privacy with MIME) cryptographic protections.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9788.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
- 1. Introduction
  - 1.1. Update to RFC 8551
    - 1.1.1. Problems with RFC 8551 Header Protection
  - 1.2. Risks of Header Protection for Legacy MUA Recipients
  - 1.3. Motivation
    - 1.3.1. Backward Compatibility
    - 1.3.2. Deliverability
  - 1.4. Other Protocols to Protect Email Header Fields
  - 1.5. Applicability to PGP/MIME
  - 1.6. Requirements Language
  - 1.7. Terms
  - 1.8. Document Scope
    - 1.8.1. In Scope
    - 1.8.2. Out of Scope
  - 1.9. Example
- 2. Internet Message Format Extensions
  - 2.1. Content-Type Parameters
    - 2.1.1. Content-Type Parameter: hp
    - 2.1.2. Content-Type Parameter: hp-legacy-display
  - 2.2. HP-Outer Header Field
    - 2.2.1. HP-Outer Header Field Definition
- 3. Header Confidentiality Policy
  - 3.1. HCP Definition
    - 3.1.1. HCP Avoids Changing addr-spec of From Header Field
  - 3.2. Initial Registered HCPs
    - 3.2.1. Baseline Header Confidentiality Policy
    - 3.2.2. Shy Header Confidentiality Policy
    - 3.2.3. No Header Confidentiality Policy
  - 3.3. Default Header Confidentiality Policy
  - 3.4. HCP Evolution
    - 3.4.1. Offering More Ambitious Header Confidentiality
    - 3.4.2. Expert Guidance for Registering Header Confidentiality Policies
- 4. Rendering Guidance (Receiving Side)
  - 4.1. Identifying That a Message Has Header Protection
  - 4.2. Extracting Protected Header Fields From an Encrypted Message
    - 4.2.1. HeaderSetsFromMessage
  - 4.3. Updating the Cryptographic Summary
    - 4.3.1. HeaderFieldProtection
  - 4.4. Handling Mismatch of From Header Fields
    - 4.4.1. Definitions
    - 4.4.2. Warning for From Header Field Mismatch
    - 4.4.3. From Header Field Rendering
    - 4.4.4. Handling the Protected From Header Field When Responding
    - 4.4.5. Matching addr-specs
  - 4.5. Rendering a Message with Header Protection
    - 4.5.1. Example Signed-Only Message
    - 4.5.2. Example Signed-and-Encrypted Message
    - 4.5.3. Do Not Render Legacy Display Elements
  - 4.6. Implicitly Rendered Header Fields
  - 4.7. Handling Undecryptable Messages
  - 4.8. Guidance for Automated Message Handling
    - 4.8.1. Only Interpret Protected Header Fields
    - 4.8.2. Ignore Legacy Display Elements
  - 4.9. Affordances for Debugging and Troubleshooting
  - 4.10. Handling RFC8551HP Messages (Backward Compatibility)
    - 4.10.1. Identifying an RFC8551HP Message
    - 4.10.2. Rendering or Responding to an RFC8551HP Message
  - 4.11. Rendering Other Schemes
- 5. Composing Guidance (Sending Side)
  - 5.1. Composing a Cryptographically Protected Message Without Header Protection
    - 5.1.1. ComposeNoHeaderProtection
  - 5.2. Composing a Message with Header Protection
    - 5.2.1. Compose
    - 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.4. Only Add a Legacy Display Element to Main Body Parts
    - 5.2.5. Do Not Add a Legacy Display Element to Other Content-Types
- 6. Replying and Forwarding Guidance
  - 6.1. Avoid Leaking Encrypted Header Fields in Replies and Forwards
    - 6.1.1. The Respond Function
    - 6.1.2. ReferenceHCP
  - 6.2. Avoid Misdirected Replies
- 7. Unprotected Header Fields Added in Transit
  - 7.1. Mailing List Header Fields: List-* and Archived-At
- 8. Email Ecosystem Evolution
  - 8.1. Dropping Legacy Display Elements
  - 8.2. More Ambitious Default HCP
  - 8.3. Deprecation of Messages Without Header Protection
- 9. Usability Considerations
  - 9.1. Mixed Protections Within a Message Are Hard to Understand
  - 9.2. Users Should Not Have to Choose a Header Confidentiality Policy
- 10. Security Considerations
  - 10.1. From Address Spoofing
    - 10.1.1. From Rendering Reasoning
  - 10.2. Avoid Cryptographic Summary Confusion from the hp Parameter
  - 10.3. Caution About Composing with Legacy Display Elements
  - 10.4. Plaintext Attacks
- 11. Privacy Considerations
  - 11.1. Leaks When Replying
  - 11.2. Encrypted Header Fields Are Not Always Private
    - 11.2.1. Encrypted Header Fields Can Leak Unwanted Information to the Recipient
    - 11.2.2. Encrypted Header Fields Can Be Inferred from External or Internal Metadata
    - 11.2.3. Encrypted Header Fields May Not Be Fully Masked by HCP
  - 11.3. A Naive Recipient May Overestimate the Cryptographic Status of a Header Field in an Encrypted Message
  - 11.4. Privacy and Deliverability Risks with Bcc and Encrypted Messages
- 12. IANA Considerations
  - 12.1. Registration of the HP-Outer Header Field
  - 12.2. Reference Update for the Content-Type Header Field
  - 12.3. New Mail Header Confidentiality Policies Registry
- 13. References
  - 13.1. Normative References
  - 13.2. Informative References
- Appendix A. Table of Pseudocode Listings
- Appendix B. Possible Problems with Legacy MUAs
  - B.1. Problems Viewing Messages in a List View
  - B.2. Problems When Rendering a Message
  - B.3. Problems When Replying to a Message
- Appendix C. Test Vectors
  - C.1. Baseline Messages
    - C.1.1. No Cryptographic Protections over a Simple Message
    - C.1.2. S/MIME Signed-Only signedData over a Simple Message, No Header Protection
    - C.1.3. S/MIME Signed-Only multipart/signed over a Simple Message, No Header Protection
    - C.1.4. S/MIME Signed-and-Encrypted over a Simple Message, No Header Protection
    - C.1.5. No Cryptographic Protections over a Complex Message
    - C.1.6. S/MIME Signed-Only signedData over a Complex Message, No Header Protection
    - C.1.7. S/MIME Signed-Only multipart/signed over a Complex Message, No Header Protection
    - C.1.8. S/MIME Signed-and-Encrypted over a Complex Message, No Header Protection
  - C.2. Signed-Only Messages
    - C.2.1. S/MIME Signed-Only signedData over a Simple Message, Header Protection
    - C.2.2. S/MIME Signed-Only multipart/signed over a Simple Message, Header Protection
    - C.2.3. S/MIME Signed-Only signedData over a Complex Message, Header Protection
    - C.2.4. S/MIME Signed-Only multipart/signed over a Complex Message, Header Protection
    - C.2.5. S/MIME Signed-Only signedData over a Complex Message, Legacy RFC 8551 Header Protection
    - C.2.6. S/MIME Signed-Only multipart/signed over a Complex Message, Legacy RFC 8551 Header Protection
  - C.3. Signed-and-Encrypted Messages
    - C.3.1. S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_baseline
    - C.3.2. S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_baseline (+ Legacy Display)
    - C.3.3. S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_shy
    - C.3.4. S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_shy (+ Legacy Display)
    - C.3.5. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_baseline
    - C.3.6. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_baseline (+ Legacy Display)
    - C.3.7. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_shy
    - C.3.8. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_shy (+ Legacy Display)
    - C.3.9. S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_baseline
    - C.3.10. S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_baseline (+ Legacy Display)
    - C.3.11. S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_shy
    - C.3.12. S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_shy (+ Legacy Display)
    - C.3.13. S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_baseline
    - C.3.14. S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_baseline (+ Legacy Display)
    - C.3.15. S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_shy
    - C.3.16. S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_shy (+ Legacy Display)
    - C.3.17. S/MIME Signed-and-Encrypted over a Complex Message, Legacy RFC 8551 Header Protection with hcp_baseline
- Appendix D. Composition Examples
  - D.1. New Message Composition
    - D.1.1. Unprotected Message
    - D.1.2. Encrypted with hcp_baseline and Legacy Display
  - D.2. Composing a Reply
    - D.2.1. Unprotected Message
    - D.2.2. Encrypted with hcp_no_confidentiality and Legacy Display
- Appendix E. Rendering Examples
  - E.1. Example text/plain Cryptographic Payload with Legacy Display Elements
  - E.2. Example text/html Cryptographic Payload with Legacy Display Elements
- Appendix F. Other Header Protection Schemes
  - F.1. Original RFC 8551 Header Protection
  - F.2. Pretty Easy Privacy (pEp)
  - F.3. "draft-autocrypt" Protected Headers
- Acknowledgements
- Authors' Addresses
Introduction
Privacy and security issues regarding email Header Protection in S/MIME and PGP/MIME have been identified for some time. Most current implementations of cryptographically protected email protect only the Body of the message, which leaves significant room for attacks against otherwise-protected messages. For example, lack of Header Protection allows an attacker to substitute the message subject and/or author.
This document describes how to cryptographically protect message headers and provides guidance for the implementer of a Mail User Agent (MUA) that generates, interprets, and replies to such a message. It uses the term "Legacy MUA" to refer to an MUA that does not implement this specification. This document takes particular care to ensure that messages interact reasonably well with Legacy MUAs.
Update to RFC 8551
An older scheme for Header Protection was specified in S/MIME 3.1 [RFC8551], which involves wrapping a message/rfc822 MIME object with a Cryptographic Envelope around the message to protect it. This document refers to that scheme as "RFC 8551 Header Protection", or "RFC8551HP". Substantial testing has shown that RFC8551HP does not interact well with some Legacy MUAs (see Section 1.1.1).
This specification supersedes RFC8551HP, effectively replacing the final two paragraphs of Section 3.1 of [RFC8551].
In this specification, all Header Fields gain end-to-end cryptographic integrity and authenticity by being copied directly into the Cryptographic Payload without using an intervening message/⁠rfc822 MIME object. In an encrypted message, some Header Fields can also be made confidential by removing or obscuring them from the Outer Header Section.
This specification also offers substantial security, privacy, and usability guidance for composing and rendering MUAs that was not considered in [RFC8551].
Problems with RFC 8551 Header Protection
Several Legacy MUAs have difficulty rendering a message that uses RFC8551HP. These problems can appear on signed-only messages, as well as signed-and-encrypted messages.
In some cases, some MUAs cannot render message/rfc822 message subparts at all, which is in violation of baseline MIME requirements as defined in requirement 6 of Section 2 of [RFC2049]. A message using RFC8551HP is unreadable by any recipient using such an MUA.
In other cases, the user sees an attachment suggesting a forwarded email message that -- in fact -- contains the protected email message that should be rendered directly. In most of these cases, the user can click on the attachment to view the protected message.
However, viewing the protected message as an attachment in isolation may strip it of any security indications, leaving the user unable to assess the cryptographic properties of the message. Worse, for encrypted messages, interacting with the protected message in isolation may leak contents of the cleartext, for example, if the reply is not also encrypted.
Furthermore, RFC8551HP lacks any discussion of the following points, all of which are provided in this specification:
- Which Header Fields should be given end-to-end cryptographic integrity and authenticity protections (this specification mandates protection of all Header Fields that the composing MUA knows about).
- How to securely indicate the composer's intent to offer Header Protection and encryption, which lets a rendering MUA detect messages whose cryptographic properties may have been modified in transit (see Section 2.1.1).
- Which Header Fields should be given end-to-end cryptographic confidentiality protections in an encrypted message and how (see Section 3).
- How to securely indicate the composer's choices about which Header Fields were made confidential, which lets a rendering MUA reply or forward an encrypted message safely without accidentally leaking confidential material (see Section 2.2).
These stumbling blocks with Legacy MUAs, missing mechanisms, and missing guidance create a strong disincentive for existing MUAs to generate messages using RFC8551HP. Because few messages have been produced, there has been little incentive for those MUAs capable of upgrading to bother interpreting them better.
In contrast, the mechanisms defined here are safe to adopt and produce messages with very few problems for Legacy MUAs. And Section 4.10 provides useful guidance for rendering and replying to RFC8551HP messages.
Risks of Header Protection for Legacy MUA Recipients
Producing a signed-only message using this specification has no additional risks (compared to producing a signed-only message without Header Protection). Such a message will render in the same way on any Legacy MUA as a Legacy Signed Message (that is, a signed message without Header Protection). An MUA conformant to this specification that encounters such a message will be able to gain the benefits of end-to-end cryptographic integrity and authenticity for all Header Fields.
An encrypted message produced according to this specification that has some User-Facing Header Fields removed or obscured may not render as desired in a Legacy MUA. In particular, those Header Fields that were made confidential will not be visible to the user of a Legacy MUA. For example, if the Subject Header Field outside the Cryptographic Envelope is replaced with [...], a Legacy MUA will render the [...] anywhere the Subject is normally seen. This is the only additional risk of producing an encrypted message according to this specification (compared to producing an encrypted message without confidentiality for any Header Field).
A workaround "Legacy Display" mechanism is provided in this specification (see Section 2.1.2). Legacy MUAs will render "Legacy Display Elements" to the user, albeit not in the same location that the Header Fields would normally be rendered.
Alternately, if the composer of an encrypted message is particularly concerned about the experience of a recipient using a Legacy MUA, and they are willing to accept leaking the User-Facing Header Fields, they can simply adopt the No Header Confidentiality Policy (see Section 3.2.3). A signed-and-encrypted message composed using the No Header Confidentiality Policy offers no usability risk for a reader using a Legacy MUA and retains end-to-end cryptographic integrity and authenticity properties for all Header Fields for any reader using a conformant MUA. Of course, such a message has the same (non-existent) confidentiality properties for all Header Fields as a Legacy Encrypted Message (that is, an encrypted message made without Header Protection).
Motivation
Ordinary Users generally do not understand the distinction between email message Body and Header Section. When an email message has cryptographic protections that cover the message Body but not the Header Fields, several attacks become possible.
For example, a Legacy Signed Message has a signature that covers the Body but not the Header Fields. An attacker can therefore modify the Header Fields (including Subject) without invalidating the signature. Since most readers consider a message Body in the context of the message's Subject, the meaning of the message itself could change drastically (under the attacker's control) while still retaining the same cryptographic indicators of integrity and authenticity.
In another example, a Legacy Encrypted Message has its Body effectively hidden from an adversary that snoops on the message. But if the Header Fields are not also encrypted, significant information about the message (such as the message Subject) will leak to the inspecting adversary.
However, if the composing and rendering MUAs ensure that cryptographic protections cover the message Header Section as well as the message Body, these attacks are defeated.
Backward Compatibility
If the composing MUA is unwilling to generate such a fully protected message due to the potential for rendering, usability, deliverability, or security issues, these defenses cannot be realized.
The composer cannot know what MUA (or MUAs) the recipient will use to handle the message. Thus, an outbound message format that is backward compatible with as many legacy implementations as possible is a more effective vehicle for providing the whole-message cryptographic protections described above.
This document aims for backward compatibility with Legacy MUAs to the extent possible. In some cases, like when a user-visible Header 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 a conformant MUA would. But accommodations are described here (in particular, Section 2.1.2) that ensure a rough semantic equivalence for a Legacy MUA even in these cases.
Deliverability
A message with perfect cryptographic protections that cannot be delivered is less useful than a message with imperfect cryptographic protections that can be delivered. Senders want their messages to reach the intended recipients.
Given the current state of the Internet mail ecosystem, encrypted messages in particular cannot shield all of their Header Fields from visibility and still be guaranteed delivery to their intended recipient.
This document accounts for this concern by providing a mechanism (Section 3) that prioritizes initial deliverability (at the cost of some header leakage) while facilitating future message variants that shield more header metadata from casual inspection.
Other Protocols to Protect Email Header Fields
A separate pair of protocols also provides some cryptographic protection for the email message header integrity: DomainKeys Identified Mail (DKIM) [RFC6376], as used in combination with Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489]. This pair of protocols provides a domain-based reputation mechanism that can be used to mitigate some forms of unsolicited email (spam).
However, the DKIM+DMARC suite provides cryptographic protection at a different scope, as it is usually applied by and evaluated by a mail transport agent (MTA). DKIM+DMARC typically provide MTA-to-MTA protection, whereas this specification provides MUA-to-MUA protection. This is because DKIM+DMARC are typically applied to messages by (and interpreted by) MTAs, whereas the mechanisms in this document are typically applied and interpreted by MUAs.
A rendering MUA that relies on DKIM+DMARC for sender authenticity should note Section 10.1.
Furthermore, the DKIM+DMARC suite only provides cryptographic integrity and authentication, not encryption. So cryptographic confidentiality is not available from that suite.
The DKIM+DMARC suite can be used on any message, including messages formed as defined in this document. There should be no conflict between DKIM+DMARC and the specification here.
Though not strictly email, similar protections have been in use on Usenet for the signing and verification of message Header Fields for years. See [PGPCONTROL] and [PGPVERIFY-FORMAT] for more details. Like DKIM, these Usenet control protections offer only integrity and authentication, not confidentiality.
Applicability to PGP/MIME
This document specifies end-to-end cryptographic protections for email messages in reference to S/MIME [RFC8551].
Comparable end-to-end cryptographic protections can also be provided by PGP/MIME [RFC3156].
The mechanisms in this document should be applicable in the PGP/MIME protections as well as S/MIME protections, but analysis and implementation in this document focuses on S/MIME.
To the extent that any divergence from the mechanism defined here is necessary for PGP/MIME, that divergence is out of scope for this document.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Terms
The following terms are defined for the scope of this document:
S/MIME:
Secure/Multipurpose Internet Mail Extensions (see [RFC8551])
PGP/MIME:
Pretty Good Privacy with MIME (see [RFC3156])
Message:
An email message consisting of Header Fields (collectively called "the Header Section of the message") optionally followed by a message Body; see [RFC5322].
Header Field:
A Header Field includes a field name, followed by a colon (":"), followed by a field Body (value), and is terminated by CRLF; see Section 2.2 of [RFC5322] for more details.
Header Section:
The Header Section is a sequence of lines of characters with special syntax as defined in [RFC5322]. The Header Section of a message contains the Header Fields associated with the message itself. The Header Section of a MIME part (that is, a subpart of a message) typically contains Header Fields associated with that particular MIME part.
Outer Header Section:
The unprotected Header Section that MTAs and MUAs unaware of Header Protection treat as the Header Section of the Message.
Inner Header Section:
The Header Section at the root of the Cryptographic Payload. An MUA that implements Header Protection renders Header Fields from this section for the user.
Body:
The Body is the part of a message that follows the Header Section and is separated from the Header Section by an empty line (that is, a line with nothing preceding the CRLF); see [RFC5322]. It is the (bottom) section of a message containing the payload of a message. Typically, the Body consists of a (possibly multipart) MIME [RFC2045] construct.
Header Protection (HP):
The cryptographic protection of email Header Sections (or parts of it) by means of signatures and/or encryption.
Legacy MUA:
An MUA that does not understand Header Protection as defined in this document. A Legacy Non-Crypto MUA is incapable of doing any end-to-end cryptographic operations. A Legacy Crypto MUA is capable of doing cryptographic operations but does not understand or generate messages with Header Protection.
Legacy Signed Message:
An email message that was signed by a Legacy MUA and therefore has no cryptographic authenticity or integrity protections on its Header Fields.
Legacy Encrypted Message:
An email message that was signed and encrypted by a Legacy MUA and therefore has no cryptographic authenticity, integrity, or confidentiality protections on any of its Header Fields.
Header Confidentiality Policy (HCP):
A functional specification of which Header Fields should be removed or obscured when composing an encrypted message with Header Protection. An HCP is considered more "conservative" when it removes or obscures fewer Header Fields. When it removes or obscures more Header Fields, it is more "ambitious". See Section 3.
Ordinary User:
A user of an MUA who follows a simple and minimal experience, focused on sending and receiving emails. A user who opts into advanced configuration, expert mode, or the like is not an "Ordinary User".
Respond Function:
A function found in most MUAs that defines how to pre-populate the Header Fields of a new message in response to another message. See Section 6.1.1.
Additionally, Cryptographic Layer, Cryptographic Payload, Cryptographic Envelope, Cryptographic Summary, Structural Header Fields, Non-Structural Header Fields, Main Body Part, User-Facing Header Fields, and MUA are all used as defined in [RFC9787].
The policies "Specification Required" and "IETF Review" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC8126].
Note: To avoid ambiguity, this document avoids using the terms "Header" or "Headers" in isolation, but instead always uses "Header Field" to refer to the individual field and "Header Section" to refer to the entire collection.
Document Scope
This document describes sensible, simple behavior for a program that generates an email message with standard end-to-end cryptographic protections, following the guidance in [RFC9787]. An implementation conformant to this document will produce messages that have cryptographic protection that covers the message's Header Fields as well as its Body.
In Scope
This document also describes sensible, simple behavior for a program that interprets such a message in a way that can take advantage of these protections covering the Header Fields as well as the Body.
The message generation guidance aims to minimize negative interactions with any Legacy rendering MUA while providing actionable cryptographic properties for modern rendering MUAs.
In particular, this document focuses on two standard types of cryptographic protection that cover the entire message:
- a cleartext message with a single signature and
- an encrypted message that contains a single cryptographic signature.
Out of Scope
The message composition guidance in this document (in Section 5.2) aims to provide minimal disruption for any Legacy MUA that renders such a message. However, by definition, a Legacy MUA does not implement any of the guidance here. Therefore, the document does not attempt to provide guidance for Legacy MUAs directly.
Furthermore, this document does not explicitly contemplate other variants of cryptographic message protections, including any of these:
- encrypted-only message (without a cryptographic signature; see Section 5.3 of [RFC9787])
- triple-wrapped message
- signed message with multiple signatures
- encrypted message with a cryptographic signature outside the encryption
All such messages are out of scope of this document.
Example
This section provides an example of MIME messages with Header Protection.
Consider the following MIME message:

A └┬╴application/pkcs7-mime; smime-type="enveloped-data"
   ╧ (decrypts to)
B  └┬╴application/pkcs7-mime; smime-type="signed-data"
    ┴ (unwraps to)
C   └┬╴multipart/alternative; hp="cipher"
D    ├─╴text/plain; hp-legacy-display="1"
E    └─╴text/html; hp-legacy-display="1"

Observe that:
- Nodes A and B are collectively called the Cryptographic Envelope. Node C (including its subnodes D and E) is called the Cryptographic Payload [RFC9787].
- Node A contains the (unprotected) outer Header Fields. Node C contains the (protected) inner Header Fields.
- The presence of the hp attribute (see Section 2.1.1) on the Content-Type of node C allows the renderer to know that the composer applied Header Protection. Its value allows the renderer to distinguish whether the composer intended for the message to be confidential (hp="cipher") or not (hp="clear"), since encryption may have been added in transit (see Section 10.2).
The Outer Header Section on node A looks as follows:

Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net>
To: Alice <alice@example.net>
Subject: [...]
Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Type: application/pkcs7-mime; smime-type="enveloped-data"
MIME-Version: 1.0

The Inner Header Section on node C looks as follows:

Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net>
To: Alice <alice@example.net>
Subject: Handling the Jones contract
Keywords: Contract, Urgent
Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Type: multipart/alternative; hp="cipher"
MIME-Version: 1.0
HP-Outer: Date: Wed, 11 Jan 2023 16:08:43 -0500
HP-Outer: From: Bob <bob@example.net>
HP-Outer: To: Alice <alice@example.net>
HP-Outer: Subject: [...]
HP-Outer: Message-ID: <20230111T210843Z.1234@lhp.example>

Observe that:
- Between node C and node A, some Header Fields are copied as is (Date, From, To, Message-ID), some are obscured (Subject), and some are removed (Keywords).
- 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 the renderer to recompute for which Header Fields the composer provided confidentiality by removing or obscuring them.
- The copying/removing/obscuring and the HP-Outer only apply to Non-Structural Header Fields, not to Structural Header Fields like Content-Type or MIME-Version (see Section 1.1.1 of [RFC9787]).
- If the composer intends no confidentiality and doesn't encrypt the message, it doesn't remove or obscure Header Fields. All Non-Structural Header Fields are copied as is. No HP-Outer Header Fields are present.
Node D looks as follows:

Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1";

Subject: Handling the Jones contract
Keywords: Contract, Urgent

Please review and approve or decline by Thursday, it's critical!

Thanks,
Bob

--
Bob Gonzalez
ACME, Inc.

Observe that:
- The composer adds the removed and obscured User-Facing Header Fields (see Section 1.1.2 of [RFC9787]) to the main Body (note the empty line after the Content-Type). This is called the Legacy Display Element. It allows a user with a Legacy MUA that doesn't implement this document to understand the message, since the Header Fields will be shown as part of the main Body.
- The hp-legacy-display="1" attribute (see Section 2.1.2) indicates that the composer added a Legacy Display Element. This allows renderers that implement this document to recognize the Legacy Display Element and distinguish it from user-added content. The renderer then hides the Legacy Display Element and doesn't display it to the user.
- hp-legacy-display is added to the node to which it applies, not on any outer nodes (e.g., not to node C).
For more examples, see Appendices D and E.
Internet Message Format Extensions
This section describes relevant, backward-compatible extensions to the Internet Message Format [RFC5322]. Subsequent sections offer concrete guidance for an MUA to make use of these mechanisms, including policy decisions and recommended pseudocode.
Content-Type Parameters
This document introduces two parameters for the Content-Type Header Field, which have distinct semantics and use cases.
Content-Type Parameter: hp
This specification defines a parameter for the Content-Type Header Field named hp (for Header Protection). This parameter is only relevant on the Content-Type Header Field at the root of the Cryptographic Payload. The presence of this parameter at the root of the Cryptographic Payload indicates that the composer intends for this message to have end-to-end cryptographic protections for the Header Fields.
The parameter's defined values describe the composer's cryptographic intent when producing the message:
hp Parameter for Content-Type Header Field
hp Value | Authenticity | Integrity | Confidentiality | Description
"clear" | yes | yes | no | This message has been signed by the composer, with Header Protection.
"cipher" | yes | yes | yes | This message has been signed by the composer, with Header Protection, and is encrypted to the recipients.
A composing implementation MUST NOT produce a Cryptographic Payload with parameter hp="cipher" for an unencrypted message (that is, where none of the Cryptographic Layers in the Cryptographic Envelope of the message provide encryption). Likewise, if a composing implementation is constructing an encrypted message with Header Protection, it MUST emit an hp="cipher" parameter, regardless of which Header Fields were made confidential.
Note that hp="cipher" indicates that the message itself has been encrypted by the composer to the recipients but makes no assertions about which Header Fields have been removed or obscured. This can be derived from the Cryptographic Payload itself (see Section 4.2).
A rendering implementation MUST NOT mistake the presence of an hp="cipher" parameter in the Cryptographic Payload for the actual presence of a Cryptographic Layer that provides encryption.
Content-Type Parameter: hp-legacy-display
This specification also defines an hp-legacy-display parameter for the Content-Type Header Field. The only defined value for this parameter is 1.
This parameter is only relevant on a leaf MIME node of Content-Type text/html or text/plain within a well-formed message with end-to-end cryptographic protections. Its presence indicates that the MIME node it is attached to contains a decorative "Legacy Display Element". The Legacy Display Element itself is used for backward-compatible visibility of any removed or obscured User-Facing Header Field in a Legacy MUA.
Such a Legacy Display Element need not be rendered to the user of an MUA that implements this specification, because the MUA already knows the correct Header Field information and can render it to the user in the appropriate part of the MUA's user interface rather than in the Body of the message.
See Section 5.2.2 for how to insert a Legacy Display Element into a text/plain Main Body Part. See Section 5.2.3 for how to insert a Legacy Display Element into a text/html Main Body Part. See Section 4.5.3 for how to avoid rendering a Legacy Display Element.
HP-Outer Header Field
This document also specifies a new Header Field: HP-Outer.
This Header Field is used only in the Header Section of the Cryptographic Payload of an encrypted message. It is not relevant for signed-only messages. It documents, with the same cryptographic guarantees shared by the rest of the message, the composer's choices about Header Field confidentiality. It does so by embedding a copy within the Cryptographic Envelope of every Non-Structural Header Field that the composer put outside the Cryptographic Envelope. This Header Field enables the MUA rendering the encrypted message to reliably identify whether the composing MUA intended to make a Header Field confidential (see also Section 11.3).
The HP-Outer Header Fields in a message's Cryptographic Payload are useful for ensuring that any confidential Header Field will not be 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 confidentiality status of any given Header Field to the user.
An implementation that composes encrypted email MUST include a copy of all Non-Structural Header Fields deliberately exposed to the outside of the Cryptographic Envelope using a series of HP-Outer Header Fields within the Cryptographic Payload. These HP-Outer MIME Header Fields should only ever appear directly within the Header Section of the Cryptographic Payload of a Cryptographic Envelope offering confidentiality. They MUST be ignored for the purposes of evaluating the message's Header Protection if they appear in other places.
Each instance of HP-Outer contains a Non-Structural Header Field name and the value that this Header Field was set to within the (unprotected) Outer Header Section. The HP-Outer Header Field can appear multiple times in the Header Section of a Cryptographic Payload.
If a Non-Structural Header Field named Z is present in Header Section of the Cryptographic Payload but doesn't appear in an HP-Outer Header Field value at all, then the composer is effectively asserting that every instance of Z was made confidential by removal from the Outer Header Section. Specifically, it means that no Header Field Z was included on the outside of the message's Cryptographic Envelope by the composer at the time the message was injected into the mail system.
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-end confidentiality of a given Header Field from an encrypted message with Header Protection using HP-Outer. See Section 6.1 for how an MUA can safely reply to (or forward) an encrypted message without leaking confidential Header Fields by default.
HP-Outer Header Field Definition
The syntax of this Header Field is defined using the following ABNF [RFC5234], where field-name, WSP, VCHAR, and FWS are defined in [RFC5322]:

hp-outer     =   "HP-Outer:" [FWS] field-name ": "
                    hp-outer-value CRLF

hp-outer-value  =   (*([FWS] VCHAR) *WSP)

Note that hp-outer-value is the same as unstructured from Section 3.2.5 of [RFC5322] but without the obsolete obs-unstruct option.
Header Confidentiality Policy
An MUA composing an encrypted message according to this specification may make any given Header Field confidential by removing it from the Header Section outside the Cryptographic Envelope or by obscuring it by rewriting it to a different value in that Outer Header Section. The composing MUA faces a choice for any new message: Which Header Fields should be made confidential, and how?
This section defines the "Header Confidentiality Policy" (or HCP) as a well-defined abstraction to encourage MUA developers to consider, document, and share reasonable policies across the community. It establishes a registry of known HCPs, defines a small number of simple HCPs in that registry, and makes a recommendation for a reasonable default.
Note that such a policy is only needed when the end-to-end protections include encryption (confidentiality). No comparable policy is needed for other end-to-end cryptographic protections (integrity and authenticity), as they are simply uniformly applied so that all Header Fields known by the composer have these protections.
This asymmetry is a consequence of complexities in existing message delivery systems, some of which may reject, drop, or delay messages where all Header Fields are removed from the top-level MIME object.
Note that no representation of the HCP itself ever appears "on the wire". However, the consumer of the encrypted message can see the decisions that were made by the composer's HCP via the HP-Outer Header Fields (see Section 2.2).
HCP Definition
In this document, we represent that HCP as a function hcp:
- hcp(name, val_in) -> val_out: This function takes a Non-Structural Header Field identified by name with the initial value val_in as arguments and returns a replacement Header Field value val_out. 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 visible outside the Cryptographic Envelope.
In the pseudocode descriptions of various choices of HCP in this document, any comparison with the name input is done case-insensitively. This is appropriate for Header Field names, as described in [RFC5322].
Note that hcp is only applied to Non-Structural Header Fields. When composing a message, Structural Header Fields are dealt with separately, as described in Section 5.2.
As an example, an MUA that obscures the Subject Header Field by replacing it with the literal string "[...]", hides all Cc'ed recipients, and does not offer confidentiality to any other Header Fields would be represented as (in pseudocode):

hcp_example_hide_cc(name, val_in) → val_out:
    if lower(name) is 'subject':
        return '[...]'
    else if lower(name) is 'cc':
        return null
    else:
        return val_in

For alignment with common practice as well as the ABNF in Section 2.2.1 for HP-Outer, val_out MUST be one of the following:
- identical to val_in,
- the special value null (meaning that the Header Field will be removed from the outside of the message), or
- a sequence of printable 7-bit clean ASCII characters (of course, non-ASCII text can be encoded as ASCII using the encoded-word construct from [RFC2047]) and ASCII whitespace (specifically, space (0x20) and tab (0x09)).
The HCP can compute val_out using any technique describable in pseudocode, such as copying a fixed string or invocations of other pseudocode functions. If it alters the value, it MUST NOT include control or NUL characters in val_out. val_out SHOULD match the expected ABNF for the Header Field identified by name.
HCP Avoids Changing addr-spec of From Header Field
The From Header Field should also be treated specially by the HCP to enable defense against possible email address spoofing (see 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 Section 4.4.5, unless the composing MUA has additional knowledge coordinated with the rendering MUA about more subtle addr-spec equivalence or certificate validity.
Initial Registered HCPs
This document formally defines three Header Confidentiality Policies with known and reasonably well-understood characteristics as a way to compare and contrast different possible behavioral choices for a composing MUA. These definitions are not meant to preclude the creation of other HCPs.
The purpose of the registry of HCPs is to facilitate HCP evolution and interoperability discussion among MUA developers and MTA operators.
(The example hypothetical HCP, hcp_example_hide_cc, described in Section 3.1 above is deliberately not formally registered, as it has not been evaluated in practice.)
Baseline Header Confidentiality Policy
The most conservative recommended HCP only provides confidentiality for Informational Fields, as defined in Section 3.6.5 of [RFC5322]. These fields are "only human-readable content" and thus their content should not be relevant to transport agents. Since most Internet messages today do have a Subject Header Field, and some filtering engines might object to a message without a Subject, this policy is conservative and merely obscures that Header Field by replacing it with a fixed string [...]. By contrast, Comments and Keywords Header Fields are comparatively rare, so these fields are removed entirely from the Outer Header Section.

hcp_baseline(name, val_in) → val_out:
    if lower(name) is 'subject':
        return '[...]'
    else if lower(name) is in ['comments', 'keywords']:
        return null
    else:
        return val_in

hcp_baseline is the recommended default HCP, as it provides meaningful confidentiality protections and is unlikely to cause deliverability or usability problems.
Shy Header Confidentiality Policy
Alternately, a slightly more ambitious (and therefore more privacy-preserving) HCP might avoid leaking human-interpretable data that MTAs generally don't care about. The additional protected data isn't related to message routing or transport but might reveal sensitive information about the composer or their relationship to the recipients. This "shy" HCP builds on hcp_baseline but also:
- avoids revealing the display-name of each identified email address and
- avoids leaking the composer's locally configured time zone in the Date Header Field.

hcp_shy(name, val_in) → val_out:
   if lower(name) is 'from':
      if val_in is an RFC 5322 mailbox:
         return the RFC 5322 addr-spec part of val_in
   if lower(name) in ['to', 'cc']:
      if val_in is an RFC 5322 mailbox-list:
         let val_out be an empty mailbox-list
         for each mailbox in val_in:
            append the RFC 5322 addr-spec part of mailbox to val_out
         return val_out
   if lower(name) is 'date':
      if val_in is an RFC 5322 date-time:
          return the UTC form of val_in
   else if lower(name) is 'subject':
      return '[...]'
   else if lower(name) is in ['comments', 'keywords']:
      return null
   return val_in

hcp_shy requires more sophisticated parsing and Header Field manipulation and is not recommended as a default HCP.
No Header Confidentiality Policy
Legacy MUAs can be conceptualized as offering a "No Header Confidentiality" Policy, which offers no confidentiality protection to any Header Field:

hcp_no_confidentiality(name, val_in) → val_out:
    return val_in

A conformant MUA that is not modified by local policy or configuration MUST NOT use hcp_no_confidentiality by default.
Default Header Confidentiality Policy
An MUA MUST have a default HCP that offers confidentiality for the Subject Header Field at least. Local policy and configuration may alter this default, but the MUA SHOULD NOT require the user to select an HCP.
hcp_baseline provides confidentiality for the Subject Header Field by replacing it with the literal string "[...]". It also provides confidentiality for the other less common Informational Header Fields (Comments and Keywords) by removing them entirely from the Outer Header Section. This is a sensible default because most users treat the Informational Fields of a message (particularly the Subject) the same way that they treat the Body, and they are surprised to find that the Subject of an encrypted message is visible.
HCP Evolution
This document does not mandate any particular HCP, though it offers guidance for MUA implementers in selecting one in Section 3.3. Future documents may recommend or mandate such a policy for an MUA with specific needs. Such a recommendation might be motivated by descriptions of metadata-derived attacks, stem from research about message deliverability, or describe new signaling mechanisms, but these topics are out of scope for this document.
Offering More Ambitious Header Confidentiality
An MUA MAY offer even more ambitious confidentiality for Header Fields of an encrypted message than defined in Section 3.2.2. For example, it might implement an HCP that removes the To and Cc Header Fields entirely, relying on the SMTP envelope to ensure proper routing. Or it might remove References and In-Reply-To so that message threading is not visible to any MTA. Any more ambitious choice might result in deliverability, rendering, or usability issues for the relevant messages, so testing and documentation will be valuable to get this right.
The authors of this document hope that implementers with deployment experience will document their chosen HCP and the rationale behind their choice.
Expert Guidance for Registering Header Confidentiality Policies
There is no formal syntax specified for the HCP, but any attempt to specify an HCP for inclusion in the registry needs to provide:
- a stable reference document clearly indicating the distinct name for the proposed HCP,
- pseudocode that other implementers can clearly and unambiguously interpret,
- a clear explanation of why this HCP is different from all other registered HCPs, and
- any relevant considerations related to deployment of the HCP (for example, known or expected deliverability, rendering, or privacy challenges and possible mitigations).
When the proposed HCP produces any non-null output for a given Header Field name, val_out SHOULD match the expected ABNF for that Header Field. If the proposed HCP does not match the expected ABNF for that Header Field, the documentation should explicitly identify the relevant circumstances and provide a justification for the deviation.
An entry should not be marked as "Recommended" unless it has been shown to offer confidentiality or privacy improvements over the status quo and have minimal or mitigable negative impact on messages to which it is applied, considering factors such as message deliverability and security. Only one entry in the table (hcp_baseline) is initially marked as "Recommended". In the future, more than one entry may be marked as "Recommended".
Rendering Guidance (Receiving Side)
An MUA that receives a cryptographically protected email will render it for the user.
The rendering MUA will render the message Body, render a selected subset of Header Fields, and (as described in Section 3 of [RFC9787]) provide a summary of the cryptographic properties of the message.
Most MUAs only render a subset of Header Fields by default. For example, most MUAs render the From, To, Cc, Date, and Subject Header Fields to the user, but few render Message-Id or Received.
An MUA that knows how to handle a message with Header Protection makes the following four changes to its behavior when rendering a message:
- If the MUA detects that an incoming message has protected Header Fields:
  - For a Header Field that is present in the protected Header Section, the MUA SHOULD render the protected value and ignore any unprotected counterparts that may be present (with a special exception for the From Header Field (see Section 4.4)).
  - For a Header Field that is present only in the Outer Header Section, the MUA SHOULD NOT render that value. If it does render the value, the MUA SHOULD indicate that the rendered value is unprotected. For an exception to this, see Section 7 for a discussion of some specific Header Fields that are known to be added in transit and therefore are not expected to have end-to-end cryptographic protections.
- The MUA SHOULD include information in the message's Cryptographic Summary to indicate the types of protection that applied to each rendered Header Field (if any).
- If any Legacy Display Elements are present in the Body of the message, it does not render them.
- When replying to (or forwarding) a message with confidential Header Fields, the replying (or forwarding) MUA avoids leaking any Header Fields that were confidential in the original into the cleartext of the reply (or forwarded message). It does this even if its own HCP would not have treated those Header Fields as confidential. See Section 6 for more details.
Note that an MUA that handles a message with Header Protection does not need to render any new Header Fields that it did not render before.
Identifying That a Message Has Header Protection
An incoming message can be identified as having Header Protection using the following test:
- The Cryptographic Payload has parameter hp set to "clear" or "cipher". See Section 4.5 for rendering guidance.
When consuming a message, an MUA MUST ignore the hp parameter to Content-Type when it encounters it anywhere other than the root of the message's Cryptographic Payload.
Extracting Protected Header Fields From an Encrypted Message
When a message is encrypted and uses Header Protection, the rendering MUA extracts two lists of Header Fields (names and values):
- The list of Header Fields that the composing MUA applied to the protected message.
- Those Header Fields added by the composing MUA to the (unprotected) Outer Header Section of the message, intended for interpretation by MTAs and Legacy MUAs.
The following algorithm takes referenced message refmsg as input, which is encrypted with Header Protection as described in this document (that is, the Cryptographic Envelope includes a Cryptographic Layer that provides encryption, and the hp parameter for the Content-Type Header Field of the Cryptographic Payload is cipher). It produces as output a pair of lists of (h,v) Header Fields.
HeaderSetsFromMessage
Method signature:
HeaderSetsFromMessage(refmsg) -> (refouter, refprotected)
Procedure:
1. Let refheaders be the list of (h,v) protected Header Fields found in the root of the Cryptographic Payload of refmsg.
2. Let refouter be an empty list of Header Field names and values.
3. Let refprotected be an empty list of Header Field names and values.
4. For each (h,v) in refheaders:
  i. If h is HP-Outer:
    a. Split v into (h1,v1) on the first colon (:), followed by any amount of whitespace.
    b. Append (h1,v1) to refouter.
  ii. Else:
    a. Append (h,v) to refprotected.
5. Return refouter, refprotected.
Note that this algorithm is independent of the Outer Header Section. It derives its output only from the normal Header Fields and the HP-Outer Header Fields, both contained inside the Cryptographic Payload.
Updating the Cryptographic Summary
Regardless of whether a cryptographically protected message has protected Header Fields, the Cryptographic Summary of the message should be modified to indicate what protections the Header Fields have. This field-by-field status is complex and isn't necessarily intended to be presented in full to the user. Rather, it represents the state of the message internally within the MUA and may be used to influence behavior like replying to or forwarding the message (see Section 6.1).
Each Header Field individually has exactly one of the following protection states:
- unprotected (has no Header Protection)
- signed-only (bound into the same validated signature as the enclosing message, but also visible in transit)
- encrypted-only (only appears within the Cryptographic Payload; the corresponding external Header Field was either removed or obscured)
- signed-and-encrypted (same as encrypted-only, but additionally is under a validated signature)
If the message does not have Header Protection (as determined by Section 4.1), then all of the Header Fields are by definition unprotected.
If the message has Header Protection, an MUA SHOULD use the following algorithm to compute the protection state of a protected Header Field (h,v):
HeaderFieldProtection
Method signature:
HeaderFieldProtection(msg, h, v) -> protection_state
Procedure:
1. Let ct be the Content-Type of the root of the Cryptographic Payload of msg.
2. Compute (refouter, refprotected) from HeaderSetsFromMessage(msg).
3. If (h, v) is not in refprotected:
  i. Abort, v is not a valid value for Header Field h.
4. Let is_sig_valid be false.
5. If the message is signed:
  i. Let is_sig_valid be the result of validating the signature.
6. If the message is encrypted, and if ct has a parameter hp="cipher", and if (h,v) is not in refouter:
  i. Return signed-and-encrypted if is_sig_valid, otherwise return encrypted-only.
7. Return signed-only if is_sig_valid, otherwise return unprotected.
Note that:
- This algorithm is independent of the unprotected Header Fields. It derives the protection state only from (h,v) and the set of HP-Outer Header Fields, both of which are inside the Cryptographic Envelope.
- If the signature fails validation, the MUA lowers the affected state to unprotected or encrypted-only without any additional warning to the user (see also Section 3.1 of [RFC9787]).
- Data from signed-and-encrypted and encrypted-only Header Fields may still not be fully private (see Section 11.2).
- Encryption may have been added in transit to an originally signed-only message. Thus, only consider Header Fields to be confidential if the composer indicates it with the hp="cipher" parameter.
- 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-encrypted, but a Header Field that is copied unmodified to the Outer Header Section is signed-only.
If the message has Header Protection, the Header Fields that are not in refprotected (e.g., because they were added in transit) are unprotected.
Rendering the cryptographic status of each Header Field is likely to be complex and messy -- users may not understand it. It is beyond the scope of this document to suggest any specific graphical affordances or user experience. Future work should include examples of successful rendering of this information.
Handling Mismatch of From Header Fields
End-to-end (MUA-to-MUA) Header Protection is good for authenticity, integrity, and confidentiality, but it potentially introduces new issues when an MUA depends on its MTA to authenticate parts of the Header Section. The latter is typically the case in modern email systems.
In particular, when an MUA depends on its MTA to ensure that the email address in the (unprotected) From Header Field is authentic, but the MUA renders the email address of the protected From Header Field that differs from the address visible to the MTA, this could create a risk of sender address spoofing (see Section 10.1). This potential risk applies to signed-only messages as well as signed-and-encrypted messages.
Definitions
From Header Field Mismatch
"From Header Field Mismatch" is defined as follows:
The addr-spec of the inner From Header Field doesn't match the addr-spec of the outer From Header Field (see Section 4.4.5).
Note: The unprotected From Header Field used in this comparison is the actual Header Field found in the Outer Header Section (as seen by the MTA), not the value indicated by any potential inner HP-Outer Header Field.
No Valid and Correctly Bound Signature
"No Valid and Correctly Bound Signature" is defined as follows:
There is no valid signature made by a certificate for which the MUA has a valid binding to the protected From address. This includes:
- the message has no signature
- the message has a broken signature
- the message has a valid signature, but the rendering MUA does not see any valid binding between the signing certificate and the addr-spec of the inner From Header Field
Note: There are many possible ways that an MUA could choose to validate a certificate-to-address binding. For example, the MUA 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 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 describe all possible ways an MUA might validate the certificate-to-address binding or to choose among them.
Warning for From Header Field Mismatch
To mitigate the above described risk of sender address spoofing, an MUA SHOULD warn the user whenever both of the following conditions are met:
- From Header Field Mismatch (as defined in Section 4.4.1.1) and
- No Valid and Correctly Bound Signature (as defined in Section 4.4.1.2)
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-matching From Header Fields.
From Header Field Rendering
Furthermore, a rendering MUA that depends on its MTA to authenticate the (unprotected) outer From Header Field SHOULD render the outer From Header Field (as an exception to the guidance in the beginning of Section 4) if both of the following conditions are met:
- From Header Field Mismatch (as defined in Section 4.4.1.1) and
- No Valid and Correctly Bound Signature (as defined in Section 4.4.1.2)
An MUA MAY apply a local preference to render a different display name (e.g., from an address book).
See Section 10.1.1 for a detailed explanation of this rendering guidance.
Handling the Protected From Header Field When Responding
When responding to a message, an MUA has different ways to populate the recipients of the new message. Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may populate the composer view using a combination of the referenced message's From, To, Cc, Reply-To, or Mail-Followup-To Header Fields as well as any other signals.
When responding to a message with Header Protection, an MUA MUST only use the protected Header Fields when populating the recipients of the new message.
This avoids compromise of message confidentiality when a machine-in-the-middle (MITM) attacker modifies the unprotected From address of an encrypted message, attempting to learn the contents through a misdirected reply. Note that with the rendering guidance above, a MITM attacker can cause the unprotected From Header Field to be displayed. Thus, when responding, the populated To address may differ from the rendered From address. However, this change in addresses should not cause more user confusion than the address change caused by a Reply-To in a Legacy Message does.
Matching addr-specs
When generating (Section 3.1.1) or consuming (Section 4.4) a protected From Header Field, the MUA considers the equivalence of two different addr-spec values.
First, the MUA MUST check whether the domain part of an addr-spec being compared contains a U-label [RFC5890]. If it does, it MUST be 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 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 addr-specs by standard DNS comparison: Assume ASCII text and compare alphabetic characters case-insensitively, as described in Section 3.1 of [RFC1035]. If the domain parts match, then the two local-parts are matched against each other. The simplest and most common comparison for the local-part is also an ASCII-based, case-insensitive match. If the MUA has special knowledge about the domain and, when composing, it can reasonably expect the rendering MUAs to have the same information, it MAY match the local-part using a more sophisticated and inclusive matching algorithm.
It is beyond the scope of this document to recommend a more sophisticated and inclusive matching algorithm.
Rendering a Message with Header Protection
When the Cryptographic Payload's Content-Type has the parameter hp set to "clear" or "cipher", the values of the protected Header Fields are drawn from the Header Fields of the Cryptographic Payload, and the Body that is rendered is the content of the Cryptographic Payload itself.
Example Signed-Only Message
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:

A └┬╴application/pkcs7-mime; smime-type="signed-data"
   ┴ (unwraps to)
B  └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
C   ├─╴text/plain
D   └─╴text/html

The message Body should be rendered the same way as this message:

B └┬╴multipart/alternative
C  ├─╴text/plain
D  └─╴text/html

The MUA should render Header Fields taken from part B.
Its Cryptographic Summary should indicate that the message was signed and all rendered Header Fields were included in the signature.
Because this message is signed-only, none of its parts will have a Legacy Display Element.
The MUA should ignore Header Fields from part A for the purposes of rendering.
Example Signed-and-Encrypted Message
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:

E └┬╴application/pkcs7-mime; smime-type="enveloped-data"
   ╧ (decrypts to)
F  └┬╴application/pkcs7-mime; smime-type="signed-data"
    ┴ (unwraps to)
G   └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
H    ├─╴text/plain
I    └─╴text/html

The message Body should be rendered the same way as this message:

G └┬╴multipart/alternative
H  ├─╴text/plain
I  └─╴text/html

It should render Header Fields taken from part G.
Its Cryptographic Summary should indicate that the message is signed-and-encrypted.
When rendering the Cryptographic Status of a Header Field and when composing a reply (or forward), each Header Field found in G should be considered against all HP-Outer Header Fields found in G. If an HP-Outer Header Field that matches both the name and value is found, the Header Field's Cryptographic Status is just signed-only, even though the message itself is signed-and-encrypted. If no matching HP-Outer Header Field is found, the Header Field's Cryptographic Status is signed-and-encrypted, like the rest of the message (see Section 4.3).
If any of the User-Facing Header Fields are removed or obscured, the composer of this message may have placed Legacy Display Elements in parts H and I.
The MUA should ignore Header Fields from part E for the purposes of rendering.
Do Not Render Legacy Display Elements
As described in Section 2.1.2, a message with cryptographic confidentiality protection MAY include Legacy Display Elements for backward compatibility with Legacy MUAs. These Legacy Display Elements are strictly decorative and unambiguously identifiable and will be discarded by compliant implementations.
The rendering MUA MUST completely avoid rendering the identified Legacy Display Elements to the user, since it is aware of Header Protection and can render the actual protected Header Fields.
If a text/html or text/plain part within the Cryptographic Envelope is identified as containing Legacy Display Elements, those elements MUST be hidden when rendering and MUST be dropped when generating a draft reply or inline forwarded message. Whenever a message or a MIME subtree is exported, downloaded, or otherwise further processed, if there is no need to retain a valid cryptographic signature, the implementer MAY drop the Legacy Display Elements.
Identifying a Part with Legacy Display Elements
A rendering MUA acting on a message that contains an encrypting Cryptographic Layer identifies a MIME subpart within the Cryptographic Payload as containing Legacy Display Elements based on the Content-Type of the subpart. The subpart's Content-Type:
- 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 Section 4.5.3.3).
Note that the term "subpart" above is used in the general sense: If the Cryptographic Payload is a single part, that part itself may contain a Legacy Display Element if it is marked with the hp-legacy-display="1" parameter.
Omitting Legacy Display Elements from text/plain
If a text/plain part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1", it should be processed before rendering in the following fashion:
- Discard the leading lines of the content of the MIME part up to and including the first entirely blank line.
Note that implementing this strategy is dependent on the charset used by the MIME part.
See Appendix E.1 for an example.
Omitting Legacy Display Elements from text/html
If a text/html part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1", it should be processed before rendering in the following fashion:
- If any element of the HTML <body> is a <div> with class attribute header-protection-legacy-display, that entire element should be omitted.
This cleanup could be done, for example, as a custom rule in the MUA's HTML sanitizer, if one exists. Another implementation strategy for an HTML-capable MUA would be to add an entry to the [CSS] style sheet for such a part:

body div.header-protection-legacy-display { display: none; }

Implicitly Rendered Header Fields
While the From, To, Cc, Subject, and Date Header Fields are often explicitly rendered to the user, some Header Fields do affect message display without being explicitly rendered.
For example, the Message-Id, References, and In-Reply-To Header Fields may collectively be used to place a message in a "thread" or series of messages.
In another example, Section 6.2 notes that the value of the Reply-To Header Field can influence the draft reply message. So while the user may never see the Reply-To Header Field directly, it is implicitly "rendered" when the user interacts with the message by replying to it.
An MUA that depends on any implicitly rendered Header Field in a message with Header Protection MUST use the value from the protected Header Field and SHOULD NOT use any value found outside the cryptographic protection unless it is known to be a Header Field added in transit, as specified in Section 7.
Handling Undecryptable Messages
An MUA might receive an apparently encrypted message that it cannot currently decrypt. For example, when an MUA does not have regular access to the secret key material needed for decryption, it cannot know the cryptographically protected Header Fields or even whether the message has any cryptographically protected Header Fields.
Such an undecrypted message will be rendered by the MUA as a message without any Header Protection. This means that the message summary may well change how it is rendered when the user is finally able to supply the secret key.
For example, the rendering of the Subject Header Field in a mailbox summary might change from [...] to the real message subject when the message is decrypted. Or the message's placement in a message thread might change if, say, References or In-Reply-To have been removed or obscured (see Section 4.6).
Additionally, if the MUA does not retain access to the decrypting secret key, and it drops the decrypted form of a message, the message's rendering may revert to the encrypted form. For example, if an MUA follows this behavior, the Subject Header Field in a mailbox summary might change from the real message subject back to [...]. Or the message might be displayed outside of its current thread if the MUA loses access to a removed References or In-Reply-To Header Field.
These behaviors are likely to surprise the user. However, an MUA has several possible ways of reducing or avoiding all of these surprises, including:
- Ensuring that the MUA always has access to decryption-capable secret key material.
- Rendering undecrypted messages in a special quarantine view until the decryption-capable secret key material is available.
To reduce or avoid the surprises associated with a decrypted message with removed or obscured Header Fields becoming undecryptable, the MUA could also:
- Securely cache metadata from a decrypted message's protected Header Fields so that its rendering doesn't change after the first decryption.
- Securely store the session key associated with a decrypted message so that attempts to read the message when the long-term secret key is unavailable can proceed using only the session key itself. For example, see the discussion about stashing session keys in Section 9.1 of [RFC9787].
Guidance for Automated Message Handling
Some automated systems have a control channel that is operated by email. For example, an incoming email message could subscribe someone to a mailing list, initiate the purchase of a specific product, approve another message for redistribution, or adjust the state of some shared object.
To the extent that such a system depends on end-to-end cryptographic guarantees about the email control message, Header Protection as defined in this document should improve the system's security. This section provides some specific guidance for systems that use email messages as a control channel that want to benefit from these security improvements.
Only Interpret Protected Header Fields
Consider the situation where an email-based control channel depends on the message's cryptographic signature and the action taken depends on some Header Field of the message.
In this case, the automated system MUST rely on information from the Header Field that is protected by the mechanism defined in this document. It MUST NOT rely on any Header Field found outside the Cryptographic Payload.
For example, consider an administrative interface for a mailing list manager that only accepts control messages that are signed by one of its administrators. When an inbound message for the list arrives, it is queued (waiting for administrative approval) and the system generates and listens for two distinct email addresses related to the queued message -- one that approves the message and one that rejects it. If an administrator sends a signed control message to the approval address, the mailing list verifies that the protected To Header Field of the signed control message contains the approval address before approving the queued message for redistribution. If the protected To Header Field does not contain that address, or there is no protected To Header Field, then the mailing list logs or reports the error and does not act on that control message.
Ignore Legacy Display Elements
Consider the situation where an email-based control channel expects to receive an end-to-end encrypted message -- for example, where the control messages need confidentiality guarantees -- and where the action taken depends on the contents of some MIME part within the message Body.
In this case, the automated system that decrypts the incoming messages and scans the relevant MIME part MUST identify when the MIME part contains a Legacy Display Element (see Section 4.5.3.1), and it MUST parse the relevant MIME part with the Legacy Display Element removed.
For example, consider an administrative interface of a confidential issue tracking software. An authorized user can confidentially adjust the status of a tracked issue by a specially formatted first line of the message Body (for example, severity #183 serious). When the user's MUA encrypts a plaintext control message to this issue tracker, depending on the MUA's HCP and its choice of legacy value, it may add a Legacy Display Element. If it does so, then the first line of the message Body will contain a decorative copy of the confidential Subject Header Field. The issue tracking software decrypts the incoming control message, identifies that there is a Legacy Display Element in the part (see Section 4.5.3.1), strips the lines comprising the Legacy Display Element (including the first blank line), and only then parses the remaining top line to look for the expected special formatting.
Affordances for Debugging and Troubleshooting
Note that advanced users of an MUA may need access to the original message, for example, to troubleshoot problems with the rendering MUA itself or problems with the SMTP transport path taken by the message.
An MUA that applies these rendering guidelines SHOULD ensure that the full original source of the message as it was received remains available to such a user for debugging and troubleshooting.
If a troubleshooting scenario demands information about the cryptographically protected values of Header Fields, and the message is encrypted, the debugging interface SHOULD also provide a "source" view of the Cryptographic Payload itself, alongside the full original source of the message as received.
Handling RFC8551HP Messages (Backward Compatibility)
Section 1.1.1 describes some drawbacks to the Header Protection scheme defined in [RFC8551], referred to here as RFC8551HP. An MUA MUST NOT generate an RFC8551HP message. However, for backward compatibility, an MUA MAY try to render or respond to such a message as though the message has standard Header Protection.
The following two sections contain guidance for identifying, rendering, replying to, and forwarding RFC8551HP messages. Corresponding test vectors are provided in Appendices C.2.5, C.2.6, and C.3.17.
Identifying an RFC8551HP Message
An RFC8551HP message can be identified by its MIME structure, given that all of the following conditions are met:
- It has a well-formed Cryptographic Envelope consisting of at least one Cryptographic Layer as the outermost MIME object.
- The Cryptographic Payload is a single message/rfc822 object.
- The message that constitutes the Cryptographic Payload does not itself have a well-formed Cryptographic Envelope; that is, its outermost MIME object is not a Cryptographic Layer.
- No Content-Type parameter of hp= is set on either the Cryptographic Payload or its immediate MIME child.
Here is the MIME structure of an example signed-and-encrypted RFC8551HP message:

A └┬╴application/pkcs7-mime; smime-type="enveloped-data"
   ╧ (decrypts to)
B  └┬╴application/pkcs7-mime; smime-type="signed-data"
    ┴ (unwraps to)
C   └┬╴message/rfc822 [Cryptographic Payload]
D    └┬╴multipart/alternative [Rendered Body]
E     ├─╴text/plain
F     └─╴text/html

This meets the definition of an RFC8551HP message because:
- Cryptographic Layers A and B form the Cryptographic Envelope.
- The Cryptographic Payload, rooted in part C, has Content-Type: message/rfc822.
- Part D (the MIME root of the message at C) is itself not a Cryptographic Layer.
- Neither part C nor part D have any hp parameters set on their Content-Type.
Rendering or Responding to an RFC8551HP Message
When an MUA has precisely identified a message as an RFC8551HP message, the MUA MAY render or respond to that message as though it were a message with Header Protection as defined in this document by making the following adjustments:
- Rather than rendering the message Body as the Cryptographic Payload itself (part C in the example above), render the RFC8551HP message's Body as the MIME subtree that is the Cryptographic Payload's immediate child (part D).
- Make a comparable modification to HeaderSetsFromMessage (Section 4.2.1) and HeaderFieldProtection (Section 4.3.1): Both algorithms currently look for the protected Header Fields on the Cryptographic Payload (part C), but they should instead look at the Cryptographic Payload's immediate child (part D).
- If the Cryptographic Envelope is signed-only, behave as though there is an hp="clear" parameter for the Cryptographic Payload; if the Envelope contains encryption, behave as though there is an hp="cipher" parameter. That is, infer the composer's cryptographic intent from the structure of the message.
- If the Cryptographic Envelope contains encryption, further modify HeaderSetsFromMessage to derive refouter from the actual Outer Header Section (those Header Fields found in part A in the example above) rather than looking for HP-Outer Header Fields with the other protected Header Fields. That is, infer Header Field confidentiality based on the unprotected Header Fields.
The inferences in the above modifications are not based on any strong end-to-end guarantees. An intervening MTA may tamper with the message's Outer Header Section or wrap the message in an encryption layer to undetectably change the recipient's understanding of the confidentiality of the message's Header Fields or the message Body itself.
Rendering Other Schemes
Other MUAs may have generated different structures of messages that aim to offer end-to-end cryptographic protections that include Header Protection. This document is not normative for those schemes, and it is NOT RECOMMENDED to generate these other schemes, as they can either have structural flaws or simply render poorly on Legacy MUAs. A conformant MUA MAY attempt to infer Header Protection when rendering an existing message that appears to use some other scheme not documented here. Pointers to some known other schemes can be found in Appendix F.
Composing Guidance (Sending Side)
This section describes the process an MUA should use to apply cryptographic protection to an email message with Header Protection.
When composing a message with end-to-end cryptographic protections, an MUA SHOULD apply Header Protection.
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 the message's Cryptographic Payload. The value of the parameter MUST indicate whether the Cryptographic Envelope contains a layer that provides encryption.
Composing a Cryptographically Protected Message Without Header Protection
For contrast, we first consider the typical message composition process of a Legacy Crypto MUA, which does not provide any Header Protection.
This process is described in Section 5.1 of [RFC9787]. We replicate it here for reference. The inputs to the algorithm are:
- origbody: The unprotected message Body as a well-formed MIME tree (possibly just a single MIME leaf part). As a well-formed MIME tree, origbody already has Structural Header Fields (Content-*) present.
- origheaders: The intended Non-Structural Header Fields for the message, represented here as a list of (h,v) pairs, where h is a Header Field name and v is the associated value. Note that these are Header Fields that the MUA intends to be visible to the recipient of the message. In particular, if the MUA uses the Bcc Header Field during composition but plans to omit it from the message (see Section 3.6.3 of [RFC5322]), it will not be in origheaders.
- crypto: The series of cryptographic protections to apply (for example, "sign with the secret key corresponding to X.509 certificate X, then encrypt to X.509 certificates X and Y"). This is a routine that accepts a MIME tree as input (the Cryptographic Payload), wraps the input in the appropriate Cryptographic Envelope, and returns the resultant MIME tree as output.
The algorithm returns a MIME object that is ready to be injected into the mail system.
ComposeNoHeaderProtection
Method signature:
ComposeNoHeaderProtection(origbody, origheaders, crypto) -> mime_message
Procedure:
1. Apply crypto to MIME part origbody, producing MIME tree output.
2. For each Header Field name and value (h,v) in origheaders:
  i. Add Header Field h to output with value v.
3. Return output.
Composing a Message with Header Protection
To compose a message using Header Protection, the composing MUA uses the following inputs:
- all the inputs described in Section 5.1
- hcp: an HCP, as defined in Section 3
- respond: if the new message is a response to another message, the MUA's Respond Function corresponding to the user's action (see Section 6.1.1), otherwise null
- refmsg: if the new message is a response to another message, the message being responded to, otherwise null
- legacy: a boolean value, indicating whether any recipient of the message is believed to have a Legacy MUA. If all recipients are known to implement this document, legacy should be set to false. (How an MUA determines the value of legacy is out of scope for this document; an initial implementation can simply set it to true.)
To enable visibility of User-Facing but now removed/obscured Header Fields for decryption-capable Legacy MUAs, the Header Fields are included as a decorative Legacy Display Element in specially marked parts of the message (see Section 2.1.2). This document recommends two mechanisms for such a decorative adjustment: one for a text/plain Main Body Part (see Section 5.2.2) and one for a text/html Main Body Part (see Section 5.2.3) of the email message. This document does not recommend adding a Legacy Display Element to any other part.
Please see Section 7.1 of [RFC9787] for guidance on identifying the parts of a message that are a Main Body Part.
Compose
Method signature:
Compose(origbody, origheaders, crypto, hcp, respond, refmsg, legacy) -> mime_message
Procedure:
1. Let newbody be a copy of origbody.
2. If crypto contains encryption and legacy is true:
  i. Create ldlist, an empty list of (header, value) pairs.
  ii. For each Header Field name and value (h,v) in origheaders:
    a. If h is User-Facing (see Section 1.1.2 of [RFC9787]):
      I. If hcp(h,v) is not v:
        A. Add (h,v) to ldlist.
  iii. If ldlist is not empty:
    a. Identify each leaf MIME part of newbody that represents a "Main Body Part" of the message.
    b. For each "Main Body Part" bodypart of type text/plain or text/html:
      I. Adjust bodypart by inserting a Legacy Display Element Header Field list ldlist into its content and adding a Content-Type parameter hp-legacy-display with value 1 (see Section 5.2.2 for text/plain and Section 5.2.3 for text/html).
3. For each Header Field name and value (h,v) in origheaders:
  i. Add Header Field h to MIME part newbody with value v.
4. If crypto does not contain encryption:
  i. Set the hp parameter on the Content-Type of MIME part newbody to clear.
  ii. Let newheaders be a copy of origheaders.
5. Else (if crypto contains encryption):
  i. Set the hp parameter on the Content-Type of MIME part newbody to cipher.
  ii. Let response_hcp be an ephemeral HCP, the output of ReferenceHCP(refmsg, respond) (see Section 6.1.2).
  iii. Create a new empty list of Header Field names and values newheaders.
  iv. For each Header Field name and value (h,v) in origheaders:
    a. Let newval be hcp(h,v).
    b. If newval is v:
      I. Let newval be response_hcp(h,v).
    c. If newval is not null:
      I. Add (h,newval) to newheaders.
  v. For each Header Field name and value (h,v) in newheaders:
    a. Let string record be the concatenation of h, a literal ": " (ASCII colon (0x3A) followed by ASCII space (0x20)), and v.
    b. Add Header Field "HP-Outer" to MIME part newbody with value record.
6. Apply crypto to MIME part newbody, producing MIME tree output.
7. For each Header Field name and value (h,v) in newheaders:
  i. Add Header Field h to output with value v.
8. Return output.
Note that both new parameters (hcp and legacy) are effectively ignored if crypto does not contain encryption. This is by design, because they are irrelevant for signed-only cryptographic protections.
Adding a Legacy Display Element to a text/plain Part
For a list of obscured and removed User-Facing Header Fields represented as (header, value) pairs, concatenate them as a set of lines, with one newline at the end of each pair. Add an additional trailing newline after the resultant text, and prepend the entire list to the content of the text/plain part.
The MUA MUST also add a Content-Type parameter of hp-legacy-display with value 1 to the MIME part to indicate that a Legacy Display Element was added.
For example, if the list of obscured Header Fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")], then a text/plain Main Body Part that originally looked like this:

Content-Type: text/plain; charset=UTF-8

I think we should skip the meeting.

would become:

Content-Type: text/plain; charset=UTF-8; hp-legacy-display=1

Subject: Thursday's meeting
Cc: alice@example.net

I think we should skip the meeting.

Note that the Legacy Display Element (the lines beginning with Subject: and Cc:) is part of the content of the MIME part in question.
This example assumes that the Main Body Part in question is not the root of the Cryptographic Payload. For instance, it could be a leaf of a multipart/alternative Cryptographic Payload. This is why there are no additional Header Fields in the MIME part of this example.
Adding a Legacy Display Element to a text/html Part
Adding a Legacy Display Element to a text/html part is similar to how it is added to a text/plain part (see Section 5.2.2). Instead of adding the obscured or removed User-Facing Header Fields to a block of text delimited by a blank line, the composing MUA injects them in an HTML <div> element annotated with a class attribute of header-protection-legacy-display.
The content and formatting of this decorative <div> have no strict requirements, but they MUST represent all the obscured and removed User-Facing Header Fields in a readable fashion. A simple approach is to assemble the text in the same way as Section 5.2.2, wrap it in a verbatim <pre> element, and put that element in the annotated <div>.
The annotated <div> should be placed as close to the start of the <body> as possible, where it will be visible when viewed with a standard HTML renderer.
The MUA MUST also add a Content-Type parameter of hp-legacy-display with value 1 to the MIME part to indicate that a Legacy Display Element was added.
For example, if the list of obscured Header Fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")], then a text/html Main Body Part that originally looked like this:

Content-Type: text/html; charset=UTF-8

<html><head><title></title></head><body>
<p>I think we should skip the meeting.</p>
</body></html>

would become:

Content-Type: text/html; charset=UTF-8; hp-legacy-display=1

<html><head><title></title></head><body>
<div class="header-protection-legacy-display">
<pre>Subject: Thursday's meeting
Cc: alice@example.net</pre></div>
<p>I think we should skip the meeting.</p>
</body></html>

This example assumes that the Main Body Part in question is not the root of the Cryptographic Payload. For instance, it could be a leaf of a multipart/alternative Cryptographic Payload. This is why there are no additional Header Fields in the MIME part of this example.
Step-by-Step Example for Inserting a Legacy Display Element into text/html
A composing MUA MAY insert the Legacy Display Element anywhere reasonable within the message as long as it prioritizes visibility for the reader using a Legacy MUA that is capable of decryption. This decision may take into account special message-specific HTML formatting expectations if the MUA is aware of them. However, some MUAs may not have any special insight into the user's preferred HTML formatting and still want to insert a Legacy Display Element. This section offers a non-normative, simple, and minimal step-by-step approach for a composing MUA that has no other information or preferences to fall back on.
The process below assumes that the MUA already has the full HTML object that it intends to send, including all of the text supplied by the user.
1. Assemble the text exactly as specified for text/plain (see Section 5.2.2).
2. Wrap that text in a verbatim <pre> element.
3. Wrap that <pre> element in a <div> element annotated with the class header-protection-legacy-display.
4. Find the <body> element of the full HTML object.
5. Insert the <div> element as the first child of the <body> element.
Only Add a Legacy Display Element to Main Body Parts
Some messages may contain a text/plain or text/html subpart that is not a Main Body Part. For example, an email message might contain an attached text file or a downloaded web page. Attached documents need to be preserved as intended in the transmission, without modification.
The composing MUA MUST NOT add a Legacy Display Element to any part of the message that is not a Main Body Part. In particular, if a part is annotated with Content-Disposition: attachment, or if it does not descend via the first child of any of its multipart/mixed or multipart/related ancestors, it is not a Main Body Part and MUST NOT be modified.
See Section 7.1 of [RFC9787] for more guidance about common ways to distinguish Main Body Parts from other MIME parts in a message.
Do Not Add a Legacy Display Element to Other Content-Types
The purpose of injecting a Legacy Display Element into each Main Body Part is to enable rendering of otherwise obscured Header Fields in Legacy MUAs that are capable of message decryption but don't know how to follow the rest of the guidance in this document.
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 generating MUA SHOULD NOT add a Legacy Display Element to any MIME part with any other Content-Type.
Replying and Forwarding Guidance
An MUA might create a new message in response to another message, 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 action like "Reply", "Reply All", "Forward", or some comparable action to start the composition of a new message. The new message created this way effectively references the original message that was viewed at the time.
For encrypted messages, special guidance applies, because information can leak in at least two ways: leaking previously confidential Header Fields and leaking the entire message by sending the reply or forward to the wrong party.
Avoid Leaking Encrypted Header Fields in Replies and Forwards
As noted in Section 5.4 of [RFC9787], an MUA in this position MUST NOT leak previously encrypted content in the clear in a follow-up message. The same is true for protected Header Fields.
Values from any Header Field that was identified as either encrypted-only or signed-and-encrypted based on the steps outlined in Section 4.3 MUST NOT be sent in cleartext in a reply or forwarded message.
For example, if Subject was encrypted, and it is copied into the draft encrypted reply's Subject, the replying MUA will automatically obscure the reply's Subject Header Field.
When crafting the Header Fields for a reply or forwarded message, the composing MUA SHOULD make use of the HP-Outer Header Fields from within the Cryptographic Envelope of the referenced message to ensure that Header Fields derived from the referenced message do not leak in the reply or forwarded message.
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 Header Field in the referenced message. For example, the To Header Field is typically derived from the referenced message's Reply-To or From Header Fields. When generating this Header Field for the Outer 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 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 Header Fields that had been in the Outer Header Section of the original message at composition time. These are inferred from the HP-Outer Header Fields located within the Cryptographic Payload of the referenced message. If the value is itself different than the 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 copied to the Outer Header Section directly. As long as the resulting value is not null, it is noted (whether identical to the protected value or not) in the protected Header Section using HP-Outer, as described in Section 2.2.1.
See Appendix D.2 for a simple worked example of this process.
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 message even if the composer's choice of HCP wouldn't normally remove or obscure the Header Field in question. This is effectively a single-use HCP. The normal composing guidance in Section 5.2 applies this single-use HCP to implement the high-level guidance above.
The Respond Function
The mechanism described below depends on an abstraction referred to in this document as a Respond Function.
The Respond Function takes a list of Header Fields from a referenced message as input and generates a list of initial candidate message Header Field names and values that are used to populate the message composition interface.
Something like this function already exists in most MUAs, though it may differ across responsive actions. For example, the Respond Function that implements "Reply All" is likely to be different from the Respond Function that implements "Reply", which is in turn different from the Respond Function that implements "Forward".
ReferenceHCP
The algorithm takes two inputs:
- refmsg: a single referenced message
- respond: the MUA's Respond Function associated with the user's action (see Section 6.1.1)
As an output, it produces an ephemeral single-use HCP, specific to this kind of response to this specific message.
Method signature:
ReferenceHCP(refmsg, respond) -> response_hcp
Procedure:
1. If respond is null, refmsg is null, or refmsg is not encrypted with Header Protection:
  i. Return hcp_no_confidentiality (there is no header confidentiality in any referenced message that needs protection).
2. Extract refouter, refprotected from refmsg as described in Section 4.2.
3. Let genprotected be a list of (h,v) pairs generated by respond(refprotected).
4. Let genouter be a list of (h,v) pairs generated by respond(refouter).
5. For each (h,v) in genprotected:
  i. If (h,v) is in genouter:
    a. Remove (h,v) from both genprotected and genouter (this Header Field does not need additional confidentiality).
6. Let confmap be a mapping from a Header Field name and value (h,v) to either a string or the special value null (this mapping is initially empty).
7. For each (h,v) remaining in genprotected:
  i. Set result to the special value null.
  ii. For each (h1,v1) in genouter:
    a. If h1 is h:
      I. Set result to v1.
  iii. Insert (h,v) -> result into confmap.
8. Return a new HCP from confmap that tests whether the (name,val_in) tuple is in confmap; if so, return confmap[(name,val_in)]; otherwise, return val_in.
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 reply to (or forward of) two messages whose Header Fields have the values refouter and refprotected, respectively (independent of any cryptographic protections). Then, it uses the difference to derive a one-time HCP. This HCP takes into account both the referenced message's composer's preferences and the derivations that can happen to Header Field values when responding. Note that while some of these derivations are straightforward (e.g., In-Reply-To is usually derived from Message-ID), others are non-trivial. For example, the From address may be derived from To, Cc, or the MUA's local address preference (especially when the MUA received the referenced message via Bcc). Similarly, To may be derived from To, From, and/or Cc Header Fields depending on the MUA implementation and depending on whether the user clicked "Reply", "Reply All", "Forward", or any other action that generates a response to a message. Reusing the MUA's existing Respond Function incorporates these nuances without requiring any extra configuration choices or additional maintenance burden.
Avoid Misdirected Replies
When replying to a message, the composing MUA typically decides who to send the reply to based on:
- the Reply-To, Mail-Followup-To, or From Header Fields
- optionally, the other To or Cc Header Fields (if the user chose to "Reply All")
When a message has Header Protection, the replying MUA MUST populate the destination fields of the draft message using the protected Header Fields and ignore any unprotected Header Fields.
This mitigates against an attack where Mallory gets a copy of an encrypted message from Alice to Bob and then replays the message to Bob with an additional Cc to Mallory's own email address in the message's (unprotected) Outer Header Section.
If Bob knows Mallory's certificate already, and he replies to such a message without following the guidance in this section, it's likely that his MUA will encrypt the cleartext of the message directly to Mallory.
Unprotected Header Fields Added in Transit
Some Header Fields are legitimately added in transit and could not have been known to the composer at message composition time.
The most common of these Header Fields are Received and DKIM-Signature, neither of which are typically rendered, either explicitly or implicitly.
If a rendering MUA has specific knowledge about a given Header Field, including that:
- the Header Field would not have been known to the original composer and
- the Header Field might be rendered explicitly or implicitly,
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 Protection.
The MUA MAY prefer to verify that the Header Fields in question have additional transit-derived cryptographic protections before rendering or acting on them. For example, the MUA could verify whether these Header Fields are covered by an appropriate and valid ARC-Authentication-Results (see [RFC8617]) or DKIM-Signature (see [RFC6376]) Header Field.
Specific examples of Header Fields added in transit that are meaningful to the user can be found in the following section.
Mailing List Header Fields: List-* and Archived-At
If the message arrives through a mailing list, the list manager itself may inject Header Fields (most have a List- prefix) in the message. Header Fields commonly added by list managers include:
- List-Archive
- List-Subscribe
- List-Unsubscribe
- List-Id
- List-Help
- List-Post
- Archived-At
Some MUAs render these Header Fields implicitly by providing buttons for actions like "Subscribe", "View Archived Version", "Reply List", "List Info", etc.
An MUA rendering a message with Header Protection that contains any of these Header Fields in the Outer Header Section and that has reason to believe the message arrived through a mailing list MAY decide to render them to the user (explicitly or implicitly) even though they are not protected.
Email Ecosystem Evolution
The email ecosystem is the set of client-side and server-side software and policies that are used in the creation, transmission, storage, rendering, and indexing of email over the Internet.
This document is intended to offer tooling needed to improve the state of the email ecosystem in a way that can be deployed without significant disruption. Some elements of this specification are present for transitional purposes but would not exist if the system were designed from scratch.
This section describes these transitional mechanisms, as well as some suggestions for how they might eventually be phased out.
Dropping Legacy Display Elements
Any decorative Legacy Display Element added to an encrypted message that uses Header Protection is present strictly for enabling Header Field visibility (most importantly, the Subject Header Field) when the message is viewed with a decryption-capable Legacy MUA.
Eventually, the hope is that most decryption-capable MUAs will conform to this specification and there will be no need for injection of Legacy Display Elements in the message Body. A survey of widely used decryption-capable MUAs might be able to establish when most of them do support this specification.
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 false, yielding a much simpler message construction set.
Until that point, an end user might want to signal that their rendering MUAs are conformant to this document so that a peer composing a message to them can set legacy to false. A signal indicating capability of handling messages with Header Protection might be placed in the user's cryptographic certificate or in outbound messages.
This document does not attempt to define the syntax or semantics of such a signal.
More Ambitious Default HCP
This document defines a few different forms of HCP. An MUA implementing an HCP for the first time SHOULD deploy hcp_baseline as recommended in Section 3.3. This HCP offers the most commonly expected protection (obscuring the Subject Header Field) without risking deliverability or rendering issues.
The HCPs proposed in this document are relatively conservative and still leak a significant amount of metadata for encrypted messages. This is largely done to ensure deliverability (see Section 1.3.2) and usability (see Section 2 of [RFC9787] and Section 9), as messages without some critical Header Fields are more likely to not reach their intended recipient.
In the future, some mail transport systems may accept and deliver messages with even less publicly visible metadata. Many MTA operators today would ask for additional guarantees about such a message to limit the risks associated with abusive or spam mail.
This specification offers the HCP formalism itself as a way for MUA developers and MTA operators to describe their expectations around message deliverability. MUA developers can propose a more ambitious default HCP and ask MTA operators (or simply test) whether their MTAs would be likely to deliver or reject encrypted mail with that HCP applied. Proponents of a more ambitious HCP should explicitly document the HCP and name it clearly and unambiguously to facilitate this kind of interoperability discussion.
Reaching widespread consensus around a more ambitious global default HCP is a challenging problem of coordinating many different actors. A piecemeal approach might be more feasible, where some signaling mechanism allows a message recipient, MTA operator, or third-party clearinghouse to announce what kinds of HCPs are likely to be deliverable for a given recipient. In such a situation, the default HCP for an MUA might involve consulting the signaled acceptable HCPs for all recipients and combining them (along with a default for when no signal is present) in some way.
If such a signal were to reach widespread use, it could also be used to guide reasonable statistical default HCP choices for recipients with no signal.
This document does not attempt to define the syntax or semantics of such a signal.
Deprecation of Messages Without Header Protection
At some point, when the majority of MUA clients that can generate cryptographically protected messages can do so with Header Protection, it should be possible to deprecate any cryptographically protected message that does not have Header Protection.
For example, as noted in Section 9.1, it's possible for an MUA to render a signed-only message that has no Header Protection the same as an unprotected message. And a signed-and-encrypted message without Header Protection could likewise be marked as not fully protected.
These stricter rules could be adopted immediately for all messages. Or an MUA developer could roll them out immediately for any new message but still treat an old message (based on the Date Header Field and cryptographic signature timestamp) more leniently.
A decision like this by any popular rendering MUA could drive adoption of this standard for composing MUAs.
Usability Considerations
This section describes concerns for MUAs that are interested in easy adoption of Header Protection by normal users.
While they are not protocol-level artifacts, these concerns motivate the protocol features described in this document.
See also the usability commentary in Section 2 of [RFC9787].
Mixed Protections Within a Message Are Hard to Understand
When rendering a message to the user, the ideal circumstance is to present a single cryptographic status for any given message. However, when message Header Fields are present, some message Header Fields do not have the same cryptographic protections as the main message.
Representing such a mixed set of protection statuses is very difficult to do in a way that an Ordinary User can understand. There are at least three scenarios that are likely to be common and poorly understood:
- A signed message with no Header Protection.
- A signed-and-encrypted message with no Header Protection.
- A signed-and-encrypted message with Header Protection as defined in this document, where some User-Facing Header Fields have confidentiality but some do not.
An MUA should have a reasonable strategy for clearly communicating each of these scenarios to the user. For example, an MUA operating in an environment where it expects most cryptographically protected messages to have Header Protection could use the following rendering strategy:
- When rendering a message with a signed-only cryptographic status but no Header Protection, an MUA may decline to indicate a positive security status overall and only indicate the cryptographic status to a user in a message properties or diagnostic view. That is, the message may appear identical to an unsigned message except if a user verifies the properties through a menu option.
- When rendering a message with a signed-and-encrypted or encrypted-only cryptographic status but no Header Protection, overlay a warning flag on the typical cryptographic status indicator. That is, if a typical signed-and-encrypted message displays a lock icon, display a lock icon with a warning sign (e.g., an exclamation point in a triangle) overlaid. For example, see the graphics in [chrome-indicators].
- When rendering a message with a signed-and-encrypted or encrypted-only cryptographic status with Header Protection but where the Subject Header Field has not been removed or obscured, place a warning sign on the Subject line.
Other simple rendering strategies could also be reasonable.
Users Should Not Have to Choose a Header Confidentiality Policy
This document defines the abstraction of an HCP object for the sake of communication between implementers and deployments.
Most email users are unlikely to understand the trade-offs between different policies. In particular, the potential negative side effects (e.g., poor deliverability) may not be easily attributable by a normal user to a particular HCP.
Therefore, MUA implementers should be conservative in their choice of default HCP and should not require the Ordinary User to make an incomprehensible choice that could cause unfixable, undiagnosable problems. The safest option is for the MUA developer to select a known, stable HCP (this document recommends hcp_baseline in Section 3.3) on the user's behalf. An MUA should not expose the Ordinary User to a configuration option where they are expected to manually select (let alone define) an HCP.
Security Considerations
Header Protection improves the security of cryptographically protected email messages. Following the guidance in this document improves security for users by more directly aligning the underlying messages with user expectations about confidentiality, authenticity, and integrity.
Nevertheless, helping the user distinguish between cryptographic protections of various messages remains a security challenge for MUAs. This is exacerbated by the fact that many existing messages with cryptographic protections do not employ Header Protection. MUAs encountering these messages (e.g., in an archive) will need to handle older forms (without Header Protection) for quite some time, possibly forever.
For any MUA that offers S/MIME cryptographic protections, the security considerations from Section 6 of [RFC8551] (S/MIME), Section 3 of [RFC5083] (Authenticated-Enveloped-Data in Cryptographic Message Syntax (CMS)), and Section 14 of [RFC5652] (CMS more broadly) continue to apply. Likewise, for any MUA that offers PGP/MIME cryptographic protections, the security considerations from Section 8 of [RFC3156] (PGP with MIME) as well as Section 13 of [RFC9580] (OpenPGP itself) continue to apply. In addition, these underlying security considerations are now also applicable to the contents of the message Header Section, not just the message Body.
From Address Spoofing
For a rendering MUA that depends on its MTA to authenticate the origin of the message, applying this specification could enable sender address spoofing.
To prevent sender spoofing, many rendering MUAs implicitly rely on their receiving MTA to inspect the Outer Header Section and verify 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 address the MTA used to authenticate and/or filter (see also Section 4.4.1.1), the MUA may be vulnerable to spoofing.
Consider a malicious MUA that sets the following Header Fields on an encrypted message with Header Protection:
- Outer: From: <alice@example.com>
- Inner: HP-Outer: From: <alice@example.com>
- Inner: From: <bob@example.org>
During sending, the MTA of example.com validates that the sending MUA is authorized to send from alice@example.com. Since the message is encrypted, the sending and receiving MTAs cannot see the protected Header Fields. A naive rendering MUA might follow the algorithms in this document without special consideration for the From Header Field. Such an MUA might display the email as coming from bob@example.org to the user, resulting in a spoofed address.
This problem applies both between domains and within a domain.
This problem always applies to signed-and-encrypted messages. This problem also applies to signed-only messages because MTAs typically do not look at the protected Header Fields when confirming From address authenticity.
Sender address spoofing is relevant for two distinct security properties:
- Sender authenticity: relevant for rendering the message (which address to show the user?)
- Message confidentiality: relevant when replying to a message (a reply to the wrong address can leak the message contents)
From Rendering Reasoning
Section 4.4.3 provides guidance for rendering the From Header Field. It recommends a rendering MUA that depends on its MTA to authenticate the (unprotected) outer From Header Field to render the outer From Header Field if both of the following conditions are met:
- From Header Field Mismatch (as defined in Section 4.4.1.1) and
- No Valid and Correctly Bound Signature (as defined in Section 4.4.1.2)
Note: The second condition effectively means that the inner (expected to be protected) From Header Field appears to have insufficient protection.
This may seem surprising since it causes the MUA to render a mix of both protected and unprotected values. This section provides an argument as to why this guidance makes sense.
We proceed by case distinction:
- Case 1: Malicious composing MUA.
  - Attack situation: The composing MUA puts a different inner From Header Field to spoof the sender address.
  - In this case, it is "better" to fall back and render the outer From Header Field because this is what the receiving MTA can validate. Otherwise, this document would introduce a new way for senders to spoof the From address of the message.
  - This does not preclude a future document from updating this document to specify a protocol for legitimate sender address hiding.
- Case 2: Malicious sending/transiting/receiving MTA (or anyone meddling between MTAs).
  - Attack situation: An on-path attacker changes the outer From Header Field (possibly with other meddling to invalidate the signature; see below). Their goal is to get the rendering MUA to show a different From address than the composing MUA intended (breaking MUA-to-MUA sender authenticity).
  - Case 2.a: The composing MUA submitted an unsigned or encrypted-only message to the email system. In this case, there can be no sender authenticity anyway.
  - Case 2.b: The composing MUA submitted a signed-only message to the email system.
    - Case 2.b.i: The attacker removes or invalidates the signature. In this case, the attacker can also modify the inner From Header Field to their liking.
    - Case 2.b.ii: The signature is valid, but the rendering MUA does not see any valid binding between the signing certificate and the addr-spec of the inner From Header Field. In this case, there can be no sender authenticity anyways (the certificate could have been generated by the on-path attacker). This case is indistinguishable from a malicious composing MUA; hence, it is "better" to fall back to the outer From Header Field that the MTA can validate. Note that once the binding is validated (e.g., after an out-of-band comparison), the rendering may change from showing the outer From address (and a warning) to showing the inner, now validated From address. In some cases, the binding may be instantly validated even for previously unseen certificates (e.g., if the certificate is issued by a trusted certification authority).
  - Case 2.c: The composing MUA submitted a signed-and-encrypted message to the email system.
    - Case 2.c.i: The attacker removes or invalidates the signature. Note that the signature is inside the ciphertext (see Section 5.2 of [RFC9787]). Thus, assuming the encryption is non-malleable, any on-path attacker cannot invalidate the signature while ensuring that the message still decrypts successfully.
    - Case 2.c.ii: The signature is valid, but the rendering MUA does not see any valid binding between the signing certificate and the addr-spec of the inner From Header Field. See case 2.b.ii.
As the case distinction shows, the outer From Header Field is either the preferred fallback (in particular, to avoid introducing a new spoofing channel) or just as good (because just as modifiable) as the inner From Header Field.
Rendering the outer From Header Field does carry the risk of a "temporary downgrade attack" in cases 2.b.ii and 2.c.ii, where a malicious MTA keeps the signature intact but modifies the outer From Header Field. The MUA can resolve this temporary downgrade by validating the certificate-to-addr-spec binding. If the MUA never does this validation, the entire message could be fake.
If there were a signaling channel where the MTA can tell the MUA whether it authenticated the From Header Field, an MUA could use this in its rendering decision. In the absence of such a signal, and when end-to-end authenticity is unavailable, this document prefers to fall back to the outer From Header Field. This default is based on the assumption that most MTAs apply some filtering based on the outer From Header Field (whether the MTA can authenticate it or not). Rendering the unprotected outer From Header Field (instead of the protected inner one) in case of a mismatch retains this ability for MTAs.
If the MUA decides not to rely on the MTA to authenticate the outer From Header Field, it may prefer the inner From Header Field.
Avoid Cryptographic Summary Confusion from the hp Parameter
When parsing a message, the recipient MUA infers the message's Cryptographic Status from the Cryptographic Layers, as described in Section 4.6 of [RFC9787].
The Cryptographic Layers that make up the Cryptographic Envelope describe an ordered list of cryptographic properties as present in the message after it has been delivered. By contrast, the hp parameter to the Content-Type Header Field contains a simpler indication: whether the composer originally tried to encrypt the message or not (see Section 2.1.1). In particular, for a message with Header Protection, the Cryptographic Payload MUST have a hp parameter of cipher if the message is encrypted (in addition to signed) and clear if no encryption is present (that is, the message is signed-only).
As noted in Section 2.1.1, the rendering implementation MUST NOT inflate its estimation of the confidentiality of the message or its Header Fields based on the composer's intent if it can see that the message was not actually encrypted. A signed-only message that happens to have an hp parameter of cipher is still signed-only.
Conversely, since the encrypting Cryptographic Layer is typically outside the signature layer (see Section 5.2 of [RFC9787]), an originally signed-only message could have been wrapped in an encryption layer by an intervening party before receipt to appear encrypted.
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 the encryption layer was not added by the original composer. For such a message, the lack of any HP-Outer Header Field (see Section 2.2) in the Header Section of the Cryptographic Payload MUST NOT be used to infer that all Header Fields were removed from the Outer Header Section by the original composer. In such a case, the rendering MUA SHOULD treat every Header Field as though it was not confidential.
Caution About Composing with Legacy Display Elements
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 in a rendering client.
For example, if the value for a Header Field to be included in a Legacy Display Element within a given Body part contains folding whitespace, it SHOULD be "unfolded" before generating the Legacy Display Element: All contiguous folding whitespace SHOULD be replaced with a single space character. Likewise, if the Header Field value was originally encoded per [RFC2047], it SHOULD be decoded first to a standard string and re-encoded using the charset appropriate to the target part.
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 of newlines (e.g., if it is broken across multiple lines by encoded newlines), the composing MUA MUST strip any newline from the Legacy Display Element. If the pair of newlines is not stripped, a 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 message.
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 explicitly HTML escaped to avoid being rendered as part of the HTML. At a minimum, the characters <, >, ', ", and & MUST be escaped to &lt;, &gt;, &apos;, &quot;, and &amp;, respectively (for example, see [HTML-ESCAPES]). If unescaped characters from removed or obscured 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 identify the boundaries of the Legacy Display Element, cutting out more than it should or leaving remnants visible. And a Legacy MUA parsing such a message might misrender the entire HTML stream, depending on the content of the removed or obscured Header Field values.
The Legacy Display Element is a decorative addition solely to enable visibility of obscured or removed Header Fields in decryption-capable Legacy MUAs. When it is produced, it should be generated minimally and strictly, as described above, to avoid damaging the rest of the message.
Plaintext Attacks
An encrypted email message using S/MIME or PGP/MIME tends to have some amount of predictable plaintext. For example, the standard MIME Header Fields of the Cryptographic Payload of a message are often a predictable sequence of bytes, even without Header Protection, when they only include the Structural Header Fields MIME-Version and Content-Type. This is a potential risk for known-plaintext attacks.
Including protected Header Fields as defined in this document increases the amount of known plaintext. Since some of those Header Fields in a reply will be derived from the message being replied to, this also creates a potential risk for chosen-plaintext attacks, in addition to known-plaintext attacks. This potential risk also applies in a similar manner to forwarded messages.
Modern message encryption mechanisms are expected to be secure against both known-plaintext attacks and chosen-plaintext attacks. An MUA composing an encrypted message should ensure that it is using such a mechanism, regardless of whether it does Header Protection.
Privacy Considerations
Leaks When Replying
The encrypted Header Fields of a message may accidentally leak when replying to the message. See the guidance in Section 6.
Encrypted Header Fields Are Not Always Private
For encrypted messages, depending on the composer's HCP, some Header Fields may appear both within the Cryptographic Envelope and on the outside of the message (e.g., Date might exist identically in both places). Section 4.3 identifies such a Header Field as signed-only. These Header Fields are clearly not private at all, despite a copy being inside the Cryptographic Envelope.
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 or signed-and-encrypted status. But even Header Fields with these stronger levels of cryptographic confidentiality protection might not be as private as the user would like.
See the examples below.
This concern is true for any encrypted data, including the Body of the message, not just the Header Fields: If the composer isn't careful, the message contents or session keys can leak in many ways that are beyond the scope of this document. The message recipient has no way in principle to tell whether the apparent confidentiality of any given piece of encrypted content has been broken via channels that they cannot perceive. Additionally, an active intermediary aware of the recipient's public key can always encrypt a cleartext message in transit to give the recipient a false sense of security (see also Section 10.2).
Encrypted Header Fields Can Leak Unwanted Information to the Recipient
For an encrypted message, even with an ambitious HCP that successfully obscures most Header Fields from all transport agents, Header Fields will be ultimately visible to each intended recipient. This can be especially problematic for a Header Field that is not User-Facing; the composer may not expect such a Header Field to be injected by their MUA. Consider the three following examples:
- The MUA may inject a User-Agent Header Field that describes itself to every recipient, even though the composer may not want a recipient to know the exact version of their OS, hardware platform, or MUA.
- The MUA may have an idiosyncratic way of generating a Message-ID Header Field, which could embed the choice of MUA, time zone, hostname, or other subtle information to a knowledgeable recipient.
- The MUA may erroneously include a Bcc Header Field in the origheaders of a copy of a message sent to a named recipient, defeating the purpose of using Bcc instead of Cc (see Section 11.4 for more details about risks related to Bcc).
Clearly, no end-to-end cryptographic protection of any Header Field as defined in this document will hide such a sensitive field from an intended recipient. Instead, the composing MUA MUST populate the origheaders list for any outbound message with only information each recipient should have access to. This is true for any message without any cryptographic protection as well, of course, and it is even worse there: Such a leak is exposed to the transport agents as well as all recipients. An encrypted message with Header Protection and a more ambitious HCP avoids these leaks that expose information to the transport agents, but it cannot defend against such a leak to a recipient.
Encrypted Header Fields Can Be Inferred from External or Internal Metadata
For example, if the To and Cc Header Fields are removed from the Outer Header Section, the values in those fields might still be inferred with high probability by an adversary who looks at the message either in transit or at rest. For example, if the message is found in a mailbox, or being delivered to a mailbox, and the mailbox is known to be associated with the email address bob@example.org, it's likely that Bob was in either To or Cc. Furthermore, encrypted message ciphertext may hint at the recipients: For S/MIME messages, the RecipientInfo, and for PGP/MIME messages, the key ID in the Public Key Encrypted Session Key (PKESK) packets will all hint at a specific set of recipients. Additionally, an MTA that handles the message may add a Received Header Field (or some other custom Header Field) that leaks some information about the nature of the delivery.
Encrypted Header Fields May Not Be Fully Masked by HCP
In another example, if the HCP modifies the Date Header Field to mask out high-resolution timestamps (e.g., rounding to the most recent hour), some information about the date of delivery will still be attached to the email. At the very least, the low-resolution, global version of the date will be present on the message. Additionally, Header Fields like Received that are added during message delivery might include higher-resolution timestamps. And if the message lands in a mailbox that is ordered by time of receipt, even its placement in the mailbox and the unobscured Date Header Fields of the surrounding messages could leak this information.
Some Header Fields like From may be impossible to fully obscure, as many modern message delivery systems depend on at least domain information in the From Header Field for determining whether a message is coming from a domain with "good reputation" (that is, from a domain that is not known for leaking spam). So even if an ambitious HCP opts to remove the human-readable part from any From Header Field and to standardize/genericize the local part of the From address, the domain will still leak.
A Naive Recipient May Overestimate the Cryptographic Status of a Header Field in an Encrypted Message
When an encrypted (or signed-and-encrypted) message is in transit, an active intermediary can strip or tamper with any Header Field that appears outside the Cryptographic Envelope. A rendering MUA that naively infers cryptographic status from differences between the external Header Fields and those found in the Cryptographic Envelope could be tricked into overestimating the protections afforded to some Header Fields.
For example, if the original composer's HCP passes through the Cc Header Field unchanged, a cleanly delivered message would indicate that the Cc Header Field has a cryptographic status of signed. But if an intermediary attacker simply removes the Header Field from the Outer Header Section before forwarding the message, then the naive recipient might believe that the field has a cryptographic status of signed-and-encrypted.
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 Cryptographic Payload. If a Header Field appears to have been obscured by inspection of the Outer Header Section but an HP-Outer Header Field matches it exactly, then the rendering MUA can indicate to the user that the Header Field in question may not have been confidential.
In such a case, a cautious MUA may render the Header Field in question as signed (because the composer did not hide it) but still treat it as signed-and-encrypted during reply to avoid accidental leakage of the cleartext value in the reply message, as described in Section 6.1.
Privacy and Deliverability Risks with Bcc and Encrypted Messages
As noted in Section 9.3 of [RFC9787], handling Bcc when generating an encrypted email message can be particularly tricky. With Header Protection, there is an additional wrinkle. When an encrypted email message with Header Protection has a Bcc'ed recipient, and the composing MUA explicitly includes the Bcc'ed recipient's address in their copy of the message (see the "second method" in Section 3.6.3 of [RFC5322]), that Bcc Header Field will always be visible to the Bcc'ed recipient.
In this scenario, though, the composing MUA has one additional choice: whether or not to hide the Bcc Header Field from intervening message transport agents by returning null when the HCP is invoked for Bcc. If the composing MUA's rationale for including an explicit Bcc in the copy of the message sent to the Bcc recipient is to ensure deliverability via a message transport agent that inspects message Header Fields, then stripping the Bcc field during encryption may cause the intervening transport agent to drop the message entirely. This is why Bcc is not explicitly stripped in hcp_baseline.
On the other hand, if deliverability to a Bcc'ed recipient is not a concern, the most privacy-preserving option is to simply omit the Bcc Header Field from the protected Header Section in the first place. An MUA that is capable of receiving and processing such a message can infer that since their user's address was not mentioned in any To or Cc Header Field, they were likely a Bcc recipient.
Please also see Section 9.4 of [RFC9787] for more discussion about Bcc and encrypted messages.
IANA Considerations
This document registers an email Header Field, describes parameters for the Content-Type Header Field, and establishes a registry for Header Confidentiality Policies to facilitate HCP evolution.
Registration of the HP-Outer Header Field
IANA has registered the following Header Field in the "Permanent Message Header Field Names" registry within the "Message Headers" registry group https://www.iana.org/assignments/message-headers in accordance with [RFC3864].
Addition to the Permanent Message Header Field Names Registry
Header Field Name | Protocol | Status | Reference
HP-Outer | mail | standard | Section 2.2.1 of RFC 9788
Note that the Template and Trace columns are empty and therefore not included in the table.
The Author/Change Controller (Section 4.5 of [RFC3864]) for this entry is the IETF.
Reference Update for the Content-Type Header Field
This document defines the Content-Type parameters known as hp (in Section 2.1.1) and hp-legacy-display (in Section 2.1.2). Consequently, IANA has added this document as a reference for Content-Type in the "Permanent Message Header Field Names" registry as shown below.
Permanent Message Header Field Names Registry
Header Field Name | Protocol | Reference
Content-Type | MIME | [RFC4021] and RFC 9788
Note that the Template and Trace columns are empty and therefore not included in the table.
New Mail Header Confidentiality Policies Registry
IANA has created a new registry titled "Mail Header Confidentiality Policies" within the "MAIL Parameters" registry group https://www.iana.org/assignments/mail-parameters/ with the following content:
Mail Header Confidentiality Policies Registry
Header Confidentiality Policy Name | Description | Recommended | Reference
hcp_no_confidentiality | No header confidentiality | N | Section 3.2.3 of RFC 9788
hcp_baseline | Confidentiality for Informational Header Fields: Subject Header Field is obscured, Keywords and Comments are removed | Y | Section 3.2.1 of RFC 9788
hcp_shy | Obscure Subject, remove Keywords and Comments, remove the time zone from Date, and remove display-names from From, To, and Cc | N | Section 3.2.2 of RFC 9788
Note that hcp_example_hide_cc is offered as an example in Section 3.1 but is not formally registered by this document.
The following textual note has been added to this registry:
Adding an entry to this registry with an N in the "Recommended" column follows the registration policy of Specification Required. Adding an entry to this registry with a Y in the "Recommended" column or changing the "Recommended" column in an existing entry (from N to Y or vice versa) requires IETF Review.
Note that during IETF Review, the designated expert must be consulted. Guidance for the designated expert can be found in Section 3.4.2.
Additionally, this textual note has been added to the registry:
The Header Confidentiality Policy Name never appears on the wire. This registry merely tracks stable references to implementable descriptions of distinct policies. Any addition to this registry should be governed by guidance in Section 3.4.2 of RFC 9788.
References
Normative References
[RFC2045]

Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
N. Freed
N. Borenstein
November 1996
RFC 2045
DOI 10.17487/RFC2045
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC3864]

Registration Procedures for Message Header Fields
G. Klyne
M. Nottingham
J. Mogul
September 2004
BCP 90
RFC 3864
DOI 10.17487/RFC3864
[RFC5083]

Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
R. Housley
November 2007
RFC 5083
DOI 10.17487/RFC5083
[RFC5234]

Augmented BNF for Syntax Specifications: ABNF
D. Crocker, Ed.
P. Overell
January 2008
STD 68
RFC 5234
DOI 10.17487/RFC5234
[RFC5322]

Internet Message Format
P. Resnick, Ed.
October 2008
RFC 5322
DOI 10.17487/RFC5322
[RFC5652]

Cryptographic Message Syntax (CMS)
R. Housley
September 2009
STD 70
RFC 5652
DOI 10.17487/RFC5652
[RFC8126]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC8551]

Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
J. Schaad
B. Ramsdell
S. Turner
April 2019
RFC 8551
DOI 10.17487/RFC8551
[RFC9580]

OpenPGP
P. Wouters, Ed.
D. Huigens
J. Winter
Y. Niibe
July 2024
RFC 9580
DOI 10.17487/RFC9580
[RFC9787]

Guidance on End-to-End Email Security
Daniel Kahn Gillmor, Ed.
American Civil Liberties Union
Alexey Melnikov, Ed.
Isode Ltd
Bernie Hoeneisen, Ed.
pEp Project
August 2025
RFC 9787
DOI 10.17487/RFC9787
Informative References
[chrome-indicators]

Evolving Chrome's security indicators
Emily Schechter
May 2018
Chromium Blog
[CSS]

Cascading Style Sheets Level 2 Revision 2 (CSS 2.2) Specification
Bert, Ed.
12 April 2016
W3C First Public Working Draft
Latest version available at https://www.w3.org/TR/CSS22/.
[HTML-ESCAPES]

Using character escapes in markup and CSS
W3C
12 August 2010
[I-D.pep-email]

pretty Easy privacy (pEp): Email Formats and Protocols
Hernâni Marques
pEp Project
Bernie Hoeneisen
pEp Project
22 May 2025
Internet-Draft draft-pep-email-03
Work in Progress
[I-D.pep-general]

pretty Easy privacy (pEp): Privacy by Default
Volker Birk
pEp Project
Hernâni Marques
pEp Project
Bernie Hoeneisen
pEp Project
22 May 2025
Internet-Draft draft-pep-general-03
Work in Progress
[PGPCONTROL]

Authentication of Usenet Group Changes
UUNET Technologies, Inc.
27 October 2016
[PGPVERIFY-FORMAT]

Signing Control Messages, Verifying Control Messages
David C Lawrence
[I-D.autocrypt-lamps-protected-headers]

(Deprecated) Protected E-mail Headers
Bjarni Rúnar Einarsson
Mailpile ehf
juga
Independent
Daniel Kahn Gillmor
American Civil Liberties Union
16 April 2025
Internet-Draft draft-autocrypt-lamps-protected-headers-03
Work in Progress
[RFC1035]

Domain names - implementation and specification
P. Mockapetris
November 1987
STD 13
RFC 1035
DOI 10.17487/RFC1035
[RFC2047]

MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
K. Moore
November 1996
RFC 2047
DOI 10.17487/RFC2047
[RFC2049]

Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
N. Freed
N. Borenstein
November 1996
RFC 2049
DOI 10.17487/RFC2049
[RFC3156]

MIME Security with OpenPGP
M. Elkins
D. Del Torto
R. Levien
T. Roessler
August 2001
RFC 3156
DOI 10.17487/RFC3156
[RFC3851]

Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification
B. Ramsdell, Ed.
July 2004
RFC 3851
DOI 10.17487/RFC3851
[RFC4021]

Registration of Mail and MIME Header Fields
G. Klyne
J. Palme
March 2005
RFC 4021
DOI 10.17487/RFC4021
[RFC5751]

Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
B. Ramsdell
S. Turner
January 2010
RFC 5751
DOI 10.17487/RFC5751
[RFC5890]

Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
J. Klensin
August 2010
RFC 5890
DOI 10.17487/RFC5890
[RFC5891]

Internationalized Domain Names in Applications (IDNA): Protocol
J. Klensin
August 2010
RFC 5891
DOI 10.17487/RFC5891
[RFC6376]

DomainKeys Identified Mail (DKIM) Signatures
D. Crocker, Ed.
T. Hansen, Ed.
M. Kucherawy, Ed.
September 2011
STD 76
RFC 6376
DOI 10.17487/RFC6376
[RFC7489]

Domain-based Message Authentication, Reporting, and Conformance (DMARC)
M. Kucherawy, Ed.
E. Zwicky, Ed.
March 2015
RFC 7489
DOI 10.17487/RFC7489
[RFC7929]

DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
P. Wouters
August 2016
RFC 7929
DOI 10.17487/RFC7929
[RFC8162]

Using Secure DNS to Associate Certificates with Domain Names for S/MIME
P. Hoffman
J. Schlyter
May 2017
RFC 8162
DOI 10.17487/RFC8162
[RFC8617]

The Authenticated Received Chain (ARC) Protocol
K. Andersen
B. Long, Ed.
S. Blank, Ed.
M. Kucherawy, Ed.
July 2019
RFC 8617
DOI 10.17487/RFC8617
[RFC9216]

S/MIME Example Keys and Certificates
D. K. Gillmor, Ed.
April 2022
RFC 9216
DOI 10.17487/RFC9216
Table of Pseudocode Listings
This document contains guidance with pseudocode descriptions. Each algorithm is listed here for easy reference.
Table of Pseudocode Listings
Method Name | Description | Reference
HeaderSetsFromMessage | Derive "outer" and "protected" sets of Header Fields from a given message | Section 4.2.1
HeaderFieldProtection | Calculate cryptographic protections for a Header Field in a given message | Section 4.3.1
ReferenceHCP | Produce an ephemeral HCP to use when responding to a given message | Section 6.1.2
ComposeNoHeaderProtection | Legacy Message composition with end-to-end cryptographic protections (but no Header Protection) | Section 5.1.1
Compose | Compose a message with end-to-end cryptographic protections including Header Protection | Section 5.2.1
Possible Problems with Legacy MUAs
When an email message with end-to-end cryptographic protection is rendered by an MUA, the user might experience many different possible problematic interactions. A message with Header Protection may introduce new forms of user experience failure.
In this section, the authors enumerate different kinds of failures we have observed when reviewing, rendering, and replying to messages with different forms of Header Protection in different Legacy MUAs. Different Legacy MUAs demonstrate different subsets of these problems.
A conformant MUA would not exhibit any of these problems. An implementer updating their Legacy MUA to be compliant with this specification should consider these concerns and try to avoid them.
Recall that "protected" refers to the values of the inner Header Fields, e.g., the real Subject, and "unprotected" refers to the values of the outer Header Fields, e.g., the replacement Subject.
Problems Viewing Messages in a List View
- Unprotected Subject, Date, From, and To Header Fields are visible (instead of being replaced by protected values)
- Threading is not visible
Problems When Rendering a Message
- Unprotected Subject is visible
- Protected Subject (on its own) is visible in the Body
- Protected Subject, Date, From, and To Header Fields are visible in the Body
- User interaction needed to view the whole message
- User interaction needed to view the message Body
- User interaction needed to view the protected Subject
- Impossible to view the protected Subject
- Nuisance alarms during user interaction
- Impossible to view the message Body
- Appears as a forwarded message
- Appears as an attachment
- Security indicators not visible
- Security indicators do not identify the protection status of Header Fields
- User has multiple different methods to reply (e.g., reply to outer, reply to inner)
- User sees English "Subject:" in Body despite message itself being in non-English
- Security indicators do not identify the protection status of Header Fields
- Header Fields in the Body render with local Header Field names (e.g., showing "Betreff" instead of "Subject") and dates (TZ, locale)
Problems When Replying to a Message
Note that the use case here is:
- User views a message, to the point where they can read it
- User then replies to the message, and they are shown a message composition window, which has some UI elements
- If the MUA has multiple different methods to reply to a message, each way may need to be evaluated separately
This section also uses the shorthand UI:x to mean "the UI element that the user can edit that they think of as x".
- Unprotected Subject is in UI:subject (instead of the protected Subject)
- Protected Subject is quoted in UI:body (from Legacy Display Element)
- Protected Subject leaks when the reply is serialized into MIME
- Protected Subject is not anywhere in UI
- Message Body is not visible/quoted in UI:body
- User cannot reply while viewing protected message
- Reply is not encrypted by default (but is for legacy signed-and-encrypted messages without Header Protection)
- Unprotected From or Reply-To Header Field is in UI:To (instead of the protected From or Reply-To Header Field)
- User's locale (lang, TZ) leaks in quoted Body
- Header Fields not protected (and in particular, Subject is not obscured) by default
Test Vectors
This section contains sample messages using the specification defined above. Each sample contains a MIME object, a textual and diagrammatic view of its structure, and examples of how an MUA might render it.
The cryptographic protections used in this document use the S/MIME standard, and keying material and certificates come from [RFC9216].
These messages should be accessible to any IMAP client at imap://bob@header-protection.cmrg.net/ (any password should authenticate to this read-only IMAP mailbox).
Copies of these test vectors can also be downloaded separately at https://header-protection.cmrg.net.
If any of the messages downloaded differ from those offered here, this document is the canonical source.
Baseline Messages
These messages offer no Header Protection at all and can be used as a baseline. They are provided in this document as a counterexample. An MUA implementer can use these Messages to verify that the reported Cryptographic Summary of the Message indicates no Header Protection.
No Cryptographic Protections over a Simple Message
This message uses no cryptographic protection at all. Its Body is a text/plain message.
It has the following structure:

└─╴text/plain 152 bytes

Its contents are:

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: no-crypto
Message-ID: <no-crypto@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:00:02 -0500
User-Agent: Sample MUA Version 1.0

This is the
no-crypto
message.

This message uses no cryptographic protection at all.  Its Body
is a text/plain message.

--
Alice
alice@smime.example

S/MIME Signed-Only signedData over a Simple Message, No Header Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses no Header Protection.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 3856 bytes
 ┴ (unwraps to)
 └─╴text/plain 206 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"
Subject: smime-one-part
Message-ID: <smime-one-part@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:01:02 -0500
User-Agent: Sample MUA Version 1.0

MIILGQYJKoZIhvcNAQcCoIILCjCCCwYCAQExDTALBglghkgBZQMEAgEwggFCBgkq
hkiG9w0BBwGgggEzBIIBL01JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6
IHRleHQvcGxhaW47IGNoYXJzZXQ9InV0Zi04Ig0KQ29udGVudC1UcmFuc2Zlci1F
bmNvZGluZzogN2JpdA0KDQpUaGlzIGlzIHRoZQ0Kc21pbWUtb25lLXBhcnQNCm1l
c3NhZ2UuDQoNClRoaXMgaXMgYSBzaWduZWQtb25seSBTL01JTUUgbWVzc2FnZSB2
aWEgUEtDUyM3IHNpZ25lZERhdGEuICBUaGUNCnBheWxvYWQgaXMgYSB0ZXh0L3Bs
YWluIG1lc3NhZ2UuIEl0IHVzZXMgbm8gSGVhZGVyIFByb3RlY3Rpb24uDQoNCi0t
IA0KQWxpY2UNCmFsaWNlQHNtaW1lLmV4YW1wbGUNCqCCB6YwggPPMIICt6ADAgEC
AhMPLSW9ETmXSs5CVIeh7j00Boq0MA0GCSqGSIb3DQEBDQUAMFUxDTALBgNVBAoT
BElFVEYxETAPBgNVBAsTCExBTVBTIFdHMTEwLwYDVQQDEyhTYW1wbGUgTEFNUFMg
UlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MCAXDTE5MTEyMDA2NTQxOFoYDzIw
NTIwOTI3MDY1NDE4WjA7MQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBX
RzEXMBUGA1UEAxMOQWxpY2UgTG92ZWxhY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQCalSn6i8Gi44/oAVAn5GnCk4PHHNjrSfWUnnelN41KImVaTC3D
9zFCrS3i4Pa9ZgHyA5Qf8JW3ZmnVz5q7M8onZm7mZjqQeb6FUH4i2GMt4jse2Dqs
165ernT9O5NLFflHUjURca3ynqEBBV4DmhnZp8eDhv3t6dXyCjNHT82S6DgCReZu
TtMc1zy++MxQlqdn9WZLhOAOpeNZKGmVwjeVy+8FkyzC3jX/Qcm+ZLCqlLqhBwDH
dZ5qDTII2PVX1X3K7/cONxhvBbaUl/k1swdszUtjhflyFZ80RuQ3qFC6vL/PGeWy
6SCf58duq/AOEksCAWlb+MD8QH9Yj7CFSmq1AgMBAAGjga8wgawwDAYDVR0TAQH/
BAIwADAXBgNVHSAEEDAOMAwGCmCGSAFlAwIBMAEwHgYDVR0RBBcwFYETYWxpY2VA
c21pbWUuZXhhbXBsZTATBgNVHSUEDDAKBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMC
BSAwHQYDVR0OBBYEFKJTQdVEPIApFXwBI/Dnjq/N83cPMB8GA1UdIwQYMBaAFJEw
jnwHFwyn8QkoZTYaZxxodvRZMA0GCSqGSIb3DQEBDQUAA4IBAQCBSXignLEynBak
DKU68ro0RsyXWAPkfXgQLgy7GrW7SrZeBc5IEcjoN9f/gsOx/Ht9Ii6zyBZVjdao
x644DsiLOQEP4YMS7y4q94RFFdmdzEbDLYx9sfUhvdTxDNOOoHz53PYDBh4zE4Na
r2inC0D+VM6RGDy66K9l+D+bl8Wj9CyGUc1ppMNURexTg+z3web/eDOdu+F2MVtl
uLihne0Bp1GUTkr0mJBolg6dSYal8Hw8/ANHpyExl56BJABb744gqoeuD9YSHjKK
49+qYC9faFmQ+mK80lh1M9RdNI7srjn0LKpuob6w06jaRzWdNeXzlEc2tUpAr4vR
hZjVD6FYMIIDzzCCAregAwIBAgITN0EFee11f0Kpolw69Phqzpqp1zANBgkqhkiG
9w0BAQ0FADBVMQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBXRzExMC8G
A1UEAxMoU2FtcGxlIExBTVBTIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAg
Fw0xOTExMjAwNjU0MThaGA8yMDUyMDkyNzA2NTQxOFowOzENMAsGA1UEChMESUVU
RjERMA8GA1UECxMITEFNUFMgV0cxFzAVBgNVBAMTDkFsaWNlIExvdmVsYWNlMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtPSJ6Fg4Fj5Nmn9PkrYo0jTk
fCv4TfA/pdO/KLpZbJOAEr0sI7AjaO7B1GuMUFJeSTulamNfCwDcDkY63PQWl+DI
Ls7GxVwXurhYdZlaV5hcUqVAckPvedDBc/3rz4D/esFfs+E7QMFtmd+K04s+A8TC
NO12DRVBDpbP4JFD9hsc8prDtpGmFk7rd0q8gqnhxBW2RZAeLqzJOMayCQtws1q7
ktkNBR2wZX5ICjecF1YJFhX4jrnHwp/iELGqqaNXd3/Y0pG7QFecN7836IPPdfTM
SiPR+peCrhJZwLSewbWXLJe3VMvbvQjoBMpEYlaJBUIKkO1zQ1Pq90njlsJLOwID
AQABo4GvMIGsMAwGA1UdEwEB/wQCMAAwFwYDVR0gBBAwDjAMBgpghkgBZQMCATAB
MB4GA1UdEQQXMBWBE2FsaWNlQHNtaW1lLmV4YW1wbGUwEwYDVR0lBAwwCgYIKwYB
BQUHAwQwDgYDVR0PAQH/BAQDAgbAMB0GA1UdDgQWBBS79syyLR0GEhyXrilqkBDT
IGZmczAfBgNVHSMEGDAWgBSRMI58BxcMp/EJKGU2GmccaHb0WTANBgkqhkiG9w0B
AQ0FAAOCAQEAc4miNqfOqaBpI3f+CpJDhxtuZ2P9HjQEQ+v6BdP7GKJ19naIs3Bj
JOd64roAKHAp+c284VvyVXWJ99FMX8q2ZUQMxH+xh6oAfzcozmnd6XaVWHg4eHIj
So27PmhKE1oAJKKhDbdbEcZXL2+x1V+duGymWtaD01DZZukKYr7agyHahiXRn/C9
cy31wbqNsy9x0fjPQg6+DqatiQpMz9EIae6aCHHBhOiPU7IPkazgPYgkLD59fk4P
GHnYxs1FhdO6zZk9E8zwlc1ALgZa/iSbczisqckN3qGehD2s16jMhwFXLJtBiN+u
CDgNG/D0qyTbY4fgKieUHx/tHuzUszZxJjGCAgAwggH8AgEBMGwwVTENMAsGA1UE
ChMESUVURjERMA8GA1UECxMITEFNUFMgV0cxMTAvBgNVBAMTKFNhbXBsZSBMQU1Q
UyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCEzdBBXntdX9CqaJcOvT4as6a
qdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMjEwMjIwMTUwMTAyWjAvBgkqhkiG9w0BCQQxIgQg+APzZJl4
pcksifU3FOYwAUqexbFmtbnUdg8eCFIklg8wDQYJKoZIhvcNAQEBBQAEggEARlZH
lulQA7h4AzGUznSRv1TB3w2u4oXQBgxTTaUFXvezPsEacndc16K4ESz8IpjsLEqC
lhFU6haOKz3OZnab6A8sCqozqAoCpJI35L3D0XwlqucqRDMQoNDZf1AZw1/2rvhl
BA4+YVc1vNjwbFF7T8bz6ttkXBdseesPV8zy01tsPVBSEr9A8QtVGTPw/BLEV/sV
d6QtbPMCqdVDjRAa5onUPyZvXkt+Qkt5Wcqxfwbotg/u7ecLhqnK0rC2SZkGDjtZ
a6BuLu88DxA9T90G+L3hhL5VPdEdkdRCounTb9McyGWWmnK0PYind/sKBATP5ouF
jj3rLaMfllxGB0xn3A==

S/MIME Signed-Only signedData over a Simple Message, No Header Protection, Unwrapped
The S/MIME signed-data layer unwraps to:

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

This is the
smime-one-part
message.

This is a signed-only S/MIME message via PKCS#7 signedData.  The
payload is a text/plain message. It uses no Header Protection.

--
Alice
alice@smime.example

S/MIME Signed-Only multipart/signed over a Simple Message, No Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses no Header Protection.
It has the following structure:

└┬╴multipart/signed 4187 bytes
 ├─╴text/plain 224 bytes
 └─╴application/pkcs7-signature [smime.p7s] 3429 bytes

Its contents are:

MIME-Version: 1.0
Content-Type: multipart/signed;
 protocol="application/pkcs7-signature"; boundary="e19";
 micalg="sha-256"
Subject: smime-multipart
Message-ID: <smime-multipart@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:02:02 -0500
User-Agent: Sample MUA Version 1.0

--e19
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

This is the
smime-multipart
message.

This is a signed-only S/MIME message via PKCS#7 detached
signature (multipart/signed).  The payload is a text/plain
message. It uses no Header Protection.

--
Alice
alice@smime.example

--e19
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature; name="smime.p7s"

MIIJ4AYJKoZIhvcNAQcCoIIJ0TCCCc0CAQExDTALBglghkgBZQMEAgEwCwYJKoZI
hvcNAQcBoIIHpjCCA88wggK3oAMCAQICEw8tJb0ROZdKzkJUh6HuPTQGirQwDQYJ
KoZIhvcNAQENBQAwVTENMAsGA1UEChMESUVURjERMA8GA1UECxMITEFNUFMgV0cx
MTAvBgNVBAMTKFNhbXBsZSBMQU1QUyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwIBcNMTkxMTIwMDY1NDE4WhgPMjA1MjA5MjcwNjU0MThaMDsxDTALBgNVBAoT
BElFVEYxETAPBgNVBAsTCExBTVBTIFdHMRcwFQYDVQQDEw5BbGljZSBMb3ZlbGFj
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqVKfqLwaLjj+gBUCfk
acKTg8cc2OtJ9ZSed6U3jUoiZVpMLcP3MUKtLeLg9r1mAfIDlB/wlbdmadXPmrsz
yidmbuZmOpB5voVQfiLYYy3iOx7YOqzXrl6udP07k0sV+UdSNRFxrfKeoQEFXgOa
Gdmnx4OG/e3p1fIKM0dPzZLoOAJF5m5O0xzXPL74zFCWp2f1ZkuE4A6l41koaZXC
N5XL7wWTLMLeNf9Byb5ksKqUuqEHAMd1nmoNMgjY9VfVfcrv9w43GG8FtpSX+TWz
B2zNS2OF+XIVnzRG5DeoULq8v88Z5bLpIJ/nx26r8A4SSwIBaVv4wPxAf1iPsIVK
arUCAwEAAaOBrzCBrDAMBgNVHRMBAf8EAjAAMBcGA1UdIAQQMA4wDAYKYIZIAWUD
AgEwATAeBgNVHREEFzAVgRNhbGljZUBzbWltZS5leGFtcGxlMBMGA1UdJQQMMAoG
CCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIFIDAdBgNVHQ4EFgQUolNB1UQ8gCkVfAEj
8OeOr83zdw8wHwYDVR0jBBgwFoAUkTCOfAcXDKfxCShlNhpnHGh29FkwDQYJKoZI
hvcNAQENBQADggEBAIFJeKCcsTKcFqQMpTryujRGzJdYA+R9eBAuDLsatbtKtl4F
zkgRyOg31/+Cw7H8e30iLrPIFlWN1qjHrjgOyIs5AQ/hgxLvLir3hEUV2Z3MRsMt
jH2x9SG91PEM046gfPnc9gMGHjMTg1qvaKcLQP5UzpEYPLror2X4P5uXxaP0LIZR
zWmkw1RF7FOD7PfB5v94M5274XYxW2W4uKGd7QGnUZROSvSYkGiWDp1JhqXwfDz8
A0enITGXnoEkAFvvjiCqh64P1hIeMorj36pgL19oWZD6YrzSWHUz1F00juyuOfQs
qm6hvrDTqNpHNZ015fOURza1SkCvi9GFmNUPoVgwggPPMIICt6ADAgECAhM3QQV5
7XV/QqmiXDr0+GrOmqnXMA0GCSqGSIb3DQEBDQUAMFUxDTALBgNVBAoTBElFVEYx
ETAPBgNVBAsTCExBTVBTIFdHMTEwLwYDVQQDEyhTYW1wbGUgTEFNUFMgUlNBIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MCAXDTE5MTEyMDA2NTQxOFoYDzIwNTIwOTI3
MDY1NDE4WjA7MQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBXRzEXMBUG
A1UEAxMOQWxpY2UgTG92ZWxhY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC09InoWDgWPk2af0+StijSNOR8K/hN8D+l078oullsk4ASvSwjsCNo7sHU
a4xQUl5JO6VqY18LANwORjrc9BaX4MguzsbFXBe6uFh1mVpXmFxSpUByQ+950MFz
/evPgP96wV+z4TtAwW2Z34rTiz4DxMI07XYNFUEOls/gkUP2GxzymsO2kaYWTut3
SryCqeHEFbZFkB4urMk4xrIJC3CzWruS2Q0FHbBlfkgKN5wXVgkWFfiOucfCn+IQ
saqpo1d3f9jSkbtAV5w3vzfog8919MxKI9H6l4KuElnAtJ7BtZcsl7dUy9u9COgE
ykRiVokFQgqQ7XNDU+r3SeOWwks7AgMBAAGjga8wgawwDAYDVR0TAQH/BAIwADAX
BgNVHSAEEDAOMAwGCmCGSAFlAwIBMAEwHgYDVR0RBBcwFYETYWxpY2VAc21pbWUu
ZXhhbXBsZTATBgNVHSUEDDAKBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBsAwHQYD
VR0OBBYEFLv2zLItHQYSHJeuKWqQENMgZmZzMB8GA1UdIwQYMBaAFJEwjnwHFwyn
8QkoZTYaZxxodvRZMA0GCSqGSIb3DQEBDQUAA4IBAQBziaI2p86poGkjd/4KkkOH
G25nY/0eNARD6/oF0/sYonX2doizcGMk53riugAocCn5zbzhW/JVdYn30UxfyrZl
RAzEf7GHqgB/NyjOad3pdpVYeDh4ciNKjbs+aEoTWgAkoqENt1sRxlcvb7HVX524
bKZa1oPTUNlm6QpivtqDIdqGJdGf8L1zLfXBuo2zL3HR+M9CDr4Opq2JCkzP0Qhp
7poIccGE6I9Tsg+RrOA9iCQsPn1+Tg8YedjGzUWF07rNmT0TzPCVzUAuBlr+JJtz
OKypyQ3eoZ6EPazXqMyHAVcsm0GI364IOA0b8PSrJNtjh+AqJ5QfH+0e7NSzNnEm
MYICADCCAfwCAQEwbDBVMQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBX
RzExMC8GA1UEAxMoU2FtcGxlIExBTVBTIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNTAyMDJa
MC8GCSqGSIb3DQEJBDEiBCAokSzA71kmvoyy0h+lrO2jw3pvGhvgRnv/zTDC9IxD
UzANBgkqhkiG9w0BAQEFAASCAQBWL6C/VCYFv6ZiQR6JYBbLWiQJyAmNFrRhAbfi
w5bPndhDbJNSv3DXoUfCKd87pvD5Qr1PsH4WXDZ/IY95h3dD7k6oIIFXhPBTYYW7
Np+vrVtS0sDklr03+ebMBY6J0rEtNf5ZXCkQULTmvwmmuKcg4S+5piNqhTnnE0en
IvICii8NgjP3VVPZmNpFmxwmztGWd04omYHbY4JY9C7yvuQ6SNEQm47bxnSIS5yH
sowWnDYqs2cMDLxZ7zy0cEyOpSy8oDfVde4TyOifqMT3VzSmlttdG1uDNE90ek3t
xJn9E+hE02sw0Mv1lLjNdRXviRsaMw33DxGbtoUSo2mOkpYb

--e19--

S/MIME Signed-and-Encrypted over a Simple Message, No Header Protection
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses no Header Protection.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 6720 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 3960 bytes
  ┴ (unwraps to)
  └─╴text/plain 241 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: smime-signed-enc
Message-ID: <smime-signed-enc@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:03:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 6592 characters]
BiD2T2KmI8jOgLaSmuAnyw==

S/MIME Signed-and-Encrypted over a Simple Message, No Header Protection, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

MIILPAYJKoZIhvcNAQcCoIILLTCCCykCAQExDTALBglghkgBZQMEAgEwggFlBgkq
hkiG9w0BBwGgggFWBIIBUk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6
IHRleHQvcGxhaW47IGNoYXJzZXQ9InV0Zi04Ig0KQ29udGVudC1UcmFuc2Zlci1F
bmNvZGluZzogN2JpdA0KDQpUaGlzIGlzIHRoZQ0Kc21pbWUtc2lnbmVkLWVuYw0K
bWVzc2FnZS4NCg0KVGhpcyBpcyBhIHNpZ25lZC1hbmQtZW5jcnlwdGVkIFMvTUlN
RSBtZXNzYWdlIHVzaW5nIFBLQ1MjNw0KZW52ZWxvcGVkRGF0YSBhcm91bmQgc2ln
bmVkRGF0YS4gIFRoZSBwYXlsb2FkIGlzIGEgdGV4dC9wbGFpbg0KbWVzc2FnZS4g
SXQgdXNlcyBubyBIZWFkZXIgUHJvdGVjdGlvbi4NCg0KLS0gDQpBbGljZQ0KYWxp
Y2VAc21pbWUuZXhhbXBsZQ0KoIIHpjCCA88wggK3oAMCAQICEw8tJb0ROZdKzkJU
h6HuPTQGirQwDQYJKoZIhvcNAQENBQAwVTENMAsGA1UEChMESUVURjERMA8GA1UE
CxMITEFNUFMgV0cxMTAvBgNVBAMTKFNhbXBsZSBMQU1QUyBSU0EgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwIBcNMTkxMTIwMDY1NDE4WhgPMjA1MjA5MjcwNjU0MTha
MDsxDTALBgNVBAoTBElFVEYxETAPBgNVBAsTCExBTVBTIFdHMRcwFQYDVQQDEw5B
bGljZSBMb3ZlbGFjZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqV
KfqLwaLjj+gBUCfkacKTg8cc2OtJ9ZSed6U3jUoiZVpMLcP3MUKtLeLg9r1mAfID
lB/wlbdmadXPmrszyidmbuZmOpB5voVQfiLYYy3iOx7YOqzXrl6udP07k0sV+UdS
NRFxrfKeoQEFXgOaGdmnx4OG/e3p1fIKM0dPzZLoOAJF5m5O0xzXPL74zFCWp2f1
ZkuE4A6l41koaZXCN5XL7wWTLMLeNf9Byb5ksKqUuqEHAMd1nmoNMgjY9VfVfcrv
9w43GG8FtpSX+TWzB2zNS2OF+XIVnzRG5DeoULq8v88Z5bLpIJ/nx26r8A4SSwIB
aVv4wPxAf1iPsIVKarUCAwEAAaOBrzCBrDAMBgNVHRMBAf8EAjAAMBcGA1UdIAQQ
MA4wDAYKYIZIAWUDAgEwATAeBgNVHREEFzAVgRNhbGljZUBzbWltZS5leGFtcGxl
MBMGA1UdJQQMMAoGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIFIDAdBgNVHQ4EFgQU
olNB1UQ8gCkVfAEj8OeOr83zdw8wHwYDVR0jBBgwFoAUkTCOfAcXDKfxCShlNhpn
HGh29FkwDQYJKoZIhvcNAQENBQADggEBAIFJeKCcsTKcFqQMpTryujRGzJdYA+R9
eBAuDLsatbtKtl4FzkgRyOg31/+Cw7H8e30iLrPIFlWN1qjHrjgOyIs5AQ/hgxLv
Lir3hEUV2Z3MRsMtjH2x9SG91PEM046gfPnc9gMGHjMTg1qvaKcLQP5UzpEYPLro
r2X4P5uXxaP0LIZRzWmkw1RF7FOD7PfB5v94M5274XYxW2W4uKGd7QGnUZROSvSY
kGiWDp1JhqXwfDz8A0enITGXnoEkAFvvjiCqh64P1hIeMorj36pgL19oWZD6YrzS
WHUz1F00juyuOfQsqm6hvrDTqNpHNZ015fOURza1SkCvi9GFmNUPoVgwggPPMIIC
t6ADAgECAhM3QQV57XV/QqmiXDr0+GrOmqnXMA0GCSqGSIb3DQEBDQUAMFUxDTAL
BgNVBAoTBElFVEYxETAPBgNVBAsTCExBTVBTIFdHMTEwLwYDVQQDEyhTYW1wbGUg
TEFNUFMgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MCAXDTE5MTEyMDA2NTQx
OFoYDzIwNTIwOTI3MDY1NDE4WjA7MQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhM
QU1QUyBXRzEXMBUGA1UEAxMOQWxpY2UgTG92ZWxhY2UwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC09InoWDgWPk2af0+StijSNOR8K/hN8D+l078oulls
k4ASvSwjsCNo7sHUa4xQUl5JO6VqY18LANwORjrc9BaX4MguzsbFXBe6uFh1mVpX
mFxSpUByQ+950MFz/evPgP96wV+z4TtAwW2Z34rTiz4DxMI07XYNFUEOls/gkUP2
GxzymsO2kaYWTut3SryCqeHEFbZFkB4urMk4xrIJC3CzWruS2Q0FHbBlfkgKN5wX
VgkWFfiOucfCn+IQsaqpo1d3f9jSkbtAV5w3vzfog8919MxKI9H6l4KuElnAtJ7B
tZcsl7dUy9u9COgEykRiVokFQgqQ7XNDU+r3SeOWwks7AgMBAAGjga8wgawwDAYD
VR0TAQH/BAIwADAXBgNVHSAEEDAOMAwGCmCGSAFlAwIBMAEwHgYDVR0RBBcwFYET
YWxpY2VAc21pbWUuZXhhbXBsZTATBgNVHSUEDDAKBggrBgEFBQcDBDAOBgNVHQ8B
Af8EBAMCBsAwHQYDVR0OBBYEFLv2zLItHQYSHJeuKWqQENMgZmZzMB8GA1UdIwQY
MBaAFJEwjnwHFwyn8QkoZTYaZxxodvRZMA0GCSqGSIb3DQEBDQUAA4IBAQBziaI2
p86poGkjd/4KkkOHG25nY/0eNARD6/oF0/sYonX2doizcGMk53riugAocCn5zbzh
W/JVdYn30UxfyrZlRAzEf7GHqgB/NyjOad3pdpVYeDh4ciNKjbs+aEoTWgAkoqEN
t1sRxlcvb7HVX524bKZa1oPTUNlm6QpivtqDIdqGJdGf8L1zLfXBuo2zL3HR+M9C
Dr4Opq2JCkzP0Qhp7poIccGE6I9Tsg+RrOA9iCQsPn1+Tg8YedjGzUWF07rNmT0T
zPCVzUAuBlr+JJtzOKypyQ3eoZ6EPazXqMyHAVcsm0GI364IOA0b8PSrJNtjh+Aq
J5QfH+0e7NSzNnEmMYICADCCAfwCAQEwbDBVMQ0wCwYDVQQKEwRJRVRGMREwDwYD
VQQLEwhMQU1QUyBXRzExMC8GA1UEAxMoU2FtcGxlIExBTVBTIFJTQSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQME
AgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0y
MTAyMjAxNTAzMDJaMC8GCSqGSIb3DQEJBDEiBCCb47LkqJUmFpzt9bQAPoWpk+vy
9sGfzpOuEZflV+goizANBgkqhkiG9w0BAQEFAASCAQCd+I+Tr7hDMV3VFvFGduS9
4ysR9dceBgPloLOH71fsoJUl508WspagFkqjkUGPipKfYVrssRi8IHQM682HQqUk
jkB0UYx0hfEBVbsDvhYejzOYfyLRQD6TYI3HTVFJIJIKVk3JQUuQWzx+A5i14oHI
mCeHl1FgRq6D1B3hjpWFFWI35pRZ1gSZ3tPryQwq1Y0bMkiF4CeuUYEKWIdFHZdo
u/IMfLJoJeYpy8cyv6FznuJzkAR9AlUIUw58zXCD0ipCfKH2w6vwqdoCo4V0+cZd
5cZlYQSFab3fduU44viKaXf4VOpWK49oDeR/tV5i1LfM3ZYeH2V1r+pmnjyt8CcW

S/MIME Signed-and-Encrypted over a Simple Message, No Header Protection, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

This is the
smime-signed-enc
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a text/plain
message. It uses no Header Protection.

--
Alice
alice@smime.example

No Cryptographic Protections over a Complex Message
This message uses no cryptographic protection at all. Its Body is a multipart/alternative message with an inline image/png attachment.
It has the following structure:

└┬╴multipart/mixed 1402 bytes
 ├┬╴multipart/alternative 794 bytes
 │├─╴text/plain 206 bytes
 │└─╴text/html 304 bytes
 └─╴image/png inline 232 bytes

Its contents are:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0cf"
Subject: no-crypto-complex
Message-ID: <no-crypto-complex@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:00:02 -0500
User-Agent: Sample MUA Version 1.0

--0cf
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="6e6"

--6e6
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
no-crypto-complex
message.

This message uses no cryptographic protection at all.  Its Body
is a multipart/alternative message with an inline image/png
attachment.

--
Alice
alice@smime.example
--6e6
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>no-crypto-complex</b>
message.</p>
<p>This message uses no cryptographic protection at all.  Its Body
is a multipart/alternative message with an inline image/png
attachment.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--6e6--

--0cf
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--0cf--

S/MIME Signed-Only signedData over a Complex Message, No Header Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses no Header Protection.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 5253 bytes
 ┴ (unwraps to)
 └┬╴multipart/mixed 1288 bytes
  ├┬╴multipart/alternative 882 bytes
  │├─╴text/plain 260 bytes
  │└─╴text/html 355 bytes
  └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"
Subject: smime-one-part-complex
Message-ID: <smime-one-part-complex@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:01:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 5120 characters]
NqgxW8weaEV03KYp+fbsIdTSDwrz5w9rmSH1b+ReoY5kMa50eu9w

S/MIME Signed-Only signedData over a Complex Message, No Header Protection, Unwrapped
The S/MIME signed-data layer unwraps to:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="db0"

--db0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="51d"

--51d
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-one-part-complex
message.

This is a signed-only S/MIME message via PKCS#7 signedData.  The
payload is a multipart/alternative message with an inline
image/png attachment. It uses no Header Protection.

--
Alice
alice@smime.example
--51d
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-one-part-complex</b>
message.</p>
<p>This is a signed-only S/MIME message via PKCS#7 signedData.  The
payload is a multipart/alternative message with an inline
image/png attachment. It uses no Header Protection.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--51d--

--db0
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--db0--

S/MIME Signed-Only multipart/signed over a Complex Message, No Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses no Header Protection.
It has the following structure:

└┬╴multipart/signed 5230 bytes
 ├┬╴multipart/mixed 1344 bytes
 │├┬╴multipart/alternative 938 bytes
 ││├─╴text/plain 278 bytes
 ││└─╴text/html 376 bytes
 │└─╴image/png inline 232 bytes
 └─╴application/pkcs7-signature [smime.p7s] 3429 bytes

Its contents are:

MIME-Version: 1.0
Content-Type: multipart/signed;
 protocol="application/pkcs7-signature"; boundary="872";
 micalg="sha-256"
Subject: smime-multipart-complex
Message-ID: <smime-multipart-complex@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:02:02 -0500
User-Agent: Sample MUA Version 1.0

--872
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="757"

--757
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="3ff"

--3ff
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-multipart-complex
message.

This is a signed-only S/MIME message via PKCS#7 detached
signature (multipart/signed).  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses no Header Protection.

--
Alice
alice@smime.example
--3ff
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-multipart-complex</b>
message.</p>
<p>This is a signed-only S/MIME message via PKCS#7 detached
signature (multipart/signed).  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses no Header Protection.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--3ff--

--757
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--757--

--872
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature; name="smime.p7s"

MIIJ4AYJKoZIhvcNAQcCoIIJ0TCCCc0CAQExDTALBglghkgBZQMEAgEwCwYJKoZI
hvcNAQcBoIIHpjCCA88wggK3oAMCAQICEw8tJb0ROZdKzkJUh6HuPTQGirQwDQYJ
KoZIhvcNAQENBQAwVTENMAsGA1UEChMESUVURjERMA8GA1UECxMITEFNUFMgV0cx
MTAvBgNVBAMTKFNhbXBsZSBMQU1QUyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwIBcNMTkxMTIwMDY1NDE4WhgPMjA1MjA5MjcwNjU0MThaMDsxDTALBgNVBAoT
BElFVEYxETAPBgNVBAsTCExBTVBTIFdHMRcwFQYDVQQDEw5BbGljZSBMb3ZlbGFj
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqVKfqLwaLjj+gBUCfk
acKTg8cc2OtJ9ZSed6U3jUoiZVpMLcP3MUKtLeLg9r1mAfIDlB/wlbdmadXPmrsz
yidmbuZmOpB5voVQfiLYYy3iOx7YOqzXrl6udP07k0sV+UdSNRFxrfKeoQEFXgOa
Gdmnx4OG/e3p1fIKM0dPzZLoOAJF5m5O0xzXPL74zFCWp2f1ZkuE4A6l41koaZXC
N5XL7wWTLMLeNf9Byb5ksKqUuqEHAMd1nmoNMgjY9VfVfcrv9w43GG8FtpSX+TWz
B2zNS2OF+XIVnzRG5DeoULq8v88Z5bLpIJ/nx26r8A4SSwIBaVv4wPxAf1iPsIVK
arUCAwEAAaOBrzCBrDAMBgNVHRMBAf8EAjAAMBcGA1UdIAQQMA4wDAYKYIZIAWUD
AgEwATAeBgNVHREEFzAVgRNhbGljZUBzbWltZS5leGFtcGxlMBMGA1UdJQQMMAoG
CCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIFIDAdBgNVHQ4EFgQUolNB1UQ8gCkVfAEj
8OeOr83zdw8wHwYDVR0jBBgwFoAUkTCOfAcXDKfxCShlNhpnHGh29FkwDQYJKoZI
hvcNAQENBQADggEBAIFJeKCcsTKcFqQMpTryujRGzJdYA+R9eBAuDLsatbtKtl4F
zkgRyOg31/+Cw7H8e30iLrPIFlWN1qjHrjgOyIs5AQ/hgxLvLir3hEUV2Z3MRsMt
jH2x9SG91PEM046gfPnc9gMGHjMTg1qvaKcLQP5UzpEYPLror2X4P5uXxaP0LIZR
zWmkw1RF7FOD7PfB5v94M5274XYxW2W4uKGd7QGnUZROSvSYkGiWDp1JhqXwfDz8
A0enITGXnoEkAFvvjiCqh64P1hIeMorj36pgL19oWZD6YrzSWHUz1F00juyuOfQs
qm6hvrDTqNpHNZ015fOURza1SkCvi9GFmNUPoVgwggPPMIICt6ADAgECAhM3QQV5
7XV/QqmiXDr0+GrOmqnXMA0GCSqGSIb3DQEBDQUAMFUxDTALBgNVBAoTBElFVEYx
ETAPBgNVBAsTCExBTVBTIFdHMTEwLwYDVQQDEyhTYW1wbGUgTEFNUFMgUlNBIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MCAXDTE5MTEyMDA2NTQxOFoYDzIwNTIwOTI3
MDY1NDE4WjA7MQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBXRzEXMBUG
A1UEAxMOQWxpY2UgTG92ZWxhY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC09InoWDgWPk2af0+StijSNOR8K/hN8D+l078oullsk4ASvSwjsCNo7sHU
a4xQUl5JO6VqY18LANwORjrc9BaX4MguzsbFXBe6uFh1mVpXmFxSpUByQ+950MFz
/evPgP96wV+z4TtAwW2Z34rTiz4DxMI07XYNFUEOls/gkUP2GxzymsO2kaYWTut3
SryCqeHEFbZFkB4urMk4xrIJC3CzWruS2Q0FHbBlfkgKN5wXVgkWFfiOucfCn+IQ
saqpo1d3f9jSkbtAV5w3vzfog8919MxKI9H6l4KuElnAtJ7BtZcsl7dUy9u9COgE
ykRiVokFQgqQ7XNDU+r3SeOWwks7AgMBAAGjga8wgawwDAYDVR0TAQH/BAIwADAX
BgNVHSAEEDAOMAwGCmCGSAFlAwIBMAEwHgYDVR0RBBcwFYETYWxpY2VAc21pbWUu
ZXhhbXBsZTATBgNVHSUEDDAKBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBsAwHQYD
VR0OBBYEFLv2zLItHQYSHJeuKWqQENMgZmZzMB8GA1UdIwQYMBaAFJEwjnwHFwyn
8QkoZTYaZxxodvRZMA0GCSqGSIb3DQEBDQUAA4IBAQBziaI2p86poGkjd/4KkkOH
G25nY/0eNARD6/oF0/sYonX2doizcGMk53riugAocCn5zbzhW/JVdYn30UxfyrZl
RAzEf7GHqgB/NyjOad3pdpVYeDh4ciNKjbs+aEoTWgAkoqENt1sRxlcvb7HVX524
bKZa1oPTUNlm6QpivtqDIdqGJdGf8L1zLfXBuo2zL3HR+M9CDr4Opq2JCkzP0Qhp
7poIccGE6I9Tsg+RrOA9iCQsPn1+Tg8YedjGzUWF07rNmT0TzPCVzUAuBlr+JJtz
OKypyQ3eoZ6EPazXqMyHAVcsm0GI364IOA0b8PSrJNtjh+AqJ5QfH+0e7NSzNnEm
MYICADCCAfwCAQEwbDBVMQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBX
RzExMC8GA1UEAxMoU2FtcGxlIExBTVBTIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNzAyMDJa
MC8GCSqGSIb3DQEJBDEiBCC5KpxWrqp9lc/at0VVROdHn83fXt5r6VC1EPizN3pz
YDANBgkqhkiG9w0BAQEFAASCAQCVWFu4+5JFFOLMcfSgjQsyxsRKPplmT35MrYT1
rZKzBqdb7BgsgtavL6xHs/GKGjbqHwrrPADgsnyeXwotOBZoFzxLxw9fQI7z7wH5
QbGLEj6hRHvrSdYzhlptTnTqc4hXdYwh3jjNJlIf1D01EP9KySaLt3M/aGcNUKDO
z2ngLLtpOQULqGm/IxkIG+Rj9YHlktQVEiPxtT+TQ8qO0eiHZVukT88BpGOBBpCs
9aLUH2JuEF6v6wKp9S+sWj4sxO9bzYmNPOmi8WWyGYx5NVldgzeZxhISConuiji7
e3Wyda9wa7pqiFz0nsY+/mqILYTxBYMcsjN8uZ8yCaPdcfpU

--872--

S/MIME Signed-and-Encrypted over a Complex Message, No Header Protection
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses no Header Protection.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 8710 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 5434 bytes
  ┴ (unwraps to)
  └┬╴multipart/mixed 1356 bytes
   ├┬╴multipart/alternative 950 bytes
   │├─╴text/plain 295 bytes
   │└─╴text/html 390 bytes
   └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: smime-signed-enc-complex
Message-ID: <smime-signed-enc-complex@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:03:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 8576 characters]

S/MIME Signed-and-Encrypted over a Complex Message, No Header Protection, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 5248 characters]
edT2/t+0u3oJtCflrQ==

S/MIME Signed-and-Encrypted over a Complex Message, No Header Protection, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="363"

--363
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="f27"

--f27
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-signed-enc-complex
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses no Header Protection.

--
Alice
alice@smime.example
--f27
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-signed-enc-complex</b>
message.</p>
<p>This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses no Header Protection.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--f27--

--363
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--363--

Signed-Only Messages
These messages are signed-only, using different schemes of Header Protection and different S/MIME structures. They use no HCP because the HCP is only relevant when a message is encrypted.
S/MIME Signed-Only signedData over a Simple Message, Header Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses the Header Protection scheme from RFC 9788.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 4189 bytes
 ┴ (unwraps to)
 └─╴text/plain 232 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"
Subject: smime-one-part-hp
Message-ID: <smime-one-part-hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:06:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 4096 characters]
GEyYkGT7mRMuLMxmHktDjUBiIA==

S/MIME Signed-Only signedData over a Simple Message, Header Protection, Unwrapped
The S/MIME signed-data layer unwraps to:

MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: smime-one-part-hp
Message-ID: <smime-one-part-hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:06:02 -0500
User-Agent: Sample MUA Version 1.0
Content-Type: text/plain; charset="utf-8"; hp="clear"

This is the
smime-one-part-hp
message.

This is a signed-only S/MIME message via PKCS#7 signedData.  The
payload is a text/plain message. It uses the Header Protection
scheme from RFC 9788.

--
Alice
alice@smime.example

S/MIME Signed-Only multipart/signed over a Simple Message, Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses the Header Protection scheme from RFC 9788.
It has the following structure:

└┬╴multipart/signed 4434 bytes
 ├─╴text/plain 249 bytes
 └─╴application/pkcs7-signature [smime.p7s] 3429 bytes

Its contents are:

MIME-Version: 1.0
Content-Type: multipart/signed;
 protocol="application/pkcs7-signature"; boundary="54f";
 micalg="sha-256"
Subject: smime-multipart-hp
Message-ID: <smime-multipart-hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:07:02 -0500
User-Agent: Sample MUA Version 1.0

--54f
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: smime-multipart-hp
Message-ID: <smime-multipart-hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:07:02 -0500
User-Agent: Sample MUA Version 1.0
Content-Type: text/plain; charset="utf-8"; hp="clear"

This is the
smime-multipart-hp
message.

This is a signed-only S/MIME message via PKCS#7 detached
signature (multipart/signed).  The payload is a text/plain
message. It uses the Header Protection scheme from RFC 9788.

--
Alice
alice@smime.example

--54f
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature; name="smime.p7s"

MIIJ4AYJKoZIhvcNAQcCoIIJ0TCCCc0CAQExDTALBglghkgBZQMEAgEwCwYJKoZI
hvcNAQcBoIIHpjCCA88wggK3oAMCAQICEw8tJb0ROZdKzkJUh6HuPTQGirQwDQYJ
KoZIhvcNAQENBQAwVTENMAsGA1UEChMESUVURjERMA8GA1UECxMITEFNUFMgV0cx
MTAvBgNVBAMTKFNhbXBsZSBMQU1QUyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwIBcNMTkxMTIwMDY1NDE4WhgPMjA1MjA5MjcwNjU0MThaMDsxDTALBgNVBAoT
BElFVEYxETAPBgNVBAsTCExBTVBTIFdHMRcwFQYDVQQDEw5BbGljZSBMb3ZlbGFj
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqVKfqLwaLjj+gBUCfk
acKTg8cc2OtJ9ZSed6U3jUoiZVpMLcP3MUKtLeLg9r1mAfIDlB/wlbdmadXPmrsz
yidmbuZmOpB5voVQfiLYYy3iOx7YOqzXrl6udP07k0sV+UdSNRFxrfKeoQEFXgOa
Gdmnx4OG/e3p1fIKM0dPzZLoOAJF5m5O0xzXPL74zFCWp2f1ZkuE4A6l41koaZXC
N5XL7wWTLMLeNf9Byb5ksKqUuqEHAMd1nmoNMgjY9VfVfcrv9w43GG8FtpSX+TWz
B2zNS2OF+XIVnzRG5DeoULq8v88Z5bLpIJ/nx26r8A4SSwIBaVv4wPxAf1iPsIVK
arUCAwEAAaOBrzCBrDAMBgNVHRMBAf8EAjAAMBcGA1UdIAQQMA4wDAYKYIZIAWUD
AgEwATAeBgNVHREEFzAVgRNhbGljZUBzbWltZS5leGFtcGxlMBMGA1UdJQQMMAoG
CCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIFIDAdBgNVHQ4EFgQUolNB1UQ8gCkVfAEj
8OeOr83zdw8wHwYDVR0jBBgwFoAUkTCOfAcXDKfxCShlNhpnHGh29FkwDQYJKoZI
hvcNAQENBQADggEBAIFJeKCcsTKcFqQMpTryujRGzJdYA+R9eBAuDLsatbtKtl4F
zkgRyOg31/+Cw7H8e30iLrPIFlWN1qjHrjgOyIs5AQ/hgxLvLir3hEUV2Z3MRsMt
jH2x9SG91PEM046gfPnc9gMGHjMTg1qvaKcLQP5UzpEYPLror2X4P5uXxaP0LIZR
zWmkw1RF7FOD7PfB5v94M5274XYxW2W4uKGd7QGnUZROSvSYkGiWDp1JhqXwfDz8
A0enITGXnoEkAFvvjiCqh64P1hIeMorj36pgL19oWZD6YrzSWHUz1F00juyuOfQs
qm6hvrDTqNpHNZ015fOURza1SkCvi9GFmNUPoVgwggPPMIICt6ADAgECAhM3QQV5
7XV/QqmiXDr0+GrOmqnXMA0GCSqGSIb3DQEBDQUAMFUxDTALBgNVBAoTBElFVEYx
ETAPBgNVBAsTCExBTVBTIFdHMTEwLwYDVQQDEyhTYW1wbGUgTEFNUFMgUlNBIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MCAXDTE5MTEyMDA2NTQxOFoYDzIwNTIwOTI3
MDY1NDE4WjA7MQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBXRzEXMBUG
A1UEAxMOQWxpY2UgTG92ZWxhY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC09InoWDgWPk2af0+StijSNOR8K/hN8D+l078oullsk4ASvSwjsCNo7sHU
a4xQUl5JO6VqY18LANwORjrc9BaX4MguzsbFXBe6uFh1mVpXmFxSpUByQ+950MFz
/evPgP96wV+z4TtAwW2Z34rTiz4DxMI07XYNFUEOls/gkUP2GxzymsO2kaYWTut3
SryCqeHEFbZFkB4urMk4xrIJC3CzWruS2Q0FHbBlfkgKN5wXVgkWFfiOucfCn+IQ
saqpo1d3f9jSkbtAV5w3vzfog8919MxKI9H6l4KuElnAtJ7BtZcsl7dUy9u9COgE
ykRiVokFQgqQ7XNDU+r3SeOWwks7AgMBAAGjga8wgawwDAYDVR0TAQH/BAIwADAX
BgNVHSAEEDAOMAwGCmCGSAFlAwIBMAEwHgYDVR0RBBcwFYETYWxpY2VAc21pbWUu
ZXhhbXBsZTATBgNVHSUEDDAKBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBsAwHQYD
VR0OBBYEFLv2zLItHQYSHJeuKWqQENMgZmZzMB8GA1UdIwQYMBaAFJEwjnwHFwyn
8QkoZTYaZxxodvRZMA0GCSqGSIb3DQEBDQUAA4IBAQBziaI2p86poGkjd/4KkkOH
G25nY/0eNARD6/oF0/sYonX2doizcGMk53riugAocCn5zbzhW/JVdYn30UxfyrZl
RAzEf7GHqgB/NyjOad3pdpVYeDh4ciNKjbs+aEoTWgAkoqENt1sRxlcvb7HVX524
bKZa1oPTUNlm6QpivtqDIdqGJdGf8L1zLfXBuo2zL3HR+M9CDr4Opq2JCkzP0Qhp
7poIccGE6I9Tsg+RrOA9iCQsPn1+Tg8YedjGzUWF07rNmT0TzPCVzUAuBlr+JJtz
OKypyQ3eoZ6EPazXqMyHAVcsm0GI364IOA0b8PSrJNtjh+AqJ5QfH+0e7NSzNnEm
MYICADCCAfwCAQEwbDBVMQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBX
RzExMC8GA1UEAxMoU2FtcGxlIExBTVBTIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNTA3MDJa
MC8GCSqGSIb3DQEJBDEiBCAfybSsej+1D6r16hb18FcqV4ucPU0CgwMlVVH7gTaP
3TANBgkqhkiG9w0BAQEFAASCAQBwlRSGR8OZHFa+8cUc5th58+DiNkwKWqz4pWWX
0QP9uuxRZjE8Dtg7b88d0HtZWL98qAp+bjFK8ElktpuBiS5Nuiy+Zm3XnMU5GhCM
ywIPUAPJA6jvibT5fzYvMGV11RBmrTFNBZxxrJOAWfGfqf96vx9VajBVbyXdXnV7
hnQCx8wsbIOrbRUUVJHBGqpx+j+bIoUmg3uKxOYkZFz9IShmq8fzsW/CVTBMLfoT
qle2y+4H+RlGioqz8Mvs+XXbL5MG1r5PGjgpa9hHxPKdbFQCoWIJMA6xJNKgeuoN
rA3kHbrX/5Gn9eK8vE5eI6rpEurDGYkws6A9Z/tvsR7Gm9Ia

--54f--

S/MIME Signed-Only signedData over a Complex Message, Header Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Header Protection scheme from RFC 9788.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 5643 bytes
 ┴ (unwraps to)
 └┬╴multipart/mixed 1568 bytes
  ├┬╴multipart/alternative 932 bytes
  │├─╴text/plain 286 bytes
  │└─╴text/html 381 bytes
  └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"
Subject: smime-one-part-complex-hp
Message-ID: <smime-one-part-complex-hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:06:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 5504 characters]
bPh7G4quw8SDQNHb/qTjsWYfAfE1K2edTz5z1u0GPm9ElCiFUPsc

S/MIME Signed-Only signedData over a Complex Message, Header Protection, Unwrapped
The S/MIME signed-data layer unwraps to:

MIME-Version: 1.0
Subject: smime-one-part-complex-hp
Message-ID: <smime-one-part-complex-hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:06:02 -0500
User-Agent: Sample MUA Version 1.0
Content-Type: multipart/mixed; boundary="ab8"; hp="clear"

--ab8
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0f4"

--0f4
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-one-part-complex-hp
message.

This is a signed-only S/MIME message via PKCS#7 signedData.  The
payload is a multipart/alternative message with an inline
image/png attachment. It uses the Header Protection scheme from
RFC 9788.

--
Alice
alice@smime.example
--0f4
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-one-part-complex-hp</b>
message.</p>
<p>This is a signed-only S/MIME message via PKCS#7 signedData.  The
payload is a multipart/alternative message with an inline
image/png attachment. It uses the Header Protection scheme from
RFC 9788.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--0f4--

--ab8
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--ab8--

S/MIME Signed-Only multipart/signed over a Complex Message, Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses the Header Protection scheme from RFC 9788.
It has the following structure:

└┬╴multipart/signed 5518 bytes
 ├┬╴multipart/mixed 1626 bytes
 │├┬╴multipart/alternative 988 bytes
 ││├─╴text/plain 303 bytes
 ││└─╴text/html 401 bytes
 │└─╴image/png inline 232 bytes
 └─╴application/pkcs7-signature [smime.p7s] 3429 bytes

Its contents are:

MIME-Version: 1.0
Content-Type: multipart/signed;
 protocol="application/pkcs7-signature"; boundary="a64";
 micalg="sha-256"
Subject: smime-multipart-complex-hp
Message-ID: <smime-multipart-complex-hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:07:02 -0500
User-Agent: Sample MUA Version 1.0

--a64
MIME-Version: 1.0
Subject: smime-multipart-complex-hp
Message-ID: <smime-multipart-complex-hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:07:02 -0500
User-Agent: Sample MUA Version 1.0
Content-Type: multipart/mixed; boundary="550"; hp="clear"

--550
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="fcd"

--fcd
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-multipart-complex-hp
message.

This is a signed-only S/MIME message via PKCS#7 detached
signature (multipart/signed).  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788.

--
Alice
alice@smime.example
--fcd
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-multipart-complex-hp</b>
message.</p>
<p>This is a signed-only S/MIME message via PKCS#7 detached
signature (multipart/signed).  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--fcd--

--550
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--550--

--a64
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature; name="smime.p7s"

MIIJ4AYJKoZIhvcNAQcCoIIJ0TCCCc0CAQExDTALBglghkgBZQMEAgEwCwYJKoZI
hvcNAQcBoIIHpjCCA88wggK3oAMCAQICEw8tJb0ROZdKzkJUh6HuPTQGirQwDQYJ
KoZIhvcNAQENBQAwVTENMAsGA1UEChMESUVURjERMA8GA1UECxMITEFNUFMgV0cx
MTAvBgNVBAMTKFNhbXBsZSBMQU1QUyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwIBcNMTkxMTIwMDY1NDE4WhgPMjA1MjA5MjcwNjU0MThaMDsxDTALBgNVBAoT
BElFVEYxETAPBgNVBAsTCExBTVBTIFdHMRcwFQYDVQQDEw5BbGljZSBMb3ZlbGFj
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqVKfqLwaLjj+gBUCfk
acKTg8cc2OtJ9ZSed6U3jUoiZVpMLcP3MUKtLeLg9r1mAfIDlB/wlbdmadXPmrsz
yidmbuZmOpB5voVQfiLYYy3iOx7YOqzXrl6udP07k0sV+UdSNRFxrfKeoQEFXgOa
Gdmnx4OG/e3p1fIKM0dPzZLoOAJF5m5O0xzXPL74zFCWp2f1ZkuE4A6l41koaZXC
N5XL7wWTLMLeNf9Byb5ksKqUuqEHAMd1nmoNMgjY9VfVfcrv9w43GG8FtpSX+TWz
B2zNS2OF+XIVnzRG5DeoULq8v88Z5bLpIJ/nx26r8A4SSwIBaVv4wPxAf1iPsIVK
arUCAwEAAaOBrzCBrDAMBgNVHRMBAf8EAjAAMBcGA1UdIAQQMA4wDAYKYIZIAWUD
AgEwATAeBgNVHREEFzAVgRNhbGljZUBzbWltZS5leGFtcGxlMBMGA1UdJQQMMAoG
CCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIFIDAdBgNVHQ4EFgQUolNB1UQ8gCkVfAEj
8OeOr83zdw8wHwYDVR0jBBgwFoAUkTCOfAcXDKfxCShlNhpnHGh29FkwDQYJKoZI
hvcNAQENBQADggEBAIFJeKCcsTKcFqQMpTryujRGzJdYA+R9eBAuDLsatbtKtl4F
zkgRyOg31/+Cw7H8e30iLrPIFlWN1qjHrjgOyIs5AQ/hgxLvLir3hEUV2Z3MRsMt
jH2x9SG91PEM046gfPnc9gMGHjMTg1qvaKcLQP5UzpEYPLror2X4P5uXxaP0LIZR
zWmkw1RF7FOD7PfB5v94M5274XYxW2W4uKGd7QGnUZROSvSYkGiWDp1JhqXwfDz8
A0enITGXnoEkAFvvjiCqh64P1hIeMorj36pgL19oWZD6YrzSWHUz1F00juyuOfQs
qm6hvrDTqNpHNZ015fOURza1SkCvi9GFmNUPoVgwggPPMIICt6ADAgECAhM3QQV5
7XV/QqmiXDr0+GrOmqnXMA0GCSqGSIb3DQEBDQUAMFUxDTALBgNVBAoTBElFVEYx
ETAPBgNVBAsTCExBTVBTIFdHMTEwLwYDVQQDEyhTYW1wbGUgTEFNUFMgUlNBIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MCAXDTE5MTEyMDA2NTQxOFoYDzIwNTIwOTI3
MDY1NDE4WjA7MQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBXRzEXMBUG
A1UEAxMOQWxpY2UgTG92ZWxhY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC09InoWDgWPk2af0+StijSNOR8K/hN8D+l078oullsk4ASvSwjsCNo7sHU
a4xQUl5JO6VqY18LANwORjrc9BaX4MguzsbFXBe6uFh1mVpXmFxSpUByQ+950MFz
/evPgP96wV+z4TtAwW2Z34rTiz4DxMI07XYNFUEOls/gkUP2GxzymsO2kaYWTut3
SryCqeHEFbZFkB4urMk4xrIJC3CzWruS2Q0FHbBlfkgKN5wXVgkWFfiOucfCn+IQ
saqpo1d3f9jSkbtAV5w3vzfog8919MxKI9H6l4KuElnAtJ7BtZcsl7dUy9u9COgE
ykRiVokFQgqQ7XNDU+r3SeOWwks7AgMBAAGjga8wgawwDAYDVR0TAQH/BAIwADAX
BgNVHSAEEDAOMAwGCmCGSAFlAwIBMAEwHgYDVR0RBBcwFYETYWxpY2VAc21pbWUu
ZXhhbXBsZTATBgNVHSUEDDAKBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBsAwHQYD
VR0OBBYEFLv2zLItHQYSHJeuKWqQENMgZmZzMB8GA1UdIwQYMBaAFJEwjnwHFwyn
8QkoZTYaZxxodvRZMA0GCSqGSIb3DQEBDQUAA4IBAQBziaI2p86poGkjd/4KkkOH
G25nY/0eNARD6/oF0/sYonX2doizcGMk53riugAocCn5zbzhW/JVdYn30UxfyrZl
RAzEf7GHqgB/NyjOad3pdpVYeDh4ciNKjbs+aEoTWgAkoqENt1sRxlcvb7HVX524
bKZa1oPTUNlm6QpivtqDIdqGJdGf8L1zLfXBuo2zL3HR+M9CDr4Opq2JCkzP0Qhp
7poIccGE6I9Tsg+RrOA9iCQsPn1+Tg8YedjGzUWF07rNmT0TzPCVzUAuBlr+JJtz
OKypyQ3eoZ6EPazXqMyHAVcsm0GI364IOA0b8PSrJNtjh+AqJ5QfH+0e7NSzNnEm
MYICADCCAfwCAQEwbDBVMQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBX
RzExMC8GA1UEAxMoU2FtcGxlIExBTVBTIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNzA3MDJa
MC8GCSqGSIb3DQEJBDEiBCAHedgXF/1PPCnjTbv4CNkHl6SU0FJSW9ykndUZcVnS
czANBgkqhkiG9w0BAQEFAASCAQCYePlJ3K4FtJC/4snTsO8l+p0qEkpFh4swjQTG
WUhZHrdzb4kvHTCaoH5ShpVxZ4FOp1InabzulsB1P9m5xDvZveUMaCiC/qgSS+st
KdklsWANoTgTlAAGs9og6Wp5Nq/evf8XIYdQV0ZXavzASl/yylz2uHTpW1ETxTlZ
fkgSqb8X/zRaVGoai20aVbmsIJFrVPIlkpgh+r8tbJOm4791cCU/8lIdreynoUKq
Bsa2Y/uhoez/pldX/5A7Rv+JX2vdt71C2BZAk4166wvDhhlHf9pVCWXdKXSh99c6
Do1TzpnakOm4bKSzPMXTrz1p5GcfDzO94kbNImkcdr8yAdcB

--a64--

S/MIME Signed-Only signedData over a Complex Message, Legacy RFC 8551 Header Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the legacy RFC 8551 Header Protection (RFC8551HP) scheme.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 5696 bytes
 ┴ (unwraps to)
 └┬╴message/rfc822 1660 bytes
  └┬╴multipart/mixed 1612 bytes
   ├┬╴multipart/alternative 974 bytes
   │├─╴text/plain 296 bytes
   │└─╴text/html 394 bytes
   └─╴image/png inline 232 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"
Subject: smime-one-part-complex-rfc8551hp
Message-ID: <smime-one-part-complex-rfc8551hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:26:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 5568 characters]
KTaTKY4sz4qH+3UWjytqrEisWQW0JkuzVOa0dg4=

S/MIME Signed-Only signedData over a Complex Message, Legacy RFC 8551 Header Protection, Unwrapped
The S/MIME signed-data layer unwraps to:

MIME-Version: 1.0
Content-Type: message/rfc822

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="fcc"
Subject: smime-one-part-complex-rfc8551hp
Message-ID: <smime-one-part-complex-rfc8551hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:26:02 -0500
User-Agent: Sample MUA Version 1.0

--fcc
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0f8"

--0f8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-one-part-complex-rfc8551hp
message.

This is a signed-only S/MIME message via PKCS#7 signedData.  The
payload is a multipart/alternative message with an inline
image/png attachment. It uses the legacy RFC 8551 Header
Protection (RFC8551HP) scheme.

--
Alice
alice@smime.example
--0f8
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-one-part-complex-rfc8551hp</b>
message.</p>
<p>This is a signed-only S/MIME message via PKCS#7 signedData.  The
payload is a multipart/alternative message with an inline
image/png attachment. It uses the legacy RFC 8551 Header
Protection (RFC8551HP) scheme.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--0f8--

--fcc
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--fcc--

S/MIME Signed-Only multipart/signed over a Complex Message, Legacy RFC 8551 Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses the legacy RFC 8551 Header Protection (RFC8551HP) scheme.
It has the following structure:

└┬╴multipart/signed 5624 bytes
 ├┬╴message/rfc822 1718 bytes
 │└┬╴multipart/mixed 1670 bytes
 │ ├┬╴multipart/alternative 1030 bytes
 │ │├─╴text/plain 324 bytes
 │ │└─╴text/html 422 bytes
 │ └─╴image/png inline 232 bytes
 └─╴application/pkcs7-signature [smime.p7s] 3429 bytes

Its contents are:

MIME-Version: 1.0
Content-Type: multipart/signed;
 protocol="application/pkcs7-signature"; boundary="740";
 micalg="sha-256"
Subject: smime-multipart-complex-rfc8551hp
Message-ID: <smime-multipart-complex-rfc8551hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:27:02 -0500
User-Agent: Sample MUA Version 1.0

--740
MIME-Version: 1.0
Content-Type: message/rfc822

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="cf8"
Subject: smime-multipart-complex-rfc8551hp
Message-ID: <smime-multipart-complex-rfc8551hp@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:27:02 -0500
User-Agent: Sample MUA Version 1.0

--cf8
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="e8a"

--e8a
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-multipart-complex-rfc8551hp
message.

This is a signed-only S/MIME message via PKCS#7 detached
signature (multipart/signed).  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the legacy RFC 8551 Header Protection
(RFC8551HP) scheme.

--
Alice
alice@smime.example
--e8a
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-multipart-complex-rfc8551hp</b>
message.</p>
<p>This is a signed-only S/MIME message via PKCS#7 detached
signature (multipart/signed).  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the legacy RFC 8551 Header Protection
(RFC8551HP) scheme.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--e8a--

--cf8
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--cf8--

--740
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature; name="smime.p7s"

MIIJ4AYJKoZIhvcNAQcCoIIJ0TCCCc0CAQExDTALBglghkgBZQMEAgEwCwYJKoZI
hvcNAQcBoIIHpjCCA88wggK3oAMCAQICEw8tJb0ROZdKzkJUh6HuPTQGirQwDQYJ
KoZIhvcNAQENBQAwVTENMAsGA1UEChMESUVURjERMA8GA1UECxMITEFNUFMgV0cx
MTAvBgNVBAMTKFNhbXBsZSBMQU1QUyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwIBcNMTkxMTIwMDY1NDE4WhgPMjA1MjA5MjcwNjU0MThaMDsxDTALBgNVBAoT
BElFVEYxETAPBgNVBAsTCExBTVBTIFdHMRcwFQYDVQQDEw5BbGljZSBMb3ZlbGFj
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqVKfqLwaLjj+gBUCfk
acKTg8cc2OtJ9ZSed6U3jUoiZVpMLcP3MUKtLeLg9r1mAfIDlB/wlbdmadXPmrsz
yidmbuZmOpB5voVQfiLYYy3iOx7YOqzXrl6udP07k0sV+UdSNRFxrfKeoQEFXgOa
Gdmnx4OG/e3p1fIKM0dPzZLoOAJF5m5O0xzXPL74zFCWp2f1ZkuE4A6l41koaZXC
N5XL7wWTLMLeNf9Byb5ksKqUuqEHAMd1nmoNMgjY9VfVfcrv9w43GG8FtpSX+TWz
B2zNS2OF+XIVnzRG5DeoULq8v88Z5bLpIJ/nx26r8A4SSwIBaVv4wPxAf1iPsIVK
arUCAwEAAaOBrzCBrDAMBgNVHRMBAf8EAjAAMBcGA1UdIAQQMA4wDAYKYIZIAWUD
AgEwATAeBgNVHREEFzAVgRNhbGljZUBzbWltZS5leGFtcGxlMBMGA1UdJQQMMAoG
CCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIFIDAdBgNVHQ4EFgQUolNB1UQ8gCkVfAEj
8OeOr83zdw8wHwYDVR0jBBgwFoAUkTCOfAcXDKfxCShlNhpnHGh29FkwDQYJKoZI
hvcNAQENBQADggEBAIFJeKCcsTKcFqQMpTryujRGzJdYA+R9eBAuDLsatbtKtl4F
zkgRyOg31/+Cw7H8e30iLrPIFlWN1qjHrjgOyIs5AQ/hgxLvLir3hEUV2Z3MRsMt
jH2x9SG91PEM046gfPnc9gMGHjMTg1qvaKcLQP5UzpEYPLror2X4P5uXxaP0LIZR
zWmkw1RF7FOD7PfB5v94M5274XYxW2W4uKGd7QGnUZROSvSYkGiWDp1JhqXwfDz8
A0enITGXnoEkAFvvjiCqh64P1hIeMorj36pgL19oWZD6YrzSWHUz1F00juyuOfQs
qm6hvrDTqNpHNZ015fOURza1SkCvi9GFmNUPoVgwggPPMIICt6ADAgECAhM3QQV5
7XV/QqmiXDr0+GrOmqnXMA0GCSqGSIb3DQEBDQUAMFUxDTALBgNVBAoTBElFVEYx
ETAPBgNVBAsTCExBTVBTIFdHMTEwLwYDVQQDEyhTYW1wbGUgTEFNUFMgUlNBIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MCAXDTE5MTEyMDA2NTQxOFoYDzIwNTIwOTI3
MDY1NDE4WjA7MQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBXRzEXMBUG
A1UEAxMOQWxpY2UgTG92ZWxhY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC09InoWDgWPk2af0+StijSNOR8K/hN8D+l078oullsk4ASvSwjsCNo7sHU
a4xQUl5JO6VqY18LANwORjrc9BaX4MguzsbFXBe6uFh1mVpXmFxSpUByQ+950MFz
/evPgP96wV+z4TtAwW2Z34rTiz4DxMI07XYNFUEOls/gkUP2GxzymsO2kaYWTut3
SryCqeHEFbZFkB4urMk4xrIJC3CzWruS2Q0FHbBlfkgKN5wXVgkWFfiOucfCn+IQ
saqpo1d3f9jSkbtAV5w3vzfog8919MxKI9H6l4KuElnAtJ7BtZcsl7dUy9u9COgE
ykRiVokFQgqQ7XNDU+r3SeOWwks7AgMBAAGjga8wgawwDAYDVR0TAQH/BAIwADAX
BgNVHSAEEDAOMAwGCmCGSAFlAwIBMAEwHgYDVR0RBBcwFYETYWxpY2VAc21pbWUu
ZXhhbXBsZTATBgNVHSUEDDAKBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBsAwHQYD
VR0OBBYEFLv2zLItHQYSHJeuKWqQENMgZmZzMB8GA1UdIwQYMBaAFJEwjnwHFwyn
8QkoZTYaZxxodvRZMA0GCSqGSIb3DQEBDQUAA4IBAQBziaI2p86poGkjd/4KkkOH
G25nY/0eNARD6/oF0/sYonX2doizcGMk53riugAocCn5zbzhW/JVdYn30UxfyrZl
RAzEf7GHqgB/NyjOad3pdpVYeDh4ciNKjbs+aEoTWgAkoqENt1sRxlcvb7HVX524
bKZa1oPTUNlm6QpivtqDIdqGJdGf8L1zLfXBuo2zL3HR+M9CDr4Opq2JCkzP0Qhp
7poIccGE6I9Tsg+RrOA9iCQsPn1+Tg8YedjGzUWF07rNmT0TzPCVzUAuBlr+JJtz
OKypyQ3eoZ6EPazXqMyHAVcsm0GI364IOA0b8PSrJNtjh+AqJ5QfH+0e7NSzNnEm
MYICADCCAfwCAQEwbDBVMQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBX
RzExMC8GA1UEAxMoU2FtcGxlIExBTVBTIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNzI3MDJa
MC8GCSqGSIb3DQEJBDEiBCA9qnCv8hrAl02HDXOOfVNCH7ucDtJ3vYdKv0vdCnWz
SDANBgkqhkiG9w0BAQEFAASCAQBp4hNammJHK5hpd7ha6lzKahf9hoZZS6TPNUCD
plGKSjV4XN7pLxDu3wXAuzon2zV0FxeA1MG6gZgdSBy/5nGivTc/NBOmXJtlNOUV
6b+IiQ1ZgJcWG6R2Pi0bE+NfadPhxvekgmCNTNl0jHQkXn+ABstolOZ+0QnY7TPe
6JoT6HHamKbV0L1/gkEEQtSvOkaDaZllA+if+Qkb6xus1QA3FGzScPpcryTvupsO
wNIlNwiRTT1Kvk7uMxJkWTvfZnWh2UOh7lJAkXbRfMwXwmnVnVooCFHWWpUBVPnn
URqYcZhz+4DJc9iim5CqXRZzIF6t6fioS8lCBalaWRy4AaEJ

--740--

Signed-and-Encrypted Messages
These messages are signed and encrypted. They use PKCS#7 signedData inside envelopedData, with different Header Protection schemes and different Header Confidentiality Policies.
S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from RFC 9788 with the hcp_baseline Header Confidentiality Policy.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 7825 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 4786 bytes
  ┴ (unwraps to)
  └─╴text/plain 330 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-hp-baseline@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:09:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 7680 characters]
aXylZnqk5kEiwW3eNjoh0Q==

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_baseline, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 4608 characters]
eh0Hs/LLI6jCJ82HDBCfgGfbJ8Lfqdk=

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_baseline, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-baseline
Message-ID: <smime-signed-enc-hp-baseline@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:09:02 -0500
User-Agent: Sample MUA Version 1.0
HP-Outer: Subject: [...]
HP-Outer: Message-ID: <smime-signed-enc-hp-baseline@example>
HP-Outer: From: Alice <alice@smime.example>
HP-Outer: To: Bob <bob@smime.example>
HP-Outer: Date: Sat, 20 Feb 2021 10:09:02 -0500
HP-Outer: User-Agent: Sample MUA Version 1.0
Content-Type: text/plain; charset="utf-8"; hp="cipher"

This is the
smime-signed-enc-hp-baseline
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a text/plain
message. It uses the Header Protection scheme from RFC 9788 with
the `hcp_baseline` Header Confidentiality Policy.

--
Alice
alice@smime.example

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_baseline (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from RFC 9788 with the hcp_baseline Header Confidentiality Policy with a "Legacy Display" element.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 8085 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 4972 bytes
  ┴ (unwraps to)
  └─╴text/plain 418 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-hp-baseline-legacy@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:10:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 7936 characters]
oOAsZzzqd5R1io5ABgZD5A==

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_baseline (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 4800 characters]
4RtIRPzk8ehj5ko6LULT

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_baseline (+ Legacy Display), Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-baseline-legacy
Message-ID: <smime-signed-enc-hp-baseline-legacy@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:10:02 -0500
User-Agent: Sample MUA Version 1.0
HP-Outer: Subject: [...]
HP-Outer:
 Message-ID: <smime-signed-enc-hp-baseline-legacy@example>
HP-Outer: From: Alice <alice@smime.example>
HP-Outer: To: Bob <bob@smime.example>
HP-Outer: Date: Sat, 20 Feb 2021 10:10:02 -0500
HP-Outer: User-Agent: Sample MUA Version 1.0
Content-Type: text/plain; charset="utf-8";
 hp-legacy-display="1"; hp="cipher"

Subject: smime-signed-enc-hp-baseline-legacy

This is the
smime-signed-enc-hp-baseline-legacy
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a text/plain
message. It uses the Header Protection scheme from RFC 9788 with
the `hcp_baseline` Header Confidentiality Policy with a "Legacy
Display" element.

--
Alice
alice@smime.example

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_shy
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from RFC 9788 with the hcp_shy Header Confidentiality Policy.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 7760 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 4732 bytes
  ┴ (unwraps to)
  └─╴text/plain 320 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-hp-shy@example>
From: alice@smime.example
To: bob@smime.example
Date: Sat, 20 Feb 2021 15:12:02 +0000
User-Agent: Sample MUA Version 1.0

[encoded data, 7616 characters]
oJQBOTOwY6Cl1c77GnYyjg==

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_shy, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 4544 characters]
fTDI2hVSCHWx/92NDZXQlak7Te6MFWpluHV8QLwn/Xo=

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_shy, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-shy
Message-ID: <smime-signed-enc-hp-shy@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:12:02 -0500
User-Agent: Sample MUA Version 1.0
HP-Outer: Subject: [...]
HP-Outer: Message-ID: <smime-signed-enc-hp-shy@example>
HP-Outer: From: alice@smime.example
HP-Outer: To: bob@smime.example
HP-Outer: Date: Sat, 20 Feb 2021 15:12:02 +0000
HP-Outer: User-Agent: Sample MUA Version 1.0
Content-Type: text/plain; charset="utf-8"; hp="cipher"

This is the
smime-signed-enc-hp-shy
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a text/plain
message. It uses the Header Protection scheme from RFC 9788 with
the `hcp_shy` Header Confidentiality Policy.

--
Alice
alice@smime.example

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_shy (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from RFC 9788 with the hcp_shy Header Confidentiality Policy with a "Legacy Display" element.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 8190 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 5050 bytes
  ┴ (unwraps to)
  └─╴text/plain 506 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-hp-shy-legacy@example>
From: alice@smime.example
To: bob@smime.example
Date: Sat, 20 Feb 2021 15:13:02 +0000
User-Agent: Sample MUA Version 1.0

[encoded data, 8064 characters]

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_shy (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 4864 characters]
veiRr2vhYuXwo3pR+NzQGx3eaqOnksSP

S/MIME Signed-and-Encrypted over a Simple Message, Header Protection with hcp_shy (+ Legacy Display), Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-shy-legacy
Message-ID: <smime-signed-enc-hp-shy-legacy@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:13:02 -0500
User-Agent: Sample MUA Version 1.0
HP-Outer: Subject: [...]
HP-Outer: Message-ID: <smime-signed-enc-hp-shy-legacy@example>
HP-Outer: From: alice@smime.example
HP-Outer: To: bob@smime.example
HP-Outer: Date: Sat, 20 Feb 2021 15:13:02 +0000
HP-Outer: User-Agent: Sample MUA Version 1.0
Content-Type: text/plain; charset="utf-8";
 hp-legacy-display="1"; hp="cipher"

Subject: smime-signed-enc-hp-shy-legacy
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:13:02 -0500

This is the
smime-signed-enc-hp-shy-legacy
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a text/plain
message. It uses the Header Protection scheme from RFC 9788 with
the `hcp_shy` Header Confidentiality Policy with a "Legacy
Display" element.

--
Alice
alice@smime.example

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from RFC 9788 with the hcp_baseline Header Confidentiality Policy.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 8300 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 5136 bytes
  ┴ (unwraps to)
  └─╴text/plain 336 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-hp-baseline-reply@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:15:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-hp-baseline@example>
References: <smime-signed-enc-hp-baseline@example>

[encoded data, 8128 characters]
A7Ihrk0TXY6pECERvfrAhWhVQsxrBQqND3Fbc2Nk6vc=

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_baseline, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 4928 characters]
qwji+i7VzeP6sQ1Jyt4vpv4R2p9stcSEUpFMRQhqNfHiJd0kZLYo

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_baseline, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-baseline-reply
Message-ID: <smime-signed-enc-hp-baseline-reply@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:15:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-hp-baseline@example>
References: <smime-signed-enc-hp-baseline@example>
HP-Outer: Subject: [...]
HP-Outer:
 Message-ID: <smime-signed-enc-hp-baseline-reply@example>
HP-Outer: From: Alice <alice@smime.example>
HP-Outer: To: Bob <bob@smime.example>
HP-Outer: Date: Sat, 20 Feb 2021 10:15:02 -0500
HP-Outer: User-Agent: Sample MUA Version 1.0
HP-Outer: In-Reply-To: <smime-signed-enc-hp-baseline@example>
HP-Outer: References: <smime-signed-enc-hp-baseline@example>
Content-Type: text/plain; charset="utf-8"; hp="cipher"

This is the
smime-signed-enc-hp-baseline-reply
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a text/plain
message. It uses the Header Protection scheme from RFC 9788 with
the `hcp_baseline` Header Confidentiality Policy.

--
Alice
alice@smime.example

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_baseline (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from RFC 9788 with the hcp_baseline Header Confidentiality Policy with a "Legacy Display" element.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 8625 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 5376 bytes
  ┴ (unwraps to)
  └─╴text/plain 430 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-hp-baseline-legacy-reply@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:16:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-hp-baseline-legacy@example>
References: <smime-signed-enc-hp-baseline-legacy@example>

[encoded data, 8448 characters]
yg/AjedixIkUNA5CfMErF/h1EV+zEux7jyQGdVQ7xJI=

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_baseline (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 5184 characters]
wd7sRi7PdwAgwUXiOuso3yAoqQ==

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_baseline (+ Legacy Display), Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-baseline-legacy-reply
Message-ID: <smime-signed-enc-hp-baseline-legacy-reply@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:16:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-hp-baseline-legacy@example>
References: <smime-signed-enc-hp-baseline-legacy@example>
HP-Outer: Subject: [...]
HP-Outer:
 Message-ID: <smime-signed-enc-hp-baseline-legacy-reply@example>
HP-Outer: From: Alice <alice@smime.example>
HP-Outer: To: Bob <bob@smime.example>
HP-Outer: Date: Sat, 20 Feb 2021 10:16:02 -0500
HP-Outer: User-Agent: Sample MUA Version 1.0
HP-Outer:
 In-Reply-To: <smime-signed-enc-hp-baseline-legacy@example>
HP-Outer:
 References: <smime-signed-enc-hp-baseline-legacy@example>
Content-Type: text/plain; charset="utf-8";
 hp-legacy-display="1"; hp="cipher"

Subject: smime-signed-enc-hp-baseline-legacy-reply

This is the
smime-signed-enc-hp-baseline-legacy-reply
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a text/plain
message. It uses the Header Protection scheme from RFC 9788 with
the `hcp_baseline` Header Confidentiality Policy with a "Legacy
Display" element.

--
Alice
alice@smime.example

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_shy
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from RFC 9788 with the hcp_shy Header Confidentiality Policy.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 8190 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 5054 bytes
  ┴ (unwraps to)
  └─╴text/plain 326 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-hp-shy-reply@example>
From: alice@smime.example
To: bob@smime.example
Date: Sat, 20 Feb 2021 15:18:02 +0000
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-hp-shy@example>
References: <smime-signed-enc-hp-shy@example>

[encoded data, 8064 characters]

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_shy, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 4864 characters]
237SKEh0m/haavxKarioAGkbzlAGbNElyX0=

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_shy, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-shy-reply
Message-ID: <smime-signed-enc-hp-shy-reply@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:18:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-hp-shy@example>
References: <smime-signed-enc-hp-shy@example>
HP-Outer: Subject: [...]
HP-Outer: Message-ID: <smime-signed-enc-hp-shy-reply@example>
HP-Outer: From: alice@smime.example
HP-Outer: To: bob@smime.example
HP-Outer: Date: Sat, 20 Feb 2021 15:18:02 +0000
HP-Outer: User-Agent: Sample MUA Version 1.0
HP-Outer: In-Reply-To: <smime-signed-enc-hp-shy@example>
HP-Outer: References: <smime-signed-enc-hp-shy@example>
Content-Type: text/plain; charset="utf-8"; hp="cipher"

This is the
smime-signed-enc-hp-shy-reply
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a text/plain
message. It uses the Header Protection scheme from RFC 9788 with
the `hcp_shy` Header Confidentiality Policy.

--
Alice
alice@smime.example

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_shy (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from RFC 9788 with the hcp_shy Header Confidentiality Policy with a "Legacy Display" element.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 8690 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 5422 bytes
  ┴ (unwraps to)
  └─╴text/plain 518 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-hp-shy-legacy-reply@example>
From: alice@smime.example
To: bob@smime.example
Date: Sat, 20 Feb 2021 15:19:02 +0000
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-hp-shy-legacy@example>
References: <smime-signed-enc-hp-shy-legacy@example>

[encoded data, 8512 characters]
51ecm3eKdxurHuZKq/0LMFykxJH0RJyh1SDLwb3eePI=

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_shy (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 5248 characters]
TucFUmr6

S/MIME Signed-and-Encrypted Reply over a Simple Message, Header Protection with hcp_shy (+ Legacy Display), Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-shy-legacy-reply
Message-ID: <smime-signed-enc-hp-shy-legacy-reply@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:19:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-hp-shy-legacy@example>
References: <smime-signed-enc-hp-shy-legacy@example>
HP-Outer: Subject: [...]
HP-Outer:
 Message-ID: <smime-signed-enc-hp-shy-legacy-reply@example>
HP-Outer: From: alice@smime.example
HP-Outer: To: bob@smime.example
HP-Outer: Date: Sat, 20 Feb 2021 15:19:02 +0000
HP-Outer: User-Agent: Sample MUA Version 1.0
HP-Outer: In-Reply-To: <smime-signed-enc-hp-shy-legacy@example>
HP-Outer: References: <smime-signed-enc-hp-shy-legacy@example>
Content-Type: text/plain; charset="utf-8";
 hp-legacy-display="1"; hp="cipher"

Subject: smime-signed-enc-hp-shy-legacy-reply
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:19:02 -0500

This is the
smime-signed-enc-hp-shy-legacy-reply
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a text/plain
message. It uses the Header Protection scheme from RFC 9788 with
the `hcp_shy` Header Confidentiality Policy with a "Legacy
Display" element.

--
Alice
alice@smime.example

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Header Protection scheme from RFC 9788 with the hcp_baseline Header Confidentiality Policy.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 10035 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 6416 bytes
  ┴ (unwraps to)
  └┬╴multipart/mixed 2054 bytes
   ├┬╴multipart/alternative 1126 bytes
   │├─╴text/plain 384 bytes
   │└─╴text/html 479 bytes
   └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-complex-hp-baseline@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:09:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 9856 characters]
XGazzMVR4ksU8jkHPdw1nA==

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_baseline, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 6208 characters]
ybK5q4kRvQ==

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_baseline, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-baseline
Message-ID: <smime-signed-enc-complex-hp-baseline@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:09:02 -0500
User-Agent: Sample MUA Version 1.0
HP-Outer: Subject: [...]
HP-Outer:
 Message-ID: <smime-signed-enc-complex-hp-baseline@example>
HP-Outer: From: Alice <alice@smime.example>
HP-Outer: To: Bob <bob@smime.example>
HP-Outer: Date: Sat, 20 Feb 2021 12:09:02 -0500
HP-Outer: User-Agent: Sample MUA Version 1.0
Content-Type: multipart/mixed; boundary="3a3"; hp="cipher"

--3a3
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="f31"

--f31
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-signed-enc-complex-hp-baseline
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_baseline` Header Confidentiality Policy.

--
Alice
alice@smime.example
--f31
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-signed-enc-complex-hp-baseline</b>
message.</p>
<p>This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_baseline` Header Confidentiality Policy.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--f31--

--3a3
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--3a3--

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_baseline (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Header Protection scheme from RFC 9788 with the hcp_baseline Header Confidentiality Policy with a "Legacy Display" element.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 10640 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 6870 bytes
  ┴ (unwraps to)
  └┬╴multipart/mixed 2373 bytes
   ├┬╴multipart/alternative 1423 bytes
   │├─╴text/plain 480 bytes
   │└─╴text/html 640 bytes
   └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID:
 <smime-signed-enc-complex-hp-baseline-legacy@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:10:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 10432 characters]
X20oNkEZ4yhYoiSOTp/yfWOphJ9iDxfXO0RVHSrO2Aw=

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_baseline (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 6656 characters]
8g==

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_baseline (+ Legacy Display), Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-baseline-legacy
Message-ID:
 <smime-signed-enc-complex-hp-baseline-legacy@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:10:02 -0500
User-Agent: Sample MUA Version 1.0
HP-Outer: Subject: [...]
HP-Outer: Message-ID:
 <smime-signed-enc-complex-hp-baseline-legacy@example>
HP-Outer: From: Alice <alice@smime.example>
HP-Outer: To: Bob <bob@smime.example>
HP-Outer: Date: Sat, 20 Feb 2021 12:10:02 -0500
HP-Outer: User-Agent: Sample MUA Version 1.0
Content-Type: multipart/mixed; boundary="3c5"; hp="cipher"

--3c5
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="af3"

--af3
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii";
 hp-legacy-display="1"

Subject: smime-signed-enc-complex-hp-baseline-legacy

This is the
smime-signed-enc-complex-hp-baseline-legacy
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_baseline` Header Confidentiality Policy with a
"Legacy Display" element.

--
Alice
alice@smime.example
--af3
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="us-ascii";
 hp-legacy-display="1"

<html><head><title></title></head><body>
<div class="header-protection-legacy-display">
<pre>
Subject: smime-signed-enc-complex-hp-baseline-legacy
</pre>
</div><p>This is the
<b>smime-signed-enc-complex-hp-baseline-legacy</b>
message.</p>
<p>This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_baseline` Header Confidentiality Policy with a
"Legacy Display" element.</p>
<p><tt>-- <br>Alice<br>alice@smime.example</tt></p></body></html>
--af3--

--3c5
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--3c5--

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_shy
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Header Protection scheme from RFC 9788 with the hcp_shy Header Confidentiality Policy.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 9945 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 6346 bytes
  ┴ (unwraps to)
  └┬╴multipart/mixed 2005 bytes
   ├┬╴multipart/alternative 1106 bytes
   │├─╴text/plain 374 bytes
   │└─╴text/html 469 bytes
   └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-complex-hp-shy@example>
From: alice@smime.example
To: bob@smime.example
Date: Sat, 20 Feb 2021 17:12:02 +0000
User-Agent: Sample MUA Version 1.0

[encoded data, 9792 characters]

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_shy, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 6144 characters]
pm6/ag==

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_shy, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-shy
Message-ID: <smime-signed-enc-complex-hp-shy@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:12:02 -0500
User-Agent: Sample MUA Version 1.0
HP-Outer: Subject: [...]
HP-Outer: Message-ID: <smime-signed-enc-complex-hp-shy@example>
HP-Outer: From: alice@smime.example
HP-Outer: To: bob@smime.example
HP-Outer: Date: Sat, 20 Feb 2021 17:12:02 +0000
HP-Outer: User-Agent: Sample MUA Version 1.0
Content-Type: multipart/mixed; boundary="eb4"; hp="cipher"

--eb4
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="aab"

--aab
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-signed-enc-complex-hp-shy
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_shy` Header Confidentiality Policy.

--
Alice
alice@smime.example
--aab
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-signed-enc-complex-hp-shy</b>
message.</p>
<p>This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_shy` Header Confidentiality Policy.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--aab--

--eb4
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--eb4--

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_shy (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Header Protection scheme from RFC 9788 with the hcp_shy Header Confidentiality Policy with a "Legacy Display" element.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 10945 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 7084 bytes
  ┴ (unwraps to)
  └┬╴multipart/mixed 2525 bytes
   ├┬╴multipart/alternative 1605 bytes
   │├─╴text/plain 568 bytes
   │└─╴text/html 740 bytes
   └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-complex-hp-shy-legacy@example>
From: alice@smime.example
To: bob@smime.example
Date: Sat, 20 Feb 2021 17:13:02 +0000
User-Agent: Sample MUA Version 1.0

[encoded data, 10752 characters]
6yI9K5QPEcFa9AErInwKFQ==

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_shy (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 6848 characters]
RzEIRwi/BymNcaR2Bac=

S/MIME Signed-and-Encrypted over a Complex Message, Header Protection with hcp_shy (+ Legacy Display), Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-shy-legacy
Message-ID: <smime-signed-enc-complex-hp-shy-legacy@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:13:02 -0500
User-Agent: Sample MUA Version 1.0
HP-Outer: Subject: [...]
HP-Outer:
 Message-ID: <smime-signed-enc-complex-hp-shy-legacy@example>
HP-Outer: From: alice@smime.example
HP-Outer: To: bob@smime.example
HP-Outer: Date: Sat, 20 Feb 2021 17:13:02 +0000
HP-Outer: User-Agent: Sample MUA Version 1.0
Content-Type: multipart/mixed; boundary="88b"; hp="cipher"

--88b
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="6bd"

--6bd
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii";
 hp-legacy-display="1"

Subject: smime-signed-enc-complex-hp-shy-legacy
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:13:02 -0500

This is the
smime-signed-enc-complex-hp-shy-legacy
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_shy` Header Confidentiality Policy with a "Legacy
Display" element.

--
Alice
alice@smime.example
--6bd
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="us-ascii";
 hp-legacy-display="1"

<html><head><title></title></head><body>
<div class="header-protection-legacy-display">
<pre>
Subject: smime-signed-enc-complex-hp-shy-legacy
From: Alice &lt;alice@smime.example&gt;
To: Bob &lt;bob@smime.example&gt;
Date: Sat, 20 Feb 2021 12:13:02 -0500
</pre>
</div><p>This is the
<b>smime-signed-enc-complex-hp-shy-legacy</b>
message.</p>
<p>This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_shy` Header Confidentiality Policy with a "Legacy
Display" element.</p>
<p><tt>-- <br>Alice<br>alice@smime.example</tt></p></body></html>
--6bd--

--88b
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--88b--

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Header Protection scheme from RFC 9788 with the hcp_baseline Header Confidentiality Policy.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 10575 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 6820 bytes
  ┴ (unwraps to)
  └┬╴multipart/mixed 2343 bytes
   ├┬╴multipart/alternative 1138 bytes
   │├─╴text/plain 390 bytes
   │└─╴text/html 485 bytes
   └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-complex-hp-baseline-reply@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:15:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-complex-hp-baseline@example>
References: <smime-signed-enc-complex-hp-baseline@example>

[encoded data, 10368 characters]
hp7RNLoN0UKRGy5/vX88/DDyoSs2DOi2NZb/A/tqNTQ=

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_baseline, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 6592 characters]
4DJRpBBHfebD7Zg7DtDN

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_baseline, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-baseline-reply
Message-ID: <smime-signed-enc-complex-hp-baseline-reply@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:15:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-complex-hp-baseline@example>
References: <smime-signed-enc-complex-hp-baseline@example>
HP-Outer: Subject: [...]
HP-Outer: Message-ID:
 <smime-signed-enc-complex-hp-baseline-reply@example>
HP-Outer: From: Alice <alice@smime.example>
HP-Outer: To: Bob <bob@smime.example>
HP-Outer: Date: Sat, 20 Feb 2021 12:15:02 -0500
HP-Outer: User-Agent: Sample MUA Version 1.0
HP-Outer:
 In-Reply-To: <smime-signed-enc-complex-hp-baseline@example>
HP-Outer:
 References: <smime-signed-enc-complex-hp-baseline@example>
Content-Type: multipart/mixed; boundary="8ec"; hp="cipher"

--8ec
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="bce"

--bce
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-signed-enc-complex-hp-baseline-reply
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_baseline` Header Confidentiality Policy.

--
Alice
alice@smime.example
--bce
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-signed-enc-complex-hp-baseline-reply</b>
message.</p>
<p>This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_baseline` Header Confidentiality Policy.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--bce--

--8ec
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--8ec--

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_baseline (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Header Protection scheme from RFC 9788 with the hcp_baseline Header Confidentiality Policy with a "Legacy Display" element.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 11205 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 7286 bytes
  ┴ (unwraps to)
  └┬╴multipart/mixed 2668 bytes
   ├┬╴multipart/alternative 1427 bytes
   │├─╴text/plain 482 bytes
   │└─╴text/html 642 bytes
   └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID:
 <smime-signed-enc-complex-hp-baseline-lgc-rpl@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:16:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To:
 <smime-signed-enc-complex-hp-baseline-legacy@example>
References:
 <smime-signed-enc-complex-hp-baseline-legacy@example>

[encoded data, 11008 characters]
GpZyX492SC9oN3dOJZELsQ==

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_baseline (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 7040 characters]
30JDp0rABngu4wItcNYBsHNP

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_baseline (+ Legacy Display), Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-baseline-lgc-rpl
Message-ID:
 <smime-signed-enc-complex-hp-baseline-lgc-rpl@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:16:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To:
 <smime-signed-enc-complex-hp-baseline-legacy@example>
References:
 <smime-signed-enc-complex-hp-baseline-legacy@example>
HP-Outer: Subject: [...]
HP-Outer: Message-ID:
 <smime-signed-enc-complex-hp-baseline-lgc-rpl@example>
HP-Outer: From: Alice <alice@smime.example>
HP-Outer: To: Bob <bob@smime.example>
HP-Outer: Date: Sat, 20 Feb 2021 12:16:02 -0500
HP-Outer: User-Agent: Sample MUA Version 1.0
HP-Outer: In-Reply-To:
 <smime-signed-enc-complex-hp-baseline-legacy@example>
HP-Outer: References:
 <smime-signed-enc-complex-hp-baseline-legacy@example>
Content-Type: multipart/mixed; boundary="bed"; hp="cipher"

--bed
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="828"

--828
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii";
 hp-legacy-display="1"

Subject: smime-signed-enc-complex-hp-baseline-lgc-rpl

This is the
smime-signed-enc-complex-hp-baseline-lgc-rpl
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_baseline` Header Confidentiality Policy with a
"Legacy Display" element.

--
Alice
alice@smime.example
--828
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="us-ascii";
 hp-legacy-display="1"

<html><head><title></title></head><body>
<div class="header-protection-legacy-display">
<pre>
Subject: smime-signed-enc-complex-hp-baseline-lgc-rpl
</pre>
</div><p>This is the
<b>smime-signed-enc-complex-hp-baseline-lgc-rpl</b>
message.</p>
<p>This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_baseline` Header Confidentiality Policy with a
"Legacy Display" element.</p>
<p><tt>-- <br>Alice<br>alice@smime.example</tt></p></body></html>
--828--

--bed
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--bed--

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_shy
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Header Protection scheme from RFC 9788 with the hcp_shy Header Confidentiality Policy.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 10445 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 6720 bytes
  ┴ (unwraps to)
  └┬╴multipart/mixed 2273 bytes
   ├┬╴multipart/alternative 1118 bytes
   │├─╴text/plain 380 bytes
   │└─╴text/html 475 bytes
   └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID: <smime-signed-enc-complex-hp-shy-reply@example>
From: alice@smime.example
To: bob@smime.example
Date: Sat, 20 Feb 2021 17:18:02 +0000
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-complex-hp-shy@example>
References: <smime-signed-enc-complex-hp-shy@example>

[encoded data, 10240 characters]
amhJ49wnRgOUWYkZzyOOaCQqA4xnGl84Dj3tQy0afpE=

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_shy, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 6464 characters]
4flYxBHvYI53lUd/ub1SQMH/+X4zL0sbfb5+idTt10u1pN0Qcb8=

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_shy, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-shy-reply
Message-ID: <smime-signed-enc-complex-hp-shy-reply@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:18:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-complex-hp-shy@example>
References: <smime-signed-enc-complex-hp-shy@example>
HP-Outer: Subject: [...]
HP-Outer:
 Message-ID: <smime-signed-enc-complex-hp-shy-reply@example>
HP-Outer: From: alice@smime.example
HP-Outer: To: bob@smime.example
HP-Outer: Date: Sat, 20 Feb 2021 17:18:02 +0000
HP-Outer: User-Agent: Sample MUA Version 1.0
HP-Outer: In-Reply-To: <smime-signed-enc-complex-hp-shy@example>
HP-Outer: References: <smime-signed-enc-complex-hp-shy@example>
Content-Type: multipart/mixed; boundary="230"; hp="cipher"

--230
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4c8"

--4c8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-signed-enc-complex-hp-shy-reply
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_shy` Header Confidentiality Policy.

--
Alice
alice@smime.example
--4c8
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-signed-enc-complex-hp-shy-reply</b>
message.</p>
<p>This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_shy` Header Confidentiality Policy.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--4c8--

--230
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--230--

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_shy (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Header Protection scheme from RFC 9788 with the hcp_shy Header Confidentiality Policy with a "Legacy Display" element.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 11530 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 7520 bytes
  ┴ (unwraps to)
  └┬╴multipart/mixed 2834 bytes
   ├┬╴multipart/alternative 1629 bytes
   │├─╴text/plain 580 bytes
   │└─╴text/html 752 bytes
   └─╴image/png inline 236 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID:
 <smime-signed-enc-complex-hp-shy-legacy-reply@example>
From: alice@smime.example
To: bob@smime.example
Date: Sat, 20 Feb 2021 17:19:02 +0000
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-complex-hp-shy-legacy@example>
References: <smime-signed-enc-complex-hp-shy-legacy@example>

[encoded data, 11328 characters]
5P6nHYB/zZ7qHM/LPSZdWA==

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_shy (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 7292 characters]

S/MIME Signed-and-Encrypted Reply over a Complex Message, Header Protection with hcp_shy (+ Legacy Display), Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-shy-legacy-reply
Message-ID:
 <smime-signed-enc-complex-hp-shy-legacy-reply@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:19:02 -0500
User-Agent: Sample MUA Version 1.0
In-Reply-To: <smime-signed-enc-complex-hp-shy-legacy@example>
References: <smime-signed-enc-complex-hp-shy-legacy@example>
HP-Outer: Subject: [...]
HP-Outer: Message-ID:
 <smime-signed-enc-complex-hp-shy-legacy-reply@example>
HP-Outer: From: alice@smime.example
HP-Outer: To: bob@smime.example
HP-Outer: Date: Sat, 20 Feb 2021 17:19:02 +0000
HP-Outer: User-Agent: Sample MUA Version 1.0
HP-Outer:
 In-Reply-To: <smime-signed-enc-complex-hp-shy-legacy@example>
HP-Outer:
 References: <smime-signed-enc-complex-hp-shy-legacy@example>
Content-Type: multipart/mixed; boundary="242"; hp="cipher"

--242
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="da7"

--da7
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii";
 hp-legacy-display="1"

Subject: smime-signed-enc-complex-hp-shy-legacy-reply
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:19:02 -0500

This is the
smime-signed-enc-complex-hp-shy-legacy-reply
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_shy` Header Confidentiality Policy with a "Legacy
Display" element.

--
Alice
alice@smime.example
--da7
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="us-ascii";
 hp-legacy-display="1"

<html><head><title></title></head><body>
<div class="header-protection-legacy-display">
<pre>
Subject: smime-signed-enc-complex-hp-shy-legacy-reply
From: Alice &lt;alice@smime.example&gt;
To: Bob &lt;bob@smime.example&gt;
Date: Sat, 20 Feb 2021 12:19:02 -0500
</pre>
</div><p>This is the
<b>smime-signed-enc-complex-hp-shy-legacy-reply</b>
message.</p>
<p>This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from RFC 9788
with the `hcp_shy` Header Confidentiality Policy with a "Legacy
Display" element.</p>
<p><tt>-- <br>Alice<br>alice@smime.example</tt></p></body></html>
--da7--

--242
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--242--

S/MIME Signed-and-Encrypted over a Complex Message, Legacy RFC 8551 Header Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the legacy RFC 8551 Header Protection (RFC8551HP) scheme with the hcp_baseline Header Confidentiality Policy.
It has the following structure:

└┬╴application/pkcs7-mime [smime.p7m] 9580 bytes
 ╧ (decrypts to)
 └┬╴application/pkcs7-mime [smime.p7m] 6082 bytes
  ┴ (unwraps to)
  └┬╴message/rfc822 1876 bytes
   └┬╴multipart/mixed 1828 bytes
    ├┬╴multipart/alternative 1168 bytes
    │├─╴text/plain 393 bytes
    │└─╴text/html 491 bytes
    └─╴image/png inline 232 bytes

Its contents are:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
Subject: [...]
Message-ID:
 <smime-enc-signed-complex-rfc8551hp-baseline@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:28:02 -0500
User-Agent: Sample MUA Version 1.0

[encoded data, 9408 characters]
FYDZOpfnljZ1ywCw30yaeA==

S/MIME Signed-and-Encrypted over a Complex Message, Legacy RFC 8551 Header Protection with hcp_baseline, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part:

Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="signed-data"

[encoded data, 5888 characters]
ES1xMiED

S/MIME Signed-and-Encrypted over a Complex Message, Legacy RFC 8551 Header Protection with hcp_baseline, Decrypted and Unwrapped
The inner signed-data layer unwraps to:

MIME-Version: 1.0
Content-Type: message/rfc822

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="144"
Subject: smime-enc-signed-complex-rfc8551hp-baseline
Message-ID:
 <smime-enc-signed-complex-rfc8551hp-baseline@example>
From: Alice <alice@smime.example>
To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:28:02 -0500
User-Agent: Sample MUA Version 1.0

--144
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="579"

--579
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

This is the
smime-enc-signed-complex-rfc8551hp-baseline
message.

This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the legacy RFC 8551 Header Protection
(RFC8551HP) scheme with the `hcp_baseline` Header
Confidentiality Policy.

--
Alice
alice@smime.example
--579
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body>
<p>This is the
<b>smime-enc-signed-complex-rfc8551hp-baseline</b>
message.</p>
<p>This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData.  The payload is a
multipart/alternative message with an inline image/png
attachment. It uses the legacy RFC 8551 Header Protection
(RFC8551HP) scheme with the `hcp_baseline` Header
Confidentiality Policy.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--579--

--144
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline

iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==

--144--

Composition Examples
This section offers step-by-step examples of message composition.
New Message Composition
A typical MUA composition interface offers the user a place to indicate the message recipients, subject, and content of the message. Consider a composition window filled out by the user like so:
Example Message Composition Interface

Composing

New

Message

Send

To:

Alice

<alice@example.net>

Subject:

Handling

the

Jones

contract

Please

review

and

approve

or

decline

by

Thursday,

it's

critical!

Thanks,

Bob
                  --

Bob

Gonzalez

ACME,

Inc.

 .------------------------------------------------------.
|                 Composing New Message          .----.  |
|          +---------------------------------+  | Send | |
|      To: | Alice <alice@example.net>       |   '----'  |
|          +---------------------------------+---------+ |
| Subject: | Handling the Jones contract               | |
|          +-------------------------------------------+ |
+--------------------------------------------------------+
| Please review and approve or decline by Thursday, it's |
| critical!                                              |
|                                                        |
| Thanks,                                                |
| Bob                                                    |
|                                                        |
| --                                                     |
| Bob Gonzalez                                           |
| ACME, Inc.                                             |
|                                                        |
+--------------------------------------------------------+

When Bob clicks "Send", his MUA generates values for the Message-ID, From, and Date Header Fields and converts the message content into the appropriate format.
Unprotected Message
The resulting message would look something like this if it was sent without cryptographic protections:

Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net>
To: Alice <alice@example.net>
Subject: Handling the Jones contract
Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0

Please review and approve or decline by Thursday, it's critical!

Thanks,
Bob

--
Bob Gonzalez
ACME, Inc.

Encrypted with hcp_baseline and Legacy Display
Now consider the message to be generated if it is to be cryptographically signed and encrypted, using HCP hcp_baseline, and the legacy variable is set.
For each Header Field, Bob's MUA passes its name and value through hcp_baseline. This returns the same value for every Header Field, except that:
hcp_baseline("Subject", "Handling the Jones contract") yields "[...]".
Cryptographic Payload
The Cryptographic Payload that will be signed and then encrypted is very similar to the unprotected message in Appendix D.1.1. Note the addition of:
- the hp="cipher" parameter for the Content-Type
- the appropriate HP-Outer Header Field for Subject
- the hp-legacy-display="1" parameter for the Content-Type
- the Legacy Display Element (the simple pseudo-header and its trailing newline) in the Main Body Part

Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net>
To: Alice <alice@example.net>
Subject: Handling the Jones contract
Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1";
 hp="cipher"
MIME-Version: 1.0
HP-Outer: Date: Wed, 11 Jan 2023 16:08:43 -0500
HP-Outer: From: Bob <bob@example.net>
HP-Outer: To: Alice <alice@example.net>
HP-Outer: Subject: [...]
HP-Outer: Message-ID: <20230111T210843Z.1234@lhp.example>

Subject: Handling the Jones contract

Please review and approve or decline by Thursday, it's critical!

Thanks,
Bob

--
Bob Gonzalez
ACME, Inc.

Outer Header Section
The Cryptographic Payload from Appendix D.1.2.1 is then wrapped in the appropriate Cryptographic Layers. For this example using S/MIME, it is wrapped in an application/pkcs7-mime; smime-type="signed-data" layer, which is in turn wrapped in an application/pkcs7-mime; smime-type="enveloped-data" layer.
Then, an Outer Header Section is applied to the outer MIME object, which looks like this:

Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net>
To: Alice <alice@example.net>
Subject: [...]
Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
MIME-Version: 1.0

Note that the Subject Header Field has been obscured appropriately by hcp_baseline. The output of the CMS enveloping operation is base64 encoded and forms the Body of the message.
Composing a Reply
Next, we consider a typical MUA reply interface, where we see Alice replying to Bob's message from Appendix D.1.
When Alice clicks "Reply" to Bob's signed-and-encrypted message with Header Protection, she might see something like this:
Example Message Reply Interface (Unedited)

Replying

to

Bob

("Handling

the

Jones

Contract")

Send

To:

Bob

<bob@example.net>

Subject:

Re:

Handling

the

Jones

contract

On

Wed,

11

Jan

2023

16:08:43

-0500,

Bob

wrote:
                  >

Please

review

and

approve

or

decline

by

Thursday,
                  >

it's

critical!
                  >
                  >

Thanks,
                  >

Bob
                  >
                  >
                  --
                  >

Bob

Gonzalez
                  >

ACME,

Inc.
                  --

Alice

Jenkins

ACME,

Inc.

 .--------------------------------------------------------.
|  Replying to Bob ("Handling the Jones Contract") .----.  |
|          +-----------------------------------+  | Send | |
|      To: | Bob <bob@example.net>             |   '----'  |
|          +-----------------------------------+---------+ |
| Subject: | Re: Handling the Jones contract             | |
|          +---------------------------------------------+ |
+----------------------------------------------------------+
| On Wed, 11 Jan 2023 16:08:43 -0500, Bob wrote:           |
|                                                          |
| > Please review and approve or decline by Thursday,      |
| > it's critical!                                         |
| >                                                        |
| > Thanks,                                                |
| > Bob                                                    |
| >                                                        |
| > --                                                     |
| > Bob Gonzalez                                           |
| > ACME, Inc.                                             |
|                                                          |
| --                                                       |
| Alice Jenkins                                            |
| ACME, Inc.                                               |
|                                                          |
+----------------------------------------------------------+

Note that because Alice's MUA is aware of Header Protection, it knows what the correct Subject Header Field is, even though it was obscured. It also knows to avoid including the Legacy Display Element in the quoted/attributed text that it includes in the draft reply.
Once Alice has edited the reply message, it might look something like this:
Example Message Reply Interface (Edited)

Replying

to

Bob

("Handling

the

Jones

Contract")

Send

To:

Bob

<bob@example.net>

Subject:

Re:

Handling

the

Jones

contract

On

Wed,

11

Jan

2023

16:08:43

-0500,

Bob

wrote:
                  >

Please

review

and

approve

or

decline

by

Thursday,
                  >

it's

critical!

I'll

get

right

on

it,

Bob!

Regards,

Alice
                  --

Alice

Jenkins

ACME,

Inc.

 .--------------------------------------------------------.
|  Replying to Bob ("Handling the Jones Contract") .----.  |
|          +-----------------------------------+  | Send | |
|      To: | Bob <bob@example.net>             |   '----'  |
|          +-----------------------------------+---------+ |
| Subject: | Re: Handling the Jones contract             | |
|          +---------------------------------------------+ |
+----------------------------------------------------------+
| On Wed, 11 Jan 2023 16:08:43 -0500, Bob wrote:           |
|                                                          |
| > Please review and approve or decline by Thursday,      |
| > it's critical!                                         |
|                                                          |
| I'll get right on it, Bob!                               |
|                                                          |
| Regards,                                                 |
| Alice                                                    |
|                                                          |
| --                                                       |
| Alice Jenkins                                            |
| ACME, Inc.                                               |
|                                                          |
+----------------------------------------------------------+

When Alice clicks "Send", the MUA generates values for the Message-ID, From, and Date Header Fields, populates the In-Reply-To and References Header Fields, and also converts the reply content into the appropriate format.
Unprotected Message
The resulting message would look something like this if it were to be sent without any cryptographic protections:

Date: Wed, 11 Jan 2023 16:48:22 -0500
From: Alice <alice@example.net>
To: Bob <bob@example.net>
Subject: Re: Handling the Jones contract
Message-ID: <20230111T214822Z.5678@lhp.example>
In-Reply-To: <20230111T210843Z.1234@lhp.example>
References: <20230111T210843Z.1234@lhp.example>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0

On Wed, 11 Jan 2023 16:08:43 -0500, Bob wrote:

> Please review and approve or decline by Thursday,
> it's critical!

I'll get right on it, Bob!

Regards,
Alice

--
Alice Jenkins
ACME, Inc.

Of course, this would leak not only the contents of Alice's message but also the contents of Bob's initial message, as well as the Subject Header Field! So Alice's MUA won't do that; it is going to create a signed-and-encrypted message to submit to the network.
Encrypted with hcp_no_confidentiality and Legacy Display
This example assumes that Alice's MUA uses hcp_no_confidentiality, not hcp_baseline. That is, by default, it does not obscure or remove any Header Fields, even when encrypting.
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 message (Appendix D.1.2.1) to determine what to obscure.
When crafting the Cryptographic Payload, its baseline HCP (hcp_no_confidentiality) leaves each field untouched. To uphold the confidentiality of the composer's values when replying, the MUA executes the following steps (for brevity, only Subject and Message-ID/In-Reply-To are shown):
- Extract the referenced Header Fields (see Section 4.2):
  - refouter contains:
    - Date: Wed, 11 Jan 2023 16:08:43 -0500
    - From: Bob <bob@example.net>
    - To: Alice <alice@example.net>
    - Subject: [...]
    - Message-ID: <20230111T210843Z.1234@lhp.example>
  - refprotected contains:
    - Date: Wed, 11 Jan 2023 16:08:43 -0500
    - From: Bob <bob@example.net>
    - To: Alice <alice@example.net>
    - Subject: Handling the Jones contract
    - Message-ID: <20230111T210843Z.1234@lhp.example>
- Apply the response function:
  - respond(refouter) contains:
    - From: Alice <alice@example.net>
    - To: Bob <bob@example.net>
    - Subject: Re: [...]
    - In-Reply-To: <20230111T210843Z.1234@lhp.example>
    - References: <20230111T210843Z.1234@lhp.example>
  - respond(refprotected) contains:
    - From: Alice <alice@example.net>
    - To: Bob <bob@example.net>
    - Subject: Re: Handling the Jones contract
    - In-Reply-To: <20230111T210843Z.1234@lhp.example>
    - References: <20230111T210843Z.1234@lhp.example>
- Compute the ephemeral response_hcp (see Section 6.1):
  - Note that all Header Fields except Subject are the same.
  - confmap contains only ("Subject", "Re: Handling the Jones contract") -> "Re: [...]"
Thus, all Header Fields that were signed are passed through untouched. The reply's Subject is obscured as Subject: Re: [...] if and only if the user does not edit the Subject line from that initially proposed by the MUA's reply interface. If the user edits the Subject line, e.g., to Subject: Re: Handling the Jones contract ASAP, the response_hcp will not obscure it and instead pass it through in the clear.
For stronger header confidentiality, the replying MUA should use a reasonable HCP (not hcp_no_confidentiality). Also recall that the local HCP is applied first and that response_hcp is only applied to what is left unchanged by the local HCP.
Cryptographic Payload
Consequently, the Cryptographic Payload for Alice's reply looks like this:

Date: Wed, 11 Jan 2023 16:48:22 -0500
From: Alice <alice@example.net>
To: Bob <bob@example.net>
Subject: Re: Handling the Jones contract
Message-ID: <20230111T214822Z.5678@lhp.example>
In-Reply-To: <20230111T210843Z.1234@lhp.example>
References: <20230111T210843Z.1234@lhp.example>
Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1";
 hp="cipher"
MIME-Version: 1.0
HP-Outer: Date: Wed, 11 Jan 2023 16:48:22 -0500
HP-Outer: From: Alice <alice@example.net>
HP-Outer: To: Bob <bob@example.net>
HP-Outer: Subject: Re: [...]
HP-Outer: Message-ID: <20230111T214822Z.5678@lhp.example>
HP-Outer: In-Reply-To: <20230111T210843Z.1234@lhp.example>
HP-Outer: References: <20230111T210843Z.1234@lhp.example>

Subject: Re: Handling the Jones contract

On Wed, 11 Jan 2023 16:08:43 -0500, Bob wrote:

> Please review and approve or decline by Thursday,
> it's critical!

I'll get right on it, Bob!

Regards,
Alice

--
Alice Jenkins
ACME, Inc.

Note the following features:
- the hp="cipher" parameter to Content-Type
- the appropriate HP-Outer Header Field for Subject
- the hp-legacy-display="1" parameter for the Content-Type
- the Legacy Display Element (the simple pseudo-header and its trailing newline) in the Main Body Part
Outer Header Section
The Cryptographic Payload from Appendix D.2.2.1 is then wrapped in the appropriate Cryptographic Layers. For this example using S/MIME, it is wrapped in an application/pkcs7-mime; smime-type="signed-data" layer, which is in turn wrapped in an application/pkcs7-mime; smime-type="enveloped-data" layer.
Then, an Outer Header Section is applied to the outer MIME object, which looks like this:

Date: Wed, 11 Jan 2023 16:48:22 -0500
From: Alice <alice@example.net>
To: Bob <bob@example.net>
Subject: Re: [...]
Message-ID: <20230111T214822Z.5678@lhp.example>
In-Reply-To: <20230111T210843Z.1234@lhp.example>
References: <20230111T210843Z.1234@lhp.example>
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m";
 smime-type="enveloped-data"
MIME-Version: 1.0

Note that the Subject Header Field has been obscured appropriately even though hcp_no_confidentiality would not have touched it by default. The output of the CMS enveloping operation is base64 encoded and forms the Body of the message.
Rendering Examples
This section offers example Cryptographic Payloads (the content within the Cryptographic Envelope) that contain Legacy Display Elements.
Example text/plain Cryptographic Payload with Legacy Display Elements
Here is a simple one-part Cryptographic Payload (Header Section and Body) of a message that includes Legacy Display Elements:

Date: Fri, 21 Jan 2022 20:40:48 -0500
From: Alice <alice@example.net>
To: Bob <bob@example.net>
Subject: Dinner plans
Message-ID: <text-plain-legacy-display@lhp.example>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1";
 hp="cipher"
HP-Outer: Date: Fri, 21 Jan 2022 20:40:48 -0500
HP-Outer: From: Alice <alice@example.net>
HP-Outer: To: Bob <bob@example.net>
HP-Outer: Subject: [...]
HP-Outer: Message-ID: <text-plain-legacy-display@lhp.example>

Subject: Dinner plans

Let's meet at Rama's Roti Shop at 8pm and go to the park
from there.

A compatible MUA will recognize the hp-legacy-display="1" parameter and render the Body of the message as:

Let's meet at Rama's Roti Shop at 8pm and go to the park
from there.

A legacy decryption-capable MUA that is unaware of this mechanism will ignore the hp-legacy-display="1" parameter and instead render the Body including the Legacy Display Elements:

Subject: Dinner plans

Let's meet at Rama's Roti Shop at 8pm and go to the park
from there.

Example text/html Cryptographic Payload with Legacy Display Elements
Here is a modern one-part Cryptographic Payload (Header Section and Body) of a message that includes Legacy Display Elements:

Date: Fri, 21 Jan 2022 20:40:48 -0500
From: Alice <alice@example.net>
To: Bob <bob@example.net>
Subject: Dinner plans
Message-ID: <text-html-legacy-display@lhp.example>
MIME-Version: 1.0
Content-Type: text/html; charset="us-ascii"; hp-legacy-display="1";
 hp="cipher"
HP-Outer: Date: Fri, 21 Jan 2022 20:40:48 -0500
HP-Outer: From: Alice <alice@example.net>
HP-Outer: To: Bob <bob@example.net>
HP-Outer: Subject: [...]
HP-Outer: Message-ID: <text-html-legacy-display@lhp.example>

<html><head><title></title></head><body>
<div class="header-protection-legacy-display">
<pre>Subject: Dinner plans</pre>
</div>
<p>
Let's meet at Rama's Roti Shop at 8pm and go to the park
from there.
</p>
</body>
</html>

A compatible MUA will recognize the hp-legacy-display="1" parameter and mask out the Legacy Display div, rendering the Body of the message as a simple paragraph:

Let's meet at Rama's Roti Shop at 8pm and go to the park
from there.

A legacy decryption-capable MUA that is unaware of this mechanism will ignore the hp-legacy-display="1" parameter and instead render the Body including the Legacy Display Elements:

Subject: Dinner plans

Let's meet at Rama's Roti Shop at 8pm and go to the park
from there.

Other Header Protection Schemes
Other Header Protection schemes have been proposed in the past. However, those typically have drawbacks such as sparse implementation, known problems with legacy interoperability (in particular with rendering), lack of clear signaling of composer intent, and/or incomplete cryptographic protections. This section lists such schemes known at the time of the publication of this document out of historical interest.
Original RFC 8551 Header Protection
S/MIME [RFC8551] (as well as its predecessors [RFC5751] and [RFC3851]) defined a form of cryptographic Header Protection that has never reached wide adoption and has significant drawbacks compared to 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 handle such a message.
Pretty Easy Privacy (pEp)
The pretty Easy privacy (pEp) [PEP-GENERAL] project specifies two different MIME schemes that include Header Protection for Signed-and-Encrypted email messages in [PEP-EMAIL]: One scheme -- referred as pEp Email Format 1 (PEF-1) -- is generated towards MUAs not known to be pEp-capable, while the other scheme -- referred as PEF-2 -- is used between MUAs discovered to be compatible with pEp. Signed-only messages are not recommended in pEp.
Although the PEF-2 scheme is only meant to be used between MUAs compatible with PEF-2, a PEF-2 message may end up at an MUA unaware of PEF-2 (in which case, it typically renders badly). This is due to signaling mechanism limitations.
As the PEF-2 scheme is an enhanced variant of the RFC8551HP scheme (with an additional MIME Layer), it is similar to the RFC8551HP scheme (see Section 4.10). The basic PEF-2 MIME structure looks as follows:

A └┬╴multipart/encrypted [Outer Message]
B  ├─╴application/pgp-encrypted
C  └┬╴application/octet-stream inline [Cryptographic Payload]
D   ╧ (decrypts to)
E   └┬╴multipart/mixed
F    ├─╴text/plain
G    ├┬╴message/rfc822
H    │└─╴[Inner Message]
I    └─╴application/pgp-keys

The MIME structure at part H contains the Inner Message to be rendered to the user.
It is possible for a normal MUA to accidentally produce a message that happens to have the same MIME structure as used for PEF-2 messages. Therefore, a PEF-2 message cannot be identified by the MIME structure alone.
The lack of a mechanism comparable to HP-Outer (see Section 2.2) makes it impossible for the recipient of a PEF-2 message to safely determine which Header Fields are confidential or not while forwarding or replying to a message (see Section 6).
Note: As this document is not normative for PEF-2 messages, it does not provide any guidance for handling them. Please see [PEP-EMAIL] for more guidance.
"draft-autocrypt" Protected Headers
[PROTECTED-HEADERS] describes a scheme similar to the Header Protection scheme specified in this document. However, instead of adding Legacy Display Elements to existing MIME parts (see Section 5.2.2), [PROTECTED-HEADERS] suggests injecting a new MIME element "Legacy Display Part", thus modifying the MIME structure of the Cryptographic Payload. These modified Cryptographic Payloads cause significant rendering problems on some common Legacy MUAs.
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 described in [PROTECTED-HEADERS] cannot be cryptographically certain whether the composer intended for the message to be confidential or not. The lack of a mechanism comparable to HP-Outer (see Section 2.2) makes it impossible for the recipient of an encrypted message as described in [PROTECTED-HEADERS] to safely determine which Header Fields are confidential or not while forwarding or replying to a message (see Section 6).
Acknowledgements
Alexander Krotov identified the risk of From address spoofing (see Section 10.1) and helped provide guidance to MUAs.
Thore Göbel identified significant gaps in earlier draft versions of this document and proposed concrete, substantial improvements. Thanks to his contributions, the document is clearer, and the protocols described herein are more useful.
Additionally, the authors would like to thank the following people who have provided helpful comments and suggestions for this document: Berna Alp, Bernhard E. Reiter, Bron Gondwana, Carl Wallace, Claudio Luck, Daniel Huigens, David Wilson, Éric Vyncke, Hernani Marques, juga, Kelly Bristol, Krista Bennett, Lars Rohwedder, Michael StJohns, Nicolas Lidzborski, Orie Steele, Paul Wouters, Peter Yee, Phillip Tao, Robert Williams, Rob Sayre, Rohan Mahy, Roman Danyliw, Russ Housley, Sofia Balicka, Steve Kille, Volker Birk, Warren Kumari, and Wei Chuang.
Authors' Addresses
Daniel Kahn Gillmor
American Civil Liberties Union
125 Broad St.
New York
NY
10004
United States of America
dkg@fifthhorseman.net
Bernie Hoeneisen
pEp Project
Oberer Graben 4
8400
Winterthur
Switzerland
bernie@ietf.hoeneisen.ch
https://pep-project.org/
Alexey Melnikov
Isode Ltd
14 Castle Mews
Hampton, Middlesex
TW12 2NP
United Kingdom
alexey.melnikov@isode.com