rfc9788.original   rfc9788.txt 
LAMPS Working Group D. K. Gillmor Internet Engineering Task Force (IETF) D. K. Gillmor
Internet-Draft American Civil Liberties Union Request for Comments: 9788 American Civil Liberties Union
Updates: 8551 (if approved) B. Hoeneisen Updates: 8551 B. Hoeneisen
Intended status: Standards Track pEp Project Category: Standards Track pEp Project
Expires: 10 July 2025 A. Melnikov ISSN: 2070-1721 A. Melnikov
Isode Ltd Isode Ltd
6 January 2025 May 2025
Header Protection for Cryptographically Protected E-mail Header Protection for Cryptographically Protected Email
draft-ietf-lamps-header-protection-25
Abstract Abstract
S/MIME version 3.1 introduced a mechanism to provide end-to-end S/MIME version 3.1 introduced a mechanism to provide end-to-end
cryptographic protection of e-mail message headers. However, few cryptographic protection of email message headers. However, few
implementations generate messages using this mechanism, and several implementations generate messages using this mechanism, and several
legacy implementations have revealed rendering or security issues legacy implementations have revealed rendering or security issues
when handling such a message. when handling such a message.
This document updates the S/MIME specification (RFC8551) to offer a This document updates the S/MIME specification (RFC 8551) to offer a
different mechanism that provides the same cryptographic protections different mechanism that provides the same cryptographic protections
but with fewer downsides when handled by legacy clients. but with fewer downsides when handled by legacy clients.
Furthermore, it offers more explicit usability, privacy, and security Furthermore, it offers more explicit usability, privacy, and security
guidance for clients when generating or handling e-mail messages with guidance for clients when generating or handling email messages with
cryptographic protection of message headers. cryptographic protection of message headers.
The Header Protection scheme defined here is also applicable to The Header Protection scheme defined here is also applicable to
messages with PGP/MIME cryptographic protections. messages with PGP/MIME (Pretty Good Privacy with MIME) cryptographic
protections.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://dkg.gitlab.io/lamps-header-protection/. Status information
for this document may be found at https://datatracker.ietf.org/doc/
draft-ietf-lamps-header-protection/.
Discussion of this document takes place on the LAMPS Working Group
mailing list (mailto:spasm@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at
https://www.ietf.org/mailman/listinfo/spasm/.
Source for this draft and an issue tracker can be found at
https://gitlab.com/dkg/lamps-header-protection.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 10 July 2025. 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 Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction
1.1. Update to RFC 8551 . . . . . . . . . . . . . . . . . . . 7 1.1. Update to RFC 8551
1.1.1. Problems with RFC 8551 Header Protection . . . . . . 8 1.1.1. Problems with RFC 8551 Header Protection
1.2. Risks of Header Protection for Legacy MUA Recipients . . 9 1.2. Risks of Header Protection for Legacy MUA Recipients
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 10 1.3. Motivation
1.3.1. Backward Compatibility . . . . . . . . . . . . . . . 10 1.3.1. Backward Compatibility
1.3.2. Deliverability . . . . . . . . . . . . . . . . . . . 11 1.3.2. Deliverability
1.4. Other Protocols to Protect E-Mail Header Fields . . . . . 11 1.4. Other Protocols to Protect Email Header Fields
1.5. Applicability to PGP/MIME . . . . . . . . . . . . . . . . 12 1.5. Applicability to PGP/MIME
1.6. Requirements Language . . . . . . . . . . . . . . . . . . 12 1.6. Requirements Language
1.7. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.7. Terms
1.8. Document Scope . . . . . . . . . . . . . . . . . . . . . 14 1.8. Document Scope
1.8.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 14 1.8.1. In Scope
1.8.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 15 1.8.2. Out of Scope
1.9. Example . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.9. Example
2. Internet Message Format Extensions
2. Internet Message Format Extensions . . . . . . . . . . . . . 18 2.1. Content-Type Parameters
2.1. Content-Type parameters . . . . . . . . . . . . . . . . . 18 2.1.1. Content-Type Parameter: hp
2.1.1. Content-Type parameter: hp . . . . . . . . . . . . . 18 2.1.2. Content-Type Parameter: hp-legacy-display
2.1.2. Content-Type parameter: hp-legacy-display . . . . . . 19 2.2. HP-Outer Header Field
2.2. The HP-Outer Header Field . . . . . . . . . . . . . . . . 19 2.2.1. HP-Outer Header Field Definition
2.2.1. HP-Outer Header Field Definition . . . . . . . . . . 21 3. Header Confidentiality Policy
3. Header Confidentiality Policy . . . . . . . . . . . . . . . . 21 3.1. HCP Definition
3.1. HCP Definition . . . . . . . . . . . . . . . . . . . . . 22 3.1.1. HCP Avoids Changing from addr-spec
3.1.1. HCP Avoids Changing From addr-spec . . . . . . . . . 23 3.2. Initial Registered HCPs
3.2. Initial Registered HCPs . . . . . . . . . . . . . . . . . 23 3.2.1. Baseline Header Confidentiality Policy
3.2.1. Baseline Header Confidentiality Policy . . . . . . . 23 3.2.2. Shy Header Confidentiality Policy
3.2.2. Shy Header Confidentiality Policy . . . . . . . . . . 24 3.2.3. No Header Confidentiality Policy
3.2.3. No Header Confidentiality Policy . . . . . . . . . . 25 3.3. Default Header Confidentiality Policy
3.3. Default Header Confidentiality Policy . . . . . . . . . . 25 3.4. HCP Evolution
3.4. HCP Evolution . . . . . . . . . . . . . . . . . . . . . . 25 3.4.1. Offering More Ambitious Header Confidentiality
3.4.1. Offering More Ambitious Header Confidentiality . . . 26
3.4.2. Expert Guidance for Registering Header Confidentiality 3.4.2. Expert Guidance for Registering Header Confidentiality
Policies . . . . . . . . . . . . . . . . . . . . . . 26 Policies
4. Receiving Guidance . . . . . . . . . . . . . . . . . . . . . 27 4. Receiving Guidance
4.1. Identifying that a Message has Header Protection . . . . 28 4.1. Identifying That a Message Has Header Protection
4.2. Extracting Protected and Unprotected ("Outer") Header 4.2. Extracting Protected and Unprotected ("Outer") Header
Fields . . . . . . . . . . . . . . . . . . . . . . . . . 28 Fields
4.2.1. HeaderSetsFromMessage . . . . . . . . . . . . . . . . 28 4.2.1. HeaderSetsFromMessage
4.3. Updating the Cryptographic Summary . . . . . . . . . . . 29 4.3. Updating the Cryptographic Summary
4.3.1. HeaderFieldProtection . . . . . . . . . . . . . . . . 30 4.3.1. HeaderFieldProtection
4.4. Handling Mismatch of From Header Fields . . . . . . . . . 31 4.4. Handling Mismatch of From Header Fields
4.4.1. Definitions . . . . . . . . . . . . . . . . . . . . . 31 4.4.1. Definitions
4.4.2. Warning for From Header Field Mismatch . . . . . . . 32 4.4.2. Warning for From Header Field Mismatch
4.4.3. From Header Field Rendering . . . . . . . . . . . . . 33 4.4.3. From Header Field Rendering
4.4.4. Handling Protected From Header Field when 4.4.4. Handling the Protected From Header Field When
Responding . . . . . . . . . . . . . . . . . . . . . 33 Responding
4.4.5. Matching addr-specs . . . . . . . . . . . . . . . . . 33 4.4.5. Matching addr-specs
4.5. Rendering a Message with Header Protection . . . . . . . 34 4.5. Rendering a Message with Header Protection
4.5.1. Example Signed-only Message . . . . . . . . . . . . . 34 4.5.1. Example Signed-Only Message
4.5.2. Example Signed-and-Encrypted Message . . . . . . . . 35 4.5.2. Example Signed-and-Encrypted Message
4.5.3. Do Not Render Legacy Display Elements . . . . . . . . 36 4.5.3. Do Not Render Legacy Display Elements
4.6. Implicitly rendered Header Fields . . . . . . . . . . . . 37 4.6. Implicitly Rendered Header Fields
4.7. Handling Undecryptable Messages . . . . . . . . . . . . . 37 4.7. Handling Undecryptable Messages
4.8. Guidance for Automated Message Handling . . . . . . . . . 39 4.8. Guidance for Automated Message Handling
4.8.1. Interpret Only Protected Header Fields . . . . . . . 39 4.8.1. Only Interpret Protected Header Fields
4.8.2. Ignore Legacy Display Elements . . . . . . . . . . . 39 4.8.2. Ignore Legacy Display Elements
4.9. Affordances for Debugging and Troubleshooting . . . . . . 40 4.9. Affordances for Debugging and Troubleshooting
4.10. Handling RFC8551HP Messages (Backward Compatibility) . . 40 4.10. Handling RFC8551HP Messages (Backward Compatibility)
4.10.1. Identifying an RFC8551HP Message . . . . . . . . . . 41 4.10.1. Identifying an RFC8551HP Message
4.10.2. Rendering or Responding to an RFC8551HP message . . 42 4.10.2. Rendering or Responding to an RFC8551HP Message
4.11. Rendering Other Schemes . . . . . . . . . . . . . . . . . 42 4.11. Rendering Other Schemes
5. Sending Guidance . . . . . . . . . . . . . . . . . . . . . . 43 5. Sending Guidance
5.1. Composing a Cryptographically Protected Message Without 5.1. Composing a Cryptographically Protected Message Without
Header Protection . . . . . . . . . . . . . . . . . . . . 43 Header Protection
5.1.1. ComposeNoHeaderProtection . . . . . . . . . . . . . . 44 5.1.1. ComposeNoHeaderProtection
5.2. Composing a Message with Header Protection . . . . . . . 44 5.2. Composing a Message with Header Protection
5.2.1. Compose . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.1. Compose
5.2.2. Adding a Legacy Display Element to a text/plain 5.2.2. Adding a Legacy Display Element to a text/plain Part
Part . . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.3. Adding a Legacy Display Element to a text/html Part
5.2.3. Adding a Legacy Display Element to a text/html 5.2.4. Only Add a Legacy Display Element to Main Body Parts
Part . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.4. Only Add a Legacy Display Element to Main Body
Parts . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.5. Do Not Add a Legacy Display Element to Other 5.2.5. Do Not Add a Legacy Display Element to Other
Content-Types . . . . . . . . . . . . . . . . . . . . 50 Content-Types
6. Replying and Forwarding Guidance . . . . . . . . . . . . . . 50 6. Replying and Forwarding Guidance
6.1. Avoid Leaking Encrypted Header Fields in Replies and 6.1. Avoid Leaking Encrypted Header Fields in Replies and
Forwards . . . . . . . . . . . . . . . . . . . . . . . . 51 Forwards
6.1.1. ReferenceHCP . . . . . . . . . . . . . . . . . . . . 52 6.1.1. ReferenceHCP
6.2. Avoid Misdirected Replies . . . . . . . . . . . . . . . . 54 6.2. Avoid Misdirected Replies
7. Unprotected Header Fields Added in Transit . . . . . . . . . 54 7. Unprotected Header Fields Added in Transit
7.1. Mailing list Header Fields: List-* and Archived-At . . . 55 7.1. Mailing List Header Fields: List-* and Archived-At
8. E-mail Ecosystem Evolution . . . . . . . . . . . . . . . . . 55 8. Email Ecosystem Evolution
8.1. Dropping Legacy Display Elements . . . . . . . . . . . . 56 8.1. Dropping Legacy Display Elements
8.2. More Ambitious Default Header Confidentiality Policy . . 56 8.2. More Ambitious Default Header Confidentiality Policy
8.3. Deprecation of Messages Without Header Protection . . . . 57 8.3. Deprecation of Messages Without Header Protection
9. Usability Considerations . . . . . . . . . . . . . . . . . . 58 9. Usability Considerations
9.1. Mixed Protections Within a Message Are Hard To 9.1. Mixed Protections Within a Message Are Hard to Understand
Understand . . . . . . . . . . . . . . . . . . . . . . . 58 9.2. Users Should Not Have to Choose a Header Confidentiality
9.2. Users Should Not Have To Choose a Header Confidentiality Policy
Policy . . . . . . . . . . . . . . . . . . . . . . . . . 59 10. Security Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 60 10.1. From Address Spoofing
10.1. From Address Spoofing . . . . . . . . . . . . . . . . . 60 10.1.1. From Rendering Reasoning
10.1.1. From Rendering Reasoning . . . . . . . . . . . . . . 61 10.2. Avoid Cryptographic Summary Confusion from the hp
10.2. Avoid Cryptographic Summary Confusion from hp Parameter
Parameter . . . . . . . . . . . . . . . . . . . . . . . 63 10.3. Caution About Composing with Legacy Display Elements
10.3. Caution about Composing with Legacy Display Elements . . 64 10.4. Plaintext Attacks
10.4. Plaintext Attacks . . . . . . . . . . . . . . . . . . . 65 11. Privacy Considerations
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 66 11.1. Leaks When Replying
11.1. Leaks When Replying . . . . . . . . . . . . . . . . . . 66 11.2. Encrypted Header Fields Are Not Always Private
11.2. Encrypted Header Fields Are Not Always Private . . . . . 66
11.2.1. Encrypted Header Fields Can Leak Unwanted Information 11.2.1. Encrypted Header Fields Can Leak Unwanted Information
to the Recipient . . . . . . . . . . . . . . . . . . 66 to the Recipient
11.2.2. Encrypted Header Fields Can Be Inferred From External 11.2.2. Encrypted Header Fields Can Be Inferred from External
or Internal Metadata . . . . . . . . . . . . . . . . 67 or Internal Metadata
11.2.3. Encrypted Header Fields May Not Be Fully Masked by 11.2.3. Encrypted Header Fields May Not Be Fully Masked by HCP
HCP . . . . . . . . . . . . . . . . . . . . . . . . . 67
11.3. A Naive Recipient May Overestimate the Cryptographic 11.3. A Naive Recipient May Overestimate the Cryptographic
Status of a Header Field in an Encrypted Message . . . . 68 Status of a Header Field in an Encrypted Message
11.4. Privacy and Deliverability Risks with Bcc and Encrypted 11.4. Privacy and Deliverability Risks with Bcc and Encrypted
Messages . . . . . . . . . . . . . . . . . . . . . . . . 69 Messages
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 12. IANA Considerations
12.1. Register the HP-Outer Header Field . . . . . . . . . . . 69 12.1. Registration of the HP-Outer Header Field
12.2. Update Reference for Content-Type Header Field due to hp 12.2. Reference Update for the Content-Type Header Field
and hp-legacy-display Parameters . . . . . . . . . . . . 70 12.3. New Mail Header Confidentiality Policies Registry
12.3. New Registry: Mail Header Confidentiality Policies . . . 71 13. References
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 72 13.1. Normative References
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 13.2. Informative References
14.1. Normative References . . . . . . . . . . . . . . . . . . 72 Appendix A. Table of Pseudocode Listings
14.2. Informative References . . . . . . . . . . . . . . . . . 73 Appendix B. Possible Problems with Legacy MUAs
Appendix A. Table of Pseudocode Listings . . . . . . . . . . . . 76 B.1. Problems Viewing Messages in a List View
Appendix B. Possible Problems with Legacy MUAs . . . . . . . . . 77 B.2. Problems When Rendering a Message
B.1. Problems Viewing Messages in a List View . . . . . . . . 78 B.3. Problems When Replying to a Message
B.2. Problems when Rendering a Message . . . . . . . . . . . . 78 Appendix C. Test Vectors
B.3. Problems when Replying to a Message . . . . . . . . . . . 79 C.1. Baseline Messages
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 80 C.1.1. No Cryptographic Protections over a Simple Message
C.1. Baseline Messages . . . . . . . . . . . . . . . . . . . . 80 C.1.2. S/MIME Signed-Only signedData over a Simple Message, No
C.1.1. No Cryptographic Protections Over a Simple Message . 80 Header Protection
C.1.2. S/MIME Signed-only signedData Over a Simple Message, No C.1.3. S/MIME Signed-Only multipart/signed over a Simple
Header Protection . . . . . . . . . . . . . . . . . . 81 Message, No Header Protection
C.1.3. S/MIME Signed-only multipart/signed Over a Simple C.1.4. S/MIME Signed and Encrypted over a Simple Message, No
Message, No Header Protection . . . . . . . . . . . . 83 Header Protection
C.1.4. S/MIME Signed and Encrypted Over a Simple Message, No C.1.5. No Cryptographic Protections over a Complex Message
Header Protection . . . . . . . . . . . . . . . . . . 85 C.1.6. S/MIME Signed-Only signedData over a Complex Message,
C.1.5. No Cryptographic Protections Over a Complex No Header Protection
Message . . . . . . . . . . . . . . . . . . . . . . . 90 C.1.7. S/MIME Signed-Only multipart/signed over a Complex
C.1.6. S/MIME Signed-only signedData Over a Complex Message, Message, No Header Protection
No Header Protection . . . . . . . . . . . . . . . . 92 C.1.8. S/MIME Signed and Encrypted over a Complex Message, No
C.1.7. S/MIME Signed-only multipart/signed Over a Complex Header Protection
Message, No Header Protection . . . . . . . . . . . . 95 C.2. Signed-Only Messages
C.1.8. S/MIME Signed and Encrypted Over a Complex Message, No C.2.1. S/MIME Signed-Only signedData over a Simple Message,
Header Protection . . . . . . . . . . . . . . . . . . 98 Header Protection
C.2. Signed-only Messages . . . . . . . . . . . . . . . . . . 105 C.2.2. S/MIME Signed-Only multipart/signed over a Simple
C.2.1. S/MIME Signed-only signedData Over a Simple Message, Message, Header Protection
Header Protection . . . . . . . . . . . . . . . . . . 105 C.2.3. S/MIME Signed-Only signedData over a Complex Message,
C.2.2. S/MIME Signed-only multipart/signed Over a Simple Header Protection
Message, Header Protection . . . . . . . . . . . . . 107 C.2.4. S/MIME Signed-Only multipart/signed over a Complex
C.2.3. S/MIME Signed-only signedData Over a Complex Message, Message, Header Protection
Header Protection . . . . . . . . . . . . . . . . . . 110 C.2.5. S/MIME Signed-Only signedData over a Complex Message,
C.2.4. S/MIME Signed-only multipart/signed Over a Complex Legacy RFC 8551 Header Protection
Message, Header Protection . . . . . . . . . . . . . 113 C.2.6. S/MIME Signed-Only multipart/signed over a Complex
C.2.5. S/MIME Signed-only signedData Over a Complex Message, Message, Legacy RFC 8551 Header Protection
Legacy RFC 8551 Header Protection . . . . . . . . . . 117 C.3. Signed-and-Encrypted Messages
C.2.6. S/MIME Signed-only multipart/signed Over a Complex C.3.1. S/MIME Signed and Encrypted over a Simple Message,
Message, Legacy RFC 8551 Header Protection . . . . . 121 Header Protection with hcp_baseline
C.3. Signed-and-Encrypted Messages . . . . . . . . . . . . . . 124 C.3.2. S/MIME Signed and Encrypted over a Simple Message,
C.3.1. S/MIME Signed and Encrypted Over a Simple Message, Header Protection with hcp_baseline (+ Legacy Display)
Header Protection With hcp_baseline . . . . . . . . . 124 C.3.3. S/MIME Signed and Encrypted over a Simple Message,
C.3.2. S/MIME Signed and Encrypted Over a Simple Message, Header Protection with hcp_shy
Header Protection With hcp_baseline (+ Legacy C.3.4. S/MIME Signed and Encrypted over a Simple Message,
Display) . . . . . . . . . . . . . . . . . . . . . . 130 Header Protection with hcp_shy (+ Legacy Display)
C.3.3. S/MIME Signed and Encrypted Over a Simple Message, C.3.5. S/MIME Signed-and-Encrypted Reply over a Simple
Header Protection With hcp_shy . . . . . . . . . . . 135 Message, Header Protection with hcp_baseline
C.3.4. S/MIME Signed and Encrypted Over a Simple Message, C.3.6. S/MIME Signed-and-Encrypted Reply over a Simple
Header Protection With hcp_shy (+ Legacy Display) . . 141 Message, Header Protection with hcp_baseline (+ Legacy
C.3.5. S/MIME Signed and Encrypted Reply Over a Simple Display)
Message, Header Protection With hcp_baseline . . . . 147 C.3.7. S/MIME Signed-and-Encrypted Reply over a Simple
C.3.6. S/MIME Signed and Encrypted Reply Over a Simple Message, Header Protection with hcp_shy
Message, Header Protection With hcp_baseline (+ Legacy C.3.8. S/MIME Signed-and-Encrypted Reply over a Simple
Display) . . . . . . . . . . . . . . . . . . . . . . 153 Message, Header Protection with hcp_shy (+ Legacy
C.3.7. S/MIME Signed and Encrypted Reply Over a Simple Display)
Message, Header Protection With hcp_shy . . . . . . . 160 C.3.9. S/MIME Signed and Encrypted over a Complex Message,
C.3.8. S/MIME Signed and Encrypted Reply Over a Simple Header Protection with hcp_baseline
Message, Header Protection With hcp_shy (+ Legacy C.3.10. S/MIME Signed and Encrypted over a Complex Message,
Display) . . . . . . . . . . . . . . . . . . . . . . 166 Header Protection with hcp_baseline (+ Legacy Display)
C.3.9. S/MIME Signed and Encrypted Over a Complex Message, C.3.11. S/MIME Signed and Encrypted over a Complex Message,
Header Protection With hcp_baseline . . . . . . . . . 174 Header Protection with hcp_shy
C.3.10. S/MIME Signed and Encrypted Over a Complex Message, C.3.12. S/MIME Signed and Encrypted over a Complex Message,
Header Protection With hcp_baseline (+ Legacy Header Protection with hcp_shy (+ Legacy Display)
Display) . . . . . . . . . . . . . . . . . . . . . . 181 C.3.13. S/MIME Signed-and-Encrypted Reply over a Complex
C.3.11. S/MIME Signed and Encrypted Over a Complex Message, Message, Header Protection with hcp_baseline
Header Protection With hcp_shy . . . . . . . . . . . 190 C.3.14. S/MIME Signed-and-Encrypted Reply over a Complex
C.3.12. S/MIME Signed and Encrypted Over a Complex Message, Message, Header Protection with hcp_baseline (+ Legacy
Header Protection With hcp_shy (+ Legacy Display) . . 197 Display)
C.3.13. S/MIME Signed and Encrypted Reply Over a Complex C.3.15. S/MIME Signed-and-Encrypted Reply over a Complex
Message, Header Protection With hcp_baseline . . . . 206 Message, Header Protection with hcp_shy
C.3.14. S/MIME Signed and Encrypted Reply Over a Complex C.3.16. S/MIME Signed-and-Encrypted Reply over a Complex
Message, Header Protection With hcp_baseline (+ Legacy Message, Header Protection with hcp_shy (+ Legacy
Display) . . . . . . . . . . . . . . . . . . . . . . 214 Display)
C.3.15. S/MIME Signed and Encrypted Reply Over a Complex C.3.17. S/MIME Signed and Encrypted over a Complex Message,
Message, Header Protection With hcp_shy . . . . . . . 223 Legacy RFC 8551 Header Protection with hcp_baseline
C.3.16. S/MIME Signed and Encrypted Reply Over a Complex Appendix D. Composition Examples
Message, Header Protection With hcp_shy (+ Legacy D.1. New Message Composition
Display) . . . . . . . . . . . . . . . . . . . . . . 231 D.1.1. Unprotected Message
C.3.17. S/MIME Signed and Encrypted Over a Complex Message, D.1.2. Encrypted with hcp_baseline and Legacy Display
Legacy RFC 8551 Header Protection With hcp_baseline . 240 D.2. Composing a Reply
Appendix D. Composition Examples . . . . . . . . . . . . . . . . 248 D.2.1. Unprotected Message
D.1. New message composition . . . . . . . . . . . . . . . . . 248
D.1.1. Unprotected message . . . . . . . . . . . . . . . . . 249
D.1.2. Encrypted with hcp_baseline and Legacy Display . . . 249
D.2. Composing a Reply . . . . . . . . . . . . . . . . . . . . 251
D.2.1. Unprotected message . . . . . . . . . . . . . . . . . 252
D.2.2. Encrypted with hcp_no_confidentiality and Legacy D.2.2. Encrypted with hcp_no_confidentiality and Legacy
Display . . . . . . . . . . . . . . . . . . . . . . . 253 Display
Appendix E. Rendering Examples
Appendix E. Rendering Examples . . . . . . . . . . . . . . . . . 257
E.1. Example text/plain Cryptographic Payload with Legacy E.1. Example text/plain Cryptographic Payload with Legacy
Display Elements . . . . . . . . . . . . . . . . . . . . 257 Display Elements
E.2. Example text/html Cryptographic Payload with Legacy Display E.2. Example text/html Cryptographic Payload with Legacy Display
Elements . . . . . . . . . . . . . . . . . . . . . . . . 258 Elements
Appendix F. Other Header Protection Schemes . . . . . . . . . . 260 Appendix F. Other Header Protection Schemes
F.1. Original RFC 8551 Header Protection . . . . . . . . . . . 260 F.1. Original RFC 8551 Header Protection
F.2. Pretty Easy Privacy (pEp) . . . . . . . . . . . . . . . . 260 F.2. Pretty Easy Privacy (pEp)
F.3. "draft-autocrypt" Protected Headers . . . . . . . . . . . 261 F.3. Protected Email Headers
Appendix G. Document Changelog . . . . . . . . . . . . . . . . . 261 Acknowledgements
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Index
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 269 Authors' Addresses
1. Introduction 1. Introduction
Privacy and security issues regarding e-mail Header Protection in S/ Privacy and security issues regarding email Header Protection in S/
MIME and PGP/MIME have been identified for some time. Most current MIME and PGP/MIME have been identified for some time. Most current
implementations of cryptographically protected electronic mail implementations of cryptographically protected email protect only the
protect only the body of the message, which leaves significant room body of the message, which leaves significant room for attacks
for attacks against otherwise-protected messages. For example, lack against otherwise-protected messages. For example, lack of Header
of Header Protection allows an attacker to substitute the message Protection allows an attacker to substitute the message subject and/
subject and/or author. or author.
This document describes how to cryptographically protect message This document describes how to cryptographically protect message
headers, and provides guidance for the implementer of a Mail User headers and provides guidance for the implementer of a Mail User
Agent (MUA) that generates, interprets, and replies to such a Agent (MUA) that generates, interprets, and replies to such a
message. It uses the term "Legacy MUA" to refer to an MUA that does message. It uses the term "Legacy MUA" to refer to an MUA that does
not implement this specification. This document takes particular not implement this specification. This document takes particular
care to ensure that messages interact reasonably well with Legacy care to ensure that messages interact reasonably well with Legacy
MUAs. MUAs.
1.1. Update to RFC 8551 1.1. Update to RFC 8551
An older scheme for Header Protection was specified in S/MIME 3.1 An older scheme for Header Protection was specified in S/MIME 3.1
([RFC8551]), which involves wrapping a message/rfc822 MIME object [RFC8551], which involves wrapping a message/rfc822 MIME object with
with a Cryptographic Envelope around the message to protect. This a Cryptographic Envelope around the message to protect it. This
document refers to that scheme as RFC 8551 Header Protection, or document refers to that scheme as "RFC 8551 Header Protection", or
"RFC8551HP". Substantial testing has shown that RFC8551HP does not "RFC8551HP". Substantial testing has shown that RFC8551HP does not
interact well with some Legacy MUAs (see Section 1.1.1). interact well with some Legacy MUAs (see Section 1.1.1).
This specification supersedes RFC8551HP, effectively replacing the This specification supersedes RFC8551HP, effectively replacing the
final two paragraphs of Section 3.1 of [RFC8551]. final two paragraphs of Section 3.1 of [RFC8551].
In this specification, all Header Fields gain end-to-end In this specification, all Header Fields gain end-to-end
cryptographic integrity and authenticity by being copied directly cryptographic integrity and authenticity by being copied directly
into the Cryptographic Payload without using an intervening message/ into the Cryptographic Payload without using an intervening message/
rfc822 MIME object. In an encrypted message, some Header Fields can rfc822 MIME object. In an encrypted message, some Header Fields can
also be made confidential by removing or obscuring them from the also be made confidential by removing or obscuring them from the
outer Header Section. outer Header Section.
This specification also offers substantial security, privacy, and This specification also offers substantial security, privacy, and
usability guidance for sending and receiving MUAs that was not usability guidance for sending and receiving MUAs that was not
considered in RFC 8551. considered in [RFC8551].
1.1.1. Problems with RFC 8551 Header Protection 1.1.1. Problems with RFC 8551 Header Protection
Several Legacy MUAs have difficulty rendering a message that uses Several Legacy MUAs have difficulty rendering a message that uses
RFC8551HP. These problems can appear on signed-only messages, as RFC8551HP. These problems can appear on signed-only messages, as
well as signed-and-encrypted messages. well as signed-and-encrypted messages.
In some cases, some mail user agents cannot render message/rfc822 In some cases, some mail user agents cannot render message/rfc822
message subparts at all, in violation of baseline MIME requirements message subparts at all, which is in violation of baseline MIME
as defined on page 5 of [RFC2049]. A message using RFC8551HP is requirements as defined in Section 2 of [RFC2049]. A message using
unreadable by any recipient using such an MUA. RFC8551HP is unreadable by any recipient using such an MUA.
In other cases, the user sees an attachment suggesting a forwarded In other cases, the user sees an attachment suggesting a forwarded
e-mail message, which -- in fact -- contains the protected e-mail email message that -- in fact -- contains the protected email message
message that should be rendered directly. In most of these cases, that should be rendered directly. In most of these cases, the user
the user can click on the attachment to view the protected message. can click on the attachment to view the protected message.
However, viewing the protected message as an attachment in isolation However, viewing the protected message as an attachment in isolation
may strip it of any security indications, leaving the user unable to may strip it of any security indications, leaving the user unable to
assess the cryptographic properties of the message. Worse, for assess the cryptographic properties of the message. Worse, for
encrypted messages, interacting with the protected message in encrypted messages, interacting with the protected message in
isolation may leak contents of the cleartext, for example, if the isolation may leak contents of the cleartext, for example, if the
reply is not also encrypted. reply is not also encrypted.
Furthermore, RFC8551HP lacks any discussion of the following points, Furthermore, RFC8551HP lacks any discussion of the following points,
all of which are provided in this specification: all of which are provided in this specification:
skipping to change at page 9, line 6 skipping to change at line 347
integrity and authenticity protections (this specification integrity and authenticity protections (this specification
mandates protection of all Header Fields that the sending MUA mandates protection of all Header Fields that the sending MUA
knows about). knows about).
* How to securely indicate the sender's intent to offer Header * How to securely indicate the sender's intent to offer Header
Protection and encryption, which lets a receiving MUA detect Protection and encryption, which lets a receiving MUA detect
messages whose cryptographic properties may have been modified in messages whose cryptographic properties may have been modified in
transit (see Section 2.1.1). transit (see Section 2.1.1).
* Which Header Fields should be given end-to-end cryptographic * Which Header Fields should be given end-to-end cryptographic
confidentiality protections in an encrypted message, and how (see confidentiality protections in an encrypted message and how (see
Section 3). Section 3).
* How to securely indicate the sender's choices about which Header * How to securely indicate the sender's choices about which Header
Fields were made confidential, which lets a receiving MUA reply or Fields were made confidential, which lets a receiving MUA reply or
forward an encrypted message safely without accidentally leaking forward an encrypted message safely without accidentally leaking
confidential material (see Section 2.2). confidential material (see Section 2.2).
These stumbling blocks with Legacy MUAs, missing mechanisms, and These stumbling blocks with Legacy MUAs, missing mechanisms, and
missing guidance create a strong disincentive for existing MUAs to missing guidance create a strong disincentive for existing MUAs to
generate messages using RFC8551HP. Because few messages have been generate messages using RFC8551HP. Because few messages have been
produced, there has been little incentive for those MUAs capable of produced, there has been little incentive for those MUAs capable of
upgrading to bother interpreting them better. upgrading to bother interpreting them better.
In contrast, the mechanisms defined here are safe to adopt and In contrast, the mechanisms defined here are safe to adopt and
produce messages with very few problems for Legacy MUAs. And, produce messages with very few problems for Legacy MUAs. And
Section 4.10 provides useful guidance for rendering and replying to Section 4.10 provides useful guidance for rendering and replying to
RFC8551HP messages. RFC8551HP messages.
1.2. Risks of Header Protection for Legacy MUA Recipients 1.2. Risks of Header Protection for Legacy MUA Recipients
Producing a signed-only message using this specification is risk- Producing a signed-only message using this specification is risk
free. Such a message will render in the same way on any Legacy MUA free. Such a message will render in the same way on any Legacy MUA
as a Legacy Signed Message (that is, a signed message without Header as a Legacy Signed Message (that is, a signed message without Header
Protection). An MUA conformant to this specification that encounters Protection). An MUA conformant to this specification that encounters
such a message will be able to gain the benefits of end-to-end such a message will be able to gain the benefits of end-to-end
cryptographic integrity and authenticity for all Header Fields. cryptographic integrity and authenticity for all Header Fields.
An encrypted message produced according to this specification that An encrypted message produced according to this specification that
has some user-facing Header Fields removed or obscured may not render has some user-facing Header Fields removed or obscured may not render
as desired in a Legacy MUA. In particular, those Header Fields that as desired in a Legacy MUA. In particular, those Header Fields that
were made confidential will not be visible to the user of a Legacy were made confidential will not be visible to the user of a Legacy
skipping to change at page 10, line 4 skipping to change at line 394
A workaround "Legacy Display" mechanism is provided in this A workaround "Legacy Display" mechanism is provided in this
specification (see Section 2.1.2). Legacy MUAs will render "Legacy specification (see Section 2.1.2). Legacy MUAs will render "Legacy
Display Elements" to the user, albeit not in the same location that Display Elements" to the user, albeit not in the same location that
the Header Fields would normally be rendered. the Header Fields would normally be rendered.
Alternately, if the sender of an encrypted message is particularly Alternately, if the sender of an encrypted message is particularly
concerned about the experience of a recipient using a Legacy MUA, and concerned about the experience of a recipient using a Legacy MUA, and
they are willing to accept leaking the user-facing Header Fields, they are willing to accept leaking the user-facing Header Fields,
they can simply adopt the No Header Confidentiality Policy (see they can simply adopt the No Header Confidentiality Policy (see
Section 3.2.3). A signed and encrypted message composed using the No Section 3.2.3). A signed-and-encrypted message composed using the No
Header Confidentiality Policy offers no usability risk for a reader Header Confidentiality Policy offers no usability risk for a reader
using a Legacy MUA, and retains end-to-end cryptographic integrity using a Legacy MUA and retains end-to-end cryptographic integrity and
and authenticity properties for all Header Fields for any reader authenticity properties for all Header Fields for any reader using a
using a conformant MUA. Of course, such a message has the same (non- conformant MUA. Of course, such a message has the same (non-
existent) confidentiality properties for all Header Fields as a existent) confidentiality properties for all Header Fields as a
Legacy Encrypted Message (that is, an encrypted message made without Legacy Encrypted Message (that is, an encrypted message made without
Header Protection). Header Protection).
1.3. Motivation 1.3. Motivation
Users generally do not understand the distinction between message Users generally do not understand the distinction between message
body and message header. When an e-mail message has cryptographic body and message header. When an email message has cryptographic
protections that cover the message body, but not the Header Fields, protections that cover the message body but not the Header Fields,
several attacks become possible. several attacks become possible.
For example, a Legacy Signed Message has a signature that covers the For example, a Legacy Signed Message has a signature that covers the
body but not the Header Fields. An attacker can therefore modify the body but not the Header Fields. An attacker can therefore modify the
Header Fields (including the Subject header) without invalidating the Header Fields (including Subject) without invalidating the signature.
signature. Since most readers consider a message body in the context Since most readers consider a message body in the context of the
of the message's Subject header, the meaning of the message itself message's Subject, the meaning of the message itself could change
could change drastically (under the attacker's control) while still drastically (under the attacker's control) while still retaining the
retaining the same cryptographic indicators of integrity and same cryptographic indicators of integrity and authenticity.
authenticity.
In another example, a Legacy Encrypted Message has its body In another example, a Legacy Encrypted Message has its body
effectively hidden from an adversary that snoops on the message. But effectively hidden from an adversary that snoops on the message. But
if the Header Fields are not also encrypted, significant information if the Header Fields are not also encrypted, significant information
about the message (such as the message Subject) will leak to the about the message (such as the message Subject) will leak to the
inspecting adversary. inspecting adversary.
However, if the sending and receiving MUAs ensure that cryptographic However, if the sending and receiving MUAs ensure that cryptographic
protections cover the message Header Section as well as the message protections cover the message Header Section as well as the message
body, these attacks are defeated. body, these attacks are defeated.
skipping to change at page 11, line 10 skipping to change at line 446
handle the message. Thus, an outbound message format that is handle the message. Thus, an outbound message format that is
backward compatible with as many legacy implementations as possible backward compatible with as many legacy implementations as possible
is a more effective vehicle for providing the whole-message is a more effective vehicle for providing the whole-message
cryptographic protections described above. cryptographic protections described above.
This document aims for backward compatibility with Legacy MUAs to the This document aims for backward compatibility with Legacy MUAs to the
extent possible. In some cases, like when a user-visible header like extent possible. In some cases, like when a user-visible header like
the Subject is cryptographically hidden, a Legacy MUA will not be 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 able to render or reply to the message exactly the same way as a
conformant MUA would. But accommodations are described here that conformant MUA would. But accommodations are described here that
ensure a rough semantic equivalence for Legacy MUA even in these ensure a rough semantic equivalence for a Legacy MUA even in these
cases. cases.
1.3.2. Deliverability 1.3.2. Deliverability
A message with perfect cryptographic protections that cannot be A message with perfect cryptographic protections that cannot be
delivered is less useful than a message with imperfect cryptographic delivered is less useful than a message with imperfect cryptographic
protections that can be delivered. Senders want their messages to protections that can be delivered. Senders want their messages to
reach the intended recipients. reach the intended recipients.
Given the current state of the Internet mail ecosystem, encrypted Given the current state of the Internet mail ecosystem, encrypted
messages in particular cannot shield all of their Header Fields from messages in particular cannot shield all of their Header Fields from
visibility and still be guaranteed delivery to their intended visibility and still be guaranteed delivery to their intended
recipient. recipient.
This document accounts for this concern by providing a mechanism This document accounts for this concern by providing a mechanism
(Section 3) that prioritizes initial deliverability (at the cost of (Section 3) that prioritizes initial deliverability (at the cost of
some header leakage) while facilitating future message variants that some header leakage) while facilitating future message variants that
shield more header metadata from casual inspection. shield more header metadata from casual inspection.
1.4. Other Protocols to Protect E-Mail Header Fields 1.4. Other Protocols to Protect Email Header Fields
A separate pair of protocols also provides some cryptographic A separate pair of protocols also provides some cryptographic
protection for the e-mail message header integrity: DomainKeys protection for the email message header integrity: DomainKeys
Identified Mail (DKIM) [RFC6376], as used in combination with Domain- Identified Mail (DKIM) [RFC6376], as used in combination with Domain-
based Message Authentication, Reporting, and Conformance (DMARC) based Message Authentication, Reporting, and Conformance (DMARC)
[RFC7489]. This pair of protocols provides a domain-based reputation [RFC7489]. This pair of protocols provides a domain-based reputation
mechanism that can be used to mitigate some forms of unsolicited mechanism that can be used to mitigate some forms of unsolicited
e-mail (spam). email (spam).
However, the DKIM+DMARC suite provides cryptographic protection at a However, the DKIM+DMARC suite provides cryptographic protection at a
different scope, as it is usually applied by and evaluated by a mail different scope, as it is usually applied by and evaluated by a mail
transport agent (MTA). DKIM+DMARC typically provide MTA-to-MTA transport agent (MTA). DKIM+DMARC typically provide MTA-to-MTA
protection, whereas this specification provides MUA-to-MUA protection, whereas this specification provides MUA-to-MUA
protection. This is because DKIM+DMARC are typically applied to protection. This is because DKIM+DMARC are typically applied to
messages by (and interpreted by) MTAs, whereas the mechanisms in this messages by (and interpreted by) MTAs, whereas the mechanisms in this
document are typically applied and interpreted by MUAs. document are typically applied and interpreted by MUAs.
A receiving MUA that relies on DKIM+DMARC for sender authenticity A receiving MUA that relies on DKIM+DMARC for sender authenticity
should note Section 10.1. should note Section 10.1.
Furthermore, the DKIM+DMARC suite only provides cryptographic Furthermore, the DKIM+DMARC suite only provides cryptographic
integrity and authentication, not encryption. So cryptographic integrity and authentication, not encryption. So cryptographic
confidentiality is not available from that suite. confidentiality is not available from that suite.
The DKIM+DMARC suite can be used on any message, including messages The DKIM+DMARC suite can be used on any message, including messages
formed as defined in this document. There should be no conflict formed as defined in this document. There should be no conflict
between DKIM+DMARC and the specification here. between DKIM+DMARC and the specification here.
Though not strictly e-mail, similar protections have been in use on Though not strictly email, similar protections have been in use on
Usenet for signing and verification of message headers for years. Usenet for the signing and verification of message headers for years.
See [PGPCONTROL] and [PGPVERIFY-FORMAT] for more details. Like DKIM, See [PGPCONTROL] and [PGPVERIFY-FORMAT] for more details. Like DKIM,
these Usenet control protections offer only integrity and these Usenet control protections offer only integrity and
authentication, not confidentiality. authentication, not confidentiality.
1.5. Applicability to PGP/MIME 1.5. Applicability to PGP/MIME
This document specifies end-to-end cryptographic protections for This document specifies end-to-end cryptographic protections for
e-mail messages in reference to S/MIME ([RFC8551]). email messages in reference to S/MIME [RFC8551].
Comparable end-to-end cryptographic protections can also be provided Comparable end-to-end cryptographic protections can also be provided
by PGP/MIME ([RFC3156]). by PGP/MIME [RFC3156].
The mechanisms in this document should be applicable in the PGP/MIME The mechanisms in this document should be applicable in the PGP/MIME
protections as well as S/MIME protections, but analysis and protections as well as S/MIME protections, but analysis and
implementation in this document focuses on S/MIME. implementation in this document focuses on S/MIME.
To the extent that any divergence from the mechanism defined here is To the extent that any divergence from the mechanism defined here is
necessary for PGP/MIME, that divergence is out of scope for this necessary for PGP/MIME, that divergence is out of scope for this
document. document.
1.6. Requirements Language 1.6. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The key words "SPECIFICATION REQUIRED" and "IETF REVIEW" that appear The policies "Specification Required" and "IETF Review" that appear
in this document when used to describe namespace allocation are to be in this document when used to describe namespace allocation are to be
interpreted as described in [RFC8126]. interpreted as described in [RFC8126].
1.7. Terms 1.7. Terms
The following terms are defined for the scope of this document: The following terms are defined for the scope of this document:
* S/MIME: Secure/Multipurpose Internet Mail Extensions (see S/MIME: Secure/Multipurpose Internet Mail Extensions (see [RFC8551])
[RFC8551])
* PGP/MIME: MIME Security with OpenPGP (see [RFC3156]) PGP/MIME: Pretty Good Privacy with MIME (see [RFC3156])
* Message: An E-Mail Message consisting of Header Fields Message: An email message consisting of Header Fields (collectively
(collectively called "the Header Section of the message") called "the Header Section of the message") optionally followed by
followed, optionally, by a Body; see [RFC5322]. a message body; see [RFC5322].
Note: To avoid ambiguity, this document avoids using the terms Note: To avoid ambiguity, this document avoids using the terms
"Header" or "Headers" in isolation, but instead always uses "Header" or "Headers" in isolation, but instead always uses
"Header Field" to refer to the individual field and "Header "Header Field" to refer to the individual field and "Header
Section" to refer to the entire collection. Section" to refer to the entire collection.
* Header Field: A Header Field includes a field name, followed by a Header Field: A Header Field includes a field name, followed by a
colon (":"), followed by a field body (value), and terminated by colon (":"), followed by a field body (value), and is terminated
CRLF; see Section 2.2 of [RFC5322] for more details. by CRLF; see Section 2.2 of [RFC5322] for more details.
* Header Section: The Header Section is a sequence of lines of Header Section: The Header Section is a sequence of lines of
characters with special syntax as defined in [RFC5322]. The characters with special syntax as defined in [RFC5322]. The
Header Section of a Message contains the Header Fields associated Header Section of a message contains the Header Fields associated
with the Message itself. The Header Section of a MIME part (that with the message itself. The Header Section of a MIME part (that
is, a subpart of a message) typically contains Header Fields is, a subpart of a message) typically contains Header Fields
associated with that particular MIME part. associated with that particular MIME part.
* Body: The Body is the part of a Message that follows the Header Body: The body is the part of a message that follows the Header
Section and is separated from the Header Section by an empty line Section and is separated from the Header Section by an empty line
(that is, a line with nothing preceding the CRLF); see [RFC5322]. (that is, a line with nothing preceding the CRLF); see [RFC5322].
It is the (bottom) section of a Message containing the payload of It is the (bottom) section of a message containing the payload of
a Message. Typically, the Body consists of a (possibly multipart) a message. Typically, the body consists of a (possibly multipart)
MIME [RFC2045] construct. MIME [RFC2045] construct.
* Header Protection (HP): cryptographic protection of e-mail Header Header Protection (HP): The cryptographic protection of email Header
Sections (or parts of it) by means of signatures and/or Sections (or parts of it) by means of signatures and/or
encryption. encryption.
* Cryptographic Layer, Cryptographic Payload, Cryptographic Legacy MUA: An MUA that does not understand Header Protection as
Envelope, Cryptographic Summary, Structural Header Fields, Main
Body Part, User-Facing Header Fields, and MUA are all used as
defined in [I-D.ietf-lamps-e2e-mail-guidance]
* Legacy MUA: an MUA that does not understand Header Protection as
defined in this document. A Legacy Non-Crypto MUA is incapable of defined in this document. A Legacy Non-Crypto MUA is incapable of
doing any end-to-end cryptographic operations. A Legacy Crypto doing any end-to-end cryptographic operations. A Legacy Crypto
MUA is capable of doing cryptographic operations, but does not MUA is capable of doing cryptographic operations but does not
understand or generate messages with Header Protection. understand or generate messages with Header Protection.
* Legacy Signed Message: an e-mail message that was signed by a Legacy Signed Message: An email message that was signed by a Legacy
Legacy MUA, and therefore has no cryptographic authenticity or MUA and therefore has no cryptographic authenticity or integrity
integrity protections on its Header Fields. protections on its Header Fields.
* Legacy Encrypted Message: an e-mail message that was signed and Legacy Encrypted Message: An email message that was signed and
encrypted by a Legacy MUA, and therefore has no cryptographic encrypted by a Legacy MUA and therefore has no cryptographic
authenticity, integrity, or confidentiality protections on any of authenticity, integrity, or confidentiality protections on any of
its Header Fields. its Header Fields.
* Header Confidentiality Policy (HCP): a functional specification of Header Confidentiality Policy (HCP): A functional specification of
which Header Fields should be removed or obscured when composing which Header Fields should be removed or obscured when composing
an encrypted message with Header Protection. An HCP is considered an encrypted message with Header Protection. An HCP is considered
more "conservative" when it removes or obscures fewer Header more "conservative" when it removes or obscures fewer Header
Fields. When it removes or obscures more Header fields, it is Fields. When it removes or obscures more Header Fields, it is
more "ambitious". See Section 3. more "ambitious". See Section 3.
* Ordinary User: a user of an MUA who follows a simple and minimal Ordinary User: A user of an MUA who follows a simple and minimal
experience, focused on sending and receiving e-mails. A user who experience, focused on sending and receiving emails. A user who
opts into advanced configuration, expert mode, or the like is not opts into advanced configuration, expert mode, or the like is not
an "Ordinary User". an "Ordinary User".
Additionally, Cryptographic Layer, Cryptographic Payload,
Cryptographic Envelope, Cryptographic Summary, Structural Header
Fields, Main Body Part, User-Facing Header Fields, and MUA are all
used as defined in [RFC9787].
1.8. Document Scope 1.8. Document Scope
This document describes sensible, simple behavior for a program that This document describes sensible, simple behavior for a program that
generates an e-mail message with standard end-to-end cryptographic generates an email message with standard end-to-end cryptographic
protections, following the guidance in protections, following the guidance in [RFC9787]. An implementation
[I-D.ietf-lamps-e2e-mail-guidance]. An implementation conformant to conformant to this document will produce messages that have
this document will produce messages that have cryptographic cryptographic protection that covers the message's Header Fields as
protection that covers the message's Header Fields as well as its well as its body.
body.
1.8.1. In Scope 1.8.1. In Scope
This document also describes sensible, simple behavior for a program This document also describes sensible, simple behavior for a program
that interprets such a message, in a way that can take advantage of that interprets such a message in a way that can take advantage of
these protections covering the Header Fields as well as the body. these protections covering the Header Fields as well as the body.
The message generation guidance aims to minimize negative The message generation guidance aims to minimize negative
interactions with any Legacy receiving MUA while providing actionable interactions with any Legacy receiving MUA while providing actionable
cryptographic properties for modern receiving clients. cryptographic properties for modern receiving clients.
In particular, this document focuses on two standard types of In particular, this document focuses on two standard types of
cryptographic protection that cover the entire message: cryptographic protection that cover the entire message:
* A cleartext message with a single signature, and * a cleartext message with a single signature and
* An encrypted message that contains a single cryptographic * an encrypted message that contains a single cryptographic
signature. signature.
1.8.2. Out of Scope 1.8.2. Out of Scope
The message composition guidance in this document (in Section 5.2) The message composition guidance in this document (in Section 5.2)
aims to provide minimal disruption for any Legacy MUA that receives aims to provide minimal disruption for any Legacy MUA that receives
such a message. However, a Legacy MUA by definition does not such a message. However, by definition, a Legacy MUA does not
implement any of the guidance here. Therefore, the document does not implement any of the guidance here. Therefore, the document does not
attempt to provide guidance for Legacy MUAs directly. attempt to provide guidance for Legacy MUAs directly.
Furthermore, this document does not explicitly contemplate other Furthermore, this document does not explicitly contemplate other
variants of cryptographic message protections, including any of variants of cryptographic message protections, including any of
these: these:
* Encrypted-only message (Without a cryptographic signature. See * encrypted-only message (without a cryptographic signature; see
Section 5.3 of [I-D.ietf-lamps-e2e-mail-guidance].) Section 5.3 of [RFC9787])
* Triple-wrapped message * triple-wrapped message
* Signed message with multiple signatures * signed message with multiple signatures
* Encrypted message with a cryptographic signature outside the * encrypted message with a cryptographic signature outside the
encryption. encryption
All such messages are out of scope of this document. All such messages are out of scope of this document.
1.9. Example 1.9. Example
This section gives an overview by providing an example of how MIME This section gives an overview by providing an example of how MIME
messages with Header Protection look like. messages with Header Protection look.
Consider the following MIME message: Consider the following MIME message:
A └─╴application/pkcs7-mime; smime-type="enveloped-data" A └─╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to) ↧ (decrypts to)
B └─╴application/pkcs7-mime; smime-type="signed-data" B └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to) ⇩ (unwraps to)
C └┬╴multipart/alternative; hp="cipher" C └┬╴multipart/alternative; hp="cipher"
D ├─╴text/plain; hp-legacy-display="1" D ├─╴text/plain; hp-legacy-display="1"
E └─╴text/html; hp-legacy-display="1" E └─╴text/html; hp-legacy-display="1"
Observe that: Observe that:
* Node A and B are collectively called the Cryptographic Envelope. * Nodes A and B are collectively called the Cryptographic Envelope.
Node C (including its sub-nodes D and E) is called the Node C (including its subnodes D and E) is called the
Cryptographic Payload ([I-D.ietf-lamps-e2e-mail-guidance]). Cryptographic Payload [RFC9787].
* Node A contains the traditional unprotected ("outer") Header * Node A contains the traditional unprotected ("outer") Header
Fields. Node C contains the protected ("inner") Header Fields. Fields. Node C contains the protected ("inner") Header Fields.
* The presence of the hp attribute (see Section 2.1.1) on the * The presence of the hp attribute (see Section 2.1.1) on the
Content-Type of node C allows the receiver to know that the sender Content-Type of node C allows the receiver to know that the sender
applied Header Protection. Its value allows the receiver to applied Header Protection. Its value allows the receiver to
distinguish whether the sender intended for the message to be distinguish whether the sender intended for the message to be
confidential (hp="cipher") or not (hp="clear"), since encryption confidential (hp="cipher") or not (hp="clear"), since encryption
may have been added in transit (see Section 10.2). may have been added in transit (see Section 10.2).
skipping to change at page 16, line 40 skipping to change at line 710
Content-Type: multipart/alternative; hp="cipher" Content-Type: multipart/alternative; hp="cipher"
MIME-Version: 1.0 MIME-Version: 1.0
HP-Outer: Date: Wed, 11 Jan 2023 16:08:43 -0500 HP-Outer: Date: Wed, 11 Jan 2023 16:08:43 -0500
HP-Outer: From: Bob <bob@example.net> HP-Outer: From: Bob <bob@example.net>
HP-Outer: To: Alice <alice@example.net> HP-Outer: To: Alice <alice@example.net>
HP-Outer: Subject: [...] HP-Outer: Subject: [...]
HP-Outer: Message-ID: <20230111T210843Z.1234@lhp.example> HP-Outer: Message-ID: <20230111T210843Z.1234@lhp.example>
Observe that: Observe that:
* Between node C and node A, some Header Fields are copied as-is * Between node C and node A, some Header Fields are copied as is
(Date, From, To, Message-ID), some are obscured (Subject), and (Date, From, To, Message-ID), some are obscured (Subject), and
some are removed (Keywords). some are removed (Keywords).
* The HP-Outer Header Fields (see Section 2.2) of node C contain a * The HP-Outer Header Fields (see Section 2.2) of node C contain a
protected copy of the Header Fields in node A. The copy allows protected copy of the Header Fields in node A. The copy allows
the receiver to recompute for which Header Fields the sender the receiver to recompute for which Header Fields the sender
provided confidentiality by removing or obscuring them. provided confidentiality by removing or obscuring them.
* The copying/removing/obscuring and the HP-Outer only apply to Non- * The copying/removing/obscuring and the HP-Outer only apply to Non-
Structural Header Fields, not to Structural Header Fields like Structural Header Fields, not to Structural Header Fields like
Content-Type or MIME-Version (see Section 1.1 of Content-Type or MIME-Version (see Section 1.1 of [RFC9787]).
[I-D.ietf-lamps-e2e-mail-guidance]).
* If the sender intends no confidentiality and doesn't encrypt the * If the sender intends no confidentiality and doesn't encrypt the
message, it doesn't remove or obscure Header Fields. All Non- message, it doesn't remove or obscure Header Fields. All Non-
Structural Header Fields are copied as-is. No HP-Outer Header Structural Header Fields are copied as is. No HP-Outer Header
Fields are present. Fields are present.
Node D looks as follows: Node D looks as follows:
Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1";
Subject: Handling the Jones contract Subject: Handling the Jones contract
Keywords: Contract, Urgent Keywords: Contract, Urgent
Please review and approve or decline by Thursday, it's critical! Please review and approve or decline by Thursday, it's critical!
skipping to change at page 17, line 29 skipping to change at line 747
Thanks, Thanks,
Bob Bob
-- --
Bob Gonzalez Bob Gonzalez
ACME, Inc. ACME, Inc.
Observe that: Observe that:
* The sender adds the removed and obscured User-Facing Header Fields * The sender adds the removed and obscured User-Facing Header Fields
(see Section 1.1.2 of [I-D.ietf-lamps-e2e-mail-guidance]) to the (see Section 1.1.2 of [RFC9787]) to the main body (note the empty
main body (note the empty line after the Content-Type). This is line after the Content-Type). This is called the Legacy Display
called the Legacy Display Element. It allows a user with a Legacy Element. It allows a user with a Legacy MUA that doesn't
MUA which doesn't implement this document to understand the implement this document to understand the message, since the
message, since the Header Fields will be shown as part of the main Header Fields will be shown as part of the main body.
body.
* The hp-legacy-display="1" attribute (see Section 2.1.2) indicates * The hp-legacy-display="1" attribute (see Section 2.1.2) indicates
that the sender added a Legacy Display Element. This allows that the sender added a Legacy Display Element. This allows
receivers that implement this document to recognise the Legacy receivers that implement this document to recognize the Legacy
Display Element and distinguish it from user-added content. The Display Element and distinguish it from user-added content. The
receiver then hides the Legacy Display Element and doesn't display receiver then hides the Legacy Display Element and doesn't display
it to the user. it to the user.
* The hp-legacy-display is added to the node to which it applies, * hp-legacy-display is added to the node to which it applies, not on
not on any outer nodes (e.g., not to node C). any outer nodes (e.g., not to node C).
For more examples, see Appendix D and Appendix E. For more examples, see Appendices D and E.
2. Internet Message Format Extensions 2. Internet Message Format Extensions
This section describes relevant, backward-compatible extensions to This section describes relevant, backward-compatible extensions to
the Internet Message Format ([RFC5322]). Subsequent sections offer the Internet Message Format [RFC5322]. Subsequent sections offer
concrete guidance for an MUA to make use of these mechanisms, concrete guidance for an MUA to make use of these mechanisms,
including policy decisions and recommended pseudocode. including policy decisions and recommended pseudocode.
2.1. Content-Type parameters 2.1. Content-Type Parameters
This document introduces two parameters for the Content-Type Header This document introduces two parameters for the Content-Type Header
Field, which have distinct semantics and use cases. Field, which have distinct semantics and use cases.
2.1.1. Content-Type parameter: hp 2.1.1. Content-Type Parameter: hp
This specification defines a parameter for the Content-Type Header This specification defines a parameter for the Content-Type Header
Field named hp (for Header Protection). This parameter is only Field named hp (for Header Protection). This parameter is only
relevant on the Content-Type Header Field at the root of the relevant on the Content-Type Header Field at the root of the
Cryptographic Payload. The presence of this parameter at the root of Cryptographic Payload. The presence of this parameter at the root of
the Cryptographic Payload indicates that the sender intends for this the Cryptographic Payload indicates that the sender intends for this
message to have end-to-end cryptographic protections for the Header message to have end-to-end cryptographic protections for the Header
Fields. Fields.
The parameter's defined values describe the sender's cryptographic The parameter's defined values describe the sender's cryptographic
intent when producing the message: intent when producing the message:
+========+==============+=========+=================+==============+ +========+==============+=========+=================+==============+
|hp Value| Authenticity |Integrity| Confidentiality | Description | |hp Value| Authenticity |Integrity| Confidentiality | Description |
+========+==============+=========+=================+==============+ +========+==============+=========+=================+==============+
|"clear" | yes |yes | no | This message | |"clear" | yes |yes | no | This message |
| | | | | has been | | | | | | has been |
| | | | | signed by | | | | | | signed by |
| | | | | the sender | | | | | | the sender, |
| | | | | with Header | | | | | | with Header |
| | | | | Protection | | | | | | Protection. |
+--------+--------------+---------+-----------------+--------------+ +--------+--------------+---------+-----------------+--------------+
|"cipher"| yes |yes | yes | This message | |"cipher"| yes |yes | yes | This message |
| | | | | has been | | | | | | has been |
| | | | | signed by | | | | | | signed by |
| | | | | the sender, | | | | | | the sender, |
| | | | | with Header | | | | | | with Header |
| | | | | Protection, | | | | | | Protection, |
| | | | | and is | | | | | | and is |
| | | | | encrypted to | | | | | | encrypted to |
| | | | | the | | | | | | the |
| | | | | recipients | | | | | | recipients. |
+--------+--------------+---------+-----------------+--------------+ +--------+--------------+---------+-----------------+--------------+
Table 1: hp parameter for Content-Type Header Field Table 1: hp Parameter for Content-Type Header Field
A sending implementation MUST NOT produce a Cryptographic Payload A sending implementation MUST NOT produce a Cryptographic Payload
with parameter hp="cipher" for a non-encrypted message (that is, with parameter hp="cipher" for a non-encrypted message (that is,
where none of the Cryptographic Layers in the Cryptographic Envelope where none of the Cryptographic Layers in the Cryptographic Envelope
of the message provide encryption). Likewise, if a sending of the message provide encryption). Likewise, if a sending
implementation is sending an encrypted message with Header implementation is sending an encrypted message with Header
Protection, it MUST emit an hp="cipher" parameter, regardless of Protection, it MUST emit an hp="cipher" parameter, regardless of
which Header Fields were made confidential. which Header Fields were made confidential.
Note that hp="cipher" indicates that the message itself has been Note that hp="cipher" indicates that the message itself has been
encrypted by the sender to the recipients, but makes no assertions encrypted by the sender to the recipients but makes no assertions
about which Header Fields have been removed or obscured. This can be about which Header Fields have been removed or obscured. This can be
derived from the Cryptographic Payload itself (see Section 4.2). derived from the Cryptographic Payload itself (see Section 4.2).
A receiving implementation MUST NOT mistake the presence of an A receiving implementation MUST NOT mistake the presence of an
hp="cipher" parameter in the Cryptographic Payload for the actual hp="cipher" parameter in the Cryptographic Payload for the actual
presence of a Cryptographic Layer that provides encryption. presence of a Cryptographic Layer that provides encryption.
2.1.2. Content-Type parameter: hp-legacy-display 2.1.2. Content-Type Parameter: hp-legacy-display
This specification also defines an hp-legacy-display parameter for This specification also defines an hp-legacy-display parameter for
the Content-Type Header Field. The only defined value for this the Content-Type Header Field. The only defined value for this
parameter is 1. parameter is 1.
This parameter is only relevant on a leaf MIME node of Content-Type This parameter is only relevant on a leaf MIME node of Content-Type
text/html or text/plain within a well-formed message with end-to-end text/html or text/plain within a well-formed message with end-to-end
cryptographic protections. Its presence indicates that the MIME node cryptographic protections. Its presence indicates that the MIME node
it is attached to contains a decorative "Legacy Display Element". it is attached to contains a decorative "Legacy Display Element".
The Legacy Display Element itself is used for backward-compatible The Legacy Display Element itself is used for backward-compatible
visibility of any removed or obscured User-Facing Header Field in a visibility of any removed or obscured User-Facing Header Field in a
Legacy MUA. Legacy MUA.
Such a Legacy Display Element need not be rendered to the user of an Such a Legacy Display Element need not be rendered to the user of an
MUA that implements this specification, because the MUA already knows MUA that implements this specification, because the MUA already knows
the correct Header Field information, and can render it to the user the correct Header Field information and can render it to the user in
in the appropriate part of the MUA's user interface rather than in the appropriate part of the MUA's user interface rather than in the
the body of the message. body of the message.
See Section 5.2.2 for how to insert a Legacy Display Element into a See Section 5.2.2 for how to insert a Legacy Display Element into a
text/plain Main Body Part. See Section 5.2.3 for how to insert a text/plain Main Body Part. See Section 5.2.3 for how to insert a
Legacy Display Element into a text/html Main Body Part. See Legacy Display Element into a text/html Main Body Part. See
Section 4.5.3 for how to avoid rendering a Legacy Display Element. Section 4.5.3 for how to avoid rendering a Legacy Display Element.
2.2. The HP-Outer Header Field 2.2. HP-Outer Header Field
This document also specifies a new Header Field: HP-Outer. This document also specifies a new Header Field: HP-Outer.
This Header Field is used only in the Header Section of the This Header Field is used only in the Header Section of the
Cryptographic Payload of an encrypted message. It is not relevant Cryptographic Payload of an encrypted message. It is not relevant
for signed-only messages. It documents, with the same cryptographic for signed-only messages. It documents, with the same cryptographic
guarantees shared by the rest of the message, the sender's choices guarantees shared by the rest of the message, the sender's choices
about Header Field confidentiality. It does so by embedding a copy about Header Field confidentiality. It does so by embedding a copy
within the Cryptographic Envelope of every non-structural Header within the Cryptographic Envelope of every non-structural Header
Field that the sender put outside the Cryptographic Envelope. This Field that the sender put outside the Cryptographic Envelope. This
Header Field enables the MUA receiving the encrypted message to Header Field enables the MUA receiving the encrypted message to
reliably identify whether the sending MUA intended to make a Header reliably identify whether the sending MUA intended to make a Header
Field confidential (see Section 11.3). Field confidential (see Section 11.3).
The HP-Outer Header Fields in a message's Cryptographic Payload are The HP-Outer Header Fields in a message's Cryptographic Payload are
useful for ensuring that any confidential Header Field will not be useful for ensuring that any confidential Header Field will not be
automatically leaked in the clear if the user replies to or forwards automatically leaked in the clear if the user replies to or forwards
the message. They may also be useful for an MUA that indicates the the message. They may also be useful for an MUA that indicates the
confidentiality status of any given Header Field to the user. confidentiality status of any given Header Field to the user.
An implementation that composes encrypted e-mail MUST include a copy An implementation that composes encrypted email MUST include a copy
of all non-structural Header Fields deliberately exposed to the of all non-structural Header Fields deliberately exposed to the
outside of the Cryptographic Envelope using a series of HP-Outer outside of the Cryptographic Envelope using a series of HP-Outer
Header Fields within the Cryptographic Payload. These HP-Outer MIME Header Fields within the Cryptographic Payload. These HP-Outer MIME
Header Fields should only ever appear directly within the Header Header Fields should only ever appear directly within the Header
Section of the Cryptographic Payload of a Cryptographic Envelope Section of the Cryptographic Payload of a Cryptographic Envelope
offering confidentiality. They MUST be ignored for the purposes of offering confidentiality. They MUST be ignored for the purposes of
evaluating the message's Header Protection if they appear in other evaluating the message's Header Protection if they appear in other
places. places.
Each instance of HP-Outer contains a non-structural Header Field name Each instance of HP-Outer contains a non-structural Header Field name
and the value that this Header Field was set in the outer and the value that this Header Field was set in within the outer
(unprotected) Header Section. The HP-Outer Header Field can appear (unprotected) Header Section. The HP-Outer Header Field can appear
multiple times in the Header Section of a Cryptographic Payload. multiple times in the Header Section of a Cryptographic Payload.
If a non-structural Header Field name Z is present in Header If a non-structural Header Field named Z is present in Header
Section of the Cryptographic Payload, but doesn't appear in an HP- Section of the Cryptographic Payload but doesn't appear in an HP-
Outer Header Field value at all, then the sender is effectively Outer Header Field value at all, then the sender is effectively
asserting that every instance of Z was made confidential by removal asserting that every instance of Z was made confidential by removal
from the Outer Header Section. Specifically, it means that no Header from the Outer Header Section. Specifically, it means that no Header
Field Z was included on the outside of the message's Cryptographic Field Z was included on the outside of the message's Cryptographic
Envelope by the sender at the time the message was injected into the Envelope by the sender at the time the message was injected into the
mail system. mail system.
See Section 5.2 for how to insert HP-Outer Header Fields into an See Section 5.2 for how to insert HP-Outer Header Fields into an
encrypted message. See Section 4.3 for how to determine the end-to- encrypted message. See Section 4.3 for how to determine the end-to-
end confidentiality of a given Header Field from an encrypted message end confidentiality of a given Header Field from an encrypted message
skipping to change at page 21, line 17 skipping to change at line 920
The syntax of this Header Field is defined using the following ABNF The syntax of this Header Field is defined using the following ABNF
[RFC5234], where field-name, WSP, VCHAR, and FWS are defined in [RFC5234], where field-name, WSP, VCHAR, and FWS are defined in
[RFC5322]: [RFC5322]:
hp-outer = "HP-Outer:" [FWS] field-name ": " hp-outer = "HP-Outer:" [FWS] field-name ": "
hp-outer-value CRLF hp-outer-value CRLF
hp-outer-value = (*([FWS] VCHAR) *WSP) hp-outer-value = (*([FWS] VCHAR) *WSP)
Note that hp-outer-value is the same as unstructured from Note that hp-outer-value is the same as unstructured from
Section 3.2.5 of [RFC5322], but without the obsolete obs-unstruct Section 3.2.5 of [RFC5322] but without the obsolete obs-unstruct
option. option.
3. Header Confidentiality Policy 3. Header Confidentiality Policy
An MUA composing an encrypted message according to this specification An MUA composing an encrypted message according to this specification
may make any given Header Field confidential by removing it from may make any given Header Field confidential by removing it from the
Header Section outside the Cryptographic Envelope, or by obscuring it Header Section outside the Cryptographic Envelope or by obscuring it
by rewriting it to a different value in that outer Header Section. by rewriting it to a different value in that outer Header Section.
The composing MUA faces a choice for any new message: which Header The composing MUA faces a choice for any new message: Which Header
Fields should be made confidential, and how? Fields should be made confidential, and how?
This section defines the "Header Confidentiality Policy" (or HCP) as This section defines the "Header Confidentiality Policy" (or HCP) as
a well-defined abstraction to encourage MUA developers to consider, a well-defined abstraction to encourage MUA developers to consider,
document, and share reasonable policies across the community. It document, and share reasonable policies across the community. It
establishes a registry of known HCPs, defines a small number of establishes a registry of known HCPs, defines a small number of
simple HCPs in that registry, and makes a recommendation for a simple HCPs in that registry, and makes a recommendation for a
reasonable default. reasonable default.
Note that such a policy is only needed when the end-to-end Note that such a policy is only needed when the end-to-end
skipping to change at page 22, line 10 skipping to change at line 959
Note that no representation of the HCP itself ever appears "on the Note that no representation of the HCP itself ever appears "on the
wire". However, the consumer of the encrypted message can see the wire". However, the consumer of the encrypted message can see the
decisions that were made by the sender's HCP via the HP-Outer Header decisions that were made by the sender's HCP via the HP-Outer Header
Fields (see Section 2.2). Fields (see Section 2.2).
3.1. HCP Definition 3.1. HCP Definition
In this document, we represent that Header Confidentiality Policy as In this document, we represent that Header Confidentiality Policy as
a function hcp: a function hcp:
* hcp(name, val_in) → val_out: this function takes a non-structural * hcp(name, val_in) -> val_out: This function takes a non-structural
Header Field identified by name with initial value val_in as Header Field identified by name with the initial value val_in as
arguments, and returns a replacement header value val_out. If arguments and returns a replacement header value val_out. If
val_out is the special value null, it means that the Header Field val_out is the special value null, it means that the Header Field
in question should be removed from the set of Header Fields in question should be removed from the set of Header Fields
visible outside the Cryptographic Envelope. visible outside the Cryptographic Envelope.
In the pseudocode descriptions of various choices of HCP in this In the pseudocode descriptions of various choices of HCP in this
document, any comparison with the name input is done case- document, any comparison with the name input is done case-
insensitively. This is appropriate for Header Field names, as insensitively. This is appropriate for Header Field names, as
described in [RFC5322]. described in [RFC5322].
Note that hcp is only applied to non-structural Header Fields. When Note that hcp is only applied to non-structural Header Fields. When
composing a message, Structural Header Fields are dealt with composing a message, Structural Header Fields are dealt with
separately, as described in Section 5.2. separately, as described in Section 5.2.
As an example, an MUA that obscures the Subject Header Field by As an example, an MUA that obscures the Subject Header Field by
replacing it with the literal string "[...]", hides all Cc'ed replacing it with the literal string "[...]" hides all Cc'ed
recipients, and does not offer confidentiality to any other Header recipients and does not offer confidentiality to any other Header
Fields would be represented as (in pseudocode): Fields that would be represented as (in pseudocode):
hcp_example_hide_cc(name, val_in) → val_out: hcp_example_hide_cc(name, val_in) → val_out:
if lower(name) is 'subject': if lower(name) is 'subject':
return '[...]' return '[...]'
else if lower(name) is 'cc': else if lower(name) is 'cc':
return null return null
else: else:
return val_in return val_in
For alignment with common practice as well as the ABNF in For alignment with common practice as well as the ABNF in
Section 2.2.1 for HP-Outer, val_out MUST be one of the following: Section 2.2.1 for HP-Outer, val_out MUST be one of the following:
* identical to val_in, or * identical to val_in,
* the special value null (meaning that the Header Field will be * the special value null (meaning that the Header Field will be
removed from the outside of the message), or removed from the outside of the message), or
* a sequence of printable and whitespace (that is, space or tab) * a sequence of whitespace (that is, space or tab) and printable
7-bit clean ASCII characters (of course, non-ASCII text can be 7-bit, clean ASCII characters (of course, non-ASCII text can be
encoded as ASCII using the encoded-word construct from [RFC2047]) encoded as ASCII using the encoded-word construct from [RFC2047])
The HCP can compute val_out using any technique describable in The HCP can compute val_out using any technique describable in
pseudocode, such as copying a fixed string or invocations of other pseudocode, such as copying a fixed string or invocations of other
pseudocode functions. If it alters the value, it MUST NOT include pseudocode functions. If it alters the value, it MUST NOT include
control or NUL characters in val_out. val_out SHOULD match the control or NUL characters in val_out. val_out SHOULD match the
expected ABNF for the Header Field identified by name. expected ABNF for the Header Field identified by name.
3.1.1. HCP Avoids Changing From addr-spec 3.1.1. HCP Avoids Changing from addr-spec
The From Header Field should also be treated specially by the HCP, to The From Header Field should also be treated specially by the HCP to
enable defense against possible e-mail address spoofing (see enable defense against possible email address spoofing (see
Section 10.1). In particular, for hcp("From", val_in), the addr-spec Section 10.1). In particular, for hcp("From", val_in), the addr-spec
of val_in and the addr-spec of val_out SHOULD match according to of val_in and the addr-spec of val_out SHOULD match according to
Section 4.4.5, unless the sending MUA has additional knowledge Section 4.4.5, unless the sending MUA has additional knowledge
coordinated with the receiving MUA about more subtle addr-spec coordinated with the receiving MUA about more subtle addr-spec
equivalence or certificate validity. equivalence or certificate validity.
3.2. Initial Registered HCPs 3.2. Initial Registered HCPs
This document formally defines three Header Confidentiality Policies This document formally defines three Header Confidentiality Policies
with known and reasonably well-understood characteristics as a way to with known and reasonably well-understood characteristics as a way to
compare and contrast different possible behavioral choices for a compare and contrast different possible behavioral choices for a
composing MUA. These definitions are not meant to preclude the composing MUA. These definitions are not meant to preclude the
creation of other HCPs. creation of other HCPs.
The purpose of the registry of HCPs is to facilitate HCP evolution The purpose of the registry of HCPs is to facilitate HCP evolution
and interoperability discussion among MUA developers and MTA and interoperability discussion among MUA developers and MTA
operators. operators.
(The example hypothetical HCP described in Section 3.1 above, (The example hypothetical HCP, hcp_example_hide_cc, described in
hcp_example_hide_cc, is deliberately not formally registered, as it Section 3.1 above is deliberately not formally registered, as it has
has not been evaluated in practice.) not been evaluated in practice.)
3.2.1. Baseline Header Confidentiality Policy 3.2.1. Baseline Header Confidentiality Policy
The most conservative recommended Header Confidentiality Policy only The most conservative recommended Header Confidentiality Policy only
provides confidentiality for Informational Fields, as defined in provides confidentiality for Informational Fields, as defined in
Section 3.6.5 of [RFC5322]. These fields are "only human-readable Section 3.6.5 of [RFC5322]. These fields are "only human-readable
content" and thus their content should not be relevant to transport content" and thus their content should not be relevant to transport
agents. Since most Internet messages today do have a Subject Header agents. Since most Internet messages today do have a Subject Header
Field, and some filtering engines might object to a message without a Field, and some filtering engines might object to a message without a
Subject, this policy is conservative and merely obscures that Header Subject, this policy is conservative and merely obscures that Header
Field by replacing it with a fixed string [...]. By contrast, Field by replacing it with a fixed string [...]. By contrast,
Comments and Keywords are comparatively rare, so these fields are Comments and Keywords Header Fields are comparatively rare, so these
removed entirely from the Outer Header Section. fields are removed entirely from the Outer Header Section.
hcp_baseline(name, val_in) → val_out: hcp_baseline(name, val_in) → val_out:
if lower(name) is 'subject': if lower(name) is 'subject':
return '[...]' return '[...]'
else if lower(name) is in ['comments', 'keywords']: else if lower(name) is in ['comments', 'keywords']:
return null return null
else: else:
return val_in return val_in
hcp_baseline is the recommended default HCP for a new implementation, hcp_baseline is the recommended default HCP for a new implementation,
as it provides meaningful confidentiality protections and is unlikely as it provides meaningful confidentiality protections and is unlikely
to cause deliverability or usability problems. to cause deliverability or usability problems.
3.2.2. Shy Header Confidentiality Policy 3.2.2. Shy Header Confidentiality Policy
Alternately, a slightly more ambitious (and therefore more privacy- Alternately, a slightly more ambitious (and therefore more privacy-
preserving) Header Confidentiality Policy might avoid leaking human- preserving) Header Confidentiality Policy might avoid leaking human-
interpretable data that MTAs generally don't care about. The interpretable data that MTAs generally don't care about. The
additional protected data isn't related to message routing or additional protected data isn't related to message routing or
transport, but but might reveal sensitive information about the transport but might reveal sensitive information about the sender or
sender or their relationship to the recipients. This "shy" HCP their relationship to the recipients. This "shy" HCP builds on
builds on hcp_baseline, but also: hcp_baseline but also:
* avoids revealing the display-name of each identified e-mail * avoids revealing the display-name of each identified email address
address, and and
* avoids leaking the sender's locally-configured time zone in the * avoids leaking the sender's locally configured time zone in the
Date Header Field. Date Header Field.
hcp_shy(name, val_in) → val_out: hcp_shy(name, val_in) → val_out:
if lower(name) is 'from': if lower(name) is 'from':
if val_in is an RFC 5322 mailbox: if val_in is an RFC 5322 mailbox:
return the RFC 5322 addr-spec part of val_in return the RFC 5322 addr-spec part of val_in
if lower(name) in ['to', 'cc']: if lower(name) in ['to', 'cc']:
if val_in is an RFC 5322 mailbox-list: if val_in is an RFC 5322 mailbox-list:
let val_out be an empty mailbox-list let val_out be an empty mailbox-list
for each mailbox in val_in: for each mailbox in val_in:
skipping to change at page 25, line 6 skipping to change at line 1093
if lower(name) is 'date': if lower(name) is 'date':
if val_in is an RFC 5322 date-time: if val_in is an RFC 5322 date-time:
return the UTC form of val_in return the UTC form of val_in
else if lower(name) is 'subject': else if lower(name) is 'subject':
return '[...]' return '[...]'
else if lower(name) is in ['comments', 'keywords']: else if lower(name) is in ['comments', 'keywords']:
return null return null
return val_in return val_in
hcp_shy requires more sophisticated parsing and Header Field hcp_shy requires more sophisticated parsing and Header Field
manipulation, and is not recommended as a default HCP for new manipulation and is not recommended as a default HCP for new
implementations. implementations.
3.2.3. No Header Confidentiality Policy 3.2.3. No Header Confidentiality Policy
Legacy MUAs can be conceptualized as offering a "No Header Legacy MUAs can be conceptualized as offering a "No Header
Confidentiality" Policy, which offers no confidentiality protection Confidentiality" Policy, which offers no confidentiality protection
to any Header Field: to any Header Field:
hcp_no_confidentiality(name, val_in) → val_out: hcp_no_confidentiality(name, val_in) → val_out:
return val_in return val_in
skipping to change at page 25, line 43 skipping to change at line 1130
the Informational Fields of a message (particularly the Subject) the the Informational Fields of a message (particularly the Subject) the
same way that they treat the body, and they are surprised to find same way that they treat the body, and they are surprised to find
that the Subject of an encrypted message is visible. that the Subject of an encrypted message is visible.
3.4. HCP Evolution 3.4. HCP Evolution
This document does not mandate any particular Header Confidentiality This document does not mandate any particular Header Confidentiality
Policy, though it offers guidance for MUA implementers in selecting Policy, though it offers guidance for MUA implementers in selecting
one in Section 3.3. Future documents may recommend or mandate such a one in Section 3.3. Future documents may recommend or mandate such a
policy for an MUA with specific needs. Such a recommendation might policy for an MUA with specific needs. Such a recommendation might
be motivated by descriptions of metadata-derived attacks, or stem be motivated by descriptions of metadata-derived attacks, stem from
from research about message deliverability, or describe new research about message deliverability, or describe new signaling
signalling mechanisms, but these topics are out of scope for this mechanisms, but these topics are out of scope for this document.
document.
3.4.1. Offering More Ambitious Header Confidentiality 3.4.1. Offering More Ambitious Header Confidentiality
An MUA MAY offer even more ambitious confidentiality for Header An MUA MAY offer even more ambitious confidentiality for Header
Fields of an encrypted message than defined in Section 3.2.2. For 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 example, it might implement an HCP that removes the To and Cc Header
Fields entirely, relying on the SMTP envelope to ensure proper Fields entirely, relying on the SMTP envelope to ensure proper
routing. Or it might remove References and In-Reply-To so that routing. Or it might remove References and In-Reply-To so that
message threading is not visible to any MTA. Any more ambitious message threading is not visible to any MTA. Any more ambitious
choice might result in deliverability, rendering, or usability issues choice might result in deliverability, rendering, or usability issues
skipping to change at page 26, line 28 skipping to change at line 1157
experience will document their chosen Header Confidentiality Policy experience will document their chosen Header Confidentiality Policy
and the rationale behind their choice. and the rationale behind their choice.
3.4.2. Expert Guidance for Registering Header Confidentiality Policies 3.4.2. Expert Guidance for Registering Header Confidentiality Policies
There is no formal syntax specified for the Header Confidentiality There is no formal syntax specified for the Header Confidentiality
Policy, but any attempt to specify an HCP for inclusion in the Policy, but any attempt to specify an HCP for inclusion in the
registry needs to provide: registry needs to provide:
* a stable reference document clearly indicating the distinct name * a stable reference document clearly indicating the distinct name
for the proposed HCP for the proposed HCP,
* pseudocode that other implementers can clearly and unambiguously * pseudocode that other implementers can clearly and unambiguously
interpret interpret,
* a clear explanation of why this HCP is different from all other * a clear explanation of why this HCP is different from all other
registered HCPs registered HCPs, and
* any relevant considerations related to deployment of the HCP (for * any relevant considerations related to deployment of the HCP (for
example, known or expected deliverability, rendering, or privacy example, known or expected deliverability, rendering, or privacy
challenges and possible mitigations) challenges and possible mitigations).
When the proposed HCP produces any non-null output for a given Header When the proposed HCP produces any non-null output for a given Header
Field name, val_out SHOULD match the expected ABNF for that Header Field name, val_out SHOULD match the expected ABNF for that Header
Field. If the proposed HCP does not match the expected ABNF for that Field. If the proposed HCP does not match the expected ABNF for that
Header Field, the documentation should explicitly identify the Header Field, the documentation should explicitly identify the
relevant circumstances and provide a justification for the deviation. relevant circumstances and provide a justification for the deviation.
An entry should not be marked as "Recommended" unless it has been An entry should not be marked as "Recommended" unless it has been
shown to offer confidentiality or privacy improvements over the shown to offer confidentiality or privacy improvements over the
status quo and have minimal or mitigatable negative impact on status quo and have minimal or mitigatory negative impact on messages
messages to which it is applied, considering factors such as message to which it is applied, considering factors such as message
deliverability and security. Only one entry in the table deliverability and security. Only one entry in the table
(hcp_baseline) is initially marked as "Recommended". In the future, (hcp_baseline) is initially marked as "Recommended". In the future,
more than one entry may be marked as "Recommended". more than one entry may be marked as "Recommended".
4. Receiving Guidance 4. Receiving Guidance
An MUA that receives a cryptographically protected e-mail will render An MUA that receives a cryptographically protected email will render
it for the user. it for the user.
The receiving MUA will render the message body, a selected subset of The receiving MUA will render the message body, render a selected
Header Fields, and (as described in Section 3 of subset of Header Fields, and provide a summary of the cryptographic
[I-D.ietf-lamps-e2e-mail-guidance]) provide a summary of the properties of the message (as described in Section 3 of [RFC9787]).
cryptographic properties of the message.
Most MUAs only render a subset of Header Fields by default. For Most MUAs only render a subset of Header Fields by default. For
example, most MUAs render From, To, Cc, Date, and Subject Header example, most MUAs render the From, To, Cc, Date, and Subject Header
Fields to the user, but few render Message-Id or Received. Fields to the user, but few render Message-Id or Received.
An MUA that knows how to handle a message with Header Protection An MUA that knows how to handle a message with Header Protection
makes the following four changes to its behavior when rendering a makes the following four changes to its behavior when rendering a
message: message:
* If the MUA detects that an incoming message has protected Header * If the MUA detects that an incoming message has protected Header
Fields: Fields:
- For a Header Field that is present in the protected Header - For a Header Field that is present in the protected Header
Section, the MUA SHOULD render the protected value, and ignore Section, the MUA SHOULD render the protected value and ignore
any unprotected counterparts that may be present (with a any unprotected counterparts that may be present (with a
special exception for the From Header Field (see Section 4.4). special exception for the From Header Field (see Section 4.4)).
- For a Header Field that is present only in the unprotected - For a Header Field that is present only in the unprotected
Header Section, the MUA SHOULD NOT render that value. If it Header Section, the MUA SHOULD NOT render that value. If it
does render the value, the MUA SHOULD indicate that the does render the value, the MUA SHOULD indicate that the
rendered value is unprotected. For an exception to this, see rendered value is unprotected. For an exception to this, see
Section 7 for a discussion of some specific Header Fields that Section 7 for a discussion of some specific Header Fields that
are known to be added in transit, and therefore are not are known to be added in transit and therefore are not expected
expected to have end-to-end cryptographic protections. to have end-to-end cryptographic protections.
* The MUA SHOULD include information in the message's Cryptographic * The MUA SHOULD include information in the message's Cryptographic
Summary to indicate the types of protection that applied to each Summary to indicate the types of protection that applied to each
rendered Header Field (if any). rendered Header Field (if any).
* If any Legacy Display Elements are present in the body of the * If any Legacy Display Elements are present in the body of the
message, it does not render them. message, it does not render them.
* When replying to a message with confidential Header Fields, the * When replying to a message with confidential Header Fields, the
replying MUA avoids leaking into the cleartext of the reply any replying MUA avoids leaking any Header Fields that were
Header Fields which were confidential in the original. It does confidential in the original into the cleartext of the reply. It
this even if its own Header Confidentiality Policy would not have does this even if its own Header Confidentiality Policy would not
treated those Header Fields as confidential. See Section 6 for have treated those Header Fields as confidential. See Section 6
more details. for more details.
Note that an MUA that handles a message with Header Protection does Note that an MUA that handles a message with Header Protection does
_not_ need to render any new Header Fields that it did not render _not_ need to render any new Header Fields that it did not render
before. before.
4.1. Identifying that a Message has Header Protection 4.1. Identifying That a Message Has Header Protection
An incoming message can be identified as having Header Protection An incoming message can be identified as having Header Protection
using the following test: using the following test:
* The Cryptographic Payload has parameter hp set to "clear" or * The Cryptographic Payload has parameter hp set to "clear" or
"cipher". See Section 4.5 for rendering guidance. "cipher". See Section 4.5 for rendering guidance.
When consuming a message, an MUA MUST ignore the hp parameter to When consuming a message, an MUA MUST ignore the hp parameter to
Content-Type when it encounters it anywhere other than the root of Content-Type when it encounters it anywhere other than the root of
the message's Cryptographic Payload. the message's Cryptographic Payload.
4.2. Extracting Protected and Unprotected ("Outer") Header Fields 4.2. Extracting Protected and Unprotected ("Outer") Header Fields
When a message is encrypted and it uses Header Protection, an MUA When a message is encrypted and uses Header Protection, an MUA
extracts a list of protected Header Fields (names and values), as extracts a list of protected Header Fields (names and values), as
well as a list of Header Fields that were added by the original well as a list of Header Fields that were added by the original
message sender in unprotected form to the outside of the message's message sender in unprotected form to the outside of the message's
Cryptographic Envelope. Cryptographic Envelope.
The following algorithm takes a reference message refmsg as input, The following algorithm takes reference message refmsg as input,
which is encrypted with Header Protection as described in this which is encrypted with Header Protection as described in this
document (that is, the Cryptographic Envelope includes a document (that is, the Cryptographic Envelope includes a
Cryptographic Layer that provides encryption, and the hp parameter Cryptographic Layer that provides encryption, and the hp parameter
for the Content-Type Header Field of the Cryptographic Payload is for the Content-Type Header Field of the Cryptographic Payload is
cipher). It produces as output a pair of lists of (h,v) Header cipher). It outputs a pair of lists of (h,v) Header Fields.
Fields.
4.2.1. HeaderSetsFromMessage 4.2.1. HeaderSetsFromMessage
Method Signature: Method Signature:
HeaderSetsFromMessage(refmsg) → (refouter, refprotected) HeaderSetsFromMessage(refmsg) -> (refouter, refprotected)
Procedure: Procedure:
1. Let refheaders be the list of (h,v) protected Header Fields found 1. Let refheaders be the list of (h,v) protected Header Fields found
in the root of the Cryptographic Payload in the root of the Cryptographic Payload.
2. Let refouter be an empty list of Header Field names and values 2. Let refouter be an empty list of Header Field names and values.
3. Let refprotected be an empty list of Header Field names and 3. Let refprotected be an empty list of Header Field names and
values values.
4. For each (h,v) in refheaders: 4. For each (h,v) in refheaders:
i. If h is HP-Outer: i. If h is HP-Outer:
a. Split v into (h1,v1) on the first colon (:) followed by a. Split v into (h1,v1) on the first colon (:), followed by
any amount of whitespace. any amount of whitespace.
b. Append (h1,v1) to refouter b. Append (h1,v1) to refouter.
ii. Else: ii. Else:
a. Append (h,v) to refprotected a. Append (h,v) to refprotected.
5. Return refouter, refprotected 5. Return refouter, refprotected.
Note that this algorithm is independent of the unprotected Header Note that this algorithm is independent of the unprotected Header
Fields. It derives its output only from the normal Header Fields and Fields. It derives its output only from the normal Header Fields and
the HP-Outer Header Fields, both contained inside the Cryptographic the HP-Outer Header Fields, both contained inside the Cryptographic
Payload. Payload.
4.3. Updating the Cryptographic Summary 4.3. Updating the Cryptographic Summary
Regardless of whether a cryptographically protected message has Regardless of whether a cryptographically protected message has
protected Header Fields, the Cryptographic Summary of the message protected Header Fields, the Cryptographic Summary of the message
should be modified to indicate what protections the Header Fields should be modified to indicate what protections the Header Fields
have. This field-by-field status is complex and isn't necessarily have. This field-by-field status is complex and isn't necessarily
intended to be presented in full to the user. Rather, it represents intended to be presented in full to the user. Rather, it represents
the state of the message internally within the MUA, and may be used the state of the message internally within the MUA and may be used to
to influence behavior like replying to the message (see Section 6.1). influence behavior like replying to the message (see Section 6.1).
Each Header Field individually has exactly one of the following Each Header Field individually has exactly one of the following
protection states: protection states:
* unprotected (has no Header Protection) * unprotected (has no Header Protection)
* signed-only (bound into the same validated signature as the * signed-only (bound into the same validated signature as the
enclosing message, but also visible in transit) enclosing message, but also visible in transit)
* encrypted-only (only appears within the Cryptographic Payload; the * encrypted-only (only appears within the Cryptographic Payload; the
skipping to change at page 30, line 13 skipping to change at line 1334
unprotected. unprotected.
If the message has Header Protection, an MUA SHOULD use the following If the message has Header Protection, an MUA SHOULD use the following
algorithm to compute the protection state of a protected Header Field algorithm to compute the protection state of a protected Header Field
(h,v) (that is, an element of refprotected from Section 4.2): (h,v) (that is, an element of refprotected from Section 4.2):
4.3.1. HeaderFieldProtection 4.3.1. HeaderFieldProtection
Method signature: Method signature:
HeaderFieldProtection(msg, h, v) → protection_state HeaderFieldProtection(msg, h, v) -> protection_state
Procedure: Procedure:
1. Let ct be the Content-Type of the root of the Cryptographic 1. Let ct be the Content-Type of the root of the Cryptographic
Payload of msg. Payload of msg.
2. Compute (refouter, refprotected) from HeaderSetsFromMessage(msg). 2. Compute (refouter, refprotected) from HeaderSetsFromMessage(msg).
3. If (h, v) is not in refprotected): 3. If (h, v) is not in refprotected:
i. Abort, v is not a valid value for header h i. Abort, v is not a valid value for header h.
4. Let is_sig_valid be false 4. Let is_sig_valid be false.
5. If the message is signed: 5. If the message is signed:
i. Let is_sig_valid be the result of validating the signature i. Let is_sig_valid be the result of validating the signature.
6. If the message is encrypted, and if ct has a parameter 6. If the message is encrypted, ct has a parameter hp="cipher", and
hp="cipher", and if (h,v) is not in refouter: (h,v) is not in refouter:
i. Return signed-and-encrypted if is_sig_valid otherwise i. Return signed-and-encrypted if is_sig_valid is otherwise
encrypted-only encrypted-only.
7. Return signed-only if is_sig_valid otherwise unprotected 7. Return signed-only if is_sig_valid is otherwise unprotected.
Note that: Note that:
* This algorithm is independent of the unprotected Header Fields. * This algorithm is independent of the unprotected Header Fields.
It derives the protection state only from (h,v) and the set of HP- It derives the protection state only from (h,v) and the set of HP-
Outer Header Fields, both of which are inside the Cryptographic Outer Header Fields, both of which are inside the Cryptographic
Envelope. Envelope.
* If the signature fails validation, the MUA lowers the affected * If the signature fails validation, the MUA lowers the affected
state to unprotected or encrypted-only without any additional state to unprotected or encrypted-only without any additional
warning to the user, as specified by Section 3.1 of warning to the user, as specified by Section 3.1 of [RFC9787].
[I-D.ietf-lamps-e2e-mail-guidance].
* Data from signed-and-encrypted and encrypted-only Header Fields * Data from signed-and-encrypted and encrypted-only Header Fields
may still not be fully private (see Section 11.2). may still not be fully private (see Section 11.2).
* Encryption may have been added in transit to an originally signed- * Encryption may have been added in transit to an originally signed-
only message. Thus only consider Header Fields to be confidential only message. Thus, only consider Header Fields to be
if the sender indicates it with the hp="cipher" parameter. confidential if the sender indicates it with the hp="cipher"
parameter.
* The protection state of a Header Field may be weaker than that of * The protection state of a Header Field may be weaker than that of
the message body. For example, a message body can be signed-and- the message body. For example, a message body can be signed-and-
encrypted, but a Header Field that is copied unmodified to the encrypted, but a Header Field that is copied unmodified to the
unprotected Header Section is signed-only. unprotected Header Section is signed-only.
If the message has Header Protection, Header Fields that are not in If the message has Header Protection, Header Fields that are not in
refprotected (e.g., because they were added in transit), are refprotected (e.g., because they were added in transit) are
unprotected. unprotected.
Rendering the cryptographic status of each Header Field is likely to Rendering the cryptographic status of each Header Field is likely to
be complex and messy --- users may not understand it. It is beyond be complex and messy -- users may not understand it. It is beyond
the scope of this document to suggest any specific graphical the scope of this document to suggest any specific graphical
affordances or user experience. Future work should include examples affordances or user experience. Future work should include examples
of successful rendering of this information. of successful rendering of this information.
4.4. Handling Mismatch of From Header Fields 4.4. Handling Mismatch of From Header Fields
End-to-end (MUA-to-MUA) Header Protection is good for authenticity, End-to-end (MUA-to-MUA) Header Protection is good for authenticity,
integrity, and confidentiality, but it potentially introduces new integrity, and confidentiality, but it potentially introduces new
issues when an MUA depends on its MTA to authenticate parts of the issues when an MUA depends on its MTA to authenticate parts of the
Header Section. The latter is typically the case in modern e-mail Header Section. The latter is typically the case in modern email
systems. systems.
In particular, when an MUA depends on its MTA to ensure that the In particular, when an MUA depends on its MTA to ensure that the
e-mail address in the (unprotected) From Header Field is authentic, email address in the (unprotected) From Header Field is authentic,
but the MUA renders the e-mail address of the protected From Header but the MUA renders the email address of the protected From Header
Field that differs from the address visible to the MTA, this could Field that differs from the address visible to the MTA, this could
create a risk of sender address spoofing (see Section 10.1). This create a risk of sender address spoofing (see Section 10.1). This
potential risk applies to signed-only messages as well as signed-and- potential risk applies to signed-only messages as well as signed-and-
encrypted messages. encrypted messages.
4.4.1. Definitions 4.4.1. Definitions
4.4.1.1. From Header Field Mismatch 4.4.1.1. From Header Field Mismatch
"From Header Field Mismatch" is defined as follows: "From Header Field Mismatch" is defined as follows:
skipping to change at page 32, line 16 skipping to change at line 1431
the actual outer Header Field (as seen by the MTA), not the value the actual outer Header Field (as seen by the MTA), not the value
indicated by any potential inner HP-Outer. indicated by any potential inner HP-Outer.
4.4.1.2. No Valid and Correctly Bound Signature 4.4.1.2. No Valid and Correctly Bound Signature
"No Valid and Correctly Bound Signature" is defined as follows: "No Valid and Correctly Bound Signature" is defined as follows:
There is no valid signature made by a certificate for which the MUA There is no valid signature made by a certificate for which the MUA
has a valid binding to the protected From address. This includes: has a valid binding to the protected From address. This includes:
* the message has no signature, or * the message has no signature,
* the message has a broken signature, or * the message has a broken signature, or
* the message has a valid signature, but the receiving MUA does not * the message has a valid signature, but the receiving MUA does not
see any valid binding between the signing certificate and the see any valid binding between the signing certificate and the
addr-spec of the inner From Header Field. addr-spec of the inner From Header Field.
Note: There are many possible ways that an MUA could choose to Note: There are many possible ways that an MUA could choose to
validate a certificate-to-address binding. For example, the MUA validate a certificate-to-address binding. For example, the MUA
could ensure the certificate is issued by one of a set of trusted could ensure the certificate is issued by one of a set of trusted
certification authorities, it could rely on the user to do a manual certification authorities, it could rely on the user to do a manual
out-of-band comparison, it could rely on a DNSSEC signal ([RFC7929] out-of-band comparison, it could rely on a DNSSEC signal ([RFC7929]
or [RFC8162]), and so on. It is beyond the scope of this document to or [RFC8162]), and so on. It is beyond the scope of this document to
describe all possible ways an MUA might validate the certificate-to- describe all possible ways an MUA might validate the certificate-to-
address binding, or to choose among them. address binding or to choose among them.
4.4.2. Warning for From Header Field Mismatch 4.4.2. Warning for From Header Field Mismatch
To mitigate the above described risk of sender address spoofing, an To mitigate the above described risk of sender address spoofing, an
MUA SHOULD warn the user whenever both of the following conditions MUA SHOULD warn the user whenever both of the following conditions
are met: are met:
* From Header Field Mismatch (as defined in Section 4.4.1.1), and * From Header Field Mismatch (as defined in Section 4.4.1.1)
* No Valid and Correctly Bound Signature (as defined in * No Valid and Correctly Bound Signature (as defined in
Section 4.4.1.2) Section 4.4.1.2)
This warning should be comparable to the MUA's warning about messages This warning should be comparable to the MUA's warning about messages
that are likely spam or phishing, and it SHOULD show both of the non- that are likely spam or phishing, and it SHOULD show both of the non-
matching From Header Fields. matching From Header Fields.
4.4.3. From Header Field Rendering 4.4.3. From Header Field Rendering
Furthermore, a receiving MUA that depends on its MTA to authenticate Furthermore, a receiving MUA that depends on its MTA to authenticate
the unprotected (outer) From Header Field SHOULD render the outer the unprotected (outer) From Header Field SHOULD render the outer
From Header Field (as an exception to the guidance in the beginning From Header Field (as an exception to the guidance in the beginning
of Section 4), if both of the following conditions are met: of Section 4) if both of the following conditions are met:
* From Header Field Mismatch (as defined in Section 4.4.1.1), and * From Header Field Mismatch (as defined in Section 4.4.1.1)
* No Valid and Correctly Bound Signature (as defined in * No Valid and Correctly Bound Signature (as defined in
Section 4.4.1.2) Section 4.4.1.2)
An MUA MAY apply a local preference to render a different display An MUA MAY apply a local preference to render a different display
name (e.g., from an address book). name (e.g., from an address book).
See Section 10.1.1 for an detailed explanation of this rendering See Section 10.1.1 for a detailed explanation of this rendering
guidance. guidance.
4.4.4. Handling Protected From Header Field when Responding 4.4.4. Handling the Protected From Header Field When Responding
When responding to a message, an MUA has different ways to populate When responding to a message, an MUA has different ways to populate
the recipients of the new message. Depending on whether it is a the recipients of the new message. Depending on whether it is a
Reply, a Reply-All, or a Forward, an MUA may populate the composer Reply, a Reply All, or a Forward, an MUA may populate the composer
view using a combination of the referenced message's From, To, Cc, view using a combination of the referenced message's From, To, Cc,
Reply-To, Mail-Followup-To Header Fields, or any other signals. Reply-To, or Mail-Followup-To Header Fields or any other signals.
When responding to a message with Header Protection, an MUA MUST only When responding to a message with Header Protection, an MUA MUST only
use the protected Header Fields when populating the recipients of the use the protected Header Fields when populating the recipients of the
new message. new message.
This avoids compromise of message confidentiality when a MITM This avoids compromise of message confidentiality when a man-in-the-
attacker modifies the unprotected From address of an encrypted middle (MITM) attacker modifies the unprotected From address of an
message, attempting to learn the contents through a misdirected encrypted message, attempting to learn the contents through a
reply. Note that with the rendering guidance above, a MITM attacker misdirected reply. Note that with the rendering guidance above, a
can cause the unprotected From Header Field to be displayed. Thus MITM attacker can cause the unprotected From Header Field to be
when responding, the populated To address may differ from the displayed. Thus, when responding, the populated To address may
rendered From address. However, this change in addresses should not differ from the rendered From address. However, this change in
cause more user confusion than the address change caused by a Reply- addresses should not cause more user confusion than the address
To in a Legacy Message does. change caused by a Reply-To in a Legacy Message does.
4.4.5. Matching addr-specs 4.4.5. Matching addr-specs
When generating (Section 3.1.1) or consuming (Section 4.4) a When generating (Section 3.1.1) or consuming (Section 4.4) a
protected From Header Field, the MUA considers the equivalence of two protected From Header Field, the MUA considers the equivalence of two
different addr-spec values. different addr-spec values.
First, the MUA MUST check whether the domain part of an addr-spec First, the MUA MUST check whether the domain part of an addr-spec
being compared contains any U-label [RFC5890]. If it does, it MUST being compared contains a U-label [RFC5890]. If it does, it MUST be
be converted to the A-label form is described in [RFC5891]. We call converted to the A-label form, which is described in [RFC5891]. We
a domain converted in this way (or the original domain, if it didn't call a domain converted in this way (or the original domain if it
contain any U-label) "the ASCII version of the domain part". Second, didn't contain any U-label) "the ASCII version of the domain part".
the MUA MUST compare the ASCII version of the domain part of the two Second, the MUA MUST compare the ASCII version of the domain part of
addr-specs by standard DNS comparison: assume ASCII text, and compare the two addr-specs by standard DNS comparison: Assume ASCII text and
alphabetic characters case-insensitively, as described in Section 3.1 compare alphabetic characters case-insensitively, as described in
of [RFC1035]. If the domain parts match, then the two local-parts Section 3.1 of [RFC1035]. If the domain parts match, then the two
are matched against each other. The simplest and most common local-parts are matched against each other. The simplest and most
comparison for the local-part is also an ASCII-based, case- common comparison for the local-part is also an ASCII-based, case-
insensitive match. If the MUA has special knowledge about the domain insensitive match. If the MUA has special knowledge about the domain
and, when composing, it can reasonably expect the receiving MUAs to and, when composing, it can reasonably expect the receiving MUAs to
have the same information, it MAY match the local-part using a more have the same information, it MAY match the local-part using a more
sophisticated and inclusive matching algorithm. sophisticated and inclusive matching algorithm.
It is beyond the scope of this document to recommend a more It is beyond the scope of this document to recommend a more
sophisticated and inclusive matching algorithm. sophisticated and inclusive matching algorithm.
4.5. Rendering a Message with Header Protection 4.5. Rendering a Message with Header Protection
When the Cryptographic Payload's Content-Type has the parameter hp When the Cryptographic Payload's Content-Type has the parameter hp
set to "clear" or "cipher", the values of the protected Header Fields set to "clear" or "cipher", the values of the protected Header Fields
are drawn from the Header Fields of the Cryptographic Payload, and are drawn from the Header Fields of the Cryptographic Payload, and
the body that is rendered is the Cryptographic Payload itself. the body that is rendered is the Cryptographic Payload itself.
4.5.1. Example Signed-only Message 4.5.1. Example Signed-Only Message
Consider a message with this structure, where the MUA is able to Consider a message with this structure, where the MUA is able to
validate the cryptographic signature: validate the cryptographic signature:
A └─╴application/pkcs7-mime; smime-type="signed-data" A └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to) ⇩ (unwraps to)
B └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] B └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
C ├─╴text/plain C ├─╴text/plain
D └─╴text/html D └─╴text/html
skipping to change at page 35, line 38 skipping to change at line 1590
I └─╴text/html I └─╴text/html
It should render Header Fields taken from part G. It should render Header Fields taken from part G.
Its Cryptographic Summary should indicate that the message is signed- Its Cryptographic Summary should indicate that the message is signed-
and-encrypted. and-encrypted.
When rendering the Cryptographic Status of a Header Field and when When rendering the Cryptographic Status of a Header Field and when
composing a reply, each Header Field found in G should be considered composing a reply, each Header Field found in G should be considered
against all HP-Outer Header Fields found in G. If an HP-Outer Header against all HP-Outer Header Fields found in G. If an HP-Outer Header
Field is found that matches both the name and value, the Header Field that matches both the name and value is found, the Header
Field's Cryptographic Status is just signed-only, even though the Field's Cryptographic Status is just signed-only, even though the
message itself is signed-and-encrypted. If no matching HP-Outer message itself is signed-and-encrypted. If no matching HP-Outer
Header Field is found, the Header Field's Cryptographic Status is Header Field is found, the Header Field's Cryptographic Status is
signed-and-encrypted, like the rest of the message. signed-and-encrypted, like the rest of the message.
If any of the User-Facing Header Fields are removed or obscured, the If any of the User-Facing Header Fields are removed or obscured, the
composer of this message may have placed Legacy Display Elements in composer of this message may have placed Legacy Display Elements in
parts H and I. parts H and I.
The MUA should ignore Header Fields from part E for the purposes of The MUA should ignore Header Fields from part E for the purposes of
rendering. rendering.
4.5.3. Do Not Render Legacy Display Elements 4.5.3. Do Not Render Legacy Display Elements
As described in Section 2.1.2, a message with cryptographic As described in Section 2.1.2, a message with cryptographic
confidentiality protection MAY include Legacy Display Elements for confidentiality protection MAY include Legacy Display Elements for
backward-compatibility with Legacy MUAs. These Legacy Display backward compatibility with Legacy MUAs. These Legacy Display
Elements are strictly decorative, unambiguously identifiable, and Elements are strictly decorative and unambiguously identifiable and
will be discarded by compliant implementations. will be discarded by compliant implementations.
The receiving MUA MUST avoid rendering the identified Legacy Display The receiving MUA MUST completely avoid rendering the identified
Elements to the user at all, since it is aware of Header Protection Legacy Display Elements to the user, since it is aware of Header
and can render the actual protected Header Fields. Protection and can render the actual protected Header Fields.
If a text/html or text/plain part within the Cryptographic Envelope If a text/html or text/plain part within the Cryptographic Envelope
is identified as containing Legacy Display Elements, those elements is identified as containing Legacy Display Elements, those elements
MUST be hidden when rendering and MUST be dropped when generating a MUST be hidden when rendering and MUST be dropped when generating a
draft reply or inline forwarded message. Whenever a Message or MIME draft reply or inline forwarded message. Whenever a Message or MIME
subtree is exported, downloaded, or otherwise further processed, if subtree is exported, downloaded, or otherwise further processed, if
there is no need to retain a valid cryptographic signature, the there is no need to retain a valid cryptographic signature, the
implementer MAY drop the Legacy Display Elements. implementer MAY drop the Legacy Display Elements.
4.5.3.1. Identifying a Part with Legacy Display Elements 4.5.3.1. Identifying a Part with Legacy Display Elements
A receiving MUA acting on a message that contains an encrypting A receiving MUA acting on a message that contains an encrypting
Cryptographic Layer identifies a MIME subpart within the Cryptographic Layer identifies a MIME subpart within the
Cryptographic Payload as containing Legacy Display Elements based on Cryptographic Payload as containing Legacy Display Elements based on
the Content-Type of the subpart. The subpart's Content-Type: the Content-Type of the subpart. The subpart's Content-Type:
* contains a parameter hp-legacy-display with value set to 1, and * contains a parameter hp-legacy-display with value set to 1 and
* is either text/html (see Section 4.5.3.3) or text/plain (see * is either text/html (see Section 4.5.3.3) or text/plain (see
Section 4.5.3.2). Section 4.5.3.2).
Note that the term "subpart" above is used in the general sense: if Note that the term "subpart" above is used in the general sense: If
the Cryptographic Payload is a single part, that part itself may the Cryptographic Payload is a single part, that part itself may
contain a Legacy Display Element if it is marked with the hp-legacy- contain a Legacy Display Element if it is marked with the hp-legacy-
display=1 parameter. display="1" parameter.
4.5.3.2. Omitting Legacy Display Elements from text/plain 4.5.3.2. Omitting Legacy Display Elements from text/plain
If a text/plain part within the Cryptographic Payload has the If a text/plain part within the Cryptographic Payload has the
Content-Type parameter hp-legacy-display="1", it should be processed Content-Type parameter hp-legacy-display="1", it should be processed
before rendering in the following fashion: before rendering in the following fashion:
* Discard the leading lines of the body of the part up to and * Discard the leading lines of the body of the part up to and
including the first entirely blank line. including the first entirely blank line.
skipping to change at page 37, line 19 skipping to change at line 1666
If a text/html part within the Cryptographic Payload has the Content- If a text/html part within the Cryptographic Payload has the Content-
Type parameter hp-legacy-display="1", it should be processed before Type parameter hp-legacy-display="1", it should be processed before
rendering in the following fashion: rendering in the following fashion:
* If any element of the HTML <body> is a <div> with class attribute * If any element of the HTML <body> is a <div> with class attribute
header-protection-legacy-display, that entire element should be header-protection-legacy-display, that entire element should be
omitted. omitted.
This cleanup could be done, for example, as a custom rule in the This cleanup could be done, for example, as a custom rule in the
MUA's HTML sanitizer, if one exists. Another implementation strategy MUA's HTML sanitizer, if one exists. Another implementation strategy
for an HTML-capable MUA would be to add an entry to the [CSS] for an HTML-capable MUA would be to add an entry to the [CSS] style
stylesheet for such a part: sheet for such a part:
body div.header-protection-legacy-display { display: none; } body div.header-protection-legacy-display { display: none; }
4.6. Implicitly rendered Header Fields 4.6. Implicitly Rendered Header Fields
While From, To, Cc, Subject, and Date Header Fields are often While the From, To, Cc, Subject, and Date Header Fields are often
explicitly rendered to the user, some Header Fields do affect message explicitly rendered to the user, some Header Fields do affect message
display, without being explicitly rendered. display without being explicitly rendered.
For example, Message-Id, References, and In-Reply-To Header Fields For example, the Message-Id, References, and In-Reply-To Header
may collectively be used to place a message in a "thread" or series Fields may collectively be used to place a message in a "thread" or
of messages. series of messages.
In another example, Section 6.2 observes that the value of the Reply- In another example, Section 6.2 notes that the value of the Reply-To
To field can influence the draft reply message. So while the user field can influence the draft reply message. So while the user may
may never see the Reply-To Header Field directly, it is implicitly never see the Reply-To Header Field directly, it is implicitly
"rendered" when the user interacts with the message by replying to "rendered" when the user interacts with the message by replying to
it. it.
An MUA that depends on any implicitly rendered Header Field in a An MUA that depends on any implicitly rendered Header Field in a
message with Header Protection MUST use the value from the protected message with Header Protection MUST use the value from the protected
Header Field, and SHOULD NOT use any value found outside the Header Field and SHOULD NOT use any value found outside the
cryptographic protection unless it is known to be a Header Field cryptographic protection unless it is known to be a Header Field
added in transit, as specified in Section 7. added in transit, as specified in Section 7.
4.7. Handling Undecryptable Messages 4.7. Handling Undecryptable Messages
An MUA might receive an apparently encrypted message that it cannot An MUA might receive an apparently encrypted message that it cannot
currently decrypt. For example, when an MUA does not have regular currently decrypt. For example, when an MUA does not have regular
access to the secret key material needed for decryption, it cannot access to the secret key material needed for decryption, it cannot
know the cryptographically protected Header Fields or even whether know the cryptographically protected Header Fields or even whether
the message has any cryptographically protected Header Fields. the message has any cryptographically protected Header Fields.
skipping to change at page 38, line 43 skipping to change at line 1739
the decryption-capable secret key material is available. the decryption-capable secret key material is available.
To reduce or avoid the surprises associated with a decrypted message To reduce or avoid the surprises associated with a decrypted message
with removed or obscured Header Fields becoming undecryptable, the with removed or obscured Header Fields becoming undecryptable, the
MUA could also: MUA could also:
* Securely cache metadata from a decrypted message's protected * Securely cache metadata from a decrypted message's protected
Header Fields so that its rendering doesn't change after the first Header Fields so that its rendering doesn't change after the first
decryption. decryption.
* Securely store the session key associated with a decrypted * Securely store the session key associated with a decrypted message
message, so that attempts to read the message when the long-term so that attempts to read the message when the long-term secret key
secret key are unavailable can proceed using only the session key is unavailable can proceed using only the session key itself. For
itself. See, for example, the discussion about stashing session example, see the discussion about stashing session keys in
keys in Section 9.1 of [I-D.ietf-lamps-e2e-mail-guidance]. Section 9.1 of [RFC9787].
4.8. Guidance for Automated Message Handling 4.8. Guidance for Automated Message Handling
Some automated systems have a control channel that is operated by Some automated systems have a control channel that is operated by
e-mail. For example, an incoming e-mail message could subscribe email. For example, an incoming email message could subscribe
someone to a mailing list, initiate the purchase of a specific someone to a mailing list, initiate the purchase of a specific
product, approve another message for redistribution, or adjust the product, approve another message for redistribution, or adjust the
state of some shared object. state of some shared object.
To the extent that such a system depends on end-to-end cryptographic To the extent that such a system depends on end-to-end cryptographic
guarantees about the e-mail control message, Header Protection as guarantees about the email control message, Header Protection as
defined in this document should improve the system's security. This defined in this document should improve the system's security. This
section provides some specific guidance for systems that use e-mail section provides some specific guidance for systems that use email
messages as a control channel that want to benefit from these messages as a control channel that want to benefit from these
security improvements. security improvements.
4.8.1. Interpret Only Protected Header Fields 4.8.1. Only Interpret Protected Header Fields
Consider the situation where an e-mail-based control channel depends Consider the situation where an email-based control channel depends
on the message's cryptographic signature and the action taken depends on the message's cryptographic signature and the action taken depends
on some Header Field of the message. on some Header Field of the message.
In this case, the automated system MUST rely on information from the In this case, the automated system MUST rely on information from the
Header Field that is protected by the mechanism defined in this Header Field that is protected by the mechanism defined in this
document. It MUST NOT rely on any Header Field found outside the document. It MUST NOT rely on any Header Field found outside the
Cryptographic Payload. Cryptographic Payload.
For example, consider an administrative interface for a mailing list For example, consider an administrative interface for a mailing list
manager that only accepts control messages that are signed by one of manager that only accepts control messages that are signed by one of
its administrators. When an inbound message for the list arrives, it its administrators. When an inbound message for the list arrives, it
is queued (waiting for administrative approval) and the system is queued (waiting for administrative approval) and the system
generates and listens for two distinct e-mail addresses related to generates and listens for two distinct email addresses related to the
the queued message -- one that approves the message, and one that queued message -- one that approves the message and one that rejects
rejects it. If an administrator sends a signed control message to it. If an administrator sends a signed control message to the
the approval address, the mailing list verifies that the protected To approval address, the mailing list verifies that the protected To
Header Field of the signed control message contains the approval Header Field of the signed control message contains the approval
address before approving the queued message for redistribution. If address before approving the queued message for redistribution. If
the protected To Header Field does not contain that address, or there the protected To Header Field does not contain that address, or there
is no protected To Header Field, then the mailing list logs or is no protected To Header Field, then the mailing list logs or
reports the error and does not act on that control message. reports the error and does not act on that control message.
4.8.2. Ignore Legacy Display Elements 4.8.2. Ignore Legacy Display Elements
Consider the situation where an e-mail-based control channel expects Consider the situation where an email-based control channel expects
to receive an end-to-end encrypted message -- for example, where the to receive an end-to-end encrypted message -- for example, where the
control messages need confidentiality guarantees -- and where the control messages need confidentiality guarantees -- and where the
action taken depends on the contents of some MIME part within the action taken depends on the contents of some MIME part within the
message body. message body.
In this case, the automated system that decrypts the incoming In this case, the automated system that decrypts the incoming
messages and scans the relevant MIME part MUST identify when the MIME messages and scans the relevant MIME part MUST identify when the MIME
part contains a Legacy Display Element (see Section 4.5.3.1), and it part contains a Legacy Display Element (see Section 4.5.3.1), and it
MUST parse the relevant MIME part with the Legacy Display Element MUST parse the relevant MIME part with the Legacy Display Element
removed. removed.
For example, consider an administrative interface of a confidential For example, consider an administrative interface of a confidential
issue tracking software. An authorized user can confidentially issue tracking software. An authorized user can confidentially
adjust the status of a tracked issue by a specially formatted first adjust the status of a tracked issue by a specially formatted first
line of the message body (for example, severity #183 serious). When line of the message body (for example, severity #183 serious). When
the user's MUA encrypts a plain text control message to this issue the user's MUA encrypts a plaintext control message to this issue
tracker, depending on the MUA's HCP and its choice of legacy value, tracker, depending on the MUA's HCP and its choice of legacy value,
it may add a Legacy Display Element. If it does so, then the first it may add a Legacy Display Element. If it does so, then the first
line of the message body will contain a decorative copy of the line of the message body will contain a decorative copy of the
confidential Subject Header Field. The issue tracking software confidential Subject Header Field. The issue tracking software
decrypts the incoming control message, identifies that there is a decrypts the incoming control message, identifies that there is a
Legacy Display Element in the part (see Section 4.5.3.1), strips the Legacy Display Element in the part (see Section 4.5.3.1), strips the
lines comprising the Legacy Display Element (including the first lines comprising the Legacy Display Element (including the first
blank line), and only then parses the remaining top line to look for blank line), and only then parses the remaining top line to look for
the expected special formatting. the expected special formatting.
4.9. Affordances for Debugging and Troubleshooting 4.9. Affordances for Debugging and Troubleshooting
Note that advanced users of an MUA may need access to the original Note that advanced users of an MUA may need access to the original
message, for example to troubleshoot problems with the rendering MUA message, for example, to troubleshoot problems with the rendering MUA
itself, or problems with the SMTP transport path taken by the itself or problems with the SMTP transport path taken by the message.
message.
An MUA that applies these rendering guidelines SHOULD ensure that the An MUA that applies these rendering guidelines SHOULD ensure that the
full original source of the message as it was received remains full original source of the message as it was received remains
available to such a user for debugging and troubleshooting. available to such a user for debugging and troubleshooting.
If a troubleshooting scenario demands information about the If a troubleshooting scenario demands information about the
cryptographically protected values of Header Fields, and the message cryptographically protected values of Header Fields, and the message
is encrypted, the debugging interface SHOULD also provide a "source" is encrypted, the debugging interface SHOULD also provide a "source"
view of the Cryptographic Payload itself, alongside the full original view of the Cryptographic Payload itself, alongside the full original
source of the message as received. source of the message as received.
4.10. Handling RFC8551HP Messages (Backward Compatibility) 4.10. Handling RFC8551HP Messages (Backward Compatibility)
Section 1.1.1 describes some drawbacks to the Header Protection Section 1.1.1 describes some drawbacks to the Header Protection
scheme defined in [RFC8551], referred to here as RFC8551HP. An MUA scheme defined in [RFC8551], referred to here as RFC8551HP. An MUA
MUST NOT generate an RFC8551HP message. However, for backward MUST NOT generate an RFC8551HP message. However, for backward
compatibility an MUA MAY try to render or respond to such a message compatibility, an MUA MAY try to render or respond to such a message
as though the message has standard Header Protection. as though the message has standard Header Protection.
The following two sections contain guidance for identifying, The following two sections contain guidance for identifying,
rendering and replying to RFC8551HP messages. Corresponding test rendering, and replying to RFC8551HP messages. Corresponding test
vectors are provided in Appendix C.2.5, Appendix C.2.6, and vectors are provided in Appendices C.2.5, C.2.6, and C.3.17.
Appendix C.3.17.
4.10.1. Identifying an RFC8551HP Message 4.10.1. Identifying an RFC8551HP Message
An RFC8551HP Message can be identified by its MIME structure, given An RFC8551HP message can be identified by its MIME structure, given
that all of the following conditions are met: that all of the following conditions are met:
* It has a well-formed Cryptographic Envelope consisting of at least * It has a well-formed Cryptographic Envelope consisting of at least
one Cryptographic Layer as the outermost MIME object. one Cryptographic Layer as the outermost MIME object.
* The Cryptographic Payload is a single message/rfc822 object * The Cryptographic Payload is a single message/rfc822 object.
* The message that constitutes the Cryptographic Payload does not * The message that constitutes the Cryptographic Payload does not
itself have a well-formed Cryptographic Envelope; that is, its itself have a well-formed Cryptographic Envelope; that is, its
outermost MIME object is not a Cryptographic Layer. outermost MIME object is not a Cryptographic Layer.
* No Content-Type parameter of hp= is set on either the * No Content-Type parameter of hp= is set on either the
Cryptographic Payload, or its immediate MIME child. Cryptographic Payload or its immediate MIME child.
Here is the MIME structure of an example signed-and-encrypted Here is the MIME structure of an example signed-and-encrypted
RFC8551HP message: RFC8551HP message:
A └─╴application/pkcs7-mime; smime-type="enveloped-data" A └─╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to) ↧ (decrypts to)
B └─╴application/pkcs7-mime; smime-type="signed-data" B └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to) ⇩ (unwraps to)
C └┬╴message/rfc822 [Cryptographic Payload] C └┬╴message/rfc822 [Cryptographic Payload]
D └┬╴multipart/alternative [Rendered Body] D └┬╴multipart/alternative [Rendered Body]
E ├─╴text/plain E ├─╴text/plain
F └─╴text/html F └─╴text/html
This meets the definition of an RFC8551HP message because: This meets the definition of an RFC8551HP message because:
* Cryptographic Layers A and B form the Cryptographic Envelope. * Cryptographic Layers A and B form the Cryptographic Envelope.
* The Cryptographic Payload, rooted in part C has Content-Type: * The Cryptographic Payload, rooted in part C, has Content-Type:
message/rfc822. message/rfc822.
* Part D (the MIME root of the message at C) is itself not a * Part D (the MIME root of the message at C) is itself not a
Cryptographic Layer. Cryptographic Layer.
* Neither part C nor part D have any hp parameter set on their * Neither part C nor part D have any hp parameters set on their
Content-Type. Content-Type.
4.10.2. Rendering or Responding to an RFC8551HP message 4.10.2. Rendering or Responding to an RFC8551HP Message
When it has precisely identified a message as an RFC8551HP message, When an MUA has precisely identified a message as an RFC8551HP
an MUA MAY render or respond to that message as though it were a message, the MUA MAY render or respond to that message as though it
message with Header Protection as defined in this document by making were a message with Header Protection as defined in this document by
the following adjustments: making the following adjustments:
* Rather than rendering the message body as the Cryptographic * Rather than rendering the message body as the Cryptographic
Payload itself (part C in the example above), render the RFC8551HP Payload itself (part C in the example above), render the RFC8551HP
message's body as the MIME subtree that is the Cryptographic message's body as the MIME subtree that is the Cryptographic
Payload's immediate child (part D). Payload's immediate child (part D).
* Make a comparable modification to HeaderSetsFromMessage * Make a comparable modification to HeaderSetsFromMessage
(Section 4.2.1) and HeaderFieldProtection (Section 4.3.1): both (Section 4.2.1) and HeaderFieldProtection (Section 4.3.1): Both
algorithms currently look for the protected Header Fields on the algorithms currently look for the protected Header Fields on the
Cryptographic Payload (part C), but they should instead look at Cryptographic Payload (part C), but they should instead look at
the Cryptographic Payload's immediate child (part D). the Cryptographic Payload's immediate child (part D).
* If the Cryptographic Envelope is signed-only, behave as though * If the Cryptographic Envelope is signed-only, behave as though
there is an hp="clear" parameter for the Cryptographic Payload; if there is an hp="clear" parameter for the Cryptographic Payload; if
the Envelope contains encryption, behave as though there is an the Envelope contains encryption, behave as though there is an
hp="cipher" parameter. That is, infer the sender's cryptographic hp="cipher" parameter. That is, infer the sender's cryptographic
intent from the structure of the message. intent from the structure of the message.
* If the Cryptographic Envelope contains encryption, further modify * If the Cryptographic Envelope contains encryption, further modify
HeaderSetsFromMessage to derive refouter from the actual outer HeaderSetsFromMessage to derive refouter from the actual outer
message Header Fields (those found in part A in the example message Header Fields (those found in part A in the example above)
above), rather than looking for HP-Outer Header Fields with the rather than looking for HP-Outer Header Fields with the other
other protected Header Fields. That is, infer Header Field protected Header Fields. That is, infer Header Field
confidentiality based on the unprotected headers. confidentiality based on the unprotected headers.
The inferences in the above modifications are not based on any strong The inferences in the above modifications are not based on any strong
end-to-end guarantees. An intervening MTA may tamper with the end-to-end guarantees. An intervening MTA may tamper with the
message's outer Header Section or wrap the message in an encryption message's outer Header Section or wrap the message in an encryption
layer to undetectably change the recipient's understanding of the layer to undetectably change the recipient's understanding of the
confidentiality of the message's Header Fields or the message body confidentiality of the message's Header Fields or the message body
itself. itself.
4.11. Rendering Other Schemes 4.11. Rendering Other Schemes
skipping to change at page 43, line 9 skipping to change at line 1937
is NOT RECOMMENDED to generate these other schemes, as they can is NOT RECOMMENDED to generate these other schemes, as they can
either have structural flaws or simply render poorly on Legacy MUAs. either have structural flaws or simply render poorly on Legacy MUAs.
A conformant MUA MAY attempt to infer Header Protection when A conformant MUA MAY attempt to infer Header Protection when
rendering an existing message that appears to use some other scheme rendering an existing message that appears to use some other scheme
not documented here. Pointers to some known other schemes can be not documented here. Pointers to some known other schemes can be
found in Appendix F. found in Appendix F.
5. Sending Guidance 5. Sending Guidance
This section describes the process an MUA should use to apply This section describes the process an MUA should use to apply
cryptographic protection to an e-mail message with Header Protection. cryptographic protection to an email message with Header Protection.
When composing a message with end-to-end cryptographic protections, When composing a message with end-to-end cryptographic protections,
an MUA SHOULD apply Header Protection. an MUA SHOULD apply Header Protection.
When generating such a message, an MUA MUST add the hp parameter (see When generating such a message, an MUA MUST add the hp parameter (see
Section 2.1.1) only to the Content-Type Header Field at the root of Section 2.1.1) only to the Content-Type Header Field at the root of
the message's Cryptographic Payload. The value of the parameter MUST the message's Cryptographic Payload. The value of the parameter MUST
indicate whether the Cryptographic Envelope contains a layer that indicate whether the Cryptographic Envelope contains a layer that
provides encryption. provides encryption.
5.1. Composing a Cryptographically Protected Message Without Header 5.1. Composing a Cryptographically Protected Message Without Header
Protection Protection
For contrast, we first consider the typical message composition For contrast, we first consider the typical message composition
process of a Legacy Crypto MUA which does not provide any Header process of a Legacy Crypto MUA, which does not provide any Header
Protection. Protection.
This process is described in Section 5.1 of This process is described in Section 5.1 of [RFC9787]. We replicate
[I-D.ietf-lamps-e2e-mail-guidance]. We replicate it here for it here for reference. The inputs to the algorithm are:
reference. The inputs to the algorithm are:
* origbody: the traditional unprotected message body as a well- * origbody: The traditional unprotected message body as a well-
formed MIME tree (possibly just a single MIME leaf part). As a formed MIME tree (possibly just a single MIME leaf part). As a
well-formed MIME tree, origbody already has structural Header well-formed MIME tree, origbody already has structural Header
Fields (Content-*) present. Fields (Content-*) present.
* origheaders: the intended non-structural Header Fields for the * origheaders: The intended non-structural Header Fields for the
message, represented here as a list of (h,v) pairs, where h is a message, represented here as a list of (h,v) pairs, where h is a
Header Field name and v is the associated value. Note that these Header Field name and v is the associated value. Note that these
are Header Fields that the MUA intends to be visible to the are Header Fields that the MUA intends to be visible to the
recipient of the message. In particular, if the MUA uses the Bcc recipient of the message. In particular, if the MUA uses the Bcc
Header Field during composition, but plans to omit it from the Header Field during composition but plans to omit it from the
message (see Section 3.6.3 of [RFC5322]), it will not be in message (see Section 3.6.3 of [RFC5322]), it will not be in
origheaders. origheaders.
* crypto: The series of cryptographic protections to apply (for * crypto: The series of cryptographic protections to apply (for
example, "sign with the secret key corresponding to X.509 example, "sign with the secret key corresponding to X.509
certificate X, then encrypt to X.509 certificates X and Y"). This certificate X, then encrypt to X.509 certificates X and Y"). This
is a routine that accepts a MIME tree as input (the Cryptographic is a routine that accepts a MIME tree as input (the Cryptographic
Payload), wraps the input in the appropriate Cryptographic Payload), wraps the input in the appropriate Cryptographic
Envelope, and returns the resultant MIME tree as output. Envelope, and returns the resultant MIME tree as output.
The algorithm returns a MIME object that is ready to be injected into The algorithm returns a MIME object that is ready to be injected into
the mail system. the mail system.
5.1.1. ComposeNoHeaderProtection 5.1.1. ComposeNoHeaderProtection
Method Signature: Method Signature:
ComposeNoHeaderProtection(origbody, origheaders, crypto) → ComposeNoHeaderProtection(origbody, origheaders, crypto) ->
mime_message mime_message
Procedure: Procedure:
1. Apply crypto to MIME part origbody, producing MIME tree output 1. Apply crypto to MIME part origbody, producing MIME tree output.
2. For each Header Field name and value (h,v) in origheaders: 2. For each Header Field name and value (h,v) in origheaders:
i. Add Header Field h to output with value v i. Add Header Field h to output with value v.
3. Return output 3. Return output.
5.2. Composing a Message with Header Protection 5.2. Composing a Message with Header Protection
To compose a message using Header Protection, the composing MUA uses To compose a message using Header Protection, the composing MUA uses
the following inputs: the following inputs:
* All the inputs described in Section 5.1 * all the inputs described in Section 5.1
* hcp: a Header Confidentiality Policy, as defined in Section 3 * hcp: a Header Confidentiality Policy, as defined in Section 3
* respond: if the new message is a response to another message * respond: if the new message is a response to another message
(e.g., "Reply", "Reply All", "Forward", etc), the MUA function (e.g., "Reply", "Reply All", "Forward", etc.), the MUA function
corresponding to the user's action (see Section 6.1), otherwise corresponding to the user's action (see Section 6.1), otherwise
null null
* refmsg: if the new message is a response to another message, the * refmsg: if the new message is a response to another message, the
message being responded to, otherwise null message being responded to, otherwise null
* legacy: a boolean value, indicating whether any recipient of the * legacy: a boolean value, indicating whether any recipient of the
message is believed to have a Legacy MUA. If all recipients are message is believed to have a Legacy MUA. If all recipients are
known to implement this document, legacy should be set to false. known to implement this document, legacy should be set to false.
(How an MUA determines the value of legacy is out of scope for (How an MUA determines the value of legacy is out of scope for
this document; an initial implementation can simply set it to this document; an initial implementation can simply set it to
true) true.)
To enable visibility of User-Facing but now removed/obscured Header To enable visibility of User-Facing but now removed/obscured Header
Fields for decryption-capable Legacy MUAs, the Header Fields are Fields for decryption-capable Legacy MUAs, the Header Fields are
included as a decorative Legacy Display Element in specially marked included as a decorative Legacy Display Element in specially marked
parts of the message (see Section 2.1.2). This document recommends parts of the message (see Section 2.1.2). This document recommends
two mechanisms for such a decorative adjustment: one for a text/html two mechanisms for such a decorative adjustment: one for a text/html
Main Body Part of the e-mail message, and one for a text/plain Main Main Body Part of the email message and one for a text/plain Main
Body Part. This document does not recommend adding a Legacy Display Body Part. This document does not recommend adding a Legacy Display
Element to any other part. Element to any other part.
Please see Section 7.1 of [I-D.ietf-lamps-e2e-mail-guidance] for Please see Section 7.1 of [RFC9787] for guidance on identifying the
guidance on identifying the parts of a message that are a Main Body parts of a message that are a Main Body Part.
Part.
5.2.1. Compose 5.2.1. Compose
Method Signature: Method Signature:
Compose(origbody, origheaders, crypto, hcp, respond, refmsg, legacy) Compose(origbody, origheaders, crypto, hcp, respond, refmsg, legacy)
→ mime_message -> mime_message
Procedure: Procedure:
1. Let newbody be a copy of origbody 1. Let newbody be a copy of origbody.
2. If crypto contains encryption, and legacy is true: 2. If crypto contains encryption and legacy is true:
i. Create ldlist, an empty list of (header, value) pairs i. Create ldlist, an empty list of (header, value) pairs.
ii. For each Header Field name and value (h,v) in origheaders: ii. For each Header Field name and value (h,v) in origheaders:
a. If h is User-Facing (see Section 1.1.2 of a. If h is User-Facing (see Section 1.1.2 of [RFC9787]):
[I-D.ietf-lamps-e2e-mail-guidance]):
I. If hcp(h,v) is not v: I. If hcp(h,v) is not v:
A. Add (h,v) to ldlist A. Add (h,v) to ldlist.
iii. If ldlist is not empty: iii. If ldlist is not empty:
a. Identify each leaf MIME part of newbody that represents a. Identify each leaf MIME part of newbody that represents
the "main body" of the message. the "main body" of the message.
b. For each "Main Body Part" bodypart of type text/plain b. For each "Main Body Part" bodypart of type text/plain
or text/html: or text/html:
I. Adjust bodypart by inserting a Legacy Display I. Adjust bodypart by inserting a Legacy Display
Element header list ldlist into its content, and Element header list ldlist into its content and
adding a Content-Type parameter hp-legacy-display adding a Content-Type parameter hp-legacy-display
with value 1 (see Section 5.2.2 for text/plain and with value 1 (see Section 5.2.2 for text/plain and
Section 5.2.3 for text/html) Section 5.2.3 for text/html).
3. For each Header Field name and value (h,v) in origheaders: 3. For each Header Field name and value (h,v) in origheaders:
i. Add Header Field h to MIME part newbody with value v i. Add Header Field h to MIME part newbody with value v.
4. If crypto does not contain encryption: 4. If crypto does not contain encryption:
i. Set the hp parameter on the Content-Type of MIME part i. Set the hp parameter on the Content-Type of MIME part
newbody to clear newbody to clear.
ii. Let newheaders be a copy of origheaders ii. Let newheaders be a copy of origheaders.
5. Else (if crypto contains encryption): 5. Else (if crypto contains encryption):
i. Set the hp parameter on the Content-Type of MIME part i. Set the hp parameter on the Content-Type of MIME part
newbody to cipher newbody to cipher.
ii. If refmsg is not null, respond is not null, and refmsg ii. If refmsg is not null, respond is not null, and refmsg
itself is encrypted with header protection: itself is encrypted with header protection:
a. Let response_hcp be a single-use HCP derived from a. Let response_hcp be a single-use HCP derived from
respond and refmsg (see Section 6.1) respond and refmsg (see Section 6.1).
iii. Else (if this is not a response to an encrypted, header- iii. Else (if this is not a response to an encrypted, header-
protected message): protected message):
a. Set response_hcp to hcp_no_confidentiality a. Set response_hcp to hcp_no_confidentiality.
iv. Create new empty list of Header Field names and values iv. Create a new empty list of Header Field names and values
newheaders newheaders.
v. For each Header Field name and value (h,v) in origheaders: v. For each Header Field name and value (h,v) in origheaders:
a. Let newval be hcp(h,v) a. Let newval be hcp(h,v).
b. If newval is v: b. If newval is v:
I. Let newval be response_hcp(h,v) I. Let newval be response_hcp(h,v).
c. If newval is not null): c. If newval is not null):
I. Add (h,newval) to newheaders I. Add (h,newval) to newheaders.
vi. For each Header Field name and value (h,v) in newheaders: vi. For each Header Field name and value (h,v) in newheaders:
a. Let string record be the concatenation of h, a literal a. Let string record be the concatenation of h, a literal
": " (ASCII colon (0x3A) followed by ASCII space ": " (ASCII colon (0x3A) followed by ASCII space
(0x20)), and v (0x20)), and v.
b. Add Header Field "HP-Outer" to MIME part newbody with b. Add Header Field "HP-Outer" to MIME part newbody with
value record value record.
6. Apply crypto to MIME part newbody, producing MIME tree output 6. Apply crypto to MIME part newbody, producing MIME tree output.
7. For each Header Field name and value (h,v) in newheaders: 7. For each Header Field name and value (h,v) in newheaders:
i. Add Header Field h to output with value v i. Add Header Field h to output with value v.
8. Return output 8. Return output.
Note that both new parameters (hcp and legacy) are effectively Note that both new parameters (hcp and legacy) are effectively
ignored if crypto does not contain encryption. This is by design, ignored if crypto does not contain encryption. This is by design,
because they are irrelevant for signed-only cryptographic because they are irrelevant for signed-only cryptographic
protections. protections.
5.2.2. Adding a Legacy Display Element to a text/plain Part 5.2.2. Adding a Legacy Display Element to a text/plain Part
For a list of obscured and removed User-Facing Header Fields For a list of obscured and removed User-Facing Header Fields
represented as (header, value) pairs, concatenate them as a set of represented as (header, value) pairs, concatenate them as a set of
skipping to change at page 47, line 38 skipping to change at line 2156
Element was added. Element was added.
For example, if the list of obscured Header Fields was [("Cc", For example, if the list of obscured Header Fields was [("Cc",
"alice@example.net"), ("Subject", "Thursday's meeting")], then a "alice@example.net"), ("Subject", "Thursday's meeting")], then a
text/plain Main Body Part that originally looked like this: text/plain Main Body Part that originally looked like this:
Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset=UTF-8
I think we should skip the meeting. I think we should skip the meeting.
Would become: would become:
Content-Type: text/plain; charset=UTF-8; hp-legacy-display=1 Content-Type: text/plain; charset=UTF-8; hp-legacy-display=1
Subject: Thursday's meeting Subject: Thursday's meeting
Cc: alice@example.net Cc: alice@example.net
I think we should skip the meeting. I think we should skip the meeting.
Note that the Legacy Display Element (the lines beginning with Note that the Legacy Display Elements (the lines beginning with
Subject: and Cc:) are part of the body of the MIME part in question. Subject: and Cc:) are part of the body of the MIME part in question.
This example assumes that the Main Body Part in question is not the This example assumes that the Main Body Part in question is not the
root of the Cryptographic Payload. For instance, it could be a leaf root of the Cryptographic Payload. For instance, it could be a leaf
of a multipart/alternative Cryptographic Payload. This is why no of a multipart/alternative Cryptographic Payload. This is why no
additional Header Fields have been injected into the MIME part in additional Header Fields have been injected into the MIME part in
this example. this example.
5.2.3. Adding a Legacy Display Element to a text/html Part 5.2.3. Adding a Legacy Display Element to a text/html Part
skipping to change at page 48, line 45 skipping to change at line 2208
For example, if the list of obscured Header Fields was [("Cc", For example, if the list of obscured Header Fields was [("Cc",
"alice@example.net"), ("Subject", "Thursday's meeting")], then a "alice@example.net"), ("Subject", "Thursday's meeting")], then a
text/html Main Body Part that originally looked like this: text/html Main Body Part that originally looked like this:
Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=UTF-8
<html><head><title></title></head><body> <html><head><title></title></head><body>
<p>I think we should skip the meeting.</p> <p>I think we should skip the meeting.</p>
</body></html> </body></html>
Would become: would become:
Content-Type: text/html; charset=UTF-8; hp-legacy-display=1 Content-Type: text/html; charset=UTF-8; hp-legacy-display=1
<html><head><title></title></head><body> <html><head><title></title></head><body>
<div class="header-protection-legacy-display"> <div class="header-protection-legacy-display">
<pre>Subject: Thursday's meeting <pre>Subject: Thursday's meeting
Cc: alice@example.net</pre></div> Cc: alice@example.net</pre></div>
<p>I think we should skip the meeting.</p> <p>I think we should skip the meeting.</p>
</body></html> </body></html>
This example assumes that the Main Body Part in question is not the This example assumes that the Main Body Part in question is not the
root of the Cryptographic Payload. For instance, it could be a leaf root of the Cryptographic Payload. For instance, it could be a leaf
of a multipart/alternative Cryptographic Payload. This is why no of a multipart/alternative Cryptographic Payload. This is why no
additional Header Fields have been injected into the MIME part in additional Header Fields have been injected into the MIME part in
this example. this example.
5.2.3.1. Step-by-step Example for Inserting Legacy Display Element to 5.2.3.1. Step-by-Step Example for Inserting a Legacy Display Element
text/html into text/html
A composing MUA MAY insert the Legacy Display Element anywhere A composing MUA MAY insert the Legacy Display Element anywhere
reasonable within the message as long as it prioritizes visibility reasonable within the message as long as it prioritizes visibility
for the reader using a Legacy decryption-capable MUA. This decision for the reader using a Legacy MUA that is capable of decryption.
may take into account special message-specific HTML formatting This decision may take into account special message-specific HTML
expectations if the MUA is aware of them. However, some MUAs may not formatting expectations if the MUA is aware of them. However, some
have any special insight into the user's preferred HTML formatting, MUAs may not have any special insight into the user's preferred HTML
and still want to insert a Legacy Display Element. This section formatting and still want to insert a Legacy Display Element. This
offers a non-normative, simple, and minimal step-by-step approach for section offers a non-normative, simple, and minimal step-by-step
a composing MUA that has no other information or preferences to fall approach for a composing MUA that has no other information or
back on. preferences to fall back on.
The process below assumes that the MUA already has the full HTML 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 object that it intends to send, including all of the text supplied by
the user. the user.
1. Assemble the text exactly as specified for text/plain (see 1. Assemble the text exactly as specified for text/plain (see
Section 5.2.2). Section 5.2.2).
2. Wrap that text in a verbatim <pre> element. 2. Wrap that text in a verbatim <pre> element.
skipping to change at page 50, line 8 skipping to change at line 2259
class header-protection-legacy-display. class header-protection-legacy-display.
4. Find the <body> element of the full HTML object. 4. Find the <body> element of the full HTML object.
5. Insert the <div> element as the first child of the <body> 5. Insert the <div> element as the first child of the <body>
element. element.
5.2.4. Only Add a Legacy Display Element to Main Body Parts 5.2.4. Only Add a Legacy Display Element to Main Body Parts
Some messages may contain a text/plain or text/html subpart that is Some messages may contain a text/plain or text/html subpart that is
_not_ a Main Body Part. For example, an e-mail message might contain _not_ a Main Body Part. For example, an email message might contain
an attached text file or a downloaded webpage. Attached documents an attached text file or a downloaded web page. Attached documents
need to be preserved as intended in the transmission, without need to be preserved as intended in the transmission, without
modification. modification.
The composing MUA MUST NOT add a Legacy Display Element to any part 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 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 part is annotated with Content-Disposition: attachment, or if it does
not descend via the first child of any of its multipart/mixed or not descend via the first child of any of its multipart/mixed or
multipart/related ancestors, it is not a Main Body Part, and MUST NOT multipart/related ancestors, it is not a Main Body Part and MUST NOT
be modified. be modified.
See Section 7.1 of [I-D.ietf-lamps-e2e-mail-guidance] for more See Section 7.1 of [RFC9787] for more guidance about common ways to
guidance about common ways to distinguish Main Body Parts from other distinguish Main Body Parts from other MIME parts in a message.
MIME parts in a message.
5.2.5. Do Not Add a Legacy Display Element to Other Content-Types 5.2.5. Do Not Add a Legacy Display Element to Other Content-Types
The purpose of injecting a Legacy Display Element into each Main Body The purpose of injecting a Legacy Display Element into each Main Body
MIME part is to enable rendering of otherwise obscured Header Fields MIME part is to enable rendering of otherwise obscured Header Fields
in Legacy MUAs that are capable of message decryption, but don't know in Legacy MUAs that are capable of message decryption but don't know
how to follow the rest of the guidance in this document. how to follow the rest of the guidance in this document.
The authors are unaware of any Legacy MUA that would render any MIME The authors are unaware of any Legacy MUA that would render any MIME
part type other than text/plain and text/html as the Main Body. A part type other than text/plain and text/html as the Main Body. A
generating MUA SHOULD NOT add a Legacy Display Element to any MIME generating MUA SHOULD NOT add a Legacy Display Element to any MIME
part with any other Content-Type. part with any other Content-Type.
6. Replying and Forwarding Guidance 6. Replying and Forwarding Guidance
An MUA might create a new message in response to another message, An MUA might create a new message in response to another message,
thus acting both as a receiving MUA and as a sending MUA. For thus acting both as a receiving MUA and as a sending MUA. For
example, the user of an MUA viewing any given message might take an example, the user of an MUA viewing any given message might take an
action like "Reply", "Reply All", "Forward", or some comparable action like "Reply", "Reply All", "Forward", or some comparable
action to start the composition of a new message. The new message action to start the composition of a new message. The new message
created this way effectively references the original message that was created this way effectively references the original message that was
viewed at the time. viewed at the time.
For encrypted messages, special guidance applies, because information For encrypted messages, special guidance applies, because information
can leak in at least two ways: leaking previously confidential Header can leak in at least two ways: leaking previously confidential Header
Fields, and leaking the entire message by sending the reply or Fields and leaking the entire message by sending the reply or forward
forward to the wrong party. to the wrong party.
6.1. Avoid Leaking Encrypted Header Fields in Replies and Forwards 6.1. Avoid Leaking Encrypted Header Fields in Replies and Forwards
As noted in Section 5.4 of [I-D.ietf-lamps-e2e-mail-guidance], an MUA As noted in Section 5.4 of [RFC9787], an MUA in this position MUST
in this position MUST NOT leak previously encrypted content in the NOT leak previously encrypted content in the clear in a follow-up
clear in a follow-up message. The same is true for protected Header message. The same is true for protected Header Fields.
Fields.
Values from any Header Field that was identified as either encrypted- Values from any Header Field that was identified as either encrypted-
only or signed-and-encrypted based on the steps outlined above MUST only or signed-and-encrypted based on the steps outlined above MUST
NOT be placed in cleartext output when generating a message. NOT be placed in cleartext output when generating a message.
In particular, if Subject was encrypted, and it is copied into the In particular, if Subject was encrypted, and it is copied into the
draft encrypted reply, the replying MUA MUST obscure the unprotected draft encrypted reply, the replying MUA MUST obscure the unprotected
(cleartext) Subject Header Field. (cleartext) Subject Header Field.
When crafting the Header Fields for a reply or forwarded message, the When crafting the Header Fields for a reply or forwarded message, the
composing MUA SHOULD make use of the HP-Outer Header Fields from composing MUA SHOULD make use of the HP-Outer Header Fields from
within the Cryptographic Envelope of the reference message to ensure within the Cryptographic Envelope of the reference message to ensure
that Header Fields derived from the reference message do not leak in that Header Fields derived from the reference message do not leak in
the reply. the reply.
On a high-level, this can be achieved as follows: Consider a Header On a high level, this can be achieved as follows: Consider a Header
Field in a reply message that is generated by derivation from a Field in a reply message that is generated by derivation from a
Header Field in the reference message. For example, the To Header Header Field in the reference message. For example, the To Header
Field is typically derived from the reference message's Reply-To or Field is typically derived from the reference message's Reply-To or
From Header Fields. When generating the outer copy of the Header From Header Fields. When generating the outer copy of the Header
Field, the composing MUA first applies its own Header Confidentiality Field, the composing MUA first applies its own Header Confidentiality
Policy. If the Header Field's value is changed by the HCP, then it Policy. If the Header Field's value is changed by the HCP, then it
is applied to the outside header. If the Header Field's value is is applied to the outside header. If the Header Field's value is
unchanged, the composing MUA re-generates the Header Field using the unchanged, the composing MUA regenerates the Header Field using the
Header Fields that had been on the outside of the original message at Header Fields that had been on the outside of the original message at
sending time. These can be inferred from the HP-Outer Header Fields sending time. These can be inferred from the HP-Outer Header Fields
located within the Cryptographic Payload of the referenced message. located within the Cryptographic Payload of the referenced message.
If that value is itself different than the protected value, then it If that value is itself different than the protected value, then it
is applied to the outside header. If the value is the same as the is applied to the outside header. If the value is the same as the
protected value, then it is simply copied to the outside header protected value, then it is simply copied to the outside header
directly. Whether it was changed or not, it is noted in the directly. Whether it was changed or not, it is noted in the
protected Header Section using HP-Outer, as described in protected Header Section using HP-Outer, as described in
Section 2.2.1. Section 2.2.1.
See Appendix D.2 for a simple worked example of this process. See Appendix D.2 for a simple worked example of this process.
Below we describe a supporting algorithm to handles this. It Below we describe a supporting algorithm to handle this. It produces
produces a list of Header Fields that should be obscured or removed a list of Header Fields that should be obscured or removed in the new
in the new message even if the sender's choice of Header message even if the sender's choice of Header Confidentiality Policy
Confidentiality Policy wouldn't normally remove or obscure the Header wouldn't normally remove or obscure the Header Field in question.
Field in question. This is effectively a single-use HCP. The normal This is effectively a single-use HCP. The normal sending guidance in
sending guidance in Section 5.2 applies this single-use HCP to Section 5.2 applies this single-use HCP to implement the high-level
implement the high-level guidance above. guidance above.
6.1.1. ReferenceHCP 6.1.1. ReferenceHCP
The algorithm takes two inputs: The algorithm takes two inputs:
* A single referenced message refmsg, and * A single referenced message refmsg
* A built-in MUA function respond associated with the user's action. * A built-in MUA respond function associated with the user's action.
respond takes as input a list of headers from a referenced message The respond function takes a list of headers from a referenced
and generates a list of initial candidate message Header Field message as input and generates a list of initial candidate message
names and values that are used to populate the message composition Header Field names and values that are used to populate the
interface. Something like this function already exists in most message composition interface. Something like this function
MUAs, though it may differ across responsive actions. For already exists in most MUAs, though it may differ across
example, the respond function that implements "Reply All" is responsive actions. For example, the respond function that
likely to be a different from the respond that implements "Reply". implements "Reply All" is likely to be a different from the
respond that implements "Reply".
As an output, it produces an ephemeral single-use Header As an output, it produces an ephemeral single-use Header
Confidentiality Policy, specific to this kind of response to this Confidentiality Policy, specific to this kind of response to this
specific message. specific message.
Method signature: Method signature:
ReferenceHCP(refmsg, respond) → ephemeral_hcp ReferenceHCP(refmsg, respond) -> ephemeral_hcp
Procedure: Procedure:
1. If refmsg is not encrypted with Header Protection: 1. If refmsg is not encrypted with Header Protection:
i. Return hcp_no_confidentiality (there is no header i. Return hcp_no_confidentiality (there is no header
confidentiality in the reference message that needs confidentiality in the reference message that needs
protection) protection).
2. Extract refouter, refprotected from refmsg as described in 2. Extract refouter, refprotected from refmsg as described in
Section 4.2 Section 4.2.
3. Let genprotected be a list of (h,v) pairs generated by 3. Let genprotected be a list of (h,v) pairs generated by
respond(refprotected) respond(refprotected).
4. Let genouter be a list of (h,v) pairs generated by 4. Let genouter be a list of (h,v) pairs generated by
respond(refouter) respond(refouter).
5. For each (h,v) in genprotected: 5. For each (h,v) in genprotected:
i. If (h,v) is in genouter: i. If (h,v) is in genouter:
a. Remove (h,v) from both genprotected and genouter (this a. Remove (h,v) from both genprotected and genouter (this
Header Field does not need additional confidentiality) Header Field does not need additional confidentiality).
6. Let confmap be a mapping from a Header Field name and value (h,v) 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 to either a string or the special value null (this mapping is
initially empty) initially empty).
7. For each (h,v) remaining in genprotected: 7. For each (h,v) remaining in genprotected:
i. Set result to the special value null i. Set result to the special value null.
ii. For each (h1,v1) in genouter: ii. For each (h1,v1) in genouter:
a. If h1 is h: a. If h1 is h:
I. Set result to v1 I. Set result to v1.
iii. Insert (h,v) -> result into confmap iii. Insert (h,v) -> result into confmap.
8. Return a new HCP from confmap that tests whether (name,val_in) 8. Return a new HCP from confmap that tests whether (name,val_in) is
are in confmap; if so, return confmap[(name,val_in)]; otherwise, in confmap; if so, return confmap[(name,val_in)]; otherwise,
return val_in return val_in.
Note that the key idea here is to reuse the MUA's existing respond Note that the key idea here is to reuse the MUA's existing respond
function. The algorithm simulates how the MUA would pre-populate a function. The algorithm simulates how the MUA would pre-populate a
reply to two traditional messages whose Header Fields have the values reply to two traditional messages whose Header Fields have the values
refouter and refprotected respectively (independent of any refouter and refprotected, respectively (independent of any
cryptographic protections). Then it uses the difference to derive a cryptographic protections). Then, it uses the difference to derive a
one-time HCP. This HCP takes into account both the referenced one-time HCP. This HCP takes into account both the referenced
message's sender's preferences and the derivations that can happen to message's sender's preferences and the derivations that can happen to
Header Field values when responding. Note that while some of these Header Field values when responding. Note that while some of these
derivations are straight forward (e.g., In-Reply-To is usually derivations are straightforward (e.g., In-Reply-To is usually derived
derived from Message-ID), others are non-trivial. For example, the from Message-ID), others are non-trivial. For example, the From
From address may be derived from To, Cc, or from the MUA's local address may be derived from To, Cc, or the MUA's local address
address preference (especially when the MUA received the referenced preference (especially when the MUA received the referenced message
message via Bcc). Similarly, To may be derived from To, From, and/or via Bcc). Similarly, To may be derived from To, From, and/or Cc
Cc Header Fields depending on the MUA implementation and depending on Header Fields depending on the MUA implementation and depending on
whether the user clicked "Reply", "Reply All", "Forward", or any whether the user clicked "Reply", "Reply All", "Forward", or any
other action that generates a response to a message. Reusing the other action that generates a response to a message. Reusing the
MUA's existing respond function incorporates these nuances without MUA's existing respond function incorporates these nuances without
requiring any extra configuration choices or additional maintenance requiring any extra configuration choices or additional maintenance
burden. burden.
6.2. Avoid Misdirected Replies 6.2. Avoid Misdirected Replies
When replying to a message, the Composing MUA typically decides who When replying to a message, the composing MUA typically decides who
to send the reply to based on: to send the reply to based on:
* the Reply-To, Mail-Followup-To, or From Header Fields * the Reply-To, Mail-Followup-To, or From Header Fields
* optionally, the other To or Cc Header Fields (if the user chose to * optionally, the other To or Cc Header Fields (if the user chose to
"reply all") "Reply All")
When a message has Header Protection, the replying MUA MUST populate When a message has Header Protection, the replying MUA MUST populate
the destination fields of the draft message using the protected the destination fields of the draft message using the protected
Header Fields, and ignore any unprotected Header Fields. Header Fields and ignore any unprotected Header Fields.
This mitigates against an attack where Mallory gets a copy of an This mitigates against an attack where Mallory gets a copy of an
encrypted message from Alice to Bob, and then replays the message to encrypted message from Alice to Bob and then relays the message to
Bob with an additional Cc to Mallory's own e-mail address in the Bob with an additional Cc to Mallory's own email address in the
message's outer (unprotected) Header Section. message's outer (unprotected) Header Section.
If Bob knows Mallory's certificate already, and he replies to such a If Bob knows Mallory's certificate already, and he replies to such a
message without following the guidance in this section, it's likely message without following the guidance in this section, it's likely
that his MUA will encrypt the cleartext of the message directly to that his MUA will encrypt the cleartext of the message directly to
Mallory. Mallory.
7. Unprotected Header Fields Added in Transit 7. Unprotected Header Fields Added in Transit
Some Header Fields are legitimately added in transit and could not Some Header Fields are legitimately added in transit and could not
have been known to the sender at message composition time. have been known to the sender at message composition time.
The most common of these Header Fields are Received and DKIM- The most common of these Header Fields are Received and DKIM-
Signature, neither of which are typically rendered, either explicitly Signature, neither of which are typically rendered, either explicitly
or implicitly. or implicitly.
If a receiving MUA has specific knowledge about a given Header Field, If a receiving MUA has specific knowledge about a given Header Field,
including that: including that:
* the Header Field would not have been known to the original sender, * the Header Field would not have been known to the original sender
and and
* the Header Field might be rendered explicitly or implicitly, * the Header Field might be rendered explicitly or implicitly,
then the MUA MAY decide to operate on the value of that Header Field then the MUA MAY decide to operate on the value of that Header Field
from the unprotected Header Section, even though the message has from the unprotected Header Section, even though the message has
Header Protection. Header Protection.
The MUA MAY prefer to verify that the Header Fields in question have The MUA MAY prefer to verify that the Header Fields in question have
additional transit-derived cryptographic protections before rendering additional transit-derived cryptographic protections before rendering
or acting on them. For example, the MUA could verify whether these or acting on them. For example, the MUA could verify whether these
Header Fields are covered by an appropriate and valid ARC- Header Fields are covered by an appropriate and valid ARC-
Authentication-Results (see [RFC8617]) or DKIM-Signature (see Authentication-Results (see [RFC8617]) or DKIM-Signature (see
[RFC6376]) Header Field. [RFC6376]) Header Field.
Specific examples of user-meaningful Header Fields commonly added by Specific examples of Header Fields that are meaningful to the user
transport agents appear below. are commonly added by the transport agents that appear below.
7.1. Mailing list Header Fields: List-* and Archived-At 7.1. Mailing List Header Fields: List-* and Archived-At
If the message arrives through a mailing list, the list manager If the message arrives through a mailing list, the list manager
itself may inject Header Fields (most have a List- prefix) in the itself may inject Header Fields (most have a List- prefix) in the
message: message:
* List-Archive * List-Archive
* List-Subscribe * List-Subscribe
* List-Unsubscribe * List-Unsubscribe
* List-Id * List-Id
* List-Help * List-Help
* List-Post * List-Post
* Archived-At * Archived-At
For some MUAs, these Header Fields are implicitly rendered, by For some MUAs, these Header Fields are implicitly rendered by
providing buttons for actions like "Subscribe", "View Archived providing buttons for actions like "Subscribe", "View Archived
Version", "Reply List", "List Info", etc. Version", "Reply List", "List Info", etc.
An MUA that receives a message with Header Protection that contains An MUA that receives a message with Header Protection that contains
these Header Fields in the unprotected section, and that has reason these Header Fields in the unprotected section and that has reason to
to believe the message is coming through a mailing list MAY decide to believe the message is coming through a mailing list MAY decide to
render them to the user (explicitly or implicitly) even though they render them to the user (explicitly or implicitly) even though they
are not protected. are not protected.
8. E-mail Ecosystem Evolution 8. Email Ecosystem Evolution
The e-mail ecosystem is the set of client-side and server-side The email ecosystem is the set of client-side and server-side
software and policies that are used in the creation, transmission, software and policies that are used in the creation, transmission,
storage, rendering, and indexing of electronic mail over the storage, rendering, and indexing of email over the Internet.
Internet.
This document is intended to offer tooling needed to improve the This document is intended to offer tooling needed to improve the
state of the e-mail ecosystem in a way that can be deployed without state of the email ecosystem in a way that can be deployed without
significant disruption. Some elements of this specification are significant disruption. Some elements of this specification are
present for transitional purposes, but would not exist if the system present for transitional purposes but would not exist if the system
were designed from scratch. were designed from scratch.
This section describes these transitional mechanisms, as well as some This section describes these transitional mechanisms, as well as some
suggestions for how they might eventually be phased out. suggestions for how they might eventually be phased out.
8.1. Dropping Legacy Display Elements 8.1. Dropping Legacy Display Elements
Any decorative Legacy Display Element added to an encrypted message Any decorative Legacy Display Element added to an encrypted message
that uses Header Protection is present strictly for enabling Header that uses Header Protection is present strictly for enabling Header
Field visibility (most importantly, the Subject Header Field) when Field visibility (most importantly, the Subject Header Field) when
the message is viewed with a decryption-capable Legacy MUA. the message is viewed with a decryption-capable Legacy MUA.
Eventually, the hope is that most decryption-capable MUAs will Eventually, the hope is that most decryption-capable MUAs will
conform to this specification, and there will be no need for conform to this specification and there will be no need for injection
injection of Legacy Display Elements in the message body. A survey of Legacy Display Elements in the message body. A survey of widely
of widely used decryption-capable MUAs might be able to establish used decryption-capable MUAs might be able to establish when most of
when most of them do support this specification. them do support this specification.
At that point, a composing MUA could set the legacy parameter defined At that point, a composing MUA could set the legacy parameter defined
in Section 5.2 to false by default or could even hard-code it to in Section 5.2 to false by default or could even hard-code it to
false, yielding a much simpler message construction set. false, yielding a much simpler message construction set.
Until that point, an end user might want to signal that their Until that point, an end user might want to signal that their
receiving MUAs are conformant to this document so that a peer receiving MUAs are conformant to this document so that a peer
composing a message to them can set legacy to false. A signal composing a message to them can set legacy to false. A signal
indicating capability of handling messages with Header Protection indicating capability of handling messages with Header Protection
might be placed in the user's cryptographic certificate, or in might be placed in the user's cryptographic certificate or in
outbound messages. outbound messages.
This document does not attempt to define the syntax or semantics of This document does not attempt to define the syntax or semantics of
such a signal. such a signal.
8.2. More Ambitious Default Header Confidentiality Policy 8.2. More Ambitious Default Header Confidentiality Policy
This document defines a few different forms of Header Confidentiality This document defines a few different forms of Header Confidentiality
Policy. An MUA implementing an HCP for the first time SHOULD deploy Policy. An MUA implementing an HCP for the first time SHOULD deploy
hcp_baseline as recommended in Section 3.3. This HCP offers the most hcp_baseline as recommended in Section 3.3. This HCP offers the most
skipping to change at page 57, line 14 skipping to change at line 2582
The HCPs proposed in this document are relatively conservative and The HCPs proposed in this document are relatively conservative and
still leak a significant amount of metadata for encrypted messages. still leak a significant amount of metadata for encrypted messages.
This is largely done to ensure deliverability (see Section 1.3.2) and This is largely done to ensure deliverability (see Section 1.3.2) and
usability, as messages without some critical Header Fields are more usability, as messages without some critical Header Fields are more
likely to not reach their intended recipient. likely to not reach their intended recipient.
In the future, some mail transport systems may accept and deliver In the future, some mail transport systems may accept and deliver
messages with even less publicly visible metadata. Many MTA messages with even less publicly visible metadata. Many MTA
operators today would ask for additional guarantees about such a operators today would ask for additional guarantees about such a
message to limit the risks associated with abusive or spammy mail. message to limit the risks associated with abusive or spam mail.
This specification offers the HCP formalism itself as a way for MUA This specification offers the HCP formalism itself as a way for MUA
developers and MTA operators to describe their expectations around developers and MTA operators to describe their expectations around
message deliverability. MUA developers can propose a more ambitious message deliverability. MUA developers can propose a more ambitious
default HCP, and ask MTA operators (or simply test) whether their default HCP and ask MTA operators (or simply test) whether their MTAs
MTAs would be likely to deliver or reject encrypted mail with that would be likely to deliver or reject encrypted mail with that HCP
HCP applied. Proponents of a more ambitious HCP should explicitly applied. Proponents of a more ambitious HCP should explicitly
document the HCP and name it clearly and unambiguously to facilitate document the HCP and name it clearly and unambiguously to facilitate
this kind of interoperability discussion. this kind of interoperability discussion.
Reaching widespread consensus around a more ambitious global default Reaching widespread consensus around a more ambitious global default
HCP is a challenging problem of coordinating many different actors. HCP is a challenging problem of coordinating many different actors.
A piecemeal approach might be more feasible, where some signalling A piecemeal approach might be more feasible, where some signaling
mechanism allows a message recipient, MTA operator, or third-party mechanism allows a message recipient, MTA operator, or third-party
clearinghouse to announce what kinds of HCPs are likely to be clearinghouse to announce what kinds of HCPs are likely to be
deliverable for a given recipient. In such a situation, the default deliverable for a given recipient. In such a situation, the default
HCP for an MUA might involve consulting the signalled acceptable HCPs HCP for an MUA might involve consulting the signaled acceptable HCPs
for all recipients, and combining them (along with a default for when for all recipients and combining them (along with a default for when
no signal is present) in some way. no signal is present) in some way.
If such a signal were to reach widespread use, it could also be used If such a signal were to reach widespread use, it could also be used
to guide reasonable statistical default HCP choices for recipients to guide reasonable statistical default HCP choices for recipients
with no signal. with no signal.
This document does not attempt to define the syntax or semantics of This document does not attempt to define the syntax or semantics of
such a signal. such a signal.
8.3. Deprecation of Messages Without Header Protection 8.3. Deprecation of Messages Without Header Protection
At some point, when the majority of MUA clients that can generate At some point, when the majority of MUA clients can generate
cryptographically protected messages with Header Protection, it cryptographically protected messages with Header Protection, it
should be possible to deprecate any cryptographically protected should be possible to deprecate any cryptographically protected
message that does not have Header Protection. message that does not have Header Protection.
For example, as noted in Section 9.1, it's possible for an MUA to 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 render a signed-only message that has no Header Protection the same
as an unprotected message. And a signed-and-encrypted message as an unprotected message. And a signed-and-encrypted message
without Header Protection could likewise be marked as not fully without Header Protection could likewise be marked as not fully
protected. protected.
These stricter rules could be adopted immediately for all messages. These stricter rules could be adopted immediately for all messages.
Or an MUA developer could roll them out immediately for any new Or an MUA developer could roll them out immediately for any new
message, but still treat an old message (based on the Date Header message but still treat an old message (based on the Date Header
Field and cryptographic signature timestamp) more leniently. Field and cryptographic signature timestamp) more leniently.
A decision like this by any popular receiving MUA could drive A decision like this by any popular receiving MUA could drive
adoption of this standard for sending MUAs. adoption of this standard for sending MUAs.
9. Usability Considerations 9. Usability Considerations
This section describes concerns for MUAs that are interested in easy This section describes concerns for MUAs that are interested in easy
adoption of Header Protection by normal users. adoption of Header Protection by normal users.
While they are not protocol-level artifacts, these concerns motivate While they are not protocol-level artifacts, these concerns motivate
the protocol features described in this document. the protocol features described in this document.
See also the Usability commentary in Section 2 of See also the usability commentary in Section 2 of [RFC9787].
[I-D.ietf-lamps-e2e-mail-guidance].
9.1. Mixed Protections Within a Message Are Hard To Understand 9.1. Mixed Protections Within a Message Are Hard to Understand
When rendering a message to the user, the ideal circumstance is to When rendering a message to the user, the ideal circumstance is to
present a single cryptographic status for any given message. present a single cryptographic status for any given message.
However, when message Header Fields are present, some message Header However, when message Header Fields are present, some message Header
Fields do not have the same cryptographic protections as the main Fields do not have the same cryptographic protections as the main
message. message.
Representing such a mixed set of protection statuses is very Representing such a mixed set of protection statuses is very
difficult to do in a way that a Ordinary User can understand. There 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 are at least three scenarios that are likely to be common and poorly
understood: understood:
* A signed message with no Header Protection. * A signed message with no Header Protection.
* A signed-and-encrypted message with no Header Protection. * A signed-and-encrypted message with no Header Protection.
* A signed-and-encrypted message with Header Protection as defined * A signed-and-encrypted message with Header Protection as defined
in this document, where some User-Facing Header Fields have in this document, where some User-Facing Header Fields have
confidentiality but some do not. confidentiality but some do not.
An MUA should have a reasonable strategy for clearly communicating An MUA should have a reasonable strategy for clearly communicating
each of these scenarios to the user. For example, an MUA operating each of these scenarios to the user. For example, an MUA operating
in an environment where it expects most cryptographically protected in an environment where it expects most cryptographically protected
messages to have Header Protection could use the following rendering messages to have Header Protection could use the following rendering
strategy: strategy:
* When rendering a message with signed-only cryptographic status but * When rendering a message with a signed-only cryptographic status
no Header Protection, an MUA may decline to indicate a positive but no Header Protection, an MUA may decline to indicate a
security status overall, and only indicate the cryptographic positive security status overall and only indicate the
status to a user in a message properties or diagnostic view. That cryptographic status to a user in a message properties or
is, the message may appear identical to an unsigned message except diagnostic view. That is, the message may appear identical to an
if a user verifies the properties through a menu option. unsigned message except if a user verifies the properties through
a menu option.
* When rendering a message with signed-and-encrypted or encrypted- * When rendering a message with a signed-and-encrypted or encrypted-
only cryptographic status but no Header Protection, overlay a only cryptographic status but no Header Protection, overlay a
warning flag on the typical cryptographic status indicator. That warning flag on the typical cryptographic status indicator. That
is, if a typical signed-and-encrypted message displays a lock is, if a typical signed-and-encrypted message displays a lock
icon, display a lock icon with a warning sign (e.g., an icon, display a lock icon with a warning sign (e.g., an
exclamation point in a triangle) overlaid. See, for example, the exclamation point in a triangle) overlaid. For example, see the
graphics in [chrome-indicators]. graphics in [chrome-indicators].
* When rendering a message with signed-and-encrypted or encrypted- * When rendering a message with a signed-and-encrypted or encrypted-
only cryptographic status, with Header Protection, but where the only cryptographic status with Header Protection but where the
Subject Header Field has not been removed or obscured, place a Subject Header Field has not been removed or obscured, place a
warning sign on the Subject line. warning sign on the Subject line.
Other simple rendering strategies could also be reasonable. Other simple rendering strategies could also be reasonable.
9.2. Users Should Not Have To Choose a Header Confidentiality Policy 9.2. Users Should Not Have to Choose a Header Confidentiality Policy
This document defines the abstraction of a Header Confidentiality This document defines the abstraction of a Header Confidentiality
Policy object for the sake of communication between implementers and Policy object for the sake of communication between implementers and
deployments. deployments.
Most e-mail users are unlikely to understand the tradeoffs between Most email users are unlikely to understand the trade-offs between
different policies. In particular, the potential negative side different policies. In particular, the potential negative side
effects (e.g., poor deliverability) may not be easily attributable by effects (e.g., poor deliverability) may not be easily attributable by
a normal user to a particular HCP. a normal user to a particular HCP.
Therefore, MUA implementers should be conservative in their choice of Therefore, MUA implementers should be conservative in their choice of
default HCP, and should not require the Ordinary User to make an default HCP and should not require the Ordinary User to make an
incomprehensible choice that could cause unfixable, undiagnosable incomprehensible choice that could cause unfixable, undiagnosable
problems. The safest option is for the MUA developer to select a problems. The safest option is for the MUA developer to select a
known, stable HCP (this document recommends hcp_baseline in known, stable HCP (this document recommends hcp_baseline in
Section 3.3) on the user's behalf. An MUA should not expose the 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 Ordinary User to a configuration option where they are expected to
manually select (let alone define) an HCP. manually select (let alone define) an HCP.
10. Security Considerations 10. Security Considerations
Header Protection improves the security of cryptographically Header Protection improves the security of cryptographically
protected e-mail messages. Following the guidance in this document protected email messages. Following the guidance in this document
improves security for users by more directly aligning the underlying improves security for users by more directly aligning the underlying
messages with user expectations about confidentiality, authenticity, messages with user expectations about confidentiality, authenticity,
and integrity. and integrity.
Nevertheless, helping the user distinguish between cryptographic Nevertheless, helping the user distinguish between cryptographic
protections of various messages remains a security challenge for protections of various messages remains a security challenge for
MUAs. This is exarcebated by the fact that many existing messages MUAs. This is exacerbated by the fact that many existing messages
with cryptographic protections do not employ Header Protection. MUAs with cryptographic protections do not employ Header Protection. MUAs
encountering these messages (e.g., in an archive) will need to handle encountering these messages (e.g., in an archive) will need to handle
older forms (without Header Protection) for quite some time, possibly older forms (without Header Protection) for quite some time, possibly
forever. forever.
The security considerations from Section 6 of [RFC8551] continue to The security considerations from Section 6 of [RFC8551] continue to
apply for any MUA that offers S/MIME cryptographic protections, as apply for any MUA that offers S/MIME cryptographic protections, as
well as Section 3 of [RFC5083] (Authenticated-Enveloped-Data in CMS) well as Section 3 of [RFC5083] (Authenticated-Enveloped-Data in
and Section 14 of [RFC5652] (CMS more broadly). Likewise, the Cryptographic Message Syntax (CMS)) and Section 14 of [RFC5652] (CMS
security considerations from Section 8 of [RFC3156] continue to apply more broadly). Likewise, the security considerations from Section 8
for any MUA that offers PGP/MIME cryptographic protections, as well of [RFC3156] continue to apply for any MUA that offers PGP/MIME
as Section 13 of [RFC9580] (OpenPGP itself). In addition, these cryptographic protections, as well as Section 13 of [RFC9580]
underlying security considerations are now also applicable to the (OpenPGP itself). In addition, these underlying security
contents of the message header, not just the message body. considerations are now also applicable to the contents of the message
header, not just the message body.
10.1. From Address Spoofing 10.1. From Address Spoofing
If the From Header Field were treated by the receiving MUA like any If the From Header Field was treated like any other protected Header
other protected Header Field, this scheme would enable sender address Field by the receiving MUA, this scheme would enable sender address
spoofing. spoofing.
To prevent sender spoofing, many receiving MUAs implicitly rely on To prevent sender spoofing, many receiving MUAs implicitly rely on
their receiving MTA to inspect the unprotected Header Section and their receiving MTA to inspect the unprotected Header Section and
verify that the From Header Field is authentic. If a receiving MUA verify that the From Header Field is authentic. If a receiving MUA
displays a From address that doesn't match the From address that the displays a From address that doesn't match the From address that the
receiving and/or sending MTAs filtered on, the MUA may be vulnerable receiving and/or sending MTAs filtered on, the MUA may be vulnerable
to spoofing. to spoofing.
Consider a malicious MUA that sets the following Header Fields on an Consider a malicious MUA that sets the following Header Fields on an
skipping to change at page 61, line 4 skipping to change at line 2759
to spoofing. to spoofing.
Consider a malicious MUA that sets the following Header Fields on an Consider a malicious MUA that sets the following Header Fields on an
encrypted message with Header Protection: encrypted message with Header Protection:
* Outer: From: <alice@example.com> * Outer: From: <alice@example.com>
* Inner: HP-Outer: From: <alice@example.com> * Inner: HP-Outer: From: <alice@example.com>
* Inner: From: <bob@example.org> * Inner: From: <bob@example.org>
During sending, the MTA of example.com validates that the sending MUA During sending, the MTA of example.com validates that the sending MUA
is authorized to send from alice@example.com. Since the message is is authorized to send from alice@example.com. Since the message is
encrypted, the sending and receiving MTAs cannot see the protected encrypted, the sending and receiving MTAs cannot see the protected
Header Fields. A naive receiving MUA might follow the algorithms in Header Fields. A naive receiving MUA might follow the algorithms in
this document without special consideration for the From Header this document without special consideration for the From Header
Field. Such an MUA might display the email as coming from Field. Such an MUA might display the email as coming from
bob@example.org to the user, resulting in a spoofed address. bob@example.org to the user, resulting in a spoofed address.
This problem applies both between domains and within a domain. This problem applies both between domains and within a domain.
This problem always applies to signed-and-encrypted messages. This This problem always applies to signed-and-encrypted messages. This
problem also applies to signed-only messages because MTAs typically problem also applies to signed-only messages because MTAs typically
do not look at the protected Header Fields when confirming From do not look at the protected Header Fields when confirming From
address authenticity. address authenticity.
Sender address spoofing is relevant for two distinct security Sender address spoofing is relevant for two distinct security
properties: properties:
* Sender authenticity: relevant for rendering the message (which * Sender authenticity: relevant for rendering the message (which
address to show the user?). address to show the user?)
* Message confidentiality: relevant when replying to a message (a * Message confidentiality: relevant when replying to a message (a
reply to the wrong address can leak the message contents). reply to the wrong address can leak the message contents)
10.1.1. From Rendering Reasoning 10.1.1. From Rendering Reasoning
Section 4.4.3 provides guidance for rendering the From Header Field. Section 4.4.3 provides guidance for rendering the From Header Field.
It recommends a receiving MUA that depends on its MTA to authenticate It recommends a receiving MUA that depends on its MTA to authenticate
the unprotected (outer) From Header Field to render the outer From the unprotected (outer) From Header Field to render the outer From
Header Field, if both of the following conditions are met: Header Field if both of the following conditions are met:
* From Header Field Mismatch (as defined in Section 4.4.1.1) * From Header Field Mismatch (as defined in Section 4.4.1.1)
* No Valid and Correctly Bound Signature (as defined in * No Valid and Correctly Bound Signature (as defined in
Section 4.4.1.2) Section 4.4.1.2)
Note: The second condition effectively means that the inner (expected Note: The second condition effectively means that the inner (expected
to be protected) From Header Field appears to have insufficient to be protected) From Header Field appears to have insufficient
protection. protection.
This may seem surprising since it causes the MUA to render a mix of This may seem surprising since it causes the MUA to render a mix of
both protected and unprotected values. This section provides an both protected and unprotected values. This section provides an
argument as to why this guidance makes sense. argument as to why this guidance makes sense.
We proceed by case distinction: We proceed by case distinction:
* Case 1: Malicious sending MUA. * Case 1: Malicious sending MUA.
- Attack situation: the sending MUA puts a different inner From - Attack situation: The sending MUA puts a different inner From
Header Field to spoof the sender address. Header Field to spoof the sender address.
- In this case, it is "better" to fall back and render the outer - In this case, it is "better" to fall back and render the outer
From Header Field because this is what the receiving MTA can From Header Field because this is what the receiving MTA can
validate. Otherwise this document would introduce a new way validate. Otherwise, this document would introduce a new way
for senders to spoof the From address of the message. for senders to spoof the From address of the message.
- This does not preclude a future document from updating this - This does not preclude a future document from updating this
document to specify a protocol for legitimate sender address document to specify a protocol for legitimate sender address
hiding. hiding.
* Case 2: Malicious sending/transiting/receiving MTA (or anyone * Case 2: Malicious sending/transiting/receiving MTA (or anyone
meddling between MTAs). meddling between MTAs).
- Attack situation: an on-path attacker changes the outer From - Attack situation: An on-path attacker changes the outer From
Header Field (possibly with other meddling to break the Header Field (possibly with other meddling to break the
signature, see below). Their goal is to get the receiving MUA signature; see below). Their goal is to get the receiving MUA
to show a different From address than the sending MUA intended to show a different From address than the sending MUA intended
(breaking MUA-to-MUA sender authenticity). (breaking MUA-to-MUA sender authenticity).
- Case 2.a: The sending MUA submitted an unsigned or encrypted- - Case 2.a: The sending MUA submitted an unsigned or encrypted-
only message to the email system. In this case, there can be only message to the email system. In this case, there can be
no sender authenticity anyway. no sender authenticity anyway.
- Case 2.b: The sending MUA submitted a signed-only message to - Case 2.b: The sending MUA submitted a signed-only message to
the email system. the email system.
o Case 2.b.i: The attacker removes or breaks the signature. o Case 2.b.i: The attacker removes or breaks the signature.
In this case, the attacker can also modify the inner From In this case, the attacker can also modify the inner From
Header Field to their liking. Header Field to their liking.
o Case 2.b.ii: The signature is valid, but the receiving MUA o Case 2.b.ii: The signature is valid, but the receiving MUA
does not see any valid binding between the signing does not see any valid binding between the signing
certificate and the addr-spec of the inner From Header certificate and the addr-spec of the inner From Header
Field. In this case, there can be no sender authenticity Field. In this case, there can be no sender authenticity
anyways (the certificate could have been generated by the anyways (the certificate could have been generated by the
on-path attacker). This case is indistinguishable from a on-path attacker). This case is indistinguishable from a
malicious sending MUA, hence it is "better" to fall back to malicious sending MUA; hence, it is "better" to fall back to
the outer From that the MTA can validate. Note that once the outer From Header Field that the MTA can validate. Note
the binding is validated (e.g., after an out-of-band that once the binding is validated (e.g., after an out-of-
comparison), the rendering may change from showing the outer band comparison), the rendering may change from showing the
From address (and a warning) to showing the inner, now outer From address (and a warning) to showing the inner, now
validated From address. In some cases, the binding may be validated From address. In some cases, the binding may be
instantly validated even for previously unseen certificates instantly validated even for previously unseen certificates
(e.g., if the certificate is issued by a trusted (e.g., if the certificate is issued by a trusted
certification authority). certification authority).
- Case 2.c: The sending MUA submitted a signed-and-encrypted - Case 2.c: The sending MUA submitted a signed-and-encrypted
message to the email system. message to the email system.
o Case 2.c.i: The attacker removes or breaks the signature. o Case 2.c.i: The attacker removes or breaks the signature.
Note that the signature is inside the ciphertext (see Note that the signature is inside the ciphertext (see
Section 5.2 of [I-D.ietf-lamps-e2e-mail-guidance]). Thus, Section 5.2 of [RFC9787]). Thus, assuming the encryption is
assuming the encryption is non-malleable, any on-path non-malleable, any on-path attacker cannot break the
attacker cannot break the signature while ensuring that the signature while ensuring that the message still decrypts
message still decrypts successfully. successfully.
o Case 2.c.ii: The signature is valid, but the receiving MUA o Case 2.c.ii: The signature is valid, but the receiving MUA
does not see any valid binding between the signing does not see any valid binding between the signing
certificate and the addr-spec of the inner From Header certificate and the addr-spec of the inner From Header
Field. See case 2.b.ii. Field. See case 2.b.ii.
As the case distinction shows, the outer From Header Field is either As the case distinction shows, the outer From Header Field is either
the preferred fallback (in particular, to avoid introducing a new the preferred fallback (in particular, to avoid introducing a new
spoofing channel), or it is just as good (because just as modifiable) spoofing channel) or just as good (because just as modifiable) as the
as the inner From Header Field. inner From Header Field.
Rendering the outer From Header Field does carry the risk of a Rendering the outer From Header Field does carry the risk of a
"temporary downgrade attack" in cases 2.b.ii and 2.c.ii, where 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 malicious MTA keeps the signature intact but modifies the outer From
Header Field. The MUA can resolve this temporary downgrade by Header Field. The MUA can resolve this temporary downgrade by
validating the certificate-to-addr-spec binding. If the MUA never validating the certificate-to-addr-spec binding. If the MUA never
does this validation, the entire message could be fake. does this validation, the entire message could be fake.
If there were a signalling channel where the MTA can tell the MUA 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 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 in its rendering decision. In the absence of such a signal, and when
end-to-end authenticity is unavailable, this document prefers to fall end-to-end authenticity is unavailable, this document prefers to fall
back to the outer From Header Field. This default is based on the back to the outer From Header Field. This default is based on the
assumption that most MTAs apply some filtering based on the outer assumption that most MTAs apply some filtering based on the outer
From Header Field (whether the MTA can authenticate it or not). From Header Field (whether the MTA can authenticate it or not).
Rendering the unprotected outer From Header Field (instead of the Rendering the unprotected outer From Header Field (instead of the
protected inner one) in case of a mismatch retains this ability for protected inner one) in case of a mismatch retains this ability for
MTAs. MTAs.
If the MUA decides not to rely on the MTA to authenticate the outer 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. From Header Field, it may prefer the inner From Header Field.
10.2. Avoid Cryptographic Summary Confusion from hp Parameter 10.2. Avoid Cryptographic Summary Confusion from the hp Parameter
When parsing a message, the recipient MUA infers the message's When parsing a message, the recipient MUA infers the message's
Cryptographic Status from the Cryptographic Layers, as described in Cryptographic Status from the Cryptographic Layers, as described in
Section 4.6 of [I-D.ietf-lamps-e2e-mail-guidance]. Section 4.6 of [RFC9787].
The Cryptographic Layers that make up the Cryptographic Envelope The Cryptographic Layers that make up the Cryptographic Envelope
describe an ordered list of cryptographic properties as present in describe an ordered list of cryptographic properties as present in
the message after it has been delivered. By contrast, the hp the message after it has been delivered. By contrast, the hp
parameter to the Content-Type Header Field contains a simpler parameter to the Content-Type Header Field contains a simpler
indication: whether the sender originally tried to encrypt the indication: whether the sender originally tried to encrypt the
message or not. In particular, for a message with Header Protection, message or not. In particular, for a message with Header Protection,
the Cryptographic Payload should have a hp parameter of cipher if the the Cryptographic Payload should have a hp parameter of cipher if the
message is encrypted (in addition to signed), and clear if no message is encrypted (in addition to signed) and clear if no
encryption is present (that is, the message is signed-only). encryption is present (that is, the message is signed-only).
As noted in Section 2.1.1, the receiving implementation should not As noted in Section 2.1.1, the receiving implementation should not
inflate its estimation of the confidentiality of the message or its inflate its estimation of the confidentiality of the message or its
Header Fields based on the sender's intent, if it can see that the Header Fields based on the sender's intent if it can see that the
message was not actually encrypted. A signed-only message that message was not actually encrypted. A signed-only message that
happens to have an hp parameter of cipher is still signed-only. happens to have an hp parameter of cipher is still signed-only.
Conversely, since the encrypting Cryptographic Layer is typically Conversely, since the encrypting Cryptographic Layer is typically
outside the signature layer (see Section 5.2 of outside the signature layer (see Section 5.2 of [RFC9787]), an
[I-D.ietf-lamps-e2e-mail-guidance]), an originally signed-only originally signed-only message could have been wrapped in an
message could have been wrapped in an encryption layer by an encryption layer by an intervening party before receipt to appear
intervening party before receipt, to appear encrypted. encrypted.
If a message appears to be wrapped in an encryption layer, and the hp If a message appears to be wrapped in an encryption layer, and the hp
parameter is present but is not set to cipher, then it is likely that parameter is present but is not set to cipher, then it is likely that
the encryption layer was not added by the original sender. For such the encryption layer was not added by the original sender. For such
a message, the lack of any HP-Outer Header Field in the Header a message, the lack of any HP-Outer Header Field in the Header
Section of the Cryptographic Payload MUST NOT be used to infer that Section of the Cryptographic Payload MUST NOT be used to infer that
all Header Fields were removed from the message by the original all Header Fields were removed from the message by the original
sender. In such a case, the receiving MUA SHOULD treat every Header sender. In such a case, the receiving MUA SHOULD treat every Header
Field as though it was not confidential. Field as though it was not confidential.
10.3. Caution about Composing with Legacy Display Elements 10.3. Caution About Composing with Legacy Display Elements
When composing a message, it's possible for a Legacy Display Element When composing a message, it's possible for a Legacy Display Element
to contain risky data that could trigger errors in a rendering to contain risky data that could trigger errors in a rendering
client. client.
For example, if the value for a Header Field to be included in a For example, if the value for a Header Field to be included in a
Legacy Display Element within a given body part contains folding Legacy Display Element within a given body part contains folding
whitespace, it should be "unfolded" before generating the Legacy whitespace, it should be "unfolded" before generating the Legacy
Display Element: all contiguous folding whitespace should be replaced Display Element: All contiguous folding whitespace should be replaced
with a single space character. Likewise, if the header value was with a single space character. Likewise, if the header value was
originally encoded with [RFC2047], it should be decoded first to a originally encoded per [RFC2047], it should be decoded first to a
standard string and re-encoded using the charset appropriate to the standard string and re-encoded using the charset appropriate to the
target part. target part.
When including a Legacy Display Element in a text/plain part (see When including a Legacy Display Element in a text/plain part (see
Section 5.2.2), if the decoded Subject Header Field contains a pair Section 5.2.2), if the decoded Subject Header Field contains a pair
of newlines (e.g., if it is broken across multiple lines by encoded of newlines (e.g., if it is broken across multiple lines by encoded
newlines), any newline MUST be stripped from the Legacy Display newlines), any newline MUST be stripped from the Legacy Display
Element. If the pair of newlines is not stripped, a receiving MUA Element. If the pair of newlines is not stripped, a receiving MUA
that follows the guidance in Section 4.5.3.2 might leave the later that follows the guidance in Section 4.5.3.2 might leave the later
part of the Legacy Display Element in the rendered message. part of the Legacy Display Element in the rendered message.
When including a Legacy Display Element in a text/html part (see When including a Legacy Display Element in a text/html part (see
Section 5.2.3), any material in the header values should be Section 5.2.3), any material in the header values should be
explicitly HTML escaped to avoid being rendered as part of the HTML. explicitly HTML escaped to avoid being rendered as part of the HTML.
At a minimum, the characters <, >, and & should be escaped to &lt;, At a minimum, the characters <, >, and & should be escaped to &lt;,
&gt;, and &amp;, respectively (see for example [HTML-ESCAPES]). If &gt;, and &amp;, respectively (for example, see [HTML-ESCAPES]). If
unescaped characters from removed or obscured header values end up in unescaped characters from removed or obscured header values end up in
the Legacy Display Element, a receiving MUA that follows the guidance the Legacy Display Element, a receiving MUA that follows the guidance
in Section 4.5.3.3 might fail to identify the boundaries of the 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 Legacy Display Element, cutting out more than it should or leaving
remnants visible. And a Legacy MUA parsing such a message might remnants visible. And a Legacy MUA parsing such a message might
misrender the entire HTML stream, depending on the content of the misrender the entire HTML stream, depending on the content of the
removed or obscured header values. removed or obscured header values.
The Legacy Display Element is a decorative addition solely to enable The Legacy Display Element is a decorative addition solely to enable
visibility of obscured or removed Header Fields in decryption-capable visibility of obscured or removed Header Fields in decryption-capable
Legacy MUAs. When it is produced, it should be generated minimally Legacy MUAs. When it is produced, it should be generated minimally
and strictly, as described above, to avoid damaging the rest of the and strictly, as described above, to avoid damaging the rest of the
message. message.
10.4. Plaintext Attacks 10.4. Plaintext Attacks
An encrypted e-mail message using S/MIME or PGP/MIME tends to have An encrypted email message using S/MIME or PGP/MIME tends to have
some amount of predictable plaintext. For example, the standard MIME some amount of predictable plaintext. For example, the standard MIME
headers of the Cryptographic Payload of a message are often a headers of the Cryptographic Payload of a message are often a
predictable sequence of bytes, even without Header Protection, when predictable sequence of bytes, even without Header Protection, when
they only include the Structural Header Fields MIME-Version and they only include the Structural Header Fields MIME-Version and
Content-Type. This is a potential risk for known-plaintext attacks. Content-Type. This is a potential risk for known-plaintext attacks.
Including protected Header Fields as defined in this document Including protected Header Fields as defined in this document
increases the amount of known plaintext. Since some of those headers increases the amount of known plaintext. Since some of those headers
in a reply will be derived from the message being replied to, this in a reply will be derived from the message being replied to, this
also creates a potential risk for chosen-plaintext attacks, in also creates a potential risk for chosen-plaintext attacks, in
skipping to change at page 66, line 22 skipping to change at line 3013
11.2. Encrypted Header Fields Are Not Always Private 11.2. Encrypted Header Fields Are Not Always Private
For encrypted messages, depending on the sender's HCP, some Header For encrypted messages, depending on the sender's HCP, some Header
Fields may appear both within the Cryptographic Envelope and on the Fields may appear both within the Cryptographic Envelope and on the
outside of the message (e.g., Date might exist identically in both outside of the message (e.g., Date might exist identically in both
places). Section 4.3 identifies such a Header Field as signed-only. places). Section 4.3 identifies such a Header Field as signed-only.
These Header Fields are clearly _not_ private at all, despite a copy These Header Fields are clearly _not_ private at all, despite a copy
being inside the Cryptographic Envelope. being inside the Cryptographic Envelope.
A Header Field whose name and value are not matched verbatim by any A Header Field whose name and value are not matched verbatim by any
HP-Outer Header Field from the same part will have encrypted-only or HP-Outer Header Field from the same part will have an encrypted-only
signed-and-encrypted status. But even Header Fields with these or signed-and-encrypted status. But even Header Fields with these
stronger levels of cryptographic confidentiality protection might not stronger levels of cryptographic confidentiality protection might not
be as private as the user would like. be as private as the user would like.
See the examples below. See the examples below.
This concern is true for any encrypted data, including the body of This concern is true for any encrypted data, including the body of
the message, not just the Header Fields: if the sender isn't careful, the message, not just the Header Fields: If the sender isn't careful,
the message contents or session keys can leak in many ways that are the message contents or session keys can leak in many ways that are
beyond the scope of this document. The message recipient has no way beyond the scope of this document. The message recipient has no way
in principle to tell whether the apparent confidentiality of any in principle to tell whether the apparent confidentiality of any
given piece of encrypted content has been broken via channels that given piece of encrypted content has been broken via channels that
they cannot perceive. Additionally, an active intermediary aware of they cannot perceive. Additionally, an active intermediary aware of
the recipient's public key can always encrypt a cleartext message in the recipient's public key can always encrypt a cleartext message in
transit to give the recipient a false sense of security. transit to give the recipient a false sense of security.
11.2.1. Encrypted Header Fields Can Leak Unwanted Information to the 11.2.1. Encrypted Header Fields Can Leak Unwanted Information to the
Recipient Recipient
skipping to change at page 67, line 6 skipping to change at line 3046
especially problematic for Header Fields that are not user-facing, especially problematic for Header Fields that are not user-facing,
which the sender may not expect to be injected by their MUA. which the sender may not expect to be injected by their MUA.
Consider the three following examples: Consider the three following examples:
* The MUA may inject a User-Agent Header Field that describes itself * The MUA may inject a User-Agent Header Field that describes itself
to every recipient, even though the sender may not want the to every recipient, even though the sender may not want the
recipient to know the exact version of their OS, hardware recipient to know the exact version of their OS, hardware
platform, or MUA. platform, or MUA.
* The MUA may have an idiosyncratic way of generating a Message-ID * The MUA may have an idiosyncratic way of generating a Message-ID
header, which could embed the choice of MUA, a time zone, a header, which could embed the choice of MUA, time zone, hostname,
hostname, or other subtle information to a knowledgeable or other subtle information to a knowledgeable recipient.
recipient.
* The MUA may erroneously include a Bcc Header Field in the * The MUA may erroneously include a Bcc Header Field in the
origheaders of a copy of a message sent to the named recipient, origheaders of a copy of a message sent to the named recipient,
defeating the purpose of using Bcc instead of Cc (see Section 11.4 defeating the purpose of using Bcc instead of Cc (see Section 11.4
for more details about risks related to Bcc). for more details about risks related to Bcc).
Clearly, no end-to-end cryptographic protection of any Header Field Clearly, no end-to-end cryptographic protection of any Header Field
as defined in this document will hide such a sensitive field from the as defined in this document will hide such a sensitive field from the
intended recipient. Instead, the composing MUA MUST populate the intended recipient. Instead, the composing MUA MUST populate the
origheaders list for any outbound message with only information the origheaders list for any outbound message with only information the
recipient should have access to. This is true for messages without recipient should have access to. This is true for messages without
any cryptographic protection as well, of course, and it is even worse 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 the there: Such a leak is exposed to the transport agents as well as the
recipient. An encrypted message with Header Protection and a more recipient. An encrypted message with Header Protection and a more
ambitious Header Confidentiality Policy avoid these leaks exposing ambitious Header Confidentiality Policy avoids these leaks that
information to the transport agents but cannot defend against such a expose information to the transport agents, but it cannot defend
leak to the recipient. against such a leak to the recipient.
11.2.2. Encrypted Header Fields Can Be Inferred From External or 11.2.2. Encrypted Header Fields Can Be Inferred from External or
Internal Metadata Internal Metadata
For example, if the To and Cc Header Fields are removed from the For example, if the To and Cc Header Fields are removed from the
unprotected Header Section, the values in those fields might still be unprotected Header Section, the values in those fields might still be
inferred with high probability by an adversary who looks at the inferred with high probability by an adversary who looks at the
message either in transit or at rest. If the message is found in, or message either in transit or at rest. If the message is found in a
being delivered to a mailbox for bob@example.org, it's likely that mailbox, or being delivered to a mailbox, for example,
Bob was in either To or Cc. Furthermore, encrypted message bob@example.org, it's likely that Bob was in either To or Cc.
ciphertext may hint at the recipients: for S/MIME messages, the Furthermore, encrypted message ciphertext may hint at the recipients:
RecipientInfo, and for PGP/MIME messages the key ID in the Public Key For S/MIME messages, the RecipientInfo, and for PGP/MIME messages,
Encrypted Session Key (PKESK) packets will all hint at a specific set the key ID in the Public Key Encrypted Session Key (PKESK) packets
of recipients. Additionally, an MTA that handles the message may add will all hint at a specific set of recipients. Additionally, an MTA
a Received Header Field (or some other custom Header Field) that that handles the message may add a Received Header Field (or some
leaks some information about the nature of the delivery. other custom Header Field) that leaks some information about the
nature of the delivery.
11.2.3. Encrypted Header Fields May Not Be Fully Masked by HCP 11.2.3. Encrypted Header Fields May Not Be Fully Masked by HCP
In another example, if the HCP modifies the Date header to mask out In another example, if the HCP modifies the Date header to mask out
high-resolution time stamps (e.g., rounding to the most recent hour), high-resolution timestamps (e.g., rounding to the most recent hour),
some information about the date of delivery will still be attached to some information about the date of delivery will still be attached to
the e-mail. At the very least, the low resolution, global version of the email. At the very least, the low-resolution, global version of
the date will be present on the message. Additionally, Header Fields the date will be present on the message. Additionally, Header Fields
like Received that are added during message delivery might include like Received that are added during message delivery might include
higher-resolution timestamps. And if the message lands in a mailbox higher-resolution timestamps. And if the message lands in a mailbox
that is ordered by time of receipt, even its placement in the mailbox that is ordered by time of receipt, even its placement in the mailbox
and the non-obscured Date Header Fields of the surrounding messages and the unobscured Date Header Fields of the surrounding messages
could leak this information. could leak this information.
Some Header Fields like From may be impossible to fully obscure, as Some Header Fields like From may be impossible to fully obscure, as
many modern message delivery systems depend on at least domain many modern message delivery systems depend on at least domain
information in the From Header Field for determining whether a information in the From Header Field for determining whether a
message is coming from a domain with "good reputation" (that is, from message is coming from a domain with "good reputation" (that is, from
a domain that is not known for leaking spam). So even if an a domain that is not known for leaking spam). So even if an
ambitious HCP opts to remove the human-readable part from any From ambitious HCP opts to remove the human-readable part from any From
Header Field, and to standardize/genericize the local part of the Header Field and to standardize/genericize the local part of the From
From address, the domain will still leak. address, the domain will still leak.
11.3. A Naive Recipient May Overestimate the Cryptographic Status of a 11.3. A Naive Recipient May Overestimate the Cryptographic Status of a
Header Field in an Encrypted Message Header Field in an Encrypted Message
When an encrypted (or signed-and-encrypted) message is in transit, an When an encrypted (or signed-and-encrypted) message is in transit, an
active intermediary can strip or tamper with any Header Field that active intermediary can strip or tamper with any Header Field that
appears outside the Cryptographic Envelope. A receiving MUA that appears outside the Cryptographic Envelope. A receiving MUA that
naively infers cryptographic status from differences between the naively infers cryptographic status from differences between the
external Header Fields and those found in the Cryptographic Envelope external Header Fields and those found in the Cryptographic Envelope
could be tricked into overestimating the protections afforded to some could be tricked into overestimating the protections afforded to some
skipping to change at page 68, line 38 skipping to change at line 3127
Header Field unchanged, a cleanly delivered message would indicate Header Field unchanged, a cleanly delivered message would indicate
that the Cc Header Field has a cryptographic status of signed. But that the Cc Header Field has a cryptographic status of signed. But
if an intermediary attacker simply removes the Header Field from the if an intermediary attacker simply removes the Header Field from the
unprotected Header Section before forwarding the message, then the unprotected Header Section before forwarding the message, then the
naive recipient might believe that the field has a cryptographic naive recipient might believe that the field has a cryptographic
status of signed-and-encrypted. status of signed-and-encrypted.
This document offers protection against such an attack by way of the This document offers protection against such an attack by way of the
HP-Outer Header Fields that can be found on the Cryptographic HP-Outer Header Fields that can be found on the Cryptographic
Payload. If a Header Field appears to have been obscured by Payload. If a Header Field appears to have been obscured by
inspection of the outer message, but an HP-Outer Header Field matches inspection of the outer message but an HP-Outer Header Field matches
it exactly, the receiving MUA can indicate to the user that the it exactly, then the receiving MUA can indicate to the user that the
Header Field in question may not have been confidential. Header Field in question may not have been confidential.
In such a case, a cautious MUA may render the Header Field in In such a case, a cautious MUA may render the Header Field in
question as signed (because the sender did not hide it), but still question as signed (because the sender did not hide it) but still
treat it as signed-and-encrypted during reply, to avoid accidental treat it as signed-and-encrypted during reply to avoid accidental
leakage of the cleartext value in the reply message, as described in leakage of the cleartext value in the reply message, as described in
Section 6.1. Section 6.1.
11.4. Privacy and Deliverability Risks with Bcc and Encrypted Messages 11.4. Privacy and Deliverability Risks with Bcc and Encrypted Messages
As noted in Section 9.3 of [I-D.ietf-lamps-e2e-mail-guidance], As noted in Section 9.3 of [RFC9787], handling Bcc when generating an
handling Bcc when generating an encrypted e-mail message can be encrypted email message can be particularly tricky. With Header
particularly tricky. With Header Protection, there is an additional Protection, there is an additional wrinkle. When an encrypted email
wrinkle. When an encrypted e-mail message with Header Protection has message with Header Protection has a Bcc'ed recipient, and the
a Bcc'ed recipient, and the composing MUA explicitly includes the composing MUA explicitly includes the Bcc'ed recipient's address in
Bcc'ed recipient's address in their copy of the message (see the their copy of the message (see the "second method" in Section 3.6.3
"second method" in Section 3.6.3 of [RFC5322]), that Bcc Header Field of [RFC5322]), that Bcc Header Field will always be visible to the
will always be visible to the Bcc'ed recipient. Bcc'ed recipient.
In this scenario, though, the composing MUA has one additional In this scenario, though, the composing MUA has one additional
choice: whether to hide the Bcc Header Field from intervening message choice: whether or not to hide the Bcc Header Field from intervening
transport agents, by returning null when the HCP is invoked for Bcc. message transport agents by returning null when the HCP is invoked
If the composing MUA's rationale for including an explicit Bcc in the for Bcc. If the composing MUA's rationale for including an explicit
copy of the message sent to the Bcc recipient is to ensure Bcc in the copy of the message sent to the Bcc recipient is to ensure
deliverability via a message transport agent that inspects message deliverability via a message transport agent that inspects message
Header Fields, then stripping the Bcc field during encryption may Header Fields, then stripping the Bcc field during encryption may
cause the intervening transport agent to drop the message entirely. cause the intervening transport agent to drop the message entirely.
This is why Bcc is not explicitly stripped in hcp_baseline. This is why Bcc is not explicitly stripped in hcp_baseline.
If, on the other hand, deliverability to a Bcc'ed recipient is not a On the other hand, if deliverability to a Bcc'ed recipient is not a
concern, the most privacy-preserving option is to simply omit the Bcc concern, the most privacy-preserving option is to simply omit the Bcc
Header Field from the protected Header Section in the first place. Header Field from the protected Header Section in the first place.
An MUA that is capable of receiving and processing such a message can An MUA that is capable of receiving and processing such a message can
infer that since their user's address was not mentioned in any To or infer that since their user's address was not mentioned in any To or
Cc Header Field, they were likely a Bcc recipient. Cc Header Field, they were likely a Bcc recipient.
Please also see Section 9.3 of [I-D.ietf-lamps-e2e-mail-guidance] for Please also see Section 9.3 of [RFC9787] for more discussion about
more discussion about Bcc and encrypted messages. Bcc and encrypted messages.
12. IANA Considerations 12. IANA Considerations
This document registers an e-mail Header Field, describes parameters This document registers an email Header Field, describes parameters
for the Content-Type Header Field, and establishes a registry for for the Content-Type Header Field, and establishes a registry for
Header Confidentiality Policies to facilitate HCP evolution. Header Confidentiality Policies to facilitate HCP evolution.
12.1. Register the HP-Outer Header Field 12.1. Registration of the HP-Outer Header Field
This document requests IANA to register the following Header Field in IANA has registered the following Header Field in the "Permanent
the "Permanent Message Header Field Names" registry within "Message Message Header Field Names" registry within the "Message Headers"
Headers" in accordance with [RFC3864]. registry group <https://www.iana.org/assignments/message-headers> in
accordance with [RFC3864].
+============+==========+==========+==========+===============+ +===================+==========+==========+===============+
| Header | Template | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
| Field Name | | | | | +===================+==========+==========+===============+
+============+==========+==========+==========+===============+ | HP-Outer | mail | standard | Section 2.2.1 |
| HP-Outer | | mail | standard | Section 2.2.1 | | | | | of RFC 9788 |
| | | | | of RFCXXXX | +-------------------+----------+----------+---------------+
+------------+----------+----------+----------+---------------+
Table 2: Additions to 'Permanent Message Header Field Table 2: Addition to the Permanent Message Header Field
Names' registry Names Registry
The Author/Change Controller of these two entries (Section 4.5 of The Author/Change Controller of these two entries (Section 4.5 of
[RFC3864]) should be the IETF itself. [RFC3864]) should be the IETF itself.
12.2. Update Reference for Content-Type Header Field due to hp and hp- 12.2. Reference Update for the Content-Type Header Field
legacy-display Parameters
This document also defines the Content-Type parameters known as hp
(in Section 2.1.1) and hp-legacy-display (in Section 2.1.2).
Consequently, the Content-Type row in the "Permanent Message Header
Field Names" registry should add a reference to this RFC to its
"References" column.
That is, the current row:
+===================+==========+==========+========+===========+
| Header Field Name | Template | Protocol | Status | Reference |
+===================+==========+==========+========+===========+
| Content-Type | | MIME | | [RFC4021] |
+-------------------+----------+----------+--------+-----------+
Table 3: Existing row in 'Permanent Message Header Field
Names' registry
Should be updated to have the following values:
+===================+==========+==========+========+===========+
| Header Field Name | Template | Protocol | Status | Reference |
+===================+==========+==========+========+===========+
| Content-Type | | MIME | | [RFC4021] |
| | | | | [RFCXXXX] |
+-------------------+----------+----------+--------+-----------+
Table 4: Replacement row in 'Permanent Message Header Field
Names' registry
12.3. New Registry: Mail Header Confidentiality Policies 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, this document has been added as a reference for
Content-Type in the "Permanent Message Header Field Names" registry
as shown below.
This document also requests IANA to create a new registry in the +===================+==========+========================+
"Mail Parameters" protocol group (https://www.iana.org/assignments/ | Header Field Name | Protocol | Reference |
mail-parameters/) titled Mail Header Confidentiality Policies with +===================+==========+========================+
the following content: | Content-Type | MIME | [RFC4021] and RFC 9788 |
+-------------------+----------+------------------------+
+========================+=================+=========+=============+ Table 3: Permanent Message Header Field Names Registry
| Header Confidentiality | Description |Reference| Recommended |
| Policy Name | | | |
+========================+=================+=========+=============+
| hcp_no_confidentiality | No header |Section | N |
| | confidentiality |3.2.3 of | |
| | |RFCXXX | |
| | |(this | |
| | |document)| |
+------------------------+-----------------+---------+-------------+
| hcp_baseline | Confidentiality |Section | Y |
| | for |3.2.1 of | |
| | Informational |RFCXXX | |
| | Header Fields: |(this | |
| | Subject Header |document)| |
| | Field is | | |
| | obscured, | | |
| | Keywords and | | |
| | Comments are | | |
| | removed | | |
+------------------------+-----------------+---------+-------------+
| hcp_shy | Obscure |Section | N |
| | Subject, remove |3.2.2 of | |
| | Keywords and |RFCXXX | |
| | Comments, |(this | |
| | remove the time |document)| |
| | zone from Date, | | |
| | and obscure | | |
| | display-names | | |
+------------------------+-----------------+---------+-------------+
Table 5: Mail Header Confidentiality Policies registry 12.3. New Mail Header Confidentiality Policies Registry
hcp_example_hide_cc is offered as an example in Section 3 but is not IANA has created a new registry titled "Mail Header Confidentiality
formally registered by this document. Policies" within the "MAIL Parameters" registry group
<https://www.iana.org/assignments/mail-parameters/> with the
following content:
Please add the following textual note to this registry: +========================+=================+=============+=========+
| Header Confidentiality | Description | Recommended |Reference|
| Policy Name | | | |
+========================+=================+=============+=========+
| hcp_no_confidentiality | No header | N |Section |
| | confidentiality | |3.2.3 of |
| | | |RFC 9788 |
+------------------------+-----------------+-------------+---------+
| hcp_baseline | Confidentiality | Y |Section |
| | for | |3.2.1 of |
| | Informational | |RFC 9788 |
| | Header Fields: | | |
| | Subject Header | | |
| | Field is | | |
| | obscured, | | |
| | Keywords and | | |
| | Comments are | | |
| | removed | | |
+------------------------+-----------------+-------------+---------+
| hcp_shy | Obscure | N |Section |
| | Subject, remove | |3.2.2 of |
| | Keywords and | |RFC 9788 |
| | Comments, | | |
| | remove the time | | |
| | zone from Date, | | |
| | and obscure | | |
| | display-names | | |
+------------------------+-----------------+-------------+---------+
The Header Confidentiality Policy Name never appears on the wire. Table 4: Mail Header Confidentiality Policies Registry
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 XXX (this
document).
Adding an entry to this registry with an N in the "Recommended" Note that hcp_example_hide_cc is offered as an example in Section 3
column follows the registration policy of SPECIFICATION REQUIRED. but is not formally registered by this document.
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. During IETF REVIEW, the
designated expert must also be consulted. Guidance for the
designated expert can be found in Section 3.4.2.
13. Acknowledgments The following textual note has been added to this registry:
Alexander Krotov identified the risk of From address spoofing (see | Adding an entry to this registry with an N in the "Recommended"
Section 10.1) and helped provide guidance to MUAs. | 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.
Thore Göbel identified significant gaps in earlier versions of this Note that during IETF Review, the designated expert must be
document, and proposed concrete and substantial improvements. Thanks consulted. Guidance for the designated expert can be found in
to his contributions, the document is clearer, and the protocols Section 3.4.2.
described herein are more useful.
Additionally, the authors would like to thank the following people Additionally, this textual note has been added to the registry:
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, Krista Bennett, Kelly Bristol, Lars Rohwedder, Michael StJohns,
Nicolas Lidzborski, Orie Steele, Paul Wouters, Peter Yee, Phillip
Tao, Robert Williams, Rohan Mahy, Roman Danyliw, Russ Housley, Sofia
Balicka, Steve Kille, Volker Birk, Warren Kumari, and Wei Chuang.
14. References | 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.
14.1. Normative References 13. References
[I-D.ietf-lamps-e2e-mail-guidance] 13.1. Normative References
Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Guidance
on End-to-End E-mail Security", Work in Progress,
Internet-Draft, draft-ietf-lamps-e2e-mail-guidance-16, 16
March 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-lamps-e2e-mail-guidance-16>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/rfc/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004,
<https://www.rfc-editor.org/rfc/rfc3864>. <https://www.rfc-editor.org/info/rfc3864>.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083, Authenticated-Enveloped-Data Content Type", RFC 5083,
DOI 10.17487/RFC5083, November 2007, DOI 10.17487/RFC5083, November 2007,
<https://www.rfc-editor.org/rfc/rfc5083>. <https://www.rfc-editor.org/info/rfc5083>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/rfc/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551, Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/rfc/rfc8551>. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, [RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe,
"OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024,
<https://www.rfc-editor.org/rfc/rfc9580>. <https://www.rfc-editor.org/info/rfc9580>.
14.2. Informative References [RFC9787] Gillmor, D. K., Ed., Hoeneisen, B., Ed., and A. Melnikov,
Ed., "Guidance on End-to-End Email Security", RFC 9787,
DOI 10.17487/RFC9787, May 2025,
<https://www.rfc-editor.org/info/rfc9787>.
13.2. Informative References
[chrome-indicators] [chrome-indicators]
Schechter, E., "Evolving Chrome's security indicators", Schechter, E., "Evolving Chrome's security indicators",
May 2018, <https://blog.chromium.org/2018/05/evolving- Chromium Blog, May 2018,
chromes-security-indicators.html>. <https://blog.chromium.org/2018/05/evolving-chromes-
security-indicators.html>.
[CSS] World Wide Web Consortium, "Cascading Style Sheets Level 2 [CSS] Bos, B., Ed., "Cascading Style Sheets Level 2 Revision 2
Revision 2 (CSS 2.2) Specification", 12 April 2016, (CSS 2.2) Specification", W3C First Public Working Draft,
<https://www.w3.org/TR/2016/WD-CSS22-20160412/>. 12 April 2016,
<https://www.w3.org/TR/2016/WD-CSS22-20160412/>. Latest
version available at <https://www.w3.org/TR/CSS22/>.
[HTML-ESCAPES] [HTML-ESCAPES]
W3C, "Using character escapes in markup and CSS", n.d., W3C, "Using character escapes in markup and CSS", 12
<https://www.w3.org/International/questions/qa- August 2010, <https://www.w3.org/International/questions/
escapes#use>. qa-escapes#use>.
[I-D.autocrypt-lamps-protected-headers]
Einarsson, B. R., "juga", and D. K. Gillmor, "Protected
Headers for Cryptographic E-mail", Work in Progress,
Internet-Draft, draft-autocrypt-lamps-protected-headers-
02, 20 December 2019,
<https://datatracker.ietf.org/doc/html/draft-autocrypt-
lamps-protected-headers-02>.
[I-D.pep-email] [PEP-EMAIL]
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
Email Formats and Protocols", Work in Progress, Internet- Email Formats and Protocols", Work in Progress, Internet-
Draft, draft-pep-email-02, 16 December 2022, Draft, draft-pep-email-02, 16 December 2022,
<https://datatracker.ietf.org/doc/html/draft-pep-email- <https://datatracker.ietf.org/doc/html/draft-pep-email-
02>. 02>.
[I-D.pep-general] [PEP-GENERAL]
Birk, V., Marques, H., and B. Hoeneisen, "pretty Easy Birk, V., Marques, H., and B. Hoeneisen, "pretty Easy
privacy (pEp): Privacy by Default", Work in Progress, privacy (pEp): Privacy by Default", Work in Progress,
Internet-Draft, draft-pep-general-02, 16 December 2022, Internet-Draft, draft-pep-general-02, 16 December 2022,
<https://datatracker.ietf.org/doc/html/draft-pep-general- <https://datatracker.ietf.org/doc/html/draft-pep-general-
02>. 02>.
[PGPCONTROL] [PGPCONTROL]
UUNET Technologies, Inc., "Authentication of Usenet Group UUNET Technologies, Inc., "Authentication of Usenet Group
Changes", 27 October 2016, Changes", 27 October 2016,
<https://ftp.isc.org/pub/pgpcontrol/>. <https://ftp.isc.org/pub/pgpcontrol/>.
[PGPVERIFY-FORMAT] [PGPVERIFY-FORMAT]
Lawrence, D. C., "Signing Control Messages, Verifying Lawrence, D. C., "Signing Control Messages, Verifying
Control Messages", n.d., Control Messages",
<https://www.eyrie.org/~eagle/usefor/other/pgpverify>. <https://www.eyrie.org/~eagle/usefor/other/pgpverify>.
[PROTECTED-HEADERS]
Einarsson, B. R., juga, and D. K. Gillmor, "(Deprecated)
Protected E-mail Headers", Work in Progress, Internet-
Draft, draft-autocrypt-lamps-protected-headers-03, 16
April 2025, <https://datatracker.ietf.org/doc/html/draft-
autocrypt-lamps-protected-headers-03>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/rfc/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, DOI 10.17487/RFC2047, November 1996, RFC 2047, DOI 10.17487/RFC2047, November 1996,
<https://www.rfc-editor.org/rfc/rfc2047>. <https://www.rfc-editor.org/info/rfc2047>.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
<https://www.rfc-editor.org/rfc/rfc2049>. <https://www.rfc-editor.org/info/rfc2049>.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, "MIME Security with OpenPGP", RFC 3156,
DOI 10.17487/RFC3156, August 2001, DOI 10.17487/RFC3156, August 2001,
<https://www.rfc-editor.org/rfc/rfc3156>. <https://www.rfc-editor.org/info/rfc3156>.
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, DOI 10.17487/RFC3851, July 2004, RFC 3851, DOI 10.17487/RFC3851, July 2004,
<https://www.rfc-editor.org/rfc/rfc3851>. <https://www.rfc-editor.org/info/rfc3851>.
[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME
Header Fields", RFC 4021, DOI 10.17487/RFC4021, March Header Fields", RFC 4021, DOI 10.17487/RFC4021, March
2005, <https://www.rfc-editor.org/rfc/rfc4021>. 2005, <https://www.rfc-editor.org/info/rfc4021>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/rfc/rfc5751>. 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/rfc/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/rfc/rfc5891>. <https://www.rfc-editor.org/info/rfc5891>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/rfc/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/rfc/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities
(DANE) Bindings for OpenPGP", RFC 7929, (DANE) Bindings for OpenPGP", RFC 7929,
DOI 10.17487/RFC7929, August 2016, DOI 10.17487/RFC7929, August 2016,
<https://www.rfc-editor.org/rfc/rfc7929>. <https://www.rfc-editor.org/info/rfc7929>.
[RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to [RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to
Associate Certificates with Domain Names for S/MIME", Associate Certificates with Domain Names for S/MIME",
RFC 8162, DOI 10.17487/RFC8162, May 2017, RFC 8162, DOI 10.17487/RFC8162, May 2017,
<https://www.rfc-editor.org/rfc/rfc8162>. <https://www.rfc-editor.org/info/rfc8162>.
[RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M. [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
Kucherawy, Ed., "The Authenticated Received Chain (ARC) Kucherawy, Ed., "The Authenticated Received Chain (ARC)
Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
<https://www.rfc-editor.org/rfc/rfc8617>. <https://www.rfc-editor.org/info/rfc8617>.
[RFC9216] Gillmor, D. K., Ed., "S/MIME Example Keys and [RFC9216] Gillmor, D. K., Ed., "S/MIME Example Keys and
Certificates", RFC 9216, DOI 10.17487/RFC9216, April 2022, Certificates", RFC 9216, DOI 10.17487/RFC9216, April 2022,
<https://www.rfc-editor.org/rfc/rfc9216>. <https://www.rfc-editor.org/info/rfc9216>.
Appendix A. Table of Pseudocode Listings Appendix A. Table of Pseudocode Listings
This document contains guidance with pseudocode descriptions. Each This document contains guidance with pseudocode descriptions. Each
algorithm is listed here for easy reference. algorithm is listed here for easy reference.
+===========================+=========================+===========+ +===========================+=========================+===========+
| Method Name | Description | Reference | | Method Name | Description | Reference |
+===========================+=========================+===========+ +===========================+=========================+===========+
| HeaderSetsFromMessage | Derive "outer" and | Section | | HeaderSetsFromMessage | Derive "outer" and | Section |
skipping to change at page 77, line 36 skipping to change at line 3488
| | protections (but no | | | | protections (but no | |
| | header protection) | | | | header protection) | |
+---------------------------+-------------------------+-----------+ +---------------------------+-------------------------+-----------+
| Compose | Compose a message with | Section | | Compose | Compose a message with | Section |
| | end-to-end | 5.2.1 | | | end-to-end | 5.2.1 |
| | cryptographic | | | | cryptographic | |
| | protections including | | | | protections including | |
| | header protection | | | | header protection | |
+---------------------------+-------------------------+-----------+ +---------------------------+-------------------------+-----------+
Table 6: Table of Pseudocode Listings Table 5: Table of Pseudocode Listings
Appendix B. Possible Problems with Legacy MUAs Appendix B. Possible Problems with Legacy MUAs
When an e-mail message with end-to-end cryptographic protection is When an email message with end-to-end cryptographic protection is
received by a mail user agent, the user might experience many received by a mail user agent, the user might experience many
different possible problematic interactions. A message with Header different possible problematic interactions. A message with Header
Protection may introduce new forms of user experience failure. Protection may introduce new forms of user experience failure.
In this section, the authors enumerate different kinds of failures we In this section, the authors enumerate different kinds of failures we
have observed when reviewing, rendering, and replying to messages have observed when reviewing, rendering, and replying to messages
with different forms of Header Protection in different Legacy MUAs. with different forms of Header Protection in different Legacy MUAs.
Different Legacy MUAs demonstrate different subsets of these Different Legacy MUAs demonstrate different subsets of these
problems. problems.
A conformant MUA would not exhibit any of these problems. An A conformant MUA would not exhibit any of these problems. An
implementer updating their Legacy MUA to be compliant with this implementer updating their Legacy MUA to be compliant with this
specification should consider these concerns and try to avoid them. specification should consider these concerns and try to avoid them.
Recall that "protected" refers to the "inner" values, e.g., the real Recall that "protected" refers to the "inner" values, e.g., the real
Subject, and "unprotected" refers to the "outer" values, e.g., the Subject, and "unprotected" refers to the "outer" values, e.g., the
dummy Subject. dummy Subject.
B.1. Problems Viewing Messages in a List View B.1. Problems Viewing Messages in a List View
* Unprotected Subject, Date, From, To Header Fields are visible * Unprotected Subject, Date, From, and To Header Fields are visible
(instead of being replaced by protected values) (instead of being replaced by protected values)
* Threading is not visible * Threading is not visible
B.2. Problems when Rendering a Message B.2. Problems When Rendering a Message
* Unprotected Subject is visible * Unprotected Subject is visible
* Protected Subject (on its own) is visible in the body * Protected Subject (on its own) is visible in the body
* Protected Subject, Date, From, and To Header Fields visible in the * Protected Subject, Date, From, and To Header Fields are visible in
body the body
* User interaction needed to view whole message * User interaction needed to view the whole message
* User interaction needed to view message body * User interaction needed to view the message body
* User interaction needed to view protected subject * User interaction needed to view the protected Subject
* Impossible to view protected Subject * Impossible to view the protected Subject
* Nuisance alarms during user interaction * Nuisance alarms during user interaction
* Impossible to view message body * Impossible to view the message body
* Appears as a forwarded message * Appears as a forwarded message
* Appears as an attachment * Appears as an attachment
* Security indicators not visible * Security indicators not visible
* Security indicators do not identify protection status of Header * Security indicators do not identify the protection status of
Fields Header Fields
* User has multiple different methods to reply (e.g., reply to * User has multiple different methods to reply (e.g., reply to
outer, reply to inner) outer, reply to inner)
* User sees English "Subject:" in body despite message itself being * User sees English "Subject:" in body despite message itself being
in non-English in non-English
* Security indicators do not identify protection status of Header * Security indicators do not identify the protection status of
Fields Header Fields
* Header Fields in body render with local Header Field names (e.g., * Header Fields in the body render with local Header Field names
showing "Betreff" instead of "Subject") and dates (TZ, locale) (e.g., showing "Betreff" instead of "Subject") and dates (TZ,
locale)
B.3. Problems when Replying to a Message B.3. Problems When Replying to a Message
Note that the use case here is: Note that the use case here is:
* User views message, to the point where they can read it * User views a message, to the point where they can read it
* User then replies to message, and they are shown a message * User then replies to the message, and they are shown a message
composition window, which has some UI elements composition window, which has some UI elements
* If the MUA has multiple different methods to reply to a message, * If the MUA has multiple different methods to reply to a message,
each way may need to be evaluated separately each way may need to be evaluated separately
This section also uses the shorthand UI:x to mean "the UI element This section also uses the shorthand UI:x to mean "the UI element
that the user can edit that they think of as x." that the user can edit that they think of as x".
* Unprotected Subject is in UI:subject (instead of the protected * Unprotected Subject is in UI:subject (instead of the protected
Subject) Subject)
* Protected Subject is quoted in UI:body (from Legacy Display * Protected Subject is quoted in UI:body (from Legacy Display
Element) Element)
* Protected Subject leaks when the reply is serialised into MIME * Protected Subject leaks when the reply is serialized into MIME
* Protected Subject is not anywhere in UI * Protected Subject is not anywhere in UI
* Message body is _not_ visible/quoted in UI:body * Message body is _not_ visible/quoted in UI:body
* User cannot reply while viewing protected message * User cannot reply while viewing protected message
* Reply is not encrypted by default (but is for legacy signed-and- * Reply is not encrypted by default (but is for legacy signed-and-
encrypted messages without Header Protection) encrypted messages without Header Protection)
skipping to change at page 80, line 19 skipping to change at line 3615
diagrammatic view of its structure, and examples of how an MUA might diagrammatic view of its structure, and examples of how an MUA might
render it. render it.
The cryptographic protections used in this document use the S/MIME The cryptographic protections used in this document use the S/MIME
standard, and keying material and certificates come from [RFC9216]. standard, and keying material and certificates come from [RFC9216].
These messages should be accessible to any IMAP client at These messages should be accessible to any IMAP client at
imap://bob@header-protection.cmrg.net/ (any password should imap://bob@header-protection.cmrg.net/ (any password should
authenticate to this read-only IMAP mailbox). authenticate to this read-only IMAP mailbox).
You can also download copies of these test vectors separately at Copies of these test vectors can also be downloaded separately at
https://header-protection.cmrg.net. <https://header-protection.cmrg.net>.
If any of the messages downloaded differ from those offered here, If any of the messages downloaded differ from those offered here,
this document is the canonical source. this document is the canonical source.
C.1. Baseline Messages C.1. Baseline Messages
These messages offer no header protection at all, and can be used as These messages offer no header protection at all and can be used as a
a baseline. They are provided in this document as a counterexample. baseline. They are provided in this document as a counterexample.
An MUA implementer can use these messages to verify that the reported An MUA implementer can use these messages to verify that the reported
cryptographic summary of the message indicates no header protection. cryptographic summary of the message indicates no header protection.
C.1.1. No Cryptographic Protections Over a Simple Message C.1.1. No Cryptographic Protections over a Simple Message
This message uses no cryptographic protection at all. Its body is a This message uses no cryptographic protection at all. Its body is a
text/plain message. text/plain message.
It has the following structure: It has the following structure:
└─╴text/plain 152 bytes └─╴text/plain 152 bytes
Its contents are: Its contents are:
skipping to change at page 81, line 26 skipping to change at line 3660
no-crypto no-crypto
message. message.
This message uses no cryptographic protection at all. Its body This message uses no cryptographic protection at all. Its body
is a text/plain message. is a text/plain message.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.1.2. S/MIME Signed-only signedData Over a Simple Message, No Header C.1.2. S/MIME Signed-Only signedData over a Simple Message, No Header
Protection Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a text/plain message. It uses no header protection. payload is a text/plain message. It uses no header protection.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 3856 bytes └─╴application/pkcs7-mime [smime.p7m] 3856 bytes
⇩ (unwraps to) ⇩ (unwraps to)
└─╴text/plain 206 bytes └─╴text/plain 206 bytes
skipping to change at page 83, line 14 skipping to change at line 3745
qdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq qdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMjEwMjIwMTUwMTAyWjAvBgkqhkiG9w0BCQQxIgQgrhyFjywc hkiG9w0BCQUxDxcNMjEwMjIwMTUwMTAyWjAvBgkqhkiG9w0BCQQxIgQgrhyFjywc
FLYzlCbb/xsgb5+a0sgYLUg094upq1ZXLWswDQYJKoZIhvcNAQEBBQAEggEABOi5 FLYzlCbb/xsgb5+a0sgYLUg094upq1ZXLWswDQYJKoZIhvcNAQEBBQAEggEABOi5
kcjRmMF4LK94svcfl92padnfUTSyjJtrIf6R6C7xy87VzsmPOPCmHgZOmTCuvY2D kcjRmMF4LK94svcfl92padnfUTSyjJtrIf6R6C7xy87VzsmPOPCmHgZOmTCuvY2D
iKuMId6WPVdjuRUaW6xkgYtgYjPDhy80NY0a9wXEQtjn448G0UHdM21cJyu9LTAg iKuMId6WPVdjuRUaW6xkgYtgYjPDhy80NY0a9wXEQtjn448G0UHdM21cJyu9LTAg
orSzcT2pwEuGzNdsHW8LB5GtJKYct3RS0+jlbSr7WpZFY1mUrwpsm2r8za2KoOcy orSzcT2pwEuGzNdsHW8LB5GtJKYct3RS0+jlbSr7WpZFY1mUrwpsm2r8za2KoOcy
t/E7Qz/8hT4HU52Na7pS1ZnxrasLr5prSjDSSKs4QK3ncJR8jhF9by0pDCoYgswy t/E7Qz/8hT4HU52Na7pS1ZnxrasLr5prSjDSSKs4QK3ncJR8jhF9by0pDCoYgswy
zYaeJt0N+8uv7ab/kBaE3wfZlipMSFRJIlh+QeXCkIHo5fW5bn/REZHxMMdMfdPh zYaeJt0N+8uv7ab/kBaE3wfZlipMSFRJIlh+QeXCkIHo5fW5bn/REZHxMMdMfdPh
bqYT1i46156CSOqyxA== bqYT1i46156CSOqyxA==
C.1.2.1. S/MIME Signed-only signedData Over a Simple Message, No Header C.1.2.1. S/MIME Signed-Only signedData over a Simple Message, No Header
Protection, Unwrapped Protection, Unwrapped
The S/MIME signed-data layer unwraps to: The S/MIME signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8" Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
This is the This is the
smime-one-part smime-one-part
message. message.
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a text/plain message. It uses no header protection. payload is a text/plain message. It uses no header protection.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.1.3. S/MIME Signed-only multipart/signed Over a Simple Message, No C.1.3. S/MIME Signed-Only multipart/signed over a Simple Message, No
Header Protection Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature This is a signed-only S/MIME message via PKCS#7 detached signature
(multipart/signed). The payload is a text/plain message. It uses no (multipart/signed). The payload is a text/plain message. It uses no
header protection. header protection.
It has the following structure: It has the following structure:
└┬╴multipart/signed 4187 bytes └┬╴multipart/signed 4187 bytes
├─╴text/plain 224 bytes ├─╴text/plain 224 bytes
skipping to change at page 85, line 44 skipping to change at line 3868
MC8GCSqGSIb3DQEJBDEiBCAB+IATfw3+2kO9hwjUYxzW+Z12sfFp2dTb1pmXGS+7 MC8GCSqGSIb3DQEJBDEiBCAB+IATfw3+2kO9hwjUYxzW+Z12sfFp2dTb1pmXGS+7
DzANBgkqhkiG9w0BAQEFAASCAQANJdfU8DtOpINW4FeIWpdexndYvHYy7jFg5ICy DzANBgkqhkiG9w0BAQEFAASCAQANJdfU8DtOpINW4FeIWpdexndYvHYy7jFg5ICy
wIkh1DcqmbdvB4PXcksbJ0zKSVjdjXPdYQYRS4E5ClAEevEe+OkFd16UoGaadoaq wIkh1DcqmbdvB4PXcksbJ0zKSVjdjXPdYQYRS4E5ClAEevEe+OkFd16UoGaadoaq
OjyGnuiEJJbRG2UUZZWMyJW2g8OZRAGZjYgEgvbVflmxqRjFRaeLGUorHaHoxk40 OjyGnuiEJJbRG2UUZZWMyJW2g8OZRAGZjYgEgvbVflmxqRjFRaeLGUorHaHoxk40
LomKSVRTUG11eEhmRmxIY4wKhwc0U9PKjCQFrhu3t1ZkGSfPn9jvdNTJkg85WUpk LomKSVRTUG11eEhmRmxIY4wKhwc0U9PKjCQFrhu3t1ZkGSfPn9jvdNTJkg85WUpk
WqmOyrup6DH4Gb84By+0IMk3vflrOyAw3kbsj6Ij+zymAlH61YypnAvddFBIuZPL WqmOyrup6DH4Gb84By+0IMk3vflrOyAw3kbsj6Ij+zymAlH61YypnAvddFBIuZPL
2LYdIHPLmq8KGrzcgjkjP+Y58hf9U+6gp0KPuS8DAGOvxYs0 2LYdIHPLmq8KGrzcgjkjP+Y58hf9U+6gp0KPuS8DAGOvxYs0
--253-- --253--
C.1.4. S/MIME Signed and Encrypted Over a Simple Message, No Header C.1.4. S/MIME Signed and Encrypted over a Simple Message, No Header
Protection Protection
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses no header protection. message. It uses no header protection.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 6720 bytes └─╴application/pkcs7-mime [smime.p7m] 6720 bytes
↧ (decrypts to) ↧ (decrypts to)
skipping to change at page 88, line 31 skipping to change at line 4000
IXVMYUfa0GFSvfhfXN7r3VvRpzkh7mgJrsIFwG035ZhZq904Z1Yw11N9pns8X2s6 IXVMYUfa0GFSvfhfXN7r3VvRpzkh7mgJrsIFwG035ZhZq904Z1Yw11N9pns8X2s6
PsSOZAO/E0NOMLSrOonmHy2wqGY7kSMprd9FI7ESe1hwLgqh2pVNesYGqx1Aw0AD PsSOZAO/E0NOMLSrOonmHy2wqGY7kSMprd9FI7ESe1hwLgqh2pVNesYGqx1Aw0AD
9rDktHKChXqAQDYElV/D1239rxc3tVFzoXtkk6BcNlwq/hvksAjk1/sMNA9x7OAf 9rDktHKChXqAQDYElV/D1239rxc3tVFzoXtkk6BcNlwq/hvksAjk1/sMNA9x7OAf
gfE/zFZQNhWFNzuGd6ADf4Io+Wg9+L60JZmgBx6A9IiTygG9D38yREzQl0BgfGx4 gfE/zFZQNhWFNzuGd6ADf4Io+Wg9+L60JZmgBx6A9IiTygG9D38yREzQl0BgfGx4
xlkbs830dOgKafDVTMWCNomvOqIcU9kdirLuaOYl7N5yIR3TMH8p2kkkyYH0hMdX xlkbs830dOgKafDVTMWCNomvOqIcU9kdirLuaOYl7N5yIR3TMH8p2kkkyYH0hMdX
TQ5v4K/OUYQteADMquJIJQiIfsOEdfd6to46yWIWlCQSJpN+M2iw0QoOPOjevCkC TQ5v4K/OUYQteADMquJIJQiIfsOEdfd6to46yWIWlCQSJpN+M2iw0QoOPOjevCkC
RVZ0xXALDuEEuUJLjlSrwRVOx5drsqLoClAeH1Li/ZFm+I6qA2pVKrxohwndGimR RVZ0xXALDuEEuUJLjlSrwRVOx5drsqLoClAeH1Li/ZFm+I6qA2pVKrxohwndGimR
3FVKgLzC1srGGXsIGqoq5ueeN2ZTIQ6OyJh/ERLFd0uEeVCv7UIBRwQ9WrNaaFY1 3FVKgLzC1srGGXsIGqoq5ueeN2ZTIQ6OyJh/ERLFd0uEeVCv7UIBRwQ9WrNaaFY1
1OtoJc+0XZ617xSFoKWnyA== 1OtoJc+0XZ617xSFoKWnyA==
C.1.4.1. S/MIME Signed and Encrypted Over a Simple Message, No Header C.1.4.1. S/MIME Signed and Encrypted over a Simple Message, No Header
Protection, Decrypted Protection, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIILPAYJKoZIhvcNAQcCoIILLTCCCykCAQExDTALBglghkgBZQMEAgEwggFlBgkq MIILPAYJKoZIhvcNAQcCoIILLTCCCykCAQExDTALBglghkgBZQMEAgEwggFlBgkq
hkiG9w0BBwGgggFWBIIBUk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6 hkiG9w0BBwGgggFWBIIBUk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6
skipping to change at page 90, line 5 skipping to change at line 4070
Y2F0aW9uIEF1dGhvcml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQME Y2F0aW9uIEF1dGhvcml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQME
AgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0y AgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0y
MTAyMjAxNTAzMDJaMC8GCSqGSIb3DQEJBDEiBCDlUvgsJW6j30yo/fAeR1vd2Kst MTAyMjAxNTAzMDJaMC8GCSqGSIb3DQEJBDEiBCDlUvgsJW6j30yo/fAeR1vd2Kst
erfZdXyjSKu5gnNGRTANBgkqhkiG9w0BAQEFAASCAQAYPeerPzpSeDL0FAep2p3r erfZdXyjSKu5gnNGRTANBgkqhkiG9w0BAQEFAASCAQAYPeerPzpSeDL0FAep2p3r
y/xmN2pXvMsg1OQI/r6H/WIUpXga0Z3Z5Ml/VsZtKIbFGv/3en7GoqKc0w7/R26B y/xmN2pXvMsg1OQI/r6H/WIUpXga0Z3Z5Ml/VsZtKIbFGv/3en7GoqKc0w7/R26B
qKvtjt+0K7CW1BaWKRqcx7hTIVJXQhT7UnQLnT5daf/BiPbf73FEKoOE4N0cvsVY qKvtjt+0K7CW1BaWKRqcx7hTIVJXQhT7UnQLnT5daf/BiPbf73FEKoOE4N0cvsVY
237ni7VR/Rz/uz3TnheOsBk7H/AEmKIaPBnJj8wFoc6E8Vtusy5ZIrhX6YEq6e3A 237ni7VR/Rz/uz3TnheOsBk7H/AEmKIaPBnJj8wFoc6E8Vtusy5ZIrhX6YEq6e3A
YIJ01cm+cNWBa7kORT2pyKZ3yF2IIcoqyEfw/QkPkh6KM5hKSOUhvbQRPdKOv5u+ YIJ01cm+cNWBa7kORT2pyKZ3yF2IIcoqyEfw/QkPkh6KM5hKSOUhvbQRPdKOv5u+
r/KmOuAbX04XzLZY+RYFdPG/grj+YxeJEgZlUfLgx8pJET9J0RkTImNh1zVVU+r4 r/KmOuAbX04XzLZY+RYFdPG/grj+YxeJEgZlUfLgx8pJET9J0RkTImNh1zVVU+r4
C.1.4.2. S/MIME Signed and Encrypted Over a Simple Message, No Header C.1.4.2. S/MIME Signed and Encrypted over a Simple Message, No Header
Protection, Decrypted and Unwrapped Protection, Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8" Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
This is the This is the
smime-signed-enc smime-signed-enc
message. message.
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses no header protection. message. It uses no header protection.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.1.5. No Cryptographic Protections Over a Complex Message C.1.5. No Cryptographic Protections over a Complex Message
This message uses no cryptographic protection at all. Its body is a This message uses no cryptographic protection at all. Its body is a
multipart/alternative message with an inline image/png attachment. multipart/alternative message with an inline image/png attachment.
It has the following structure: It has the following structure:
└┬╴multipart/mixed 1402 bytes └┬╴multipart/mixed 1402 bytes
├┬╴multipart/alternative 794 bytes ├┬╴multipart/alternative 794 bytes
│├─╴text/plain 206 bytes │├─╴text/plain 206 bytes
│└─╴text/html 304 bytes │└─╴text/html 304 bytes
skipping to change at page 92, line 5 skipping to change at line 4162
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--e68-- --e68--
C.1.6. S/MIME Signed-only signedData Over a Complex Message, No Header C.1.6. S/MIME Signed-Only signedData over a Complex Message, No Header
Protection Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a multipart/alternative message with an inline image/png payload is a multipart/alternative message with an inline image/png
attachment. It uses no header protection. attachment. It uses no header protection.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 5253 bytes └─╴application/pkcs7-mime [smime.p7m] 5253 bytes
⇩ (unwraps to) ⇩ (unwraps to)
skipping to change at page 94, line 19 skipping to change at line 4273
dGhvcml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkq dGhvcml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNzAx hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNzAx
MDJaMC8GCSqGSIb3DQEJBDEiBCDw/DGldVr1aM/U2iIYH8C6YHSKLUihv8FIEUZC MDJaMC8GCSqGSIb3DQEJBDEiBCDw/DGldVr1aM/U2iIYH8C6YHSKLUihv8FIEUZC
JPECvDANBgkqhkiG9w0BAQEFAASCAQA/sn8ReNdvJH8O3Ejzs7eF6tBy6DYD5dFE JPECvDANBgkqhkiG9w0BAQEFAASCAQA/sn8ReNdvJH8O3Ejzs7eF6tBy6DYD5dFE
aLVxB6o3G6qHcupmwvHvL6zouALUoh+zkYRxuWNcPQGfbUqXoAC2cQ6ejwtz3Qnm aLVxB6o3G6qHcupmwvHvL6zouALUoh+zkYRxuWNcPQGfbUqXoAC2cQ6ejwtz3Qnm
4L6amZZQC3NnwFfytOrIvGrMdT1M/39igmep2ZUq9BQS7vq0mYQzSgkGm148yOfI 4L6amZZQC3NnwFfytOrIvGrMdT1M/39igmep2ZUq9BQS7vq0mYQzSgkGm148yOfI
QDeuJZGcw1EcFZuFUZPX4J9kvUu5twvDQoPnTitPVGJ9C2lB6PRkYjKW7JAmNtBL QDeuJZGcw1EcFZuFUZPX4J9kvUu5twvDQoPnTitPVGJ9C2lB6PRkYjKW7JAmNtBL
qRbwZbtOjbrhAszzkRG5P8jR+35FIkG6abSF8hwYix0fJokUn3YnU7G6pRM7DSGg qRbwZbtOjbrhAszzkRG5P8jR+35FIkG6abSF8hwYix0fJokUn3YnU7G6pRM7DSGg
S9MtDUy34GTkdUQ7OXFlLa5kpQfUFBbQ5qflKUvIrBsYX6qjWAVs S9MtDUy34GTkdUQ7OXFlLa5kpQfUFBbQ5qflKUvIrBsYX6qjWAVs
C.1.6.1. S/MIME Signed-only signedData Over a Complex Message, No C.1.6.1. S/MIME Signed-Only signedData over a Complex Message, No
Header Protection, Unwrapped Header Protection, Unwrapped
The S/MIME signed-data layer unwraps to: The S/MIME signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="533" Content-Type: multipart/mixed; boundary="533"
--533 --533
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="931" Content-Type: multipart/alternative; boundary="931"
skipping to change at page 95, line 26 skipping to change at line 4328
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--533-- --533--
C.1.7. S/MIME Signed-only multipart/signed Over a Complex Message, No C.1.7. S/MIME Signed-Only multipart/signed over a Complex Message, No
Header Protection Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature This is a signed-only S/MIME message via PKCS#7 detached signature
(multipart/signed). The payload is a multipart/alternative message (multipart/signed). The payload is a multipart/alternative message
with an inline image/png attachment. It uses no header protection. with an inline image/png attachment. It uses no header protection.
It has the following structure: It has the following structure:
└┬╴multipart/signed 5230 bytes └┬╴multipart/signed 5230 bytes
├┬╴multipart/mixed 1344 bytes ├┬╴multipart/mixed 1344 bytes
skipping to change at page 98, line 25 skipping to change at line 4471
MC8GCSqGSIb3DQEJBDEiBCDQTcb+2QaMhBSlslOnLpojyHSnq4gNzFYU45gwqAHj MC8GCSqGSIb3DQEJBDEiBCDQTcb+2QaMhBSlslOnLpojyHSnq4gNzFYU45gwqAHj
7jANBgkqhkiG9w0BAQEFAASCAQCYM1/HD0Ka4aZwwLS4xMGoyFzGn5G2C3ph0jKS 7jANBgkqhkiG9w0BAQEFAASCAQCYM1/HD0Ka4aZwwLS4xMGoyFzGn5G2C3ph0jKS
mCVbpfAxeHnsnuFjdCYzgN/mdBCOQs4P2/rBGWy3DpDHnKdaB+Q2/IZmI1UgyRTM mCVbpfAxeHnsnuFjdCYzgN/mdBCOQs4P2/rBGWy3DpDHnKdaB+Q2/IZmI1UgyRTM
oclbWWQfTLX1BuI/mJKqHBhJn0y17UXCUAnvSoYGFhjmqTQStR3k4PsdJod78pEa oclbWWQfTLX1BuI/mJKqHBhJn0y17UXCUAnvSoYGFhjmqTQStR3k4PsdJod78pEa
9+Yx6lBGVyznuhHaGuB7lh/S9pxAYtoJFUuIVq+frSN5xhmisPXluFHC3UPu3Hyb 9+Yx6lBGVyznuhHaGuB7lh/S9pxAYtoJFUuIVq+frSN5xhmisPXluFHC3UPu3Hyb
3w6gm+bTL4NDNWwXXSn5wfm9Ru05b3eAEv9pADPZ2TKZPxzrfe4wPNzArgYwdn3k 3w6gm+bTL4NDNWwXXSn5wfm9Ru05b3eAEv9pADPZ2TKZPxzrfe4wPNzArgYwdn3k
6NdLvgw4mZmSSiOyOlfKo3cgo4rZuN6CeLCgqZ0GjIJS43v+ 6NdLvgw4mZmSSiOyOlfKo3cgo4rZuN6CeLCgqZ0GjIJS43v+
--4e5-- --4e5--
C.1.8. S/MIME Signed and Encrypted Over a Complex Message, No Header C.1.8. S/MIME Signed and Encrypted over a Complex Message, No Header
Protection Protection
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses no alternative message with an inline image/png attachment. It uses no
header protection. header protection.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8710 bytes └─╴application/pkcs7-mime [smime.p7m] 8710 bytes
skipping to change at page 102, line 5 skipping to change at line 4638
6ugnYd3ahi8Zk3+v6Taz0a7ZUtnGqvarOX6S4EH+h8H+CnLyuOPron5wJIssCMD2 6ugnYd3ahi8Zk3+v6Taz0a7ZUtnGqvarOX6S4EH+h8H+CnLyuOPron5wJIssCMD2
cNDVB8a/n26EiQUG+fsakGyCIEqin5nSSdzgBlDiM0ghav5onizmKyqxHtHjZvRP cNDVB8a/n26EiQUG+fsakGyCIEqin5nSSdzgBlDiM0ghav5onizmKyqxHtHjZvRP
/1tGNa0yDwgfSDycM5QGsMD4JUFmozQ/NZsNeGfJEjyZpsI4v64jzcs4QxEbJoDP /1tGNa0yDwgfSDycM5QGsMD4JUFmozQ/NZsNeGfJEjyZpsI4v64jzcs4QxEbJoDP
/K8v9kiCQZ3NtkHGDRcUBWNDbKij8wgOPAJmHweFIA6UnHoqJdbPzNwsAAjMVN2Z /K8v9kiCQZ3NtkHGDRcUBWNDbKij8wgOPAJmHweFIA6UnHoqJdbPzNwsAAjMVN2Z
vtvsfFtuDu5BALHyKAlf67WbdKfFYqfktnmR2rPXa5U/3WWiS6cOLly6h+cseQvS vtvsfFtuDu5BALHyKAlf67WbdKfFYqfktnmR2rPXa5U/3WWiS6cOLly6h+cseQvS
bPn77hbn6y2tRQOIMstJ7pBIlim6m/duKc7PZz1u/tANP/gKkHzthMyAErEOPmqM bPn77hbn6y2tRQOIMstJ7pBIlim6m/duKc7PZz1u/tANP/gKkHzthMyAErEOPmqM
Plfvt8ju0UpwGpiF1T1E3SRodx5/q8NV6TSKANWeKN7nahusiB5CVO2EclhjATXR Plfvt8ju0UpwGpiF1T1E3SRodx5/q8NV6TSKANWeKN7nahusiB5CVO2EclhjATXR
XmPo08kyxwYYK7P+oBOXsE2gM/uZy3If5hIEfmxxJ+5F19cNiotTQwJM7Jmbag1O XmPo08kyxwYYK7P+oBOXsE2gM/uZy3If5hIEfmxxJ+5F19cNiotTQwJM7Jmbag1O
MtW7IWC7g+sDYln9L8hCxnCjoH331ss7c3470XB9pTy8EBnRdX5IRW9QuoRcMcZw MtW7IWC7g+sDYln9L8hCxnCjoH331ss7c3470XB9pTy8EBnRdX5IRW9QuoRcMcZw
C.1.8.1. S/MIME Signed and Encrypted Over a Complex Message, No Header C.1.8.1. S/MIME Signed and Encrypted over a Complex Message, No Header
Protection, Decrypted Protection, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIPaQYJKoZIhvcNAQcCoIIPWjCCD1YCAQExDTALBglghkgBZQMEAgEwggWSBgkq MIIPaQYJKoZIhvcNAQcCoIIPWjCCD1YCAQExDTALBglghkgBZQMEAgEwggWSBgkq
hkiG9w0BBwGgggWDBIIFf01JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6 hkiG9w0BBwGgggWDBIIFf01JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6
skipping to change at page 104, line 5 skipping to change at line 4731
qdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq qdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMjEwMjIwMTcwMzAyWjAvBgkqhkiG9w0BCQQxIgQgXYQxbGVS hkiG9w0BCQUxDxcNMjEwMjIwMTcwMzAyWjAvBgkqhkiG9w0BCQQxIgQgXYQxbGVS
YbD1RRyrYjMaj8vm0wJceMeGDm9qv/JsQlgwDQYJKoZIhvcNAQEBBQAEggEAbtxK YbD1RRyrYjMaj8vm0wJceMeGDm9qv/JsQlgwDQYJKoZIhvcNAQEBBQAEggEAbtxK
BK0ie88UC9KGR0/nHIWpXJOnN1/tXtEWsLoypwYiw8XKgcN8zgZ06RikcGX12ijW BK0ie88UC9KGR0/nHIWpXJOnN1/tXtEWsLoypwYiw8XKgcN8zgZ06RikcGX12ijW
Gz2wgA2yIRfnzWBvS6zmBc9r37klP8uhB0GgPrPFTtq+GeLn9hUApYQTb20HlSKM Gz2wgA2yIRfnzWBvS6zmBc9r37klP8uhB0GgPrPFTtq+GeLn9hUApYQTb20HlSKM
e34oCU7qv0lYFfN0sDlwxkha1X3AAg4QFcUrnLJRkYFWDH6XvxsHNiLznwsF/+B1 e34oCU7qv0lYFfN0sDlwxkha1X3AAg4QFcUrnLJRkYFWDH6XvxsHNiLznwsF/+B1
uNiPIi7rhKgG3oLYu4H8qGolM5H+gyl7+h4t8hUHZVTxZ6QyTO0K+D2JO8aazcor uNiPIi7rhKgG3oLYu4H8qGolM5H+gyl7+h4t8hUHZVTxZ6QyTO0K+D2JO8aazcor
PgJsa85BUfcx0JXsixcqtLzTAfsPOAQBl1CUHEied1qX6nlMb2gCxP6psFEXPRGM PgJsa85BUfcx0JXsixcqtLzTAfsPOAQBl1CUHEied1qX6nlMb2gCxP6psFEXPRGM
rxSLzwv5QtKJCaDfYw== rxSLzwv5QtKJCaDfYw==
C.1.8.2. S/MIME Signed and Encrypted Over a Complex Message, No Header C.1.8.2. S/MIME Signed and Encrypted over a Complex Message, No Header
Protection, Decrypted and Unwrapped Protection, Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="508" Content-Type: multipart/mixed; boundary="508"
--508 --508
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="804" Content-Type: multipart/alternative; boundary="804"
skipping to change at page 105, line 13 skipping to change at line 4788
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--508-- --508--
C.2. Signed-only Messages C.2. Signed-Only Messages
These messages are signed-only, using different schemes of header These messages are signed-only, using different schemes of header
protection and different S/MIME structure. The use no Header protection and different S/MIME structures. They use no Header
Confidentiality Policy because the hcp is only relevant when a Confidentiality Policy because the HCP is only relevant when a
message is encrypted. message is encrypted.
C.2.1. S/MIME Signed-only signedData Over a Simple Message, Header C.2.1. S/MIME Signed-Only signedData over a Simple Message, Header
Protection Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a text/plain message. It uses the Header Protection payload is a text/plain message. It uses the Header Protection
scheme from the draft. scheme from the draft.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 4189 bytes └─╴application/pkcs7-mime [smime.p7m] 4189 bytes
⇩ (unwraps to) ⇩ (unwraps to)
skipping to change at page 107, line 15 skipping to change at line 4886
XDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B XDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE1MDYwMlowLwYJKoZIhvcNAQkEMSIE BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE1MDYwMlowLwYJKoZIhvcNAQkEMSIE
IHBk91pcJj0zJrTyROHOdfUnQMoctIHVb6WXTpS3gYxlMA0GCSqGSIb3DQEBAQUA IHBk91pcJj0zJrTyROHOdfUnQMoctIHVb6WXTpS3gYxlMA0GCSqGSIb3DQEBAQUA
BIIBABWhy/yIy9RLS3OdZZTlUNChBhzNHjpSSoL3v0JmzOHeYJVblzBgpyPU33Tu BIIBABWhy/yIy9RLS3OdZZTlUNChBhzNHjpSSoL3v0JmzOHeYJVblzBgpyPU33Tu
JALxlGuGp4ybO16yQREHMXNFZJkrqWcIAMZG/4tG7WIHXm0AGIcxl8BKKEpn8t1m JALxlGuGp4ybO16yQREHMXNFZJkrqWcIAMZG/4tG7WIHXm0AGIcxl8BKKEpn8t1m
kiOO/NWzFY9TW1pYd/+CC7Q8Asc+S2Nd269HGrFFpL36r74Gt2xJDxn11N3coBh3 kiOO/NWzFY9TW1pYd/+CC7Q8Asc+S2Nd269HGrFFpL36r74Gt2xJDxn11N3coBh3
khaFt+p5GkqqrNUtfGeo0ifF+66x/oW9A/AtNE+iKwx7mEtukOhBgTXgyr3bi+ev khaFt+p5GkqqrNUtfGeo0ifF+66x/oW9A/AtNE+iKwx7mEtukOhBgTXgyr3bi+ev
sEQzWYVLyVS7TCsCM5A1LxHZHv5gVcX1EMTZi7rRaNKKEmUcA9vbJYBSOWlmR/o4 sEQzWYVLyVS7TCsCM5A1LxHZHv5gVcX1EMTZi7rRaNKKEmUcA9vbJYBSOWlmR/o4
FeLYNUvUvFXvV9YCb/0R0pgp9Aw= FeLYNUvUvFXvV9YCb/0R0pgp9Aw=
C.2.1.1. S/MIME Signed-only signedData Over a Simple Message, Header C.2.1.1. S/MIME Signed-Only signedData over a Simple Message, Header
Protection, Unwrapped Protection, Unwrapped
The S/MIME signed-data layer unwraps to: The S/MIME signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Subject: smime-one-part-hp Subject: smime-one-part-hp
Message-ID: <smime-one-part-hp@example> Message-ID: <smime-one-part-hp@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
skipping to change at page 107, line 42 skipping to change at line 4913
message. message.
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a text/plain message. It uses the Header Protection payload is a text/plain message. It uses the Header Protection
scheme from the draft. scheme from the draft.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.2.2. S/MIME Signed-only multipart/signed Over a Simple Message, C.2.2. S/MIME Signed-Only multipart/signed over a Simple Message,
Header Protection Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature This is a signed-only S/MIME message via PKCS#7 detached signature
(multipart/signed). The payload is a text/plain message. It uses (multipart/signed). The payload is a text/plain message. It uses
the Header Protection scheme from the draft. the Header Protection scheme from the draft.
It has the following structure: It has the following structure:
└┬╴multipart/signed 4435 bytes └┬╴multipart/signed 4435 bytes
├─╴text/plain 250 bytes ├─╴text/plain 250 bytes
skipping to change at page 110, line 8 skipping to change at line 5022
MC8GCSqGSIb3DQEJBDEiBCAIw1Q7hUXhrDaz3lXMFP0A3q3nvlhWh9ejLg/g9kjk MC8GCSqGSIb3DQEJBDEiBCAIw1Q7hUXhrDaz3lXMFP0A3q3nvlhWh9ejLg/g9kjk
vDANBgkqhkiG9w0BAQEFAASCAQAcl0M6ZwFAzFvsP+/siWSN0EM0YWxuOzvCmSWC vDANBgkqhkiG9w0BAQEFAASCAQAcl0M6ZwFAzFvsP+/siWSN0EM0YWxuOzvCmSWC
0QwnAQ/dSwXcKMcej0wWMKTDTQSYBUjxFVE0chcK6FMH2gHDVb/PztWrSECmvh6F 0QwnAQ/dSwXcKMcej0wWMKTDTQSYBUjxFVE0chcK6FMH2gHDVb/PztWrSECmvh6F
utJ2SRxs0uGrFkee3hR0kowuOu9pDXasLtWP2MnB5pSMWX5QMpya1UxYcbIoaUOx utJ2SRxs0uGrFkee3hR0kowuOu9pDXasLtWP2MnB5pSMWX5QMpya1UxYcbIoaUOx
Jeu5zjbYf/Oo2tINvZHP+r+wxQZ7qTaEzviQ+IV0KoJanfU3Qd/giS6MuySwozwP Jeu5zjbYf/Oo2tINvZHP+r+wxQZ7qTaEzviQ+IV0KoJanfU3Qd/giS6MuySwozwP
r3E7YAy3O9dZT7zL6AR5CsC1I0coo7X1PRNnBXXLMEcR/v5cXniGV+GNf8xYaiGA r3E7YAy3O9dZT7zL6AR5CsC1I0coo7X1PRNnBXXLMEcR/v5cXniGV+GNf8xYaiGA
iT9IwijZa6psfTSFjzUWTIc0jGx3GcLZr+BIm+MEBCSRzDum iT9IwijZa6psfTSFjzUWTIc0jGx3GcLZr+BIm+MEBCSRzDum
--78f-- --78f--
C.2.3. S/MIME Signed-only signedData Over a Complex Message, Header C.2.3. S/MIME Signed-Only signedData over a Complex Message, Header
Protection Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a multipart/alternative message with an inline image/png payload is a multipart/alternative message with an inline image/png
attachment. It uses the Header Protection scheme from the draft. attachment. It uses the Header Protection scheme from the draft.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 5647 bytes └─╴application/pkcs7-mime [smime.p7m] 5647 bytes
⇩ (unwraps to) ⇩ (unwraps to)
skipping to change at page 112, line 29 skipping to change at line 5139
QXV0aG9yaXR5AhM3QQV57XV/QqmiXDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgG QXV0aG9yaXR5AhM3QQV57XV/QqmiXDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE3 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE3
MDYwMlowLwYJKoZIhvcNAQkEMSIEIGbRm8jphDRUXRWIk4vxhAup+YZsmtrednWv MDYwMlowLwYJKoZIhvcNAQkEMSIEIGbRm8jphDRUXRWIk4vxhAup+YZsmtrednWv
3iPoigWSMA0GCSqGSIb3DQEBAQUABIIBAEHG833PIy7iky9Ok2pN22fjSF6xtjlt 3iPoigWSMA0GCSqGSIb3DQEBAQUABIIBAEHG833PIy7iky9Ok2pN22fjSF6xtjlt
h1Pi4Eh9PSjQ5Rdrsv9pJFFsBhSLOXv+O8fwYfS1rUrgwsCVMO64zz5MT1Kj4Y4Z h1Pi4Eh9PSjQ5Rdrsv9pJFFsBhSLOXv+O8fwYfS1rUrgwsCVMO64zz5MT1Kj4Y4Z
a6ztE9weXTlciQydOWER6lV1BDP4GwUaz+BBCoKKB0DTHq+nPNo97XtTCUfo55Vz a6ztE9weXTlciQydOWER6lV1BDP4GwUaz+BBCoKKB0DTHq+nPNo97XtTCUfo55Vz
55vmNXxqWQ952hzw+qxxTxKzdYApFd9cZYzvV4otZgtvZDu3sn6GWFCtVpN4+6TR 55vmNXxqWQ952hzw+qxxTxKzdYApFd9cZYzvV4otZgtvZDu3sn6GWFCtVpN4+6TR
xClE93q+LZwvJyXFRFWHcKqpUfQ16ZAomBadrJ1RU3BmRXnC6DAI/J/yhm7OegdN xClE93q+LZwvJyXFRFWHcKqpUfQ16ZAomBadrJ1RU3BmRXnC6DAI/J/yhm7OegdN
0Or/+EuyWAzp0r/GCsSGXt2owaAkGPuZf6kPc0mLhb/VFdeY16wy9J0= 0Or/+EuyWAzp0r/GCsSGXt2owaAkGPuZf6kPc0mLhb/VFdeY16wy9J0=
C.2.3.1. S/MIME Signed-only signedData Over a Complex Message, Header C.2.3.1. S/MIME Signed-Only signedData over a Complex Message, Header
Protection, Unwrapped Protection, Unwrapped
The S/MIME signed-data layer unwraps to: The S/MIME signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Subject: smime-one-part-complex-hp Subject: smime-one-part-complex-hp
Message-ID: <smime-one-part-complex-hp@example> Message-ID: <smime-one-part-complex-hp@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:06:02 -0500 Date: Sat, 20 Feb 2021 12:06:02 -0500
skipping to change at page 113, line 44 skipping to change at line 5202
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--e2e-- --e2e--
C.2.4. S/MIME Signed-only multipart/signed Over a Complex Message, C.2.4. S/MIME Signed-Only multipart/signed over a Complex Message,
Header Protection Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature This is a signed-only S/MIME message via PKCS#7 detached signature
(multipart/signed). The payload is a multipart/alternative message (multipart/signed). The payload is a multipart/alternative message
with an inline image/png attachment. It uses the Header Protection with an inline image/png attachment. It uses the Header Protection
scheme from the draft. scheme from the draft.
It has the following structure: It has the following structure:
└┬╴multipart/signed 5520 bytes └┬╴multipart/signed 5520 bytes
skipping to change at page 117, line 5 skipping to change at line 5352
MC8GCSqGSIb3DQEJBDEiBCDKNV54rM1AYevevF+c3DI/JjX14STIx3nsp5B95mHf MC8GCSqGSIb3DQEJBDEiBCDKNV54rM1AYevevF+c3DI/JjX14STIx3nsp5B95mHf
gTANBgkqhkiG9w0BAQEFAASCAQBWQxNUY6IG27ju4XS4aApRfPoBUjk6m7uUMIQF gTANBgkqhkiG9w0BAQEFAASCAQBWQxNUY6IG27ju4XS4aApRfPoBUjk6m7uUMIQF
/VC9EpXLvWRkn6B9k7L9MMrMJPRKR03oCzimaPjTKH3JKTxdj0gWtb2eELmIaRWY /VC9EpXLvWRkn6B9k7L9MMrMJPRKR03oCzimaPjTKH3JKTxdj0gWtb2eELmIaRWY
nOTaAK/3/h2dqMbPXYXgmWRQPsgFs42m6zWF4CH3YpurTvQC5gB0PSEPF0BOHdcm nOTaAK/3/h2dqMbPXYXgmWRQPsgFs42m6zWF4CH3YpurTvQC5gB0PSEPF0BOHdcm
77bRs4AcPf1mfGThUG3YUNXuJ99BKb3Zz3lQiTohvhti9eHRYAMXL/XdP7TLiGVm 77bRs4AcPf1mfGThUG3YUNXuJ99BKb3Zz3lQiTohvhti9eHRYAMXL/XdP7TLiGVm
Ee7uoUREekXvLmj8C6B3z8fiTfiWlqENU7J2BkrVF0KgW5X9ANwhekNROEx6X05R Ee7uoUREekXvLmj8C6B3z8fiTfiWlqENU7J2BkrVF0KgW5X9ANwhekNROEx6X05R
NVcBYNKNxCxuKMbHcE47Ytt8AuV4NoDWk2yumc8T6sM0Wkue NVcBYNKNxCxuKMbHcE47Ytt8AuV4NoDWk2yumc8T6sM0Wkue
--ba4-- --ba4--
C.2.5. S/MIME Signed-only signedData Over a Complex Message, Legacy RFC C.2.5. S/MIME Signed-Only signedData over a Complex Message, Legacy RFC
8551 Header Protection 8551 Header Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a multipart/alternative message with an inline image/png payload is a multipart/alternative message with an inline image/png
attachment. It uses the legacy RFC 8551 header protection attachment. It uses the legacy RFC 8551 header protection
(RFC8551HP) scheme. (RFC8551HP) scheme.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 5696 bytes └─╴application/pkcs7-mime [smime.p7m] 5696 bytes
skipping to change at page 119, line 28 skipping to change at line 5472
QQV57XV/QqmiXDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzEL QQV57XV/QqmiXDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE3MjYwMlowLwYJKoZI BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE3MjYwMlowLwYJKoZI
hvcNAQkEMSIEIPo6cfj2PNIuP7W8SRv7KpxepLUu9zPgalLeN0BNuSo/MA0GCSqG hvcNAQkEMSIEIPo6cfj2PNIuP7W8SRv7KpxepLUu9zPgalLeN0BNuSo/MA0GCSqG
SIb3DQEBAQUABIIBAIB0l2cJSO2iAJg5nB/+gal+wZn3hOPlWW6n8YQ957q/TxIj SIb3DQEBAQUABIIBAIB0l2cJSO2iAJg5nB/+gal+wZn3hOPlWW6n8YQ957q/TxIj
Iny59ctj4CokVaRb3uAm50r1TpK1h1x/hse1MsZgWQ0ew+omUQQkJg3RLZ9R8wsv Iny59ctj4CokVaRb3uAm50r1TpK1h1x/hse1MsZgWQ0ew+omUQQkJg3RLZ9R8wsv
Ol8SN5WMNdiNSRNC9a3MFtSVPEOCt90XdQdQ2kqeRkL/fthatcF8gI+p4+pOP2+U Ol8SN5WMNdiNSRNC9a3MFtSVPEOCt90XdQdQ2kqeRkL/fthatcF8gI+p4+pOP2+U
dOfnKCjP9nPobyBcXkljv0pRriu7snqQi1O0I1aqd4VwocIm8YV65la0/9522f6e dOfnKCjP9nPobyBcXkljv0pRriu7snqQi1O0I1aqd4VwocIm8YV65la0/9522f6e
/4Zi30oBLuIz1+pT2z6frPzUJfd6UbGtSiAwRHyfIJHZ2PAYt94iMv7U0VmK3GmJ /4Zi30oBLuIz1+pT2z6frPzUJfd6UbGtSiAwRHyfIJHZ2PAYt94iMv7U0VmK3GmJ
TkzFm1if4dpFLofdkEtUX8Is+DPf+/ZB1MvrrQk= TkzFm1if4dpFLofdkEtUX8Is+DPf+/ZB1MvrrQk=
C.2.5.1. S/MIME Signed-only signedData Over a Complex Message, Legacy C.2.5.1. S/MIME Signed-Only signedData over a Complex Message, Legacy
RFC 8551 Header Protection, Unwrapped RFC 8551 Header Protection, Unwrapped
The S/MIME signed-data layer unwraps to: The S/MIME signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: message/rfc822 Content-Type: message/rfc822
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="e68" Content-Type: multipart/mixed; boundary="e68"
Subject: smime-one-part-complex-rfc8551hp Subject: smime-one-part-complex-rfc8551hp
skipping to change at page 121, line 5 skipping to change at line 5538
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--e68-- --e68--
C.2.6. S/MIME Signed-only multipart/signed Over a Complex Message, C.2.6. S/MIME Signed-Only multipart/signed over a Complex Message,
Legacy RFC 8551 Header Protection Legacy RFC 8551 Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature This is a signed-only S/MIME message via PKCS#7 detached signature
(multipart/signed). The payload is a multipart/alternative message (multipart/signed). The payload is a multipart/alternative message
with an inline image/png attachment. It uses the legacy RFC 8551 with an inline image/png attachment. It uses the legacy RFC 8551
header protection (RFC8551HP) scheme. header protection (RFC8551HP) scheme.
It has the following structure: It has the following structure:
└┬╴multipart/signed 5624 bytes └┬╴multipart/signed 5624 bytes
skipping to change at page 124, line 21 skipping to change at line 5700
B49YO28fRuAztMvesvs4M8kW6DAJjYj2fFAgT87CdWErzM7r B49YO28fRuAztMvesvs4M8kW6DAJjYj2fFAgT87CdWErzM7r
--a61-- --a61--
C.3. Signed-and-Encrypted Messages C.3. Signed-and-Encrypted Messages
These messages are signed and encrypted. They use PKCS#7 signedData These messages are signed and encrypted. They use PKCS#7 signedData
inside envelopedData, with different header protection schemes and inside envelopedData, with different header protection schemes and
different Header Confidentiality Policies. different Header Confidentiality Policies.
C.3.1. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.1. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_baseline Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft with message. It uses the Header Protection scheme from the draft with
the hcp_baseline Header Confidentiality Policy. the hcp_baseline Header Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 7825 bytes └─╴application/pkcs7-mime [smime.p7m] 7825 bytes
↧ (decrypts to) ↧ (decrypts to)
skipping to change at page 127, line 27 skipping to change at line 5850
UDswKkNICxi0rUppHp0Nzr7HRH1Y76htABrX+wyFVtA6ttwbm8nNqSVof7wb0pYa UDswKkNICxi0rUppHp0Nzr7HRH1Y76htABrX+wyFVtA6ttwbm8nNqSVof7wb0pYa
cHYMfJDCVJvCLCLy/sePxzwGbH8bW/Va4ebVQfNBgS49ATHNbv2HfjROYqgWAINJ cHYMfJDCVJvCLCLy/sePxzwGbH8bW/Va4ebVQfNBgS49ATHNbv2HfjROYqgWAINJ
l8L3IqyUROBveA+3+a0wEZ/kJnlIJppNGqIhuS7SiKUBXN+lHvxoGAfeJFN8uQ2B l8L3IqyUROBveA+3+a0wEZ/kJnlIJppNGqIhuS7SiKUBXN+lHvxoGAfeJFN8uQ2B
C5KuodUGgcTbVsxkVDweTfBdS8bG06OIAklSXvgE614E146DNKKlqD3nc8xDCzbN C5KuodUGgcTbVsxkVDweTfBdS8bG06OIAklSXvgE614E146DNKKlqD3nc8xDCzbN
+YZ9VjShMxepn6pJ06xOKW54NVTa3zy/R+HZ+/WixdzkAcn8gog93ybxg/9PhAi4 +YZ9VjShMxepn6pJ06xOKW54NVTa3zy/R+HZ+/WixdzkAcn8gog93ybxg/9PhAi4
VauRPmbhrasLdiZwGyQ65shkUaJMwkjY+BpTK40M5KUV4yLr0ddkzbmKWo4Q50FY VauRPmbhrasLdiZwGyQ65shkUaJMwkjY+BpTK40M5KUV4yLr0ddkzbmKWo4Q50FY
NMc2AtCg1A8e9ziRU4Y2MD8abcs5S8rOKk5/R7o5gJGNHjlHpn9Xz+7fTpqtYqIf NMc2AtCg1A8e9ziRU4Y2MD8abcs5S8rOKk5/R7o5gJGNHjlHpn9Xz+7fTpqtYqIf
UY+YJhE+LyJW2uu8Gu1tTe05BSdy13E367FpALD0ZTeQHQWKmAckvwjsQ29YcKFM UY+YJhE+LyJW2uu8Gu1tTe05BSdy13E367FpALD0ZTeQHQWKmAckvwjsQ29YcKFM
n5+AmwDhDdpWKXih4nxFgQ== n5+AmwDhDdpWKXih4nxFgQ==
C.3.1.1. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.1.1. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_baseline, Decrypted Protection with hcp_baseline, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIINkgYJKoZIhvcNAQcCoIINgzCCDX8CAQExDTALBglghkgBZQMEAgEwggO7Bgkq MIINkgYJKoZIhvcNAQcCoIINgzCCDX8CAQExDTALBglghkgBZQMEAgEwggO7Bgkq
hkiG9w0BBwGgggOsBIIDqE1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z hkiG9w0BBwGgggOsBIIDqE1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z
ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw
skipping to change at page 129, line 14 skipping to change at line 5933
qaJcOvT4as6aqdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 qaJcOvT4as6aqdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjIwMTUwOTAyWjAvBgkqhkiG9w0BCQQx DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjIwMTUwOTAyWjAvBgkqhkiG9w0BCQQx
IgQgX3dswDsmGjwXzejaB+kh8kzNOiNjkHpEtBXbJ8gjT5UwDQYJKoZIhvcNAQEB IgQgX3dswDsmGjwXzejaB+kh8kzNOiNjkHpEtBXbJ8gjT5UwDQYJKoZIhvcNAQEB
BQAEggEASC6sf2ioO3Y7yVOzy/6sbjR6suLfigryPkvaOvuh1aHCP/I071/j3LYL BQAEggEASC6sf2ioO3Y7yVOzy/6sbjR6suLfigryPkvaOvuh1aHCP/I071/j3LYL
nER9aCGoEFXzxXzI1aiTjwlQp+Fg6qNz8avFRbSvecUpAsbihlRbbOSirvNwW6F4 nER9aCGoEFXzxXzI1aiTjwlQp+Fg6qNz8avFRbSvecUpAsbihlRbbOSirvNwW6F4
McP6cbA4UR6M52M4mE8buxvDtwf6caf8gwtx9XbZy9a/FSr1YqQoB9ebotZDadDy McP6cbA4UR6M52M4mE8buxvDtwf6caf8gwtx9XbZy9a/FSr1YqQoB9ebotZDadDy
sh0hjzMTjvHbq6DTPytem6Dy7rBP7F32Z1SHNC1Wc2MaW4NKejRxubh4kKpopRvk sh0hjzMTjvHbq6DTPytem6Dy7rBP7F32Z1SHNC1Wc2MaW4NKejRxubh4kKpopRvk
diHHADbm6WUwa3IsgU65HV7X/BkE4vQcYsWzYjqyA3WjpZZWlYus023kqug5sHX5 diHHADbm6WUwa3IsgU65HV7X/BkE4vQcYsWzYjqyA3WjpZZWlYus023kqug5sHX5
G5uhNtW6SURCQjN+d6PNa182OqCW3w== G5uhNtW6SURCQjN+d6PNa182OqCW3w==
C.3.1.2. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.1.2. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_baseline, Decrypted and Unwrapped Protection with hcp_baseline, Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-baseline Subject: smime-signed-enc-hp-baseline
Message-ID: <smime-signed-enc-hp-baseline@example> Message-ID: <smime-signed-enc-hp-baseline@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:09:02 -0500 Date: Sat, 20 Feb 2021 10:09:02 -0500
skipping to change at page 130, line 5 skipping to change at line 5967
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft message. It uses the Header Protection scheme from the draft
with the hcp_baseline Header Confidentiality Policy. with the hcp_baseline Header Confidentiality Policy.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.3.2. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.2. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_baseline (+ Legacy Display) Protection with hcp_baseline (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft with message. It uses the Header Protection scheme from the draft with
the hcp_baseline Header Confidentiality Policy with a "Legacy the hcp_baseline Header Confidentiality Policy with a "Legacy
Display" part. Display" part.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8085 bytes └─╴application/pkcs7-mime [smime.p7m] 8085 bytes
skipping to change at page 133, line 15 skipping to change at line 6122
MNRBo4MxXU9cYHzi0umhauiw9I3UG4HAKH75L+1DFf1wbbgu165dCSIo2wVTIgOt MNRBo4MxXU9cYHzi0umhauiw9I3UG4HAKH75L+1DFf1wbbgu165dCSIo2wVTIgOt
zr3Y03kTJJidclkYzP7o2d80EMGftQQ4uGyEtowWJbEn0yWhss35Vs3Fyy10mwGM zr3Y03kTJJidclkYzP7o2d80EMGftQQ4uGyEtowWJbEn0yWhss35Vs3Fyy10mwGM
pncS4Tc1dVGyddkDXyAZ1JvfFzsXnoX+38R5lI25aYHAbfij582/hv48FU1I3XoB pncS4Tc1dVGyddkDXyAZ1JvfFzsXnoX+38R5lI25aYHAbfij582/hv48FU1I3XoB
WXR/gIKr/hQ2cFLwHsiJlGRw6smfBGOzk/x4JhG7sCR2E0QmM9CYzmyhZAKXORaX WXR/gIKr/hQ2cFLwHsiJlGRw6smfBGOzk/x4JhG7sCR2E0QmM9CYzmyhZAKXORaX
Ur75d8x99mIJdEO4uu4avHvaRouG6D9tPJWYIRioVDTPD1AU6qirN32hOupGwcz7 Ur75d8x99mIJdEO4uu4avHvaRouG6D9tPJWYIRioVDTPD1AU6qirN32hOupGwcz7
t8q70Jbv/tDpcLmLNX5VxsQzUfjpsGGvuz/Eq77raPG/TByissRMTjUuFv4BxS0x t8q70Jbv/tDpcLmLNX5VxsQzUfjpsGGvuz/Eq77raPG/TByissRMTjUuFv4BxS0x
wh//p9l2sJA4FWCA+Sr5YLFublQqRF1C3Vv0h2YEEz+sFA44u4VMmcCrwGBoJob1 wh//p9l2sJA4FWCA+Sr5YLFublQqRF1C3Vv0h2YEEz+sFA44u4VMmcCrwGBoJob1
4we46RXwzH3K7gRV/1tv2QB9pK4G8KxsbHXNV5RwVJ6xXI6JRvIJru3/w4nRPnrA 4we46RXwzH3K7gRV/1tv2QB9pK4G8KxsbHXNV5RwVJ6xXI6JRvIJru3/w4nRPnrA
lRXXfx7senJDd2tXmXvYkA== lRXXfx7senJDd2tXmXvYkA==
C.3.2.1. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.2.1. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_baseline (+ Legacy Display), Decrypted Protection with hcp_baseline (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIOFwYJKoZIhvcNAQcCoIIOCDCCDgQCAQExDTALBglghkgBZQMEAgEwggRABgkq MIIOFwYJKoZIhvcNAQcCoIIOCDCCDgQCAQExDTALBglghkgBZQMEAgEwggRABgkq
hkiG9w0BBwGgggQxBIIELU1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z hkiG9w0BBwGgggQxBIIELU1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z
ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw
skipping to change at page 135, line 5 skipping to change at line 6208
MAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI MAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTIxMDIyMDE1MTAwMlowLwYJKoZIhvcNAQkEMSIEIBmb56ZODWgP hvcNAQkFMQ8XDTIxMDIyMDE1MTAwMlowLwYJKoZIhvcNAQkEMSIEIBmb56ZODWgP
A1SVa8da67RsNicfHZ2zJVUWYLTKrF07MA0GCSqGSIb3DQEBAQUABIIBAAou3+Ck A1SVa8da67RsNicfHZ2zJVUWYLTKrF07MA0GCSqGSIb3DQEBAQUABIIBAAou3+Ck
FB6wTfWUVq1ABIBF3AFS+wBR2+mDSQKXxlVCnt/cfY07qKDX2YsVkj1uXq3I1Ptw FB6wTfWUVq1ABIBF3AFS+wBR2+mDSQKXxlVCnt/cfY07qKDX2YsVkj1uXq3I1Ptw
6RHEtqtbY3iwAqB5pzgfcw7qZHDpRMMEwobNLzHBdSZwW+ljkQ3LvDAZao5c+Cmt 6RHEtqtbY3iwAqB5pzgfcw7qZHDpRMMEwobNLzHBdSZwW+ljkQ3LvDAZao5c+Cmt
gSUCdnQ9Kvzdkl+xgtJQnjGGGNBiiWDb7NkZhlHYesV7QKNHTP+qP+awE1ZMrOP3 gSUCdnQ9Kvzdkl+xgtJQnjGGGNBiiWDb7NkZhlHYesV7QKNHTP+qP+awE1ZMrOP3
qBgIS1UH9nSNSmOfyTprD8MWoUKPkzFI1YUyPByE/QKjdV245YvYuZjz0cqn4VvV qBgIS1UH9nSNSmOfyTprD8MWoUKPkzFI1YUyPByE/QKjdV245YvYuZjz0cqn4VvV
2Y6t9DI4EmJJhay+P4EJwiggTjH9mJeeXIHyKpyELVSC5KCaIghQpTHV/pIH+fNs 2Y6t9DI4EmJJhay+P4EJwiggTjH9mJeeXIHyKpyELVSC5KCaIghQpTHV/pIH+fNs
WxxyPU2C+RwECSI= WxxyPU2C+RwECSI=
C.3.2.2. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.2.2. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_baseline (+ Legacy Display), Decrypted and Protection with hcp_baseline (+ Legacy Display), Decrypted and
Unwrapped Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-baseline-legacy Subject: smime-signed-enc-hp-baseline-legacy
Message-ID: <smime-signed-enc-hp-baseline-legacy@example> Message-ID: <smime-signed-enc-hp-baseline-legacy@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
skipping to change at page 135, line 45 skipping to change at line 6248
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft message. It uses the Header Protection scheme from the draft
with the hcp_baseline Header Confidentiality Policy with a with the hcp_baseline Header Confidentiality Policy with a
"Legacy Display" part. "Legacy Display" part.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.3.3. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.3. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_shy Protection with hcp_shy
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft with message. It uses the Header Protection scheme from the draft with
the hcp_shy Header Confidentiality Policy. the hcp_shy Header Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 7760 bytes └─╴application/pkcs7-mime [smime.p7m] 7760 bytes
↧ (decrypts to) ↧ (decrypts to)
skipping to change at page 139, line 5 skipping to change at line 6397
VfDTvOyeMGVjrJUPxsydbA9zF6GzTmT6PWNfsLlr4wX38CQkKQzG/8IEGvYQ6xWT VfDTvOyeMGVjrJUPxsydbA9zF6GzTmT6PWNfsLlr4wX38CQkKQzG/8IEGvYQ6xWT
kADeNyrFvVVE0diZgyCcybjTAI1LGj8n36DQBmfpYp1w6T/EyrznwS7PtRftaTm6 kADeNyrFvVVE0diZgyCcybjTAI1LGj8n36DQBmfpYp1w6T/EyrznwS7PtRftaTm6
bI3eXQqnO+I1HCR6+1gqcS70LK+bX+Cw0sNzLaUy66XVm7/CxYJrohRkNRxTGkHy bI3eXQqnO+I1HCR6+1gqcS70LK+bX+Cw0sNzLaUy66XVm7/CxYJrohRkNRxTGkHy
cqFFL/wBx1TK/jhARfxm4kWkW7Fsmo5t/ZRAv6jMAlYMjHdBF20HKMNDhZWtf/bC cqFFL/wBx1TK/jhARfxm4kWkW7Fsmo5t/ZRAv6jMAlYMjHdBF20HKMNDhZWtf/bC
mEV4/BERSfbHB60aM6ZXWUzBlf486ffAvxsQy5qGjQ/yJIwAMN84qHZvqoA3NwIs mEV4/BERSfbHB60aM6ZXWUzBlf486ffAvxsQy5qGjQ/yJIwAMN84qHZvqoA3NwIs
JThbTIFM0Xtux76AITxAYIhtB07ChxXrXC/owJ35oFve+sq1HQGh0fQIGTgTtv60 JThbTIFM0Xtux76AITxAYIhtB07ChxXrXC/owJ35oFve+sq1HQGh0fQIGTgTtv60
tq82T7KLO6ervK1UVL6oxHkt/xbr3c6wu4wd2Vh+Kk3xn3wp7ShpT6sopk4GCdBv tq82T7KLO6ervK1UVL6oxHkt/xbr3c6wu4wd2Vh+Kk3xn3wp7ShpT6sopk4GCdBv
mxxbUu50F7e7tlc/sxvCIU1ObwiF6WOJH+7RUJEGmWpvt7eGFZSo/h8oLjnxxvmK mxxbUu50F7e7tlc/sxvCIU1ObwiF6WOJH+7RUJEGmWpvt7eGFZSo/h8oLjnxxvmK
Qyus5nGIIWDZgKWYxxIGpQ== Qyus5nGIIWDZgKWYxxIGpQ==
C.3.3.1. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.3.1. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_shy, Decrypted Protection with hcp_shy, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIINawYJKoZIhvcNAQcCoIINXDCCDVgCAQExDTALBglghkgBZQMEAgEwggOUBgkq MIINawYJKoZIhvcNAQcCoIINXDCCDVgCAQExDTALBglghkgBZQMEAgEwggOUBgkq
hkiG9w0BBwGgggOFBIIDgU1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z hkiG9w0BBwGgggOFBIIDgU1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z
ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw
skipping to change at page 140, line 38 skipping to change at line 6479
EzdBBXntdX9CqaJcOvT4as6aqdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkD EzdBBXntdX9CqaJcOvT4as6aqdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjIwMTUxMjAyWjAvBgkq MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjIwMTUxMjAyWjAvBgkq
hkiG9w0BCQQxIgQgL6N313auMszx5Byu+sPmUUoQvZ6glyBIgh0k1qycdmUwDQYJ hkiG9w0BCQQxIgQgL6N313auMszx5Byu+sPmUUoQvZ6glyBIgh0k1qycdmUwDQYJ
KoZIhvcNAQEBBQAEggEAmHzQqLkVTKl8TKMaeYFFuU9fLrHZbg3aZ5eP+Zt3OkIN KoZIhvcNAQEBBQAEggEAmHzQqLkVTKl8TKMaeYFFuU9fLrHZbg3aZ5eP+Zt3OkIN
ErSsCBXE2V0u7yCmxk/PdfkTzOoSI9PW/seA5dd/W6yrCVX7EhqWWQx1vA+s+jtx ErSsCBXE2V0u7yCmxk/PdfkTzOoSI9PW/seA5dd/W6yrCVX7EhqWWQx1vA+s+jtx
oZ+Fh5a1GO9W7XmcQBvpjJQL0hyt78UzZt+CL0K5E5oueKj9CxCBkuKlgzzvwtpX oZ+Fh5a1GO9W7XmcQBvpjJQL0hyt78UzZt+CL0K5E5oueKj9CxCBkuKlgzzvwtpX
CAK6iYUzwGRWkxqdBaClu1xi2OCEzu5mbpAUY8ra26hGGaExYIZRVbwNZ5uGjfCI CAK6iYUzwGRWkxqdBaClu1xi2OCEzu5mbpAUY8ra26hGGaExYIZRVbwNZ5uGjfCI
lsrsd5wFdxQbcWOF/M5QIjbed1Gz862IZxaOA/fRY126jdeJyG2VKdD/3XglLNx4 lsrsd5wFdxQbcWOF/M5QIjbed1Gz862IZxaOA/fRY126jdeJyG2VKdD/3XglLNx4
+6kU9F3BYb7itpwqnkY3MiKxLuofNQVx/ZQ1m9arww== +6kU9F3BYb7itpwqnkY3MiKxLuofNQVx/ZQ1m9arww==
C.3.3.2. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.3.2. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_shy, Decrypted and Unwrapped Protection with hcp_shy, Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-shy Subject: smime-signed-enc-hp-shy
Message-ID: <smime-signed-enc-hp-shy@example> Message-ID: <smime-signed-enc-hp-shy@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:12:02 -0500 Date: Sat, 20 Feb 2021 10:12:02 -0500
skipping to change at page 141, line 34 skipping to change at line 6513
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft message. It uses the Header Protection scheme from the draft
with the hcp_shy Header Confidentiality Policy. with the hcp_shy Header Confidentiality Policy.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.3.4. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.4. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_shy (+ Legacy Display) Protection with hcp_shy (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft with message. It uses the Header Protection scheme from the draft with
the hcp_shy Header Confidentiality Policy with a "Legacy Display" the hcp_shy Header Confidentiality Policy with a "Legacy Display"
part. part.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8170 bytes └─╴application/pkcs7-mime [smime.p7m] 8170 bytes
skipping to change at page 144, line 45 skipping to change at line 6669
g3j4RmMIswPdagpYELQcwuek5e5ffD5bidL2Xn5BOXkMK7N2S1lXlmWn215NZG55 g3j4RmMIswPdagpYELQcwuek5e5ffD5bidL2Xn5BOXkMK7N2S1lXlmWn215NZG55
PoIAeXjgNDjdMmCXSt/frUvTsFOPtcCA2JAcI/e2dsyAF3iIRvPpDPRfUsvEzSQe PoIAeXjgNDjdMmCXSt/frUvTsFOPtcCA2JAcI/e2dsyAF3iIRvPpDPRfUsvEzSQe
gB6OEFYkDOqcG7Lk9Hx5d78ZpJst+XViQAIDlgLHBpPuwkIvh9OOdeP/XKLH/1lJ gB6OEFYkDOqcG7Lk9Hx5d78ZpJst+XViQAIDlgLHBpPuwkIvh9OOdeP/XKLH/1lJ
yOQ9mQCfuTx6rBtj2216o2L92OKFI27F/Ns4Lcir5VX0/6hrNe4/BlkAnexKnOgs yOQ9mQCfuTx6rBtj2216o2L92OKFI27F/Ns4Lcir5VX0/6hrNe4/BlkAnexKnOgs
Ok3hIuQnB6C9Z2vtWt1P0lnsemX+AhIJPtgRs6aGhMUnIwtvb8aZwFsS8WvaA6PG Ok3hIuQnB6C9Z2vtWt1P0lnsemX+AhIJPtgRs6aGhMUnIwtvb8aZwFsS8WvaA6PG
uLKBUfuv5V+mjt5vNNlnkaaF9bMGQVk9NmK6mgkqmjmoaXP+8MbKHJ7cf2Kt1Bpc uLKBUfuv5V+mjt5vNNlnkaaF9bMGQVk9NmK6mgkqmjmoaXP+8MbKHJ7cf2Kt1Bpc
PJ8uPBQ302Qv3PjpFk/YYdi3tmmvaxbOlDkNCJ87xjN7Tlgd5jmBZRCDzxDBmbOs PJ8uPBQ302Qv3PjpFk/YYdi3tmmvaxbOlDkNCJ87xjN7Tlgd5jmBZRCDzxDBmbOs
1USxLB1yDN/k4soKAKL/Ze6rVusjC+GJ02TcWFQkS5eQjxoHNKIkU4fMDggw1vzJ 1USxLB1yDN/k4soKAKL/Ze6rVusjC+GJ02TcWFQkS5eQjxoHNKIkU4fMDggw1vzJ
m5kyP5p5DST0+cko42Ae0yjn05T75MdYP0/l/I8YBes= m5kyP5p5DST0+cko42Ae0yjn05T75MdYP0/l/I8YBes=
C.3.4.1. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.4.1. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_shy (+ Legacy Display), Decrypted Protection with hcp_shy (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIOUAYJKoZIhvcNAQcCoIIOQTCCDj0CAQExDTALBglghkgBZQMEAgEwggR5Bgkq MIIOUAYJKoZIhvcNAQcCoIIOQTCCDj0CAQExDTALBglghkgBZQMEAgEwggR5Bgkq
hkiG9w0BBwGgggRqBIIEZk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z hkiG9w0BBwGgggRqBIIEZk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z
ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw
skipping to change at page 146, line 38 skipping to change at line 6756
XDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B XDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE1MTMwMlowLwYJKoZIhvcNAQkEMSIE BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE1MTMwMlowLwYJKoZIhvcNAQkEMSIE
INdmPheiziYcbAwKeKaDpmuOQFmVMdAqPn4+xeOFjp3NMA0GCSqGSIb3DQEBAQUA INdmPheiziYcbAwKeKaDpmuOQFmVMdAqPn4+xeOFjp3NMA0GCSqGSIb3DQEBAQUA
BIIBAD0aQzYiNU8AycDkBbQVbuAjHzerZmO27QlIZ47Cw9QfNcJ3w40RJAohR487 BIIBAD0aQzYiNU8AycDkBbQVbuAjHzerZmO27QlIZ47Cw9QfNcJ3w40RJAohR487
1NpkFskR79WY6aHuiLxClWV0Jw/iuieAFfBZ8Z9t2hOt+F93M+9v1eoLzrgA7YZG 1NpkFskR79WY6aHuiLxClWV0Jw/iuieAFfBZ8Z9t2hOt+F93M+9v1eoLzrgA7YZG
itp6r5zToKCdwNOc2futk/+dutbrTqYlFI8nnjLNqegBiGMMzVfateMc2fVnIVN+ itp6r5zToKCdwNOc2futk/+dutbrTqYlFI8nnjLNqegBiGMMzVfateMc2fVnIVN+
7/4fyA8ASzseEis/HQTN7sEjw0pUCvU4JvQy2klVYsaTZO4bdKXW86DHEWjoiweF 7/4fyA8ASzseEis/HQTN7sEjw0pUCvU4JvQy2klVYsaTZO4bdKXW86DHEWjoiweF
liiKSueA3WB1jeJRse2/g33dL+5++UUtQLY3kdknM78705WOaFg03V57abGCp2r+ liiKSueA3WB1jeJRse2/g33dL+5++UUtQLY3kdknM78705WOaFg03V57abGCp2r+
bgcHQNhfe0MXoJHKqYrnG++22tA= bgcHQNhfe0MXoJHKqYrnG++22tA=
C.3.4.2. S/MIME Signed and Encrypted Over a Simple Message, Header C.3.4.2. S/MIME Signed and Encrypted over a Simple Message, Header
Protection With hcp_shy (+ Legacy Display), Decrypted and Protection with hcp_shy (+ Legacy Display), Decrypted and
Unwrapped Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-shy-legacy Subject: smime-signed-enc-hp-shy-legacy
Message-ID: <smime-signed-enc-hp-shy-legacy@example> Message-ID: <smime-signed-enc-hp-shy-legacy@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
skipping to change at page 147, line 41 skipping to change at line 6798
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft message. It uses the Header Protection scheme from the draft
with the hcp_shy Header Confidentiality Policy with a "Legacy with the hcp_shy Header Confidentiality Policy with a "Legacy
Display" part. Display" part.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.3.5. S/MIME Signed and Encrypted Reply Over a Simple Message, Header C.3.5. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header
Protection With hcp_baseline Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft with message. It uses the Header Protection scheme from the draft with
the hcp_baseline Header Confidentiality Policy. the hcp_baseline Header Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8300 bytes └─╴application/pkcs7-mime [smime.p7m] 8300 bytes
↧ (decrypts to) ↧ (decrypts to)
skipping to change at page 151, line 9 skipping to change at line 6957
RzA9qsqEXuJBLqP13d0iciEa3AexWFU9om+lDNHc8bIoZfxk3wW4BITDoM7CwO9k RzA9qsqEXuJBLqP13d0iciEa3AexWFU9om+lDNHc8bIoZfxk3wW4BITDoM7CwO9k
M3mPHTwIU0zwauzqgWkBS7XNWGuFdyphRf8Oos9nlDfZr5hnQsRDKwusMxQQMpyK M3mPHTwIU0zwauzqgWkBS7XNWGuFdyphRf8Oos9nlDfZr5hnQsRDKwusMxQQMpyK
aamXq/Yhcr2flUZ9hffQwVffGlLT/4h4WhKrDcYlO4XwY85AOB+9MouvPIgUt5Pa aamXq/Yhcr2flUZ9hffQwVffGlLT/4h4WhKrDcYlO4XwY85AOB+9MouvPIgUt5Pa
fyWG4tqcFy5DSKTiGpoO4Y5N51tQqnO0X6j8fd4DuI/WkMfib+84Os+ZnfQ4BM+b fyWG4tqcFy5DSKTiGpoO4Y5N51tQqnO0X6j8fd4DuI/WkMfib+84Os+ZnfQ4BM+b
AnGWAqHzU2mwg1vSR1nBoLNERKLnsTUM8OX0qkhqo4hxCjdh+Dc7gqbCNVtUfBbe AnGWAqHzU2mwg1vSR1nBoLNERKLnsTUM8OX0qkhqo4hxCjdh+Dc7gqbCNVtUfBbe
fqdfr1EdJoe+GEdrT8J3NVl1AYzS3t3zTQdQ5yNzrP0kVyOUIbiyd5MpNBxLquLS fqdfr1EdJoe+GEdrT8J3NVl1AYzS3t3zTQdQ5yNzrP0kVyOUIbiyd5MpNBxLquLS
TwpOTnEcj+46IC6cXcIeVmTWtEmnGvGcQHdw95waGV0BrpAyPjyEfZ48ubfY7i6x TwpOTnEcj+46IC6cXcIeVmTWtEmnGvGcQHdw95waGV0BrpAyPjyEfZ48ubfY7i6x
eSC4YX5vzM0DEfkz8tXrEkA0PHbOvuEJgJE0iX52fYc4vnMquiEY4GDIc7WRJ62H eSC4YX5vzM0DEfkz8tXrEkA0PHbOvuEJgJE0iX52fYc4vnMquiEY4GDIc7WRJ62H
j4nVpvjAa34DWgZ+RgQCXF95kSztyoSAL3Jnq1fQOZ8= j4nVpvjAa34DWgZ+RgQCXF95kSztyoSAL3Jnq1fQOZ8=
C.3.5.1. S/MIME Signed and Encrypted Reply Over a Simple Message, C.3.5.1. S/MIME Signed-and-Encrypted Reply over a Simple Message,
Header Protection With hcp_baseline, Decrypted Header Protection with hcp_baseline, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIOkgYJKoZIhvcNAQcCoIIOgzCCDn8CAQExDTALBglghkgBZQMEAgEwggS7Bgkq MIIOkgYJKoZIhvcNAQcCoIIOgzCCDn8CAQExDTALBglghkgBZQMEAgEwggS7Bgkq
hkiG9w0BBwGgggSsBIIEqE1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z hkiG9w0BBwGgggSsBIIEqE1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z
ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw
skipping to change at page 153, line 5 skipping to change at line 7045
aG9yaXR5AhM3QQV57XV/QqmiXDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgGCSqG aG9yaXR5AhM3QQV57XV/QqmiXDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE1MTUw SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE1MTUw
MlowLwYJKoZIhvcNAQkEMSIEIKHPvLfnw9dsDhrKZlaFW3+cbW6ewBQ6mkp22q7y MlowLwYJKoZIhvcNAQkEMSIEIKHPvLfnw9dsDhrKZlaFW3+cbW6ewBQ6mkp22q7y
BhI9MA0GCSqGSIb3DQEBAQUABIIBAH3cRn5LOa7nqW8Z/czFCRpkU6j2e8xqaw7/ BhI9MA0GCSqGSIb3DQEBAQUABIIBAH3cRn5LOa7nqW8Z/czFCRpkU6j2e8xqaw7/
eCh6GvC4emq/eAgKhqpbhw+QwEOYZCMmTe7GFb/eSl82QjB+zYaR+pGgVhBH57Zp eCh6GvC4emq/eAgKhqpbhw+QwEOYZCMmTe7GFb/eSl82QjB+zYaR+pGgVhBH57Zp
IOtobnzbOEsgzmUKakI2iaAuQBtOxMPqDRTRjMPLMhc6ddIRBqNeDpC3hm+sOXrj IOtobnzbOEsgzmUKakI2iaAuQBtOxMPqDRTRjMPLMhc6ddIRBqNeDpC3hm+sOXrj
r8rQAMDBJTck7psP72DTyDWDeVPw7BRMSnxz7FwSbW1CXFeiJ6mWhZ0Va1YgDpJK r8rQAMDBJTck7psP72DTyDWDeVPw7BRMSnxz7FwSbW1CXFeiJ6mWhZ0Va1YgDpJK
Ic2uW2Tq/ob8jTjnPrVIQhq0ZxKOiWsHTMfzxRnH3xyYt/c/huuoDtcf9P3j9GWa Ic2uW2Tq/ob8jTjnPrVIQhq0ZxKOiWsHTMfzxRnH3xyYt/c/huuoDtcf9P3j9GWa
a23tU+PDSpfcpG5MJPe9DBzExWII7Z50Om8g6tZETD0+pOjNTAg= a23tU+PDSpfcpG5MJPe9DBzExWII7Z50Om8g6tZETD0+pOjNTAg=
C.3.5.2. S/MIME Signed and Encrypted Reply Over a Simple Message, C.3.5.2. S/MIME Signed-and-Encrypted Reply over a Simple Message,
Header Protection With hcp_baseline, Decrypted and Unwrapped Header Protection with hcp_baseline, Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-baseline-reply Subject: smime-signed-enc-hp-baseline-reply
Message-ID: <smime-signed-enc-hp-baseline-reply@example> Message-ID: <smime-signed-enc-hp-baseline-reply@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:15:02 -0500 Date: Sat, 20 Feb 2021 10:15:02 -0500
skipping to change at page 153, line 44 skipping to change at line 7084
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft message. It uses the Header Protection scheme from the draft
with the hcp_baseline Header Confidentiality Policy. with the hcp_baseline Header Confidentiality Policy.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.3.6. S/MIME Signed and Encrypted Reply Over a Simple Message, Header C.3.6. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header
Protection With hcp_baseline (+ Legacy Display) Protection with hcp_baseline (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft with message. It uses the Header Protection scheme from the draft with
the hcp_baseline Header Confidentiality Policy with a "Legacy the hcp_baseline Header Confidentiality Policy with a "Legacy
Display" part. Display" part.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8625 bytes └─╴application/pkcs7-mime [smime.p7m] 8625 bytes
skipping to change at page 157, line 16 skipping to change at line 7249
wUAsTXpE2HR9Amg17uOU7qBqBkCC4nbArddaw9d/Jv6IxfsGx5kyDK1X8Nkalqvh wUAsTXpE2HR9Amg17uOU7qBqBkCC4nbArddaw9d/Jv6IxfsGx5kyDK1X8Nkalqvh
wT59cOw3GXzOeS3eIfvu5RO9o+d2mfRH+77sRkvPIXOkM/bDwZH3cPtT+YEveqOK wT59cOw3GXzOeS3eIfvu5RO9o+d2mfRH+77sRkvPIXOkM/bDwZH3cPtT+YEveqOK
8RJTDQeLMqSX7lo1+VC+975x2Wsv1z1LBpWiw68tXLj4De9Pp8O5BXnfBS80vJFY 8RJTDQeLMqSX7lo1+VC+975x2Wsv1z1LBpWiw68tXLj4De9Pp8O5BXnfBS80vJFY
JMBtAg6MIVIQyblv+QxnYX09CGCxjqjka1PehmYpafcP10OUfU5tSqJb4kB7MyUj JMBtAg6MIVIQyblv+QxnYX09CGCxjqjka1PehmYpafcP10OUfU5tSqJb4kB7MyUj
NRn6yYcJXJBAt1lMRGlLDkUTN/mswR5Bzy4NnzThZb62sUZ23xwKJVOoApexfBVK NRn6yYcJXJBAt1lMRGlLDkUTN/mswR5Bzy4NnzThZb62sUZ23xwKJVOoApexfBVK
rJRaeuUaDx1upyGfMEVuIlmCT1aYIXBb3f/W2zK5219f2dbAFU0goYTKJoohBzGL rJRaeuUaDx1upyGfMEVuIlmCT1aYIXBb3f/W2zK5219f2dbAFU0goYTKJoohBzGL
tJ3/dO5jLgje9H1AgZS22UVUI+FQo8uG8ApPJgts3AW91fjohjzzYCp7T/zR7x4h tJ3/dO5jLgje9H1AgZS22UVUI+FQo8uG8ApPJgts3AW91fjohjzzYCp7T/zR7x4h
UERWGfMG2fHYje5/QuyobVCKt8QfG2DhvSIMDPBY7KHO7bXJdEmUwb/aSeggmDCp UERWGfMG2fHYje5/QuyobVCKt8QfG2DhvSIMDPBY7KHO7bXJdEmUwb/aSeggmDCp
LHK2foRU983nLGdDrp2q4TWCoMGVSmOwBasUjVHiUA8= LHK2foRU983nLGdDrp2q4TWCoMGVSmOwBasUjVHiUA8=
C.3.6.1. S/MIME Signed and Encrypted Reply Over a Simple Message, C.3.6.1. S/MIME Signed-and-Encrypted Reply over a Simple Message,
Header Protection With hcp_baseline (+ Legacy Display), Header Protection with hcp_baseline (+ Legacy Display),
Decrypted Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIPOwYJKoZIhvcNAQcCoIIPLDCCDygCAQExDTALBglghkgBZQMEAgEwggVkBgkq MIIPOwYJKoZIhvcNAQcCoIIPLDCCDygCAQExDTALBglghkgBZQMEAgEwggVkBgkq
hkiG9w0BBwGgggVVBIIFUU1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z hkiG9w0BBwGgggVVBIIFUU1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z
skipping to change at page 159, line 13 skipping to change at line 7342
zpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG zpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0yMTAyMjAxNTE2MDJaMC8GCSqGSIb3DQEJBDEiBCDlm+B5 CSqGSIb3DQEJBTEPFw0yMTAyMjAxNTE2MDJaMC8GCSqGSIb3DQEJBDEiBCDlm+B5
0QBs78N2wRl0kf1Exib4redr1foUWvF3vmcyCTANBgkqhkiG9w0BAQEFAASCAQBc 0QBs78N2wRl0kf1Exib4redr1foUWvF3vmcyCTANBgkqhkiG9w0BAQEFAASCAQBc
m0fLRAACOYr8JymCYS4CYBWzMuTqh1DOat4MTroQLeNXvV8NijRWYdbHFcL1hrdy m0fLRAACOYr8JymCYS4CYBWzMuTqh1DOat4MTroQLeNXvV8NijRWYdbHFcL1hrdy
uLBoqHTkv29eG3Lp5+Ah+uYLcPeamzoxWgfiLgPBaFSQU8ZyxPqVRj2xLq2EqG16 uLBoqHTkv29eG3Lp5+Ah+uYLcPeamzoxWgfiLgPBaFSQU8ZyxPqVRj2xLq2EqG16
IW5DfieHgVN0bv9P+gmRdKdzG8+hiZcZXBm2aJtN8oifP/ahgTzePiBiHK4Qvecy IW5DfieHgVN0bv9P+gmRdKdzG8+hiZcZXBm2aJtN8oifP/ahgTzePiBiHK4Qvecy
q+Cr1gFwVlT+1t/2MO1tGqif6R14NCmUaHzeOvzEpJs1HlE8W7yUjBdrS3my9KW1 q+Cr1gFwVlT+1t/2MO1tGqif6R14NCmUaHzeOvzEpJs1HlE8W7yUjBdrS3my9KW1
fAv+chp5rIXeSrZGTg7ZhNLcq/uq1H9IpgnYvRXN/f6WhggdVUZ5BJwPqbNcCJFl fAv+chp5rIXeSrZGTg7ZhNLcq/uq1H9IpgnYvRXN/f6WhggdVUZ5BJwPqbNcCJFl
zAP8CJk3IK1fzZulSebk zAP8CJk3IK1fzZulSebk
C.3.6.2. S/MIME Signed and Encrypted Reply Over a Simple Message, C.3.6.2. S/MIME Signed-and-Encrypted Reply over a Simple Message,
Header Protection With hcp_baseline (+ Legacy Display), Header Protection with hcp_baseline (+ Legacy Display),
Decrypted and Unwrapped Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-baseline-legacy-reply Subject: smime-signed-enc-hp-baseline-legacy-reply
Message-ID: <smime-signed-enc-hp-baseline-legacy-reply@example> Message-ID: <smime-signed-enc-hp-baseline-legacy-reply@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
skipping to change at page 160, line 45 skipping to change at line 7388
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft message. It uses the Header Protection scheme from the draft
with the hcp_baseline Header Confidentiality Policy with a with the hcp_baseline Header Confidentiality Policy with a
"Legacy Display" part. "Legacy Display" part.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.3.7. S/MIME Signed and Encrypted Reply Over a Simple Message, Header C.3.7. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header
Protection With hcp_shy Protection with hcp_shy
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft with message. It uses the Header Protection scheme from the draft with
the hcp_shy Header Confidentiality Policy. the hcp_shy Header Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8190 bytes └─╴application/pkcs7-mime [smime.p7m] 8190 bytes
↧ (decrypts to) ↧ (decrypts to)
skipping to change at page 164, line 9 skipping to change at line 7545
gJ/cA7EJSIzJ4DpcUlKk+HBVmvl0HX63NSTBEEfWrsWdoEUAktVHmTTMfxnvrtoh gJ/cA7EJSIzJ4DpcUlKk+HBVmvl0HX63NSTBEEfWrsWdoEUAktVHmTTMfxnvrtoh
LPnNUdEXJae+0kE+EyEWce9MbSPjsNFddHAdNpxthy04hbvQx6/YrUrk0BHGtzDI LPnNUdEXJae+0kE+EyEWce9MbSPjsNFddHAdNpxthy04hbvQx6/YrUrk0BHGtzDI
lIdeatVgxlIb6XS3UzfS/DqHx6+FCGZ75ZYM5/IwlYXkNzXXibin6xqAL3UFAGob lIdeatVgxlIb6XS3UzfS/DqHx6+FCGZ75ZYM5/IwlYXkNzXXibin6xqAL3UFAGob
kGeAoKE1bo4d4TJdoYafa+9KxU8DH8fQvMrfFBtS9327I4qWFv4fzPG81opU/+d9 kGeAoKE1bo4d4TJdoYafa+9KxU8DH8fQvMrfFBtS9327I4qWFv4fzPG81opU/+d9
kkKOvewfx99h4aMfflT0Y1bs8/mLMABnZiiyPdE4ZDIwoicqGsQgO1u/dRD7pHWt kkKOvewfx99h4aMfflT0Y1bs8/mLMABnZiiyPdE4ZDIwoicqGsQgO1u/dRD7pHWt
J9Hv77iPBZMmURHGiRkK0hBxYlRGUFZm/6/Y/aX4vG/1K+A8l2ksWdLpqXRQpcuD J9Hv77iPBZMmURHGiRkK0hBxYlRGUFZm/6/Y/aX4vG/1K+A8l2ksWdLpqXRQpcuD
kqIBlcn++x8pyWyY1STAOF9w1IFp5wBHH1fy07yNBDj/xKMufz9j6hrYWQV8bjWV kqIBlcn++x8pyWyY1STAOF9w1IFp5wBHH1fy07yNBDj/xKMufz9j6hrYWQV8bjWV
TK3cb8Ar2Qr80TrUUCjyu+d+37kcsi2uMDkiRD/avJbLPwePFTuJZe7nZYdA1A2s TK3cb8Ar2Qr80TrUUCjyu+d+37kcsi2uMDkiRD/avJbLPwePFTuJZe7nZYdA1A2s
hxnJyBasTI4iMlxH11JYuMGHouu24u5BbCILf654lR+BIQ1d2ogA41eHPlZ7x3H7 hxnJyBasTI4iMlxH11JYuMGHouu24u5BbCILf654lR+BIQ1d2ogA41eHPlZ7x3H7
C.3.7.1. S/MIME Signed and Encrypted Reply Over a Simple Message, C.3.7.1. S/MIME Signed-and-Encrypted Reply over a Simple Message,
Header Protection With hcp_shy, Decrypted Header Protection with hcp_shy, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIOVQYJKoZIhvcNAQcCoIIORjCCDkICAQExDTALBglghkgBZQMEAgEwggR+Bgkq MIIOVQYJKoZIhvcNAQcCoIIORjCCDkICAQExDTALBglghkgBZQMEAgEwggR+Bgkq
hkiG9w0BBwGgggRvBIIEa01JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z hkiG9w0BBwGgggRvBIIEa01JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z
ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw
skipping to change at page 166, line 5 skipping to change at line 7632
dX9CqaJcOvT4as6aqdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqG dX9CqaJcOvT4as6aqdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqG
SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjIwMTUxODAyWjAvBgkqhkiG9w0B SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjIwMTUxODAyWjAvBgkqhkiG9w0B
CQQxIgQgMahPfXeRTJKDWjCE/0llScBMuyD7DptAxoKsAmAzBdgwDQYJKoZIhvcN CQQxIgQgMahPfXeRTJKDWjCE/0llScBMuyD7DptAxoKsAmAzBdgwDQYJKoZIhvcN
AQEBBQAEggEASJuMfoErHP+bowktPN/yJIltnTlZUibkbJxhHPhR5EgNnn3JyMoW AQEBBQAEggEASJuMfoErHP+bowktPN/yJIltnTlZUibkbJxhHPhR5EgNnn3JyMoW
l0yP6nJyH3sBQ2/CIBkmMSXmg+A0PFv3w40fUtX2oKVzT5TKnNsIDtv2Z7J5JRI3 l0yP6nJyH3sBQ2/CIBkmMSXmg+A0PFv3w40fUtX2oKVzT5TKnNsIDtv2Z7J5JRI3
TbATMRmw8VItmPGFCJsD9nXRc4cEgvrvojXSfv6bWp5hCO+8WNadiiGZNdoZduiL TbATMRmw8VItmPGFCJsD9nXRc4cEgvrvojXSfv6bWp5hCO+8WNadiiGZNdoZduiL
rWNSwO9nQSxuNkqNo+wwaXF9Rynh1ZcazsVopBB4s5XuJ/Zcbbsaci1w34ywNCHw rWNSwO9nQSxuNkqNo+wwaXF9Rynh1ZcazsVopBB4s5XuJ/Zcbbsaci1w34ywNCHw
5xx9Cgj+6+yUsFp33P2YVgdfK4beyoOZK27Rm9e7Mpi6QxUi+BCR/8DB9svZBwob 5xx9Cgj+6+yUsFp33P2YVgdfK4beyoOZK27Rm9e7Mpi6QxUi+BCR/8DB9svZBwob
K7iaKJzRBDxl4Qt/m6VHxtvkTXjkOOD+7g== K7iaKJzRBDxl4Qt/m6VHxtvkTXjkOOD+7g==
C.3.7.2. S/MIME Signed and Encrypted Reply Over a Simple Message, C.3.7.2. S/MIME Signed-and-Encrypted Reply over a Simple Message,
Header Protection With hcp_shy, Decrypted and Unwrapped Header Protection with hcp_shy, Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-shy-reply Subject: smime-signed-enc-hp-shy-reply
Message-ID: <smime-signed-enc-hp-shy-reply@example> Message-ID: <smime-signed-enc-hp-shy-reply@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 10:18:02 -0500 Date: Sat, 20 Feb 2021 10:18:02 -0500
skipping to change at page 166, line 43 skipping to change at line 7670
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft message. It uses the Header Protection scheme from the draft
with the hcp_shy Header Confidentiality Policy. with the hcp_shy Header Confidentiality Policy.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.3.8. S/MIME Signed and Encrypted Reply Over a Simple Message, Header C.3.8. S/MIME Signed-and-Encrypted Reply over a Simple Message, Header
Protection With hcp_shy (+ Legacy Display) Protection with hcp_shy (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft with message. It uses the Header Protection scheme from the draft with
the hcp_shy Header Confidentiality Policy with a "Legacy Display" the hcp_shy Header Confidentiality Policy with a "Legacy Display"
part. part.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 8690 bytes └─╴application/pkcs7-mime [smime.p7m] 8690 bytes
skipping to change at page 170, line 15 skipping to change at line 7836
2eU6X7yMWvTwRYbByybrKpqsM2moy4IpMS+DgaThSVxVHf3RbFvIXPUmhRCFFkS4 2eU6X7yMWvTwRYbByybrKpqsM2moy4IpMS+DgaThSVxVHf3RbFvIXPUmhRCFFkS4
lmmm2czKN9wUaBLKcmeynBpRaunt9n0uFyWJgSbekqw3cet82vu9MOPSmM2h36UV lmmm2czKN9wUaBLKcmeynBpRaunt9n0uFyWJgSbekqw3cet82vu9MOPSmM2h36UV
WgJDktehhr/gi23ON4kavEwGngVIvlq+Emm0SuUmKacqdaOmATxUhL92IA93L9pm WgJDktehhr/gi23ON4kavEwGngVIvlq+Emm0SuUmKacqdaOmATxUhL92IA93L9pm
RvT6xARWsy0DrG/r362C6PDwp1fsTOQju6LkhFAOAvqDPKk+HOIjgBtkynHUPGwv RvT6xARWsy0DrG/r362C6PDwp1fsTOQju6LkhFAOAvqDPKk+HOIjgBtkynHUPGwv
8EN9Gx2SWwDJahAjPoz2t9kByC7PdG9qyGAAAEU6G/wXjshmzgw3jdw/PRmfSdNs 8EN9Gx2SWwDJahAjPoz2t9kByC7PdG9qyGAAAEU6G/wXjshmzgw3jdw/PRmfSdNs
gbky/4GGewNl06WC9c+6qN4ldDff+m83ABgWonCuamerjlaIFFbfBJEGX/CBz7GQ gbky/4GGewNl06WC9c+6qN4ldDff+m83ABgWonCuamerjlaIFFbfBJEGX/CBz7GQ
QpfxuAEbhi11UloM77povWS5Cl8e0GSD2t2mt7E0aLgMT+L2TZXQx8lZmN8sWQq7 QpfxuAEbhi11UloM77povWS5Cl8e0GSD2t2mt7E0aLgMT+L2TZXQx8lZmN8sWQq7
cP6aK8FpkDhidLIc9fneWucvMH5BKXx8em3ug4Bl8MUABR4K03ebuTLfDH+FGkD0 cP6aK8FpkDhidLIc9fneWucvMH5BKXx8em3ug4Bl8MUABR4K03ebuTLfDH+FGkD0
HNeqqUVBSzDveFdaylcw2HkJpm8D9BoC3Y0n/WMW5VE= HNeqqUVBSzDveFdaylcw2HkJpm8D9BoC3Y0n/WMW5VE=
C.3.8.1. S/MIME Signed and Encrypted Reply Over a Simple Message, C.3.8.1. S/MIME Signed-and-Encrypted Reply over a Simple Message,
Header Protection With hcp_shy (+ Legacy Display), Decrypted Header Protection with hcp_shy (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIPXgYJKoZIhvcNAQcCoIIPTzCCD0sCAQExDTALBglghkgBZQMEAgEwggWHBgkq MIIPXgYJKoZIhvcNAQcCoIIPTzCCD0sCAQExDTALBglghkgBZQMEAgEwggWHBgkq
hkiG9w0BBwGgggV4BIIFdE1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z hkiG9w0BBwGgggV4BIIFdE1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5z
ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw ZmVyLUVuY29kaW5nOiA3Yml0DQpTdWJqZWN0OiBzbWltZS1zaWduZWQtZW5jLWhw
skipping to change at page 172, line 12 skipping to change at line 7929
AwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X AwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTIxMDIyMDE1MTkwMlowLwYJKoZIhvcNAQkEMSIEIDUClbNj9mKYodH3vCGfNVpZ DTIxMDIyMDE1MTkwMlowLwYJKoZIhvcNAQkEMSIEIDUClbNj9mKYodH3vCGfNVpZ
jSSWg3QZ6u/dLxbyfbvEMA0GCSqGSIb3DQEBAQUABIIBAHqRG2dp61WFSKrkBcj7 jSSWg3QZ6u/dLxbyfbvEMA0GCSqGSIb3DQEBAQUABIIBAHqRG2dp61WFSKrkBcj7
sVy7SmsllIQUOl3EO23T5h4PcL8PjggAJi/GHWaEsGviQEdS0QAbljEnzd2wjgn0 sVy7SmsllIQUOl3EO23T5h4PcL8PjggAJi/GHWaEsGviQEdS0QAbljEnzd2wjgn0
QDtLBAfpQtQR0byQGTzpg7y9Lt5WnuxQaZxsBPvENqeYSFesUVlW1JrJGXcqLH7U QDtLBAfpQtQR0byQGTzpg7y9Lt5WnuxQaZxsBPvENqeYSFesUVlW1JrJGXcqLH7U
cu1+bdDLEe0p2ITtazvmgJ5NvoHkucBk1v8fwW6uliGJCZC0Gf9WJDP1qay2Jexy cu1+bdDLEe0p2ITtazvmgJ5NvoHkucBk1v8fwW6uliGJCZC0Gf9WJDP1qay2Jexy
/TUzmr2Egnxq71WlAVql2kfUOfZkgALFRzhaHtonrST83I1sLK9ZxB8ZX8vJX56v /TUzmr2Egnxq71WlAVql2kfUOfZkgALFRzhaHtonrST83I1sLK9ZxB8ZX8vJX56v
5hHRzhuQQyAVgOeVz7skKIb5ODfBHqJ1vEzvCjf72BgQLYGEzR6hmPXW1Ml4vXtV 5hHRzhuQQyAVgOeVz7skKIb5ODfBHqJ1vEzvCjf72BgQLYGEzR6hmPXW1Ml4vXtV
lIw= lIw=
C.3.8.2. S/MIME Signed and Encrypted Reply Over a Simple Message, C.3.8.2. S/MIME Signed-and-Encrypted Reply over a Simple Message,
Header Protection With hcp_shy (+ Legacy Display), Decrypted Header Protection with hcp_shy (+ Legacy Display), Decrypted
and Unwrapped and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Subject: smime-signed-enc-hp-shy-legacy-reply Subject: smime-signed-enc-hp-shy-legacy-reply
Message-ID: <smime-signed-enc-hp-shy-legacy-reply@example> Message-ID: <smime-signed-enc-hp-shy-legacy-reply@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
skipping to change at page 174, line 5 skipping to change at line 7976
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft message. It uses the Header Protection scheme from the draft
with the hcp_shy Header Confidentiality Policy with a "Legacy with the hcp_shy Header Confidentiality Policy with a "Legacy
Display" part. Display" part.
-- --
Alice Alice
alice@smime.example alice@smime.example
C.3.9. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.9. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_baseline Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses the alternative message with an inline image/png attachment. It uses the
Header Protection scheme from the draft with the hcp_baseline Header Header Protection scheme from the draft with the hcp_baseline Header
Confidentiality Policy. Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 10035 bytes └─╴application/pkcs7-mime [smime.p7m] 10035 bytes
skipping to change at page 178, line 5 skipping to change at line 8165
cOaqQssUWkpjJSzSeedcA4oonnq833DXP6SPF1ksXlArsDVWB4atlFRqbaUKKrpv cOaqQssUWkpjJSzSeedcA4oonnq833DXP6SPF1ksXlArsDVWB4atlFRqbaUKKrpv
Hinhb+MUjANUW+TcAEznbTyHFvEuNCIX7WU7SlOglcrEjJzGnJZC24+l0KzxF3ed Hinhb+MUjANUW+TcAEznbTyHFvEuNCIX7WU7SlOglcrEjJzGnJZC24+l0KzxF3ed
7PndgDslLmJc4ExhALrKGFw57Muvy1UNd4f6W7AEraj/54FIoZzDRH+R/owcjuiK 7PndgDslLmJc4ExhALrKGFw57Muvy1UNd4f6W7AEraj/54FIoZzDRH+R/owcjuiK
Pza8vs8W8792ds1ewGcLs+B1g+l79IbO0+zR4eio1f+6kSsRf+EucrH4RF+lU+ba Pza8vs8W8792ds1ewGcLs+B1g+l79IbO0+zR4eio1f+6kSsRf+EucrH4RF+lU+ba
w56nBq1EMoBJFuzPrLdAOD9vRVwi8cmKYYf/VgriDvZxqsDsdjC81fUEesG8/iVS w56nBq1EMoBJFuzPrLdAOD9vRVwi8cmKYYf/VgriDvZxqsDsdjC81fUEesG8/iVS
axpAOFhCp8oUQZVg8yRsR7x/m0EjFWZPu9JZwAge76HhwpSu+yg55m5ndeXEy55p axpAOFhCp8oUQZVg8yRsR7x/m0EjFWZPu9JZwAge76HhwpSu+yg55m5ndeXEy55p
ss6t9jHwuFu7F8q75xTTVE+jBZomyxfYQV0qFvvelF86Hrc+FTobS2AzPRzhwj+p ss6t9jHwuFu7F8q75xTTVE+jBZomyxfYQV0qFvvelF86Hrc+FTobS2AzPRzhwj+p
Wfh8ORVoQaHb/BuAREB/xXCLhzDsirqoUKDcVATLnBUvZIawptgC1OjIaAX3Xgn0 Wfh8ORVoQaHb/BuAREB/xXCLhzDsirqoUKDcVATLnBUvZIawptgC1OjIaAX3Xgn0
VQXDSeABdtUDVBgI67OgFw== VQXDSeABdtUDVBgI67OgFw==
C.3.9.1. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.9.1. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_baseline, Decrypted Protection with hcp_baseline, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIISMQYJKoZIhvcNAQcCoIISIjCCEh4CAQExDTALBglghkgBZQMEAgEwgghaBgkq MIISMQYJKoZIhvcNAQcCoIISIjCCEh4CAQExDTALBglghkgBZQMEAgEwgghaBgkq
hkiG9w0BBwGggghLBIIIR01JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt hkiG9w0BBwGggghLBIIIR01JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt
ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtYmFzZWxpbmUNCk1lc3NhZ2UtSUQ6IDxz ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtYmFzZWxpbmUNCk1lc3NhZ2UtSUQ6IDxz
skipping to change at page 180, line 16 skipping to change at line 8273
SAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF SAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTIxMDIyMDE3MDkwMlowLwYJKoZIhvcNAQkEMSIEIFPOmRBiI1gpSbRbrEhT MQ8XDTIxMDIyMDE3MDkwMlowLwYJKoZIhvcNAQkEMSIEIFPOmRBiI1gpSbRbrEhT
xW8uQ+V/G/cmOB6495mnsKVeMA0GCSqGSIb3DQEBAQUABIIBADgh7UBYrX+esUzQ xW8uQ+V/G/cmOB6495mnsKVeMA0GCSqGSIb3DQEBAQUABIIBADgh7UBYrX+esUzQ
I9zNqk4LnbgdQoUdeJtdY2Jvyl6dlV8cfIFNgng8IluuuJI48a5yJwYG3060AkvF I9zNqk4LnbgdQoUdeJtdY2Jvyl6dlV8cfIFNgng8IluuuJI48a5yJwYG3060AkvF
JC/hq7sSBCLzNVb9UioTixGi+4nGB2iRb7TKsfamuyh5Zdjg4OrN8N1H4rwUQ1K4 JC/hq7sSBCLzNVb9UioTixGi+4nGB2iRb7TKsfamuyh5Zdjg4OrN8N1H4rwUQ1K4
Sis2TCi5/TSc+UYG7rH+YyIRSeVxNCII3rEA8E+dDRg6R5bqOTHxInQbBvG9q19e Sis2TCi5/TSc+UYG7rH+YyIRSeVxNCII3rEA8E+dDRg6R5bqOTHxInQbBvG9q19e
pelntJeSxvRSOSYwcoNGXenZ6S7eqfB3iln65d0gURSV7hPSfZwh1QSZa47egE7V pelntJeSxvRSOSYwcoNGXenZ6S7eqfB3iln65d0gURSV7hPSfZwh1QSZa47egE7V
9Dgce5pbZYQgeB27mLBCpsgRgYKbQ/+NBPBexT6Kxixd4sND++AZ6kUie+AvUpXo 9Dgce5pbZYQgeB27mLBCpsgRgYKbQ/+NBPBexT6Kxixd4sND++AZ6kUie+AvUpXo
+kGun/Q= +kGun/Q=
C.3.9.2. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.9.2. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_baseline, Decrypted and Unwrapped Protection with hcp_baseline, Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-baseline Subject: smime-signed-enc-complex-hp-baseline
Message-ID: <smime-signed-enc-complex-hp-baseline@example> Message-ID: <smime-signed-enc-complex-hp-baseline@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:09:02 -0500 Date: Sat, 20 Feb 2021 12:09:02 -0500
User-Agent: Sample MUA Version 1.0 User-Agent: Sample MUA Version 1.0
skipping to change at page 181, line 40 skipping to change at line 8345
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--e03-- --e03--
C.3.10. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.10. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_baseline (+ Legacy Display) Protection with hcp_baseline (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses the alternative message with an inline image/png attachment. It uses the
Header Protection scheme from the draft with the hcp_baseline Header Header Protection scheme from the draft with the hcp_baseline Header
Confidentiality Policy with a "Legacy Display" part. Confidentiality Policy with a "Legacy Display" part.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 10640 bytes └─╴application/pkcs7-mime [smime.p7m] 10640 bytes
skipping to change at page 186, line 5 skipping to change at line 8544
6zdOuNbd7LrTimhtu6lWIFtSgrJpPNKpDTgjGn5X8R8MuAFJFibkS4uMbL1Fty32 6zdOuNbd7LrTimhtu6lWIFtSgrJpPNKpDTgjGn5X8R8MuAFJFibkS4uMbL1Fty32
bESHzoLqSLRgWgLpZQjmrTyvOgvYyauKjZYslBnVqjd+oBq9JUgxh7xKsG+z2KQo bESHzoLqSLRgWgLpZQjmrTyvOgvYyauKjZYslBnVqjd+oBq9JUgxh7xKsG+z2KQo
V4QC4M3z0ppx76fYMETfOMjp9Pm8KyuhEHXIbAXoVE1rer2m1ptaJGZF7wUJAqEL V4QC4M3z0ppx76fYMETfOMjp9Pm8KyuhEHXIbAXoVE1rer2m1ptaJGZF7wUJAqEL
uJiKSztN5S5sFe+a87BsIlDWkCLZRuDb04aO+ndSd343yK9CMfYKbknZXtC/cAVd uJiKSztN5S5sFe+a87BsIlDWkCLZRuDb04aO+ndSd343yK9CMfYKbknZXtC/cAVd
2cwFAg+qix+351gdmGd5L8tQC9V4FO3uy0JQU90g0Twq0nE45fvLj0J4rnivuQkD 2cwFAg+qix+351gdmGd5L8tQC9V4FO3uy0JQU90g0Twq0nE45fvLj0J4rnivuQkD
NMypJdswmGcd8TWFdb8kQMtZPNWuupbV5w1lF3ibGEhGqtO+4/gu1ua3jg+cHI3o NMypJdswmGcd8TWFdb8kQMtZPNWuupbV5w1lF3ibGEhGqtO+4/gu1ua3jg+cHI3o
oKBzUuvYGLXrbrYnPE1b3HQXvxDVd8m/+KLDNiwyQ7UT676iJn7ARCYZCwP/D3g6 oKBzUuvYGLXrbrYnPE1b3HQXvxDVd8m/+KLDNiwyQ7UT676iJn7ARCYZCwP/D3g6
zMc3NXJkUZ8KFOHqokaaJ3jleLoMi6JB23bhiv/RRJuYk+TCwX7uBKF8fnt+E802 zMc3NXJkUZ8KFOHqokaaJ3jleLoMi6JB23bhiv/RRJuYk+TCwX7uBKF8fnt+E802
YOhbKcnThdDUreGM2QrsjZeHZQ6qgIkLUedro8EsPI8= YOhbKcnThdDUreGM2QrsjZeHZQ6qgIkLUedro8EsPI8=
C.3.10.1. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.10.1. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_baseline (+ Legacy Display), Decrypted Protection with hcp_baseline (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIITdQYJKoZIhvcNAQcCoIITZjCCE2ICAQExDTALBglghkgBZQMEAgEwggmeBgkq MIITdQYJKoZIhvcNAQcCoIITZjCCE2ICAQExDTALBglghkgBZQMEAgEwggmeBgkq
hkiG9w0BBwGgggmPBIIJi01JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt hkiG9w0BBwGgggmPBIIJi01JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt
ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtYmFzZWxpbmUtbGVnYWN5DQpNZXNzYWdl ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtYmFzZWxpbmUtbGVnYWN5DQpNZXNzYWdl
skipping to change at page 188, line 22 skipping to change at line 8658
QXV0aG9yaXR5AhM3QQV57XV/QqmiXDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgG QXV0aG9yaXR5AhM3QQV57XV/QqmiXDr0+GrOmqnXMAsGCWCGSAFlAwQCAaBpMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE3 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDIyMDE3
MTAwMlowLwYJKoZIhvcNAQkEMSIEIDe7/NLwTkHNon7IR1M1xiObMU+8qMIZ1No5 MTAwMlowLwYJKoZIhvcNAQkEMSIEIDe7/NLwTkHNon7IR1M1xiObMU+8qMIZ1No5
ANcjz5C9MA0GCSqGSIb3DQEBAQUABIIBABi/HvXTe3Z+LaltuFv57ZaUvY6kegwe ANcjz5C9MA0GCSqGSIb3DQEBAQUABIIBABi/HvXTe3Z+LaltuFv57ZaUvY6kegwe
OGiZ5UPa5FBpQxoE/1vp8xG+UVIUnpdV/1THKPjKFr6bZZff1/4u4NFeBYwI9yg+ OGiZ5UPa5FBpQxoE/1vp8xG+UVIUnpdV/1THKPjKFr6bZZff1/4u4NFeBYwI9yg+
tK1cYz+B2cscX6FDAGjUr/6QxMOwd+ol7bnlzJJDrXvv8B5AOdHFosyOrDSrvn2k tK1cYz+B2cscX6FDAGjUr/6QxMOwd+ol7bnlzJJDrXvv8B5AOdHFosyOrDSrvn2k
Pzc6ush4JvS3aee5QFEgtd1bQx9fx3t/QhBsn5kGMC+3FzvKtmAYUlz0unqvk4HV Pzc6ush4JvS3aee5QFEgtd1bQx9fx3t/QhBsn5kGMC+3FzvKtmAYUlz0unqvk4HV
I40Goh/Fm3uzNxwTQ3/rzE7ws1Qkrp0VlBxVGgUa4dZ1VXVIizkRz1PRtis66F73 I40Goh/Fm3uzNxwTQ3/rzE7ws1Qkrp0VlBxVGgUa4dZ1VXVIizkRz1PRtis66F73
EXJlygf9Btm/TJDUivXGr7fCI2i+njByX9vqUf/0UANsPevCy0HQWCY= EXJlygf9Btm/TJDUivXGr7fCI2i+njByX9vqUf/0UANsPevCy0HQWCY=
C.3.10.2. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.10.2. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_baseline (+ Legacy Display), Decrypted Protection with hcp_baseline (+ Legacy Display), Decrypted
and Unwrapped and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-baseline-legacy Subject: smime-signed-enc-complex-hp-baseline-legacy
Message-ID: Message-ID:
<smime-signed-enc-complex-hp-baseline-legacy@example> <smime-signed-enc-complex-hp-baseline-legacy@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
skipping to change at page 190, line 10 skipping to change at line 8742
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--308-- --308--
C.3.11. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.11. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_shy Protection with hcp_shy
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses the alternative message with an inline image/png attachment. It uses the
Header Protection scheme from the draft with the hcp_shy Header Header Protection scheme from the draft with the hcp_shy Header
Confidentiality Policy. Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 9925 bytes └─╴application/pkcs7-mime [smime.p7m] 9925 bytes
skipping to change at page 194, line 5 skipping to change at line 8929
stpjIHk4BsJGwoqJN8Gf9IGV6Pi6DlpUtifBcDEpCoBt7wkMUCHp/Bjq5lEsTtZA stpjIHk4BsJGwoqJN8Gf9IGV6Pi6DlpUtifBcDEpCoBt7wkMUCHp/Bjq5lEsTtZA
86yRqNOZKLuyW7tqDfOPYQUsUpbAM4E8hrN84EDgLYMCg6AC/Qs3H/wDO7cJ4LCk 86yRqNOZKLuyW7tqDfOPYQUsUpbAM4E8hrN84EDgLYMCg6AC/Qs3H/wDO7cJ4LCk
M5Hph06hiyehanuMCtUVyvyfSb1hWY5LELyr9UKLYHXMdCRm6SI4lhkcD/yd7YRc M5Hph06hiyehanuMCtUVyvyfSb1hWY5LELyr9UKLYHXMdCRm6SI4lhkcD/yd7YRc
8xXJwFVSBSXcuRFQD8ViGo84HNNw45Oa/kcT0tfJLNDk2psDgMICjWkiZDcOJ0fF 8xXJwFVSBSXcuRFQD8ViGo84HNNw45Oa/kcT0tfJLNDk2psDgMICjWkiZDcOJ0fF
ExXO65SCDaVSK2a2hScuhLb4o87nkHPTtmCwse92gYQlgEJqhAUCe4tupS3Tlced ExXO65SCDaVSK2a2hScuhLb4o87nkHPTtmCwse92gYQlgEJqhAUCe4tupS3Tlced
rYx5p0TRq0a4saxyQw3KOkvCYb00vr3e5ywj+I7FJmdT/3FRepXHAdJgeymSmelh rYx5p0TRq0a4saxyQw3KOkvCYb00vr3e5ywj+I7FJmdT/3FRepXHAdJgeymSmelh
MUnQVvRetUv+tbsHk96DXjMHUfvCArWcjf4NfuweEud6JAtmIxZhmBFTlg/j+oB7 MUnQVvRetUv+tbsHk96DXjMHUfvCArWcjf4NfuweEud6JAtmIxZhmBFTlg/j+oB7
L3+nunA6/dDrIlBNCCQ/WWW3STpAhFC7jBCzIZMJMwyP7tRk6KL+PptfMMWD2rJy L3+nunA6/dDrIlBNCCQ/WWW3STpAhFC7jBCzIZMJMwyP7tRk6KL+PptfMMWD2rJy
QpFXwNDVCKOca+JCuhJ3lhlfjrexPJKD5/hhqGdKqc8= QpFXwNDVCKOca+JCuhJ3lhlfjrexPJKD5/hhqGdKqc8=
C.3.11.1. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.11.1. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_shy, Decrypted Protection with hcp_shy, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIR/gYJKoZIhvcNAQcCoIIR7zCCEesCAQExDTALBglghkgBZQMEAgEwgggnBgkq MIIR/gYJKoZIhvcNAQcCoIIR7zCCEesCAQExDTALBglghkgBZQMEAgEwgggnBgkq
hkiG9w0BBwGggggYBIIIFE1JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt hkiG9w0BBwGggggYBIIIFE1JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt
ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtc2h5DQpNZXNzYWdlLUlEOiA8c21pbWUt ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtc2h5DQpNZXNzYWdlLUlEOiA8c21pbWUt
skipping to change at page 196, line 15 skipping to change at line 9036
AwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X AwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTIxMDIyMDE3MTIwMlowLwYJKoZIhvcNAQkEMSIEIOk6rjm9vW4yAFhPqraTwTSM DTIxMDIyMDE3MTIwMlowLwYJKoZIhvcNAQkEMSIEIOk6rjm9vW4yAFhPqraTwTSM
poDXdAk+kSVCc47Smx1DMA0GCSqGSIb3DQEBAQUABIIBAAURi5oouLYIh9YruNpF poDXdAk+kSVCc47Smx1DMA0GCSqGSIb3DQEBAQUABIIBAAURi5oouLYIh9YruNpF
Se6sDsPTGmIcZsDjQ/MZV55S4pmhVBQu4SoVZDVM9KHKxqfBbj+aTs1Cyas8R88h Se6sDsPTGmIcZsDjQ/MZV55S4pmhVBQu4SoVZDVM9KHKxqfBbj+aTs1Cyas8R88h
cWqd8xhiU9ufoC7p6qEMVIyMvyppeupRyjQWUCH+2XtQ5sAVmr+F+l/Valuj7JZw cWqd8xhiU9ufoC7p6qEMVIyMvyppeupRyjQWUCH+2XtQ5sAVmr+F+l/Valuj7JZw
JU8XS84oinCF6uApu7eucGblt8t7ek7j3JXoFVE7g8a/O1JKg4ezNV2RduQeNXLT JU8XS84oinCF6uApu7eucGblt8t7ek7j3JXoFVE7g8a/O1JKg4ezNV2RduQeNXLT
m/lBVIfeiiOsmgmJa5RTgbgAakJtdo3odHj0cI31eANSbQlE3XENz2E9L8JWxYNP m/lBVIfeiiOsmgmJa5RTgbgAakJtdo3odHj0cI31eANSbQlE3XENz2E9L8JWxYNP
bBceEhIvu2AOtV2PYCBfrVp0WTVwWHorm8GG/DyvsAsa6eGJI55hA8VeBg170gT5 bBceEhIvu2AOtV2PYCBfrVp0WTVwWHorm8GG/DyvsAsa6eGJI55hA8VeBg170gT5
nzc= nzc=
C.3.11.2. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.11.2. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_shy, Decrypted and Unwrapped Protection with hcp_shy, Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-shy Subject: smime-signed-enc-complex-hp-shy
Message-ID: <smime-signed-enc-complex-hp-shy@example> Message-ID: <smime-signed-enc-complex-hp-shy@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:12:02 -0500 Date: Sat, 20 Feb 2021 12:12:02 -0500
User-Agent: Sample MUA Version 1.0 User-Agent: Sample MUA Version 1.0
skipping to change at page 197, line 38 skipping to change at line 9107
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--1fa-- --1fa--
C.3.12. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.12. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_shy (+ Legacy Display) Protection with hcp_shy (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses the alternative message with an inline image/png attachment. It uses the
Header Protection scheme from the draft with the hcp_shy Header Header Protection scheme from the draft with the hcp_shy Header
Confidentiality Policy with a "Legacy Display" part. Confidentiality Policy with a "Legacy Display" part.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 10920 bytes └─╴application/pkcs7-mime [smime.p7m] 10920 bytes
skipping to change at page 202, line 5 skipping to change at line 9309
SHSAyMEe3+9g2Xd9Y5UyhPCePnIFtfvThUUWDMBbl4NkTZhci2Q+NGhwSfd//i/q SHSAyMEe3+9g2Xd9Y5UyhPCePnIFtfvThUUWDMBbl4NkTZhci2Q+NGhwSfd//i/q
0dCdTZHj3ucJsNkCtfW7DtIykpy6Vld5smayE1zu5WjE2EzfumQHHqkOrfCNBBbi 0dCdTZHj3ucJsNkCtfW7DtIykpy6Vld5smayE1zu5WjE2EzfumQHHqkOrfCNBBbi
plJwXI0WLdVCJrSAUoOTlZbE22r4tJnar1DA+V3Jep/VPZ1mNxa5Dh0fseI4h63q plJwXI0WLdVCJrSAUoOTlZbE22r4tJnar1DA+V3Jep/VPZ1mNxa5Dh0fseI4h63q
eudtLO5NBMLMQxz762u9uB0y1vuFmKOX0VWz2aXZ6jHmN0z4zuwrqbS6yHYqEX3Z eudtLO5NBMLMQxz762u9uB0y1vuFmKOX0VWz2aXZ6jHmN0z4zuwrqbS6yHYqEX3Z
4NzaoFOD7eRJbH92yFb1owGjPsb7QcRykQfBhmiIHeNJUoja5xZdk9M7vX5ygB8w 4NzaoFOD7eRJbH92yFb1owGjPsb7QcRykQfBhmiIHeNJUoja5xZdk9M7vX5ygB8w
AIk33yHYWOumHHFeSPvHlTTsNvLel422gDyiDO0fXmJfGAsauqcX11jNB7RI+HM3 AIk33yHYWOumHHFeSPvHlTTsNvLel422gDyiDO0fXmJfGAsauqcX11jNB7RI+HM3
HnXNeubb3y3aA1bl1djZxngAwOQ1Sr9aLobmpbL/zsKrFXG7/fiz2DmachOLJL97 HnXNeubb3y3aA1bl1djZxngAwOQ1Sr9aLobmpbL/zsKrFXG7/fiz2DmachOLJL97
PU1j9MTspdH8VtBXX1KFyOSQKBRoGtYmG/OK5gilSXSSevz84KJiZw1ReIMXCa77 PU1j9MTspdH8VtBXX1KFyOSQKBRoGtYmG/OK5gilSXSSevz84KJiZw1ReIMXCa77
8Qxgzs7bIccDSBVzfzxjFADQxFY2jm+g8mr5b17byqO5wiNlLaGyneQeGMsI6H4Q 8Qxgzs7bIccDSBVzfzxjFADQxFY2jm+g8mr5b17byqO5wiNlLaGyneQeGMsI6H4Q
C.3.12.1. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.12.1. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_shy (+ Legacy Display), Decrypted Protection with hcp_shy (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIUEgYJKoZIhvcNAQcCoIIUAzCCE/8CAQExDTALBglghkgBZQMEAgEwggo7Bgkq MIIUEgYJKoZIhvcNAQcCoIIUAzCCE/8CAQExDTALBglghkgBZQMEAgEwggo7Bgkq
hkiG9w0BBwGgggosBIIKKE1JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt hkiG9w0BBwGgggosBIIKKE1JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt
ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtc2h5LWxlZ2FjeQ0KTWVzc2FnZS1JRDog ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtc2h5LWxlZ2FjeQ0KTWVzc2FnZS1JRDog
skipping to change at page 204, line 26 skipping to change at line 9427
hkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ hkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yMTAyMjAxNzEzMDJaMC8GCSqGSIb3DQEJBDEiBCBllHSf7b+HyaqXmEwT BTEPFw0yMTAyMjAxNzEzMDJaMC8GCSqGSIb3DQEJBDEiBCBllHSf7b+HyaqXmEwT
DQLFcyd845Y683fln5KaB6NJmjANBgkqhkiG9w0BAQEFAASCAQCRRSDM+MtNb5av DQLFcyd845Y683fln5KaB6NJmjANBgkqhkiG9w0BAQEFAASCAQCRRSDM+MtNb5av
W1U6o2LxrDXrrIy7lb8Vw1D3gHSgEaeZ3ZvZ6OefQPh4OkHNy/oescj+rKZzcLHB W1U6o2LxrDXrrIy7lb8Vw1D3gHSgEaeZ3ZvZ6OefQPh4OkHNy/oescj+rKZzcLHB
s3RZ9Tnybr7p3kawIEFv1DW3aiyXQ49gQyPHn2Nwi6hK7Gn5d7rjSFuzprWYACg7 s3RZ9Tnybr7p3kawIEFv1DW3aiyXQ49gQyPHn2Nwi6hK7Gn5d7rjSFuzprWYACg7
hAVWBd4/prAE1mNMR4DOOXoPYZn+ggJb/oaagcbdEy3WrznO2n6TW6Eb7bBoUT4t hAVWBd4/prAE1mNMR4DOOXoPYZn+ggJb/oaagcbdEy3WrznO2n6TW6Eb7bBoUT4t
IrZRWxPrdP30T7N1eHMmCDNGSXt/fC9rgcRLz+cj+1czfU1Gf+qIxg05HyrVMrkL IrZRWxPrdP30T7N1eHMmCDNGSXt/fC9rgcRLz+cj+1czfU1Gf+qIxg05HyrVMrkL
+XiCEoOck2+pbpz5WFPcmnRXLgH2FMlSNWU5RwbRu5YZejoKBiUZNlUmlA08d5JV +XiCEoOck2+pbpz5WFPcmnRXLgH2FMlSNWU5RwbRu5YZejoKBiUZNlUmlA08d5JV
U3Zqnl/G U3Zqnl/G
C.3.12.2. S/MIME Signed and Encrypted Over a Complex Message, Header C.3.12.2. S/MIME Signed and Encrypted over a Complex Message, Header
Protection With hcp_shy (+ Legacy Display), Decrypted and Protection with hcp_shy (+ Legacy Display), Decrypted and
Unwrapped Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-shy-legacy Subject: smime-signed-enc-complex-hp-shy-legacy
Message-ID: <smime-signed-enc-complex-hp-shy-legacy@example> Message-ID: <smime-signed-enc-complex-hp-shy-legacy@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:13:02 -0500 Date: Sat, 20 Feb 2021 12:13:02 -0500
skipping to change at page 206, line 19 skipping to change at line 9516
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--cd5-- --cd5--
C.3.13. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.13. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_baseline Header Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses the alternative message with an inline image/png attachment. It uses the
Header Protection scheme from the draft with the hcp_baseline Header Header Protection scheme from the draft with the hcp_baseline Header
Confidentiality Policy. Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 10575 bytes └─╴application/pkcs7-mime [smime.p7m] 10575 bytes
skipping to change at page 210, line 26 skipping to change at line 9715
ztxxOBngAlBMdPtxEi4tev7S93SFKoqMwY18vHlLOHi/oFpaWMjJsE4uxdqvtz/x ztxxOBngAlBMdPtxEi4tev7S93SFKoqMwY18vHlLOHi/oFpaWMjJsE4uxdqvtz/x
aeZMmgstD1ZYRykBqGzjm8cMeoQawJ9HF6AkNFPo9+AsgXCuPNhutGZuCv3vAWTg aeZMmgstD1ZYRykBqGzjm8cMeoQawJ9HF6AkNFPo9+AsgXCuPNhutGZuCv3vAWTg
yXAiMHDuzahSggfr7r2ixkDUxD12/5RSeSDvCkeCWsjBKVpyzoWn2QksAMBoETyN yXAiMHDuzahSggfr7r2ixkDUxD12/5RSeSDvCkeCWsjBKVpyzoWn2QksAMBoETyN
F2gcjouX2Cp+OkOQV0e8Y6zIOWE/SGUkFkUDRJUSA8gkpfXWDPV8MN6rAMULWUGP F2gcjouX2Cp+OkOQV0e8Y6zIOWE/SGUkFkUDRJUSA8gkpfXWDPV8MN6rAMULWUGP
jYcRtabSgnlXKn6VivRiBlGXvp7iOXpsoGtMwof9hUcoo/HYMAvdsd5anaIZU8tA jYcRtabSgnlXKn6VivRiBlGXvp7iOXpsoGtMwof9hUcoo/HYMAvdsd5anaIZU8tA
g+c+8OHky2OJ5mzUWmk1CcBIWO9yyAHsy7ivSVzJtxDuTrQAuuH92MZgyvGnoioM g+c+8OHky2OJ5mzUWmk1CcBIWO9yyAHsy7ivSVzJtxDuTrQAuuH92MZgyvGnoioM
uaKOwNzrmhAAhBruv0XpMd/RBIu5+e8EM+fIuYwwwYDWIpn9vMbkKiBv4h5PQ8+T uaKOwNzrmhAAhBruv0XpMd/RBIu5+e8EM+fIuYwwwYDWIpn9vMbkKiBv4h5PQ8+T
cunAwgNdg0qVFeZ96Gu1sIHttbexEvSADg9fplx7TG+DZgSrDkxhnJ80a0hZhZ2F cunAwgNdg0qVFeZ96Gu1sIHttbexEvSADg9fplx7TG+DZgSrDkxhnJ80a0hZhZ2F
CYJJrvEcQn+/ItTftmmV5tpG2r/LCufYFL26h0RXdD8= CYJJrvEcQn+/ItTftmmV5tpG2r/LCufYFL26h0RXdD8=
C.3.13.1. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.13.1. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_baseline, Decrypted Header Protection with hcp_baseline, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIITWQYJKoZIhvcNAQcCoIITSjCCE0YCAQExDTALBglghkgBZQMEAgEwggmCBgkq MIITWQYJKoZIhvcNAQcCoIITSjCCE0YCAQExDTALBglghkgBZQMEAgEwggmCBgkq
hkiG9w0BBwGggglzBIIJb01JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt hkiG9w0BBwGggglzBIIJb01JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt
ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtYmFzZWxpbmUtcmVwbHkNCk1lc3NhZ2Ut ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtYmFzZWxpbmUtcmVwbHkNCk1lc3NhZ2Ut
skipping to change at page 212, line 44 skipping to change at line 9829
qdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq qdcwCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMjEwMjIwMTcxNTAyWjAvBgkqhkiG9w0BCQQxIgQgzz6zrLzs hkiG9w0BCQUxDxcNMjEwMjIwMTcxNTAyWjAvBgkqhkiG9w0BCQQxIgQgzz6zrLzs
Pn86IlgrGm7Fheev5QucTU+VJZWxIIrBFk8wDQYJKoZIhvcNAQEBBQAEggEASITl Pn86IlgrGm7Fheev5QucTU+VJZWxIIrBFk8wDQYJKoZIhvcNAQEBBQAEggEASITl
JnQGy7Cb5U6BdSMX3mnksCOX8mvaxy3o0QqNUbUGhNNPKI0LIWOdjHUL2Eq8+99Y JnQGy7Cb5U6BdSMX3mnksCOX8mvaxy3o0QqNUbUGhNNPKI0LIWOdjHUL2Eq8+99Y
2+WvVn3ZkAJ7KF/89ja3u4NTiwu30wWsd7DL7t1z8DJBK6JuyaY4xtohUPVa2gL2 2+WvVn3ZkAJ7KF/89ja3u4NTiwu30wWsd7DL7t1z8DJBK6JuyaY4xtohUPVa2gL2
1atPowCt0X5RF7lmihqZnDGGUAzjfLpVsFnyIVAL3QG4/vW609d+aeO+ccdwzzUh 1atPowCt0X5RF7lmihqZnDGGUAzjfLpVsFnyIVAL3QG4/vW609d+aeO+ccdwzzUh
lE03h3qpHK9wX5pWBNZCfdmjdXUFacU+fMe1mG9I8A1HMY09zj+rNz3onoIHJWJ2 lE03h3qpHK9wX5pWBNZCfdmjdXUFacU+fMe1mG9I8A1HMY09zj+rNz3onoIHJWJ2
FBWS2tqK2eW8yCf/LSq9M5k86VbTjPjvjPz8FqupzugC5sUAx2JMUfUOq4A9hW+j FBWS2tqK2eW8yCf/LSq9M5k86VbTjPjvjPz8FqupzugC5sUAx2JMUfUOq4A9hW+j
g8PEOcwaEeYOMdSeKw== g8PEOcwaEeYOMdSeKw==
C.3.13.2. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.13.2. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_baseline, Decrypted and Unwrapped Header Protection with hcp_baseline, Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-baseline-reply Subject: smime-signed-enc-complex-hp-baseline-reply
Message-ID: <smime-signed-enc-complex-hp-baseline-reply@example> Message-ID: <smime-signed-enc-complex-hp-baseline-reply@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:15:02 -0500 Date: Sat, 20 Feb 2021 12:15:02 -0500
User-Agent: Sample MUA Version 1.0 User-Agent: Sample MUA Version 1.0
skipping to change at page 214, line 28 skipping to change at line 9907
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--b2f-- --b2f--
C.3.14. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.14. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_baseline (+ Legacy Display) Header Protection with hcp_baseline (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses the alternative message with an inline image/png attachment. It uses the
Header Protection scheme from the draft with the hcp_baseline Header Header Protection scheme from the draft with the hcp_baseline Header
Confidentiality Policy with a "Legacy Display" part. Confidentiality Policy with a "Legacy Display" part.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 11205 bytes └─╴application/pkcs7-mime [smime.p7m] 11205 bytes
skipping to change at page 219, line 5 skipping to change at line 10119
GkOgetOL6bcoW29PkhnodKSscod7sk4C70hJBJ7RrJNlA5YuwrWzokeD3rjEzqlj GkOgetOL6bcoW29PkhnodKSscod7sk4C70hJBJ7RrJNlA5YuwrWzokeD3rjEzqlj
dmRN2m9DQnXNeHKsxEsCkgIeLZVsrCxMVONTCrdfQnKnzZDgtoI4EYFfEElN6qQ7 dmRN2m9DQnXNeHKsxEsCkgIeLZVsrCxMVONTCrdfQnKnzZDgtoI4EYFfEElN6qQ7
v8LtiJyqtmYSPU3c3xb+zsWtElso+HfHELrwsY8ge485xBwtGTGKZtCcxsKtj97X v8LtiJyqtmYSPU3c3xb+zsWtElso+HfHELrwsY8ge485xBwtGTGKZtCcxsKtj97X
gb/4pfvziajCLU/MWnE4fzQXPjXk8NEQRdk+EsgoCOxnTPShAnW+MDN143ndDN+J gb/4pfvziajCLU/MWnE4fzQXPjXk8NEQRdk+EsgoCOxnTPShAnW+MDN143ndDN+J
+BuTpFVF/duO+Vobv3N+3dH+Qd1qhui+q7R+ojXyp516X0IZCKr6211hAGgI7i+y +BuTpFVF/duO+Vobv3N+3dH+Qd1qhui+q7R+ojXyp516X0IZCKr6211hAGgI7i+y
Z2RGCHIF3AA3ncH/An0X0RHgQi7ZIoSGDoHR2v0blOXDBNlzRXXiVEUGu1XuBp/o Z2RGCHIF3AA3ncH/An0X0RHgQi7ZIoSGDoHR2v0blOXDBNlzRXXiVEUGu1XuBp/o
BDnnXqcLT2Nng2tgdu6XvbIfgdr15/zrwKEAbG3yJa2iGsotgdiu1DgU7lfktlPq BDnnXqcLT2Nng2tgdu6XvbIfgdr15/zrwKEAbG3yJa2iGsotgdiu1DgU7lfktlPq
ftTzg2nvDkTGT86AsTQNM2ClARtAmQnul5v/Oo926jCr+471rEXfN6Gm6zkwwoAG ftTzg2nvDkTGT86AsTQNM2ClARtAmQnul5v/Oo926jCr+471rEXfN6Gm6zkwwoAG
ZyE19pnIaF/p7tczePNgug== ZyE19pnIaF/p7tczePNgug==
C.3.14.1. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.14.1. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_baseline (+ Legacy Display), Header Protection with hcp_baseline (+ Legacy Display),
Decrypted Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIUpgYJKoZIhvcNAQcCoIIUlzCCFJMCAQExDTALBglghkgBZQMEAgEwggrPBgkq MIIUpgYJKoZIhvcNAQcCoIIUlzCCFJMCAQExDTALBglghkgBZQMEAgEwggrPBgkq
hkiG9w0BBwGgggrABIIKvE1JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt hkiG9w0BBwGgggrABIIKvE1JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt
skipping to change at page 221, line 30 skipping to change at line 10241
CwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG CwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMjEwMjIwMTcxNjAyWjAvBgkqhkiG9w0BCQQxIgQg4f753q+skjOT 9w0BCQUxDxcNMjEwMjIwMTcxNjAyWjAvBgkqhkiG9w0BCQQxIgQg4f753q+skjOT
bEsl5q6WUySCAbgxotWkN7Ci2/Q7J9cwDQYJKoZIhvcNAQEBBQAEggEAiUGuCHAe bEsl5q6WUySCAbgxotWkN7Ci2/Q7J9cwDQYJKoZIhvcNAQEBBQAEggEAiUGuCHAe
JkzXXnkH3k8yFGtEkkMscuC0JOPwqnxHzILBDYt9udpeParT/drO0VgRKxCQ0mxT JkzXXnkH3k8yFGtEkkMscuC0JOPwqnxHzILBDYt9udpeParT/drO0VgRKxCQ0mxT
sz0D65erzo+ZXfuXC5+Q4hzqdNkQhC8Vi7H2NL8KLsBrXNLZtG82xco08fTKTWVq sz0D65erzo+ZXfuXC5+Q4hzqdNkQhC8Vi7H2NL8KLsBrXNLZtG82xco08fTKTWVq
c2HwuAPL0+Yh+fTfqrr5oRnJvPVkTxl97KxTA1YNQh/s+Uuacumnmr/3iuHwjubd c2HwuAPL0+Yh+fTfqrr5oRnJvPVkTxl97KxTA1YNQh/s+Uuacumnmr/3iuHwjubd
+iesA8wZ9RWsmeg4FGUzaVrTRIHj8p6YQQYJcOomV9GuRbjUzMVTL/fOB0G6Jho1 +iesA8wZ9RWsmeg4FGUzaVrTRIHj8p6YQQYJcOomV9GuRbjUzMVTL/fOB0G6Jho1
aq6nGVcsoVTMIrH8nJv54eHQtWtYFBJI855oDbkIS4DxH0wR5121BayRN7MgC6q+ aq6nGVcsoVTMIrH8nJv54eHQtWtYFBJI855oDbkIS4DxH0wR5121BayRN7MgC6q+
H+cJTAZUD2IF7Q== H+cJTAZUD2IF7Q==
C.3.14.2. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.14.2. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_baseline (+ Legacy Display), Header Protection with hcp_baseline (+ Legacy Display),
Decrypted and Unwrapped Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-baseline-lgc-rpl Subject: smime-signed-enc-complex-hp-baseline-lgc-rpl
Message-ID: Message-ID:
<smime-signed-enc-complex-hp-baseline-lgc-rpl@example> <smime-signed-enc-complex-hp-baseline-lgc-rpl@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
skipping to change at page 223, line 26 skipping to change at line 10333
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--63c-- --63c--
C.3.15. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.15. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_shy Header Protection with hcp_shy
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses the alternative message with an inline image/png attachment. It uses the
Header Protection scheme from the draft with the hcp_shy Header Header Protection scheme from the draft with the hcp_shy Header
Confidentiality Policy. Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 10445 bytes └─╴application/pkcs7-mime [smime.p7m] 10445 bytes
skipping to change at page 227, line 34 skipping to change at line 10530
SNFkFDZ4I+CfQDrN9YedY+lAMjcmiYIDn9s2RmYnGgAVlYweN7y8hE36sNAxDUKq SNFkFDZ4I+CfQDrN9YedY+lAMjcmiYIDn9s2RmYnGgAVlYweN7y8hE36sNAxDUKq
AEgC8bJrTAy7axaqj2m8c/F1nXzmKBn1+Q4zSW8oeNjvfSpfS5ZeljHnyHrZrUN5 AEgC8bJrTAy7axaqj2m8c/F1nXzmKBn1+Q4zSW8oeNjvfSpfS5ZeljHnyHrZrUN5
fVyet/3gok33Qqh58j2kXSVgWJrtbsIk1x5Zu2Q+QeUmMykA2ltAe//NbcRm5NzW fVyet/3gok33Qqh58j2kXSVgWJrtbsIk1x5Zu2Q+QeUmMykA2ltAe//NbcRm5NzW
fdAyOP3IIvpwp6wOrtDxyBeDDmPS6Jkthp/3A9CmD7jewnt2D3f9OG1jlZI1nvvi fdAyOP3IIvpwp6wOrtDxyBeDDmPS6Jkthp/3A9CmD7jewnt2D3f9OG1jlZI1nvvi
VxqKkC+yHGxYKC1kdvZnkoVPS5sGA3STRxzWgfzZOrnvyNjKneokJY2CMA89A8wm VxqKkC+yHGxYKC1kdvZnkoVPS5sGA3STRxzWgfzZOrnvyNjKneokJY2CMA89A8wm
cdAbA8WTxoLo7ObjelYiyPgB5BWUqWvRbrVUYS6lrgLToUIfVSS/beNyjwwmjHgR cdAbA8WTxoLo7ObjelYiyPgB5BWUqWvRbrVUYS6lrgLToUIfVSS/beNyjwwmjHgR
C3a2iQQ74kYyMr1iBj9K0cUeyVSBHOMvwG5Xv0Phovz6waVZdSWOcxjDslz+Ghg/ C3a2iQQ74kYyMr1iBj9K0cUeyVSBHOMvwG5Xv0Phovz6waVZdSWOcxjDslz+Ghg/
c74x37hFQSAiIUt9ZzrE569QNP6wcGe/S0MxL5MG6bqu5BH8MGrBeQ0IPRCwXFwI c74x37hFQSAiIUt9ZzrE569QNP6wcGe/S0MxL5MG6bqu5BH8MGrBeQ0IPRCwXFwI
+Hvwh/mIF5Uc0hssRDYNn9YxYA0jCLsjpxjMcDJCMUA= +Hvwh/mIF5Uc0hssRDYNn9YxYA0jCLsjpxjMcDJCMUA=
C.3.15.1. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.15.1. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_shy, Decrypted Header Protection with hcp_shy, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIITEAYJKoZIhvcNAQcCoIITATCCEv0CAQExDTALBglghkgBZQMEAgEwggk5Bgkq MIITEAYJKoZIhvcNAQcCoIITATCCEv0CAQExDTALBglghkgBZQMEAgEwggk5Bgkq
hkiG9w0BBwGgggkqBIIJJk1JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt hkiG9w0BBwGgggkqBIIJJk1JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt
ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtc2h5LXJlcGx5DQpNZXNzYWdlLUlEOiA8 ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtc2h5LXJlcGx5DQpNZXNzYWdlLUlEOiA8
skipping to change at page 230, line 5 skipping to change at line 10642
cml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG cml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNzE4MDJa 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNzE4MDJa
MC8GCSqGSIb3DQEJBDEiBCD0vcxZnCjxaOpfz5cIo9Maa0SVODPCXLJlV2Wbq4Z6 MC8GCSqGSIb3DQEJBDEiBCD0vcxZnCjxaOpfz5cIo9Maa0SVODPCXLJlV2Wbq4Z6
7zANBgkqhkiG9w0BAQEFAASCAQB3m6q708hB5tmuz6jzSJ+nCR7C0BRbfKypEnSP 7zANBgkqhkiG9w0BAQEFAASCAQB3m6q708hB5tmuz6jzSJ+nCR7C0BRbfKypEnSP
k2tdLaOAJWrHqljSd4klEJWy3x2SvLL9q+rSbmIWpK34PWVL1E7gbbJIBjfpoIUo k2tdLaOAJWrHqljSd4klEJWy3x2SvLL9q+rSbmIWpK34PWVL1E7gbbJIBjfpoIUo
+YMSIkhKFaKfUgulEi0zQG/HgnMENl6CDXa5ZrbW53SEpNpYgchUcqpg6Z0yOB07 +YMSIkhKFaKfUgulEi0zQG/HgnMENl6CDXa5ZrbW53SEpNpYgchUcqpg6Z0yOB07
oH7YOqF2111RRSzsjNMMDAm/1LvOFBR+nUERAhHvq1dpGpNuvbtAh4itWLLbDLlR oH7YOqF2111RRSzsjNMMDAm/1LvOFBR+nUERAhHvq1dpGpNuvbtAh4itWLLbDLlR
gIvrihHbqaUhf4VDQNg4MWjdHGATgPHNAb4hpfaxHxGEv+NYB/65VQWKGKMZujqk gIvrihHbqaUhf4VDQNg4MWjdHGATgPHNAb4hpfaxHxGEv+NYB/65VQWKGKMZujqk
aLH9nVThiAlEOyirAA7VlmvlUQgBem0pjh6ixnwK9HfPb7pG aLH9nVThiAlEOyirAA7VlmvlUQgBem0pjh6ixnwK9HfPb7pG
C.3.15.2. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.15.2. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_shy, Decrypted and Unwrapped Header Protection with hcp_shy, Decrypted and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-shy-reply Subject: smime-signed-enc-complex-hp-shy-reply
Message-ID: <smime-signed-enc-complex-hp-shy-reply@example> Message-ID: <smime-signed-enc-complex-hp-shy-reply@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
Date: Sat, 20 Feb 2021 12:18:02 -0500 Date: Sat, 20 Feb 2021 12:18:02 -0500
User-Agent: Sample MUA Version 1.0 User-Agent: Sample MUA Version 1.0
skipping to change at page 231, line 32 skipping to change at line 10718
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--46f-- --46f--
C.3.16. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.16. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_shy (+ Legacy Display) Header Protection with hcp_shy (+ Legacy Display)
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses the alternative message with an inline image/png attachment. It uses the
Header Protection scheme from the draft with the hcp_shy Header Header Protection scheme from the draft with the hcp_shy Header
Confidentiality Policy with a "Legacy Display" part. Confidentiality Policy with a "Legacy Display" part.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 11505 bytes └─╴application/pkcs7-mime [smime.p7m] 11505 bytes
skipping to change at page 236, line 5 skipping to change at line 10932
SFctnufOoPlH9JrL+mfoU83prsRDMmOqudzyi5/xWh4IvamvvQsq5+3xsQr1duA+ SFctnufOoPlH9JrL+mfoU83prsRDMmOqudzyi5/xWh4IvamvvQsq5+3xsQr1duA+
W/HeZ8jx5hgO5UfexS5hAcgNs4Wz2NVCCl9fProSuYh9Caoz2PwlK87c/MliEqWc W/HeZ8jx5hgO5UfexS5hAcgNs4Wz2NVCCl9fProSuYh9Caoz2PwlK87c/MliEqWc
jZ5oSk0+zwLXTp3xpv4MHwDzHwqV6Sdg+cOUtl6wlZp0vJVxPD5tljBU9EW2vjfF jZ5oSk0+zwLXTp3xpv4MHwDzHwqV6Sdg+cOUtl6wlZp0vJVxPD5tljBU9EW2vjfF
Iq19LN50RLPQ7RpfCtJAIYUAuYGz0mwd66Q71d39Wx56wHA9TqQBTzNqI0CK6/mX Iq19LN50RLPQ7RpfCtJAIYUAuYGz0mwd66Q71d39Wx56wHA9TqQBTzNqI0CK6/mX
sRZKrMvLBTdHKk4Capu6ehFJgUt3Oifib6DWV6v5HUG14Dt4z8Bj9a3R66NBLWlR sRZKrMvLBTdHKk4Capu6ehFJgUt3Oifib6DWV6v5HUG14Dt4z8Bj9a3R66NBLWlR
K+2PoBYdd942K9XlMGBn3LJl4ALdvIcPBWj3GF+uGyuVe7wBlSx9CflX2WSI5YSg K+2PoBYdd942K9XlMGBn3LJl4ALdvIcPBWj3GF+uGyuVe7wBlSx9CflX2WSI5YSg
UDSpg+5kGBqjvtMlI8+4lfWZWKxub8YY4IMzkQxJcbvfqIwwjrevtIArQbtPlZDG UDSpg+5kGBqjvtMlI8+4lfWZWKxub8YY4IMzkQxJcbvfqIwwjrevtIArQbtPlZDG
q5zPmbmEot+ceJepsSmSeiEXJoDQJgbl6ZodjzNaAzLdOcGZI+qvi9m1S95VDfVG q5zPmbmEot+ceJepsSmSeiEXJoDQJgbl6ZodjzNaAzLdOcGZI+qvi9m1S95VDfVG
qrLl6hDxECQwnHKXwGrH6Qt4lftSzDHOnWKRERbiAgu9JPEuek4MY4C3u6dteyC+ qrLl6hDxECQwnHKXwGrH6Qt4lftSzDHOnWKRERbiAgu9JPEuek4MY4C3u6dteyC+
C.3.16.1. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.16.1. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_shy (+ Legacy Display), Decrypted Header Protection with hcp_shy (+ Legacy Display), Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIVUAYJKoZIhvcNAQcCoIIVQTCCFT0CAQExDTALBglghkgBZQMEAgEwggt5Bgkq MIIVUAYJKoZIhvcNAQcCoIIVQTCCFT0CAQExDTALBglghkgBZQMEAgEwggt5Bgkq
hkiG9w0BBwGgggtqBIILZk1JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt hkiG9w0BBwGgggtqBIILZk1JTUUtVmVyc2lvbjogMS4wDQpTdWJqZWN0OiBzbWlt
ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtc2h5LWxlZ2FjeS1yZXBseQ0KTWVzc2Fn ZS1zaWduZWQtZW5jLWNvbXBsZXgtaHAtc2h5LWxlZ2FjeS1yZXBseQ0KTWVzc2Fn
skipping to change at page 238, line 32 skipping to change at line 11056
cml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG cml0eQITN0EFee11f0Kpolw69Phqzpqp1zALBglghkgBZQMEAgGgaTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNzE5MDJa 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjAxNzE5MDJa
MC8GCSqGSIb3DQEJBDEiBCDmeJ6lsrSkjN4AZBIkFqDsd0GBqHEAIhAZzSPkodWm MC8GCSqGSIb3DQEJBDEiBCDmeJ6lsrSkjN4AZBIkFqDsd0GBqHEAIhAZzSPkodWm
CTANBgkqhkiG9w0BAQEFAASCAQA8+6A0jm2WrDdfvFYh0OQ4Rpy+6ofiRnx5jI8I CTANBgkqhkiG9w0BAQEFAASCAQA8+6A0jm2WrDdfvFYh0OQ4Rpy+6ofiRnx5jI8I
a0iD6U77+KS/1W9c4rm5Sk2ElE7gZb/XL5D7l9X5aoiuF6KgyPrzNCL4G3Zz9zLY a0iD6U77+KS/1W9c4rm5Sk2ElE7gZb/XL5D7l9X5aoiuF6KgyPrzNCL4G3Zz9zLY
1l+7Cc+VsR8HcY9mgI5U34bmT1xZCHk3V+hTSUn+zE2XV5khxX0E5OxGzkrSz39Y 1l+7Cc+VsR8HcY9mgI5U34bmT1xZCHk3V+hTSUn+zE2XV5khxX0E5OxGzkrSz39Y
TReERGZGPPXorUIc/MPPKVNE0uhlVUY3WVp9oECnYOBnZ8Ed91rzJWH9hbvUq+jx TReERGZGPPXorUIc/MPPKVNE0uhlVUY3WVp9oECnYOBnZ8Ed91rzJWH9hbvUq+jx
22s5mbPGSi5napgEIr/vv66CuCSBK9oqUG4/dyd/hvLVgtZ3knoxn8VPXUgf8Yw6 22s5mbPGSi5napgEIr/vv66CuCSBK9oqUG4/dyd/hvLVgtZ3knoxn8VPXUgf8Yw6
my5/oStqcO3Q9Sd176LsZ4Otgc4kG789qHAlTax4HGqU3bAi my5/oStqcO3Q9Sd176LsZ4Otgc4kG789qHAlTax4HGqU3bAi
C.3.16.2. S/MIME Signed and Encrypted Reply Over a Complex Message, C.3.16.2. S/MIME Signed-and-Encrypted Reply over a Complex Message,
Header Protection With hcp_shy (+ Legacy Display), Decrypted Header Protection with hcp_shy (+ Legacy Display), Decrypted
and Unwrapped and Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Subject: smime-signed-enc-complex-hp-shy-legacy-reply Subject: smime-signed-enc-complex-hp-shy-legacy-reply
Message-ID: Message-ID:
<smime-signed-enc-complex-hp-shy-legacy-reply@example> <smime-signed-enc-complex-hp-shy-legacy-reply@example>
From: Alice <alice@smime.example> From: Alice <alice@smime.example>
To: Bob <bob@smime.example> To: Bob <bob@smime.example>
skipping to change at page 240, line 32 skipping to change at line 11152
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--d37-- --d37--
C.3.17. S/MIME Signed and Encrypted Over a Complex Message, Legacy RFC C.3.17. S/MIME Signed and Encrypted over a Complex Message, Legacy RFC
8551 Header Protection With hcp_baseline 8551 Header Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a multipart/ envelopedData around signedData. The payload is a multipart/
alternative message with an inline image/png attachment. It uses the alternative message with an inline image/png attachment. It uses the
legacy RFC 8551 header protection (RFC8551HP) scheme with the legacy RFC 8551 header protection (RFC8551HP) scheme with the
hcp_baseline Header Confidentiality Policy. hcp_baseline Header Confidentiality Policy.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 9580 bytes └─╴application/pkcs7-mime [smime.p7m] 9580 bytes
skipping to change at page 244, line 33 skipping to change at line 11336
kuu0AYauvHf6mDPhbsvdtTLQUY9cQ991c1XFB3NZwZa1GL9BtYpLU9xsd4k+qyzI kuu0AYauvHf6mDPhbsvdtTLQUY9cQ991c1XFB3NZwZa1GL9BtYpLU9xsd4k+qyzI
5zW1UEG0B265+FhYBMz12KRvjfTMegaMCqo3WKG0p/HfdGRFXzYScZCDKe/n7pDW 5zW1UEG0B265+FhYBMz12KRvjfTMegaMCqo3WKG0p/HfdGRFXzYScZCDKe/n7pDW
45+PhVyrxqQpsdyxTHb0qetjbYM/OlydenM47tvb9D+UIpRjYLmk3RCMKfbAd6nE 45+PhVyrxqQpsdyxTHb0qetjbYM/OlydenM47tvb9D+UIpRjYLmk3RCMKfbAd6nE
ctVLhUHswCMx4lnVRdIXuIc4yQrquAVPvlfzBVIxDeemkf2kmrA1P5aYZniflr7i ctVLhUHswCMx4lnVRdIXuIc4yQrquAVPvlfzBVIxDeemkf2kmrA1P5aYZniflr7i
SRG+XntvfKyyKqr09A605hOz8GyDSOIDRq5SykbeuUZd2MkhMHiqn3pkgWxfFADH SRG+XntvfKyyKqr09A605hOz8GyDSOIDRq5SykbeuUZd2MkhMHiqn3pkgWxfFADH
rptkhjQytcY4j8Znqg8O70da9J4G4sbILV5OgKaTt/7okM+rQ8ikzR9UJsAAgewn rptkhjQytcY4j8Znqg8O70da9J4G4sbILV5OgKaTt/7okM+rQ8ikzR9UJsAAgewn
DrnutsyrGrSmz7wIFkexxWnM6NZYMcJpdy0KXuctfBWIQs+ZyYrsd4pH3MP/hc+1 DrnutsyrGrSmz7wIFkexxWnM6NZYMcJpdy0KXuctfBWIQs+ZyYrsd4pH3MP/hc+1
t2W57Gm57dXBh0lqxDnaGFGVBlYioWj/v1s0EoaVUM+XCYEsRKge45drULGh0qAZ t2W57Gm57dXBh0lqxDnaGFGVBlYioWj/v1s0EoaVUM+XCYEsRKge45drULGh0qAZ
sG1/1VBptLyt3UY3jh1tUw== sG1/1VBptLyt3UY3jh1tUw==
C.3.17.1. S/MIME Signed and Encrypted Over a Complex Message, Legacy C.3.17.1. S/MIME Signed and Encrypted over a Complex Message, Legacy
RFC 8551 Header Protection With hcp_baseline, Decrypted RFC 8551 Header Protection with hcp_baseline, Decrypted
The S/MIME enveloped-data layer unwraps to this signed-data part: The S/MIME enveloped-data layer unwraps to this signed-data part:
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="signed-data" smime-type="signed-data"
MIIRQAYJKoZIhvcNAQcCoIIRMTCCES0CAQExDTALBglghkgBZQMEAgEwggdpBgkq MIIRQAYJKoZIhvcNAQcCoIIRMTCCES0CAQExDTALBglghkgBZQMEAgEwggdpBgkq
hkiG9w0BBwGgggdaBIIHVk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6 hkiG9w0BBwGgggdaBIIHVk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6
IG1lc3NhZ2UvcmZjODIyDQoNCk1JTUUtVmVyc2lvbjogMS4wCkNvbnRlbnQtVHlw IG1lc3NhZ2UvcmZjODIyDQoNCk1JTUUtVmVyc2lvbjogMS4wCkNvbnRlbnQtVHlw
skipping to change at page 246, line 40 skipping to change at line 11439
AWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx AWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMjEwMjIwMTcyODAyWjAvBgkqhkiG9w0BCQQxIgQgzbXAB7rXfNs26yYOHvuE DxcNMjEwMjIwMTcyODAyWjAvBgkqhkiG9w0BCQQxIgQgzbXAB7rXfNs26yYOHvuE
D4KQ9RzsSF5fL55lZZY7AjgwDQYJKoZIhvcNAQEBBQAEggEAAs1y7DQLS7S+Vh2b D4KQ9RzsSF5fL55lZZY7AjgwDQYJKoZIhvcNAQEBBQAEggEAAs1y7DQLS7S+Vh2b
Ju5W9UwkHp6lUk/F7mJE80FRc8K6z8pcSn4xTrlCaLgL7azQ0o/iNQEh2EVJqdy6 Ju5W9UwkHp6lUk/F7mJE80FRc8K6z8pcSn4xTrlCaLgL7azQ0o/iNQEh2EVJqdy6
huwwtlaeiPa2gXwIHCKcLGhA2bW3/R+sEsJZi7FryqTakOZ9eXcYRXoPWv6ncf+I huwwtlaeiPa2gXwIHCKcLGhA2bW3/R+sEsJZi7FryqTakOZ9eXcYRXoPWv6ncf+I
eA7jlQX3Z4Ln5pP9p+Uw7H1oroH2Y4e0yAqIMtYXnS+GKALTtbxTa1p2Y9dsHQLS eA7jlQX3Z4Ln5pP9p+Uw7H1oroH2Y4e0yAqIMtYXnS+GKALTtbxTa1p2Y9dsHQLS
2cXbfUsU2zc5bstgKXZyTkjuKJ8ivbYJ2ttk79AOMosWkDBmgzKTTS/0HptfO9SD 2cXbfUsU2zc5bstgKXZyTkjuKJ8ivbYJ2ttk79AOMosWkDBmgzKTTS/0HptfO9SD
mX58BvQt6GHQZ4TR2NVDvq3z+/CAlzsR5xmNH1C+uDH99ORoy3w6CHmv4aTTmRM9 mX58BvQt6GHQZ4TR2NVDvq3z+/CAlzsR5xmNH1C+uDH99ORoy3w6CHmv4aTTmRM9
S+uZXg== S+uZXg==
C.3.17.2. S/MIME Signed and Encrypted Over a Complex Message, Legacy C.3.17.2. S/MIME Signed and Encrypted over a Complex Message, Legacy
RFC 8551 Header Protection With hcp_baseline, Decrypted and RFC 8551 Header Protection with hcp_baseline, Decrypted and
Unwrapped Unwrapped
The inner signed-data layer unwraps to: The inner signed-data layer unwraps to:
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: message/rfc822 Content-Type: message/rfc822
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="266" Content-Type: multipart/mixed; boundary="266"
Subject: smime-enc-signed-complex-rfc8551hp-baseline Subject: smime-enc-signed-complex-rfc8551hp-baseline
skipping to change at page 248, line 4 skipping to change at line 11498
<b>smime-enc-signed-complex-rfc8551hp-baseline</b> <b>smime-enc-signed-complex-rfc8551hp-baseline</b>
message.</p> message.</p>
<p>This is an encrypted and signed S/MIME message using PKCS#7 <p>This is an encrypted and signed S/MIME message using PKCS#7
envelopedData around signedData. The payload is a envelopedData around signedData. The payload is a
multipart/alternative message with an inline image/png multipart/alternative message with an inline image/png
attachment. It uses the legacy RFC 8551 header protection attachment. It uses the legacy RFC 8551 header protection
(RFC8551HP) scheme with the hcp_baseline Header Confidentiality (RFC8551HP) scheme with the hcp_baseline Header Confidentiality
Policy.</p> Policy.</p>
<p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html> <p><tt>-- <br/>Alice<br/>alice@smime.example</tt></p></body></html>
--db6-- --db6--
--266 --266
Content-Type: image/png Content-Type: image/png
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: inline Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--266-- --266--
Appendix D. Composition Examples Appendix D. Composition Examples
This section offers step-by-step examples of message composition. This section offers step-by-step examples of message composition.
D.1. New message composition D.1. New Message Composition
A typical MUA composition interface offers the user a place to A typical MUA composition interface offers the user a place to
indicate the message recipients, the subject, and the body. Consider indicate the message recipients, subject, and body. Consider a
a composition window filled out by the user like so: composition window filled out by the user like so:
.------------------------------------------------------. .------------------------------------------------------.
| Composing New Message .----. | | Composing New Message .----. |
| +---------------------------------+ | Send | | | +---------------------------------+ | Send | |
| To: | Alice <alice@example.net> | '----' | | To: | Alice <alice@example.net> | '----' |
| +---------------------------------+---------+ | | +---------------------------------+---------+ |
| Subject: | Handling the Jones contract | | | Subject: | Handling the Jones contract | |
| +-------------------------------------------+ | | +-------------------------------------------+ |
+--------------------------------------------------------+ +--------------------------------------------------------+
| Please review and approve or decline by Thursday, it's | | Please review and approve or decline by Thursday, it's |
skipping to change at page 248, line 48 skipping to change at line 11543
| Bob | | Bob |
| | | |
| -- | | -- |
| Bob Gonzalez | | Bob Gonzalez |
| ACME, Inc. | | ACME, Inc. |
| | | |
+--------------------------------------------------------+ +--------------------------------------------------------+
Figure 1: Example Message Composition Interface Figure 1: Example Message Composition Interface
When Bob clicks "Send", his MUA generates values for Message-ID, When Bob clicks "Send", his MUA generates values for the Message-ID,
From, and Date Header Fields, and converts the message body into the From, and Date Header Fields and converts the message body into the
appropriate format. appropriate format.
D.1.1. Unprotected message D.1.1. Unprotected Message
The resulting message would look something like this if it was sent The resulting message would look something like this if it was sent
without cryptographic protections: without cryptographic protections:
Date: Wed, 11 Jan 2023 16:08:43 -0500 Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net> From: Bob <bob@example.net>
To: Alice <alice@example.net> To: Alice <alice@example.net>
Subject: Handling the Jones contract Subject: Handling the Jones contract
Message-ID: <20230111T210843Z.1234@lhp.example> Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Type: text/plain; charset="us-ascii" Content-Type: text/plain; charset="us-ascii"
skipping to change at page 249, line 46 skipping to change at line 11588
hcp_baseline("Subject", "Handling the Jones contract") yields hcp_baseline("Subject", "Handling the Jones contract") yields
"[...]". "[...]".
D.1.2.1. Cryptographic Payload D.1.2.1. Cryptographic Payload
The Cryptographic Payload that will be signed and then encrypted is The Cryptographic Payload that will be signed and then encrypted is
very similar to the unprotected message in Appendix D.1.1. Note the very similar to the unprotected message in Appendix D.1.1. Note the
addition of: addition of:
* The hp="cipher" parameter for the Content-Type * the hp="cipher" parameter for the Content-Type
* The appropriate HP-Outer Header Field for Subject * the appropriate HP-Outer Header Field for Subject
* The hp-legacy-display="1" parameter for the Content-Type * 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. * 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 Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net> From: Bob <bob@example.net>
To: Alice <alice@example.net> To: Alice <alice@example.net>
Subject: Handling the Jones contract Subject: Handling the Jones contract
Message-ID: <20230111T210843Z.1234@lhp.example> Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1";
hp="cipher" hp="cipher"
MIME-Version: 1.0 MIME-Version: 1.0
HP-Outer: Date: Wed, 11 Jan 2023 16:08:43 -0500 HP-Outer: Date: Wed, 11 Jan 2023 16:08:43 -0500
skipping to change at page 250, line 35 skipping to change at line 11625
Thanks, Thanks,
Bob Bob
-- --
Bob Gonzalez Bob Gonzalez
ACME, Inc. ACME, Inc.
D.1.2.2. External Header Section D.1.2.2. External Header Section
The Cryptographic Payload from Appendix D.1.2.1 is then wrapped in The Cryptographic Payload from Appendix D.1.2.1 is then wrapped in
the appropriate Cryptographic Layers. For this example, using S/ the appropriate Cryptographic Layers. For this example using S/MIME,
MIME, it is wrapped in an application/pkcs7-mime; smime-type="signed- it is wrapped in an application/pkcs7-mime; smime-type="signed-data"
data" layer, which is in turn wrapped in an application/pkcs7-mime; layer, which is in turn wrapped in an application/pkcs7-mime; smime-
smime-type="enveloped-data" layer. type="enveloped-data" layer.
Then an external Header Section is applied to the outer MIME object, Then, an external Header Section is applied to the outer MIME object,
which looks like this: which looks like this:
Date: Wed, 11 Jan 2023 16:08:43 -0500 Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net> From: Bob <bob@example.net>
To: Alice <alice@example.net> To: Alice <alice@example.net>
Subject: [...] Subject: [...]
Message-ID: <20230111T210843Z.1234@lhp.example> Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="enveloped-data" smime-type="enveloped-data"
skipping to change at page 251, line 4 skipping to change at line 11642
Date: Wed, 11 Jan 2023 16:08:43 -0500 Date: Wed, 11 Jan 2023 16:08:43 -0500
From: Bob <bob@example.net> From: Bob <bob@example.net>
To: Alice <alice@example.net> To: Alice <alice@example.net>
Subject: [...] Subject: [...]
Message-ID: <20230111T210843Z.1234@lhp.example> Message-ID: <20230111T210843Z.1234@lhp.example>
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="enveloped-data" smime-type="enveloped-data"
MIME-Version: 1.0 MIME-Version: 1.0
Note that the Subject Header Field has been obscured appropriately by Note that the Subject Header Field has been obscured appropriately by
hcp_baseline. The output of the CMS enveloping operation is hcp_baseline. The output of the CMS enveloping operation is base64
base64-encoded and forms the body of the message. encoded and forms the body of the message.
D.2. Composing a Reply D.2. Composing a Reply
Next we consider a typical MUA reply interface, where we see Alice Next, we consider a typical MUA reply interface, where we see Alice
replying to Bob's message from Appendix D.1. replying to Bob's message from Appendix D.1.
When Alice clicks "Reply" to Bob's signed-and-encrypted message with When Alice clicks "Reply" to Bob's signed-and-encrypted message with
Header Protection, she might see something like this: Header Protection, she might see something like this:
.--------------------------------------------------------. .--------------------------------------------------------.
| Replying to Bob ("Handling the Jones Contract") .----. | | Replying to Bob ("Handling the Jones Contract") .----. |
| +-----------------------------------+ | Send | | | +-----------------------------------+ | Send | |
| To: | Bob <bob@example.net> | '----' | | To: | Bob <bob@example.net> | '----' |
| +-----------------------------------+---------+ | | +-----------------------------------+---------+ |
skipping to change at page 251, line 42 skipping to change at line 11681
| > -- | | > -- |
| > Bob Gonzalez | | > Bob Gonzalez |
| > ACME, Inc. | | > ACME, Inc. |
| | | |
| -- | | -- |
| Alice Jenkins | | Alice Jenkins |
| ACME, Inc. | | ACME, Inc. |
| | | |
+----------------------------------------------------------+ +----------------------------------------------------------+
Figure 2: Example Message Reply Interface (unedited) Figure 2: Example Message Reply Interface (Unedited)
Note that because Alice's MUA is aware of Header Protection, it knows Note that because Alice's MUA is aware of Header Protection, it knows
what the correct Subject header is, even though it was obscured. It what the correct Subject header is, even though it was obscured. It
also knows to avoid including the Legacy Display Element in the also knows to avoid including the Legacy Display Element in the
quoted/attributed text that it includes in the draft reply. quoted/attributed text that it includes in the draft reply.
Once Alice has edited the reply message, it might look something like Once Alice has edited the reply message, it might look something like
this: this:
.--------------------------------------------------------. .--------------------------------------------------------.
skipping to change at page 252, line 29 skipping to change at line 11715
| | | |
| Regards, | | Regards, |
| Alice | | Alice |
| | | |
| -- | | -- |
| Alice Jenkins | | Alice Jenkins |
| ACME, Inc. | | ACME, Inc. |
| | | |
+----------------------------------------------------------+ +----------------------------------------------------------+
Figure 3: Example Message Reply Interface (edited) Figure 3: Example Message Reply Interface (Edited)
When Alice clicks "Send", the MUA generates values for Message-ID, When Alice clicks "Send", the MUA generates values for the Message-
From, and Date Header Fields, populates the In-Reply-To, and ID, From, and Date Header Fields, populates the In-Reply-To and
References Header Fields, and also converts the reply body into the References Header Fields, and also converts the reply body into the
appropriate format. appropriate format.
D.2.1. Unprotected message D.2.1. Unprotected Message
The resulting message would look something like this if it were to be The resulting message would look something like this if it were to be
sent without any cryptographic protections: sent without any cryptographic protections:
Date: Wed, 11 Jan 2023 16:48:22 -0500 Date: Wed, 11 Jan 2023 16:48:22 -0500
From: Alice <alice@example.net> From: Alice <alice@example.net>
To: Bob <bob@example.net> To: Bob <bob@example.net>
Subject: Re: Handling the Jones contract Subject: Re: Handling the Jones contract
Message-ID: <20230111T214822Z.5678@lhp.example> Message-ID: <20230111T214822Z.5678@lhp.example>
In-Reply-To: <20230111T210843Z.1234@lhp.example> In-Reply-To: <20230111T210843Z.1234@lhp.example>
skipping to change at page 253, line 29 skipping to change at line 11751
I'll get right on it, Bob! I'll get right on it, Bob!
Regards, Regards,
Alice Alice
-- --
Alice Jenkins Alice Jenkins
ACME, Inc. ACME, Inc.
Of course, this would leak not only the contents of Alice's message, 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 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 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. create a signed-and-encrypted message to submit to the network.
D.2.2. Encrypted with hcp_no_confidentiality and Legacy Display D.2.2. Encrypted with hcp_no_confidentiality and Legacy Display
This example assumes that Alice's MUA uses hcp_no_confidentiality, This example assumes that Alice's MUA uses hcp_no_confidentiality,
not hcp_baseline. That is, by default, it does not obscure or remove not hcp_baseline. That is, by default, it does not obscure or remove
any Header Fields, even when encrypting. any Header Fields, even when encrypting.
However, it follows the guidance in Section 6.1, and will make use of However, it follows the guidance in Section 6.1 and will make use of
the HP-Outer field in the Cryptographic Payload of Bob's original the HP-Outer field in the Cryptographic Payload of Bob's original
message (Appendix D.1.2.1) to determine what to obscure. message (Appendix D.1.2.1) to determine what to obscure.
When crafting the Cryptographic Payload, its baseline HCP When crafting the Cryptographic Payload, its baseline HCP
(hcp_no_confidentiality) leaves each field untouched. To uphold the (hcp_no_confidentiality) leaves each field untouched. To uphold the
confidentiality of the sender's values when replying, the MUA confidentiality of the sender's values when replying, the MUA
executes the following steps (for brevity only Subject and Message- executes the following steps (for brevity, only Subject and Message-
ID/In-Reply-To are shown): ID/In-Reply-To are shown):
* Extract the referenced header fields (see Section 4.2): * Extract the referenced Header Fields (see Section 4.2):
- refouter contains: - refouter contains:
o Date: Wed, 11 Jan 2023 16:08:43 -0500 o Date: Wed, 11 Jan 2023 16:08:43 -0500
o From: Bob <bob@example.net> o From: Bob <bob@example.net>
o To: Alice <alice@example.net> o To: Alice <alice@example.net>
o Subject: [...] o Subject: [...]
skipping to change at page 255, line 12 skipping to change at line 11831
o References: <20230111T210843Z.1234@lhp.example> o References: <20230111T210843Z.1234@lhp.example>
* Compute the ephemeral response_hcp (see Section 6.1): * Compute the ephemeral response_hcp (see Section 6.1):
- Note that all headers except Subject are the same. - Note that all headers except Subject are the same.
- confmap contains only ("Subject", "Re: Handling the Jones - confmap contains only ("Subject", "Re: Handling the Jones
contract") -> "Re: [...]" contract") -> "Re: [...]"
Thus all Header Fields that were signed are passed through untouched. Thus, all Header Fields that were signed are passed through
The reply's Subject is obscured as Subject: Re: [...] if and only if untouched. The reply's Subject is obscured as Subject: Re: [...] if
the user does not edit the subject line from that initially proposed and only if the user does not edit the Subject line from that
by the MUA's reply interface. If the user edits the subject line, initially proposed by the MUA's reply interface. If the user edits
e.g., to Subject: Re: Handling the Jones contract ASAP, the the Subject line, e.g., to Subject: Re: Handling the Jones contract
response_hcp will _not_ obscure it, and instead pass it through in ASAP, the response_hcp will _not_ obscure it and instead pass it
the clear. through in the clear.
For stronger header confidentiality, the replying MUA should use a For stronger header confidentiality, the replying MUA should use a
reasonable HCP (not hcp_no_confidentiality). Also recall that the reasonable HCP (not hcp_no_confidentiality). Also recall that the
local HCP is applied first, and that response_hcp is only applied to local HCP is applied first and that response_hcp is only applied to
what is left unchanged by the local HCP. what is left unchanged by the local HCP.
D.2.2.1. Cryptographic Payload D.2.2.1. Cryptographic Payload
Consequently, the Cryptographic Payload for Alice's reply looks like Consequently, the Cryptographic Payload for Alice's reply looks like
this: this:
Date: Wed, 11 Jan 2023 16:48:22 -0500 Date: Wed, 11 Jan 2023 16:48:22 -0500
From: Alice <alice@example.net> From: Alice <alice@example.net>
To: Bob <bob@example.net> To: Bob <bob@example.net>
skipping to change at page 256, line 43 skipping to change at line 11887
Alice Alice
-- --
Alice Jenkins Alice Jenkins
ACME, Inc. ACME, Inc.
Note the following features: Note the following features:
* the hp="cipher" parameter to Content-Type * the hp="cipher" parameter to Content-Type
* the appropriate HP-Outer Header Field for Subject, * the appropriate HP-Outer Header Field for Subject
* the hp-legacy-display="1" parameter for the Content-Type * the hp-legacy-display="1" parameter for the Content-Type
* the Legacy Display Element (the simple pseudo-header and its * the Legacy Display Element (the simple pseudo-header and its
trailing newline) in the Main Body Part. trailing newline) in the Main Body Part
D.2.2.2. External Header Section D.2.2.2. External Header Section
The Cryptographic Payload from Appendix D.2.2.1 is then wrapped in The Cryptographic Payload from Appendix D.2.2.1 is then wrapped in
the appropriate Cryptographic Layers. For this example, using S/ the appropriate Cryptographic Layers. For this example using S/MIME,
MIME, it is wrapped in an application/pkcs7-mime; smime-type="signed- it is wrapped in an application/pkcs7-mime; smime-type="signed-data"
data" layer, which is in turn wrapped in an application/pkcs7-mime; layer, which is in turn wrapped in an application/pkcs7-mime; smime-
smime-type="enveloped-data" layer. type="enveloped-data" layer.
Then an external Header Section is applied to the outer MIME object, Then, an external Header Section is applied to the outer MIME object,
which looks like this: which looks like this:
Date: Wed, 11 Jan 2023 16:48:22 -0500 Date: Wed, 11 Jan 2023 16:48:22 -0500
From: Alice <alice@example.net> From: Alice <alice@example.net>
To: Bob <bob@example.net> To: Bob <bob@example.net>
Subject: Re: [...] Subject: Re: [...]
Message-ID: <20230111T214822Z.5678@lhp.example> Message-ID: <20230111T214822Z.5678@lhp.example>
In-Reply-To: <20230111T210843Z.1234@lhp.example> In-Reply-To: <20230111T210843Z.1234@lhp.example>
References: <20230111T210843Z.1234@lhp.example> References: <20230111T210843Z.1234@lhp.example>
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-mime; name="smime.p7m"; Content-Type: application/pkcs7-mime; name="smime.p7m";
smime-type="enveloped-data" smime-type="enveloped-data"
MIME-Version: 1.0 MIME-Version: 1.0
Note that the Subject Header Field has been obscured appropriately Note that the Subject Header Field has been obscured appropriately
even though hcp_no_confidentiality would not have touched it by even though hcp_no_confidentiality would not have touched it by
default. The output of the CMS enveloping operation is default. The output of the CMS enveloping operation is base64
base64-encoded and forms the body of the message. encoded and forms the body of the message.
Appendix E. Rendering Examples Appendix E. Rendering Examples
This section offers example Cryptographic Payloads (the content This section offers example Cryptographic Payloads (the content
within the Cryptographic Envelope) that contain Legacy Display within the Cryptographic Envelope) that contain Legacy Display
Elements. Elements.
E.1. Example text/plain Cryptographic Payload with Legacy Display E.1. Example text/plain Cryptographic Payload with Legacy Display
Elements Elements
skipping to change at page 260, line 10 skipping to change at line 12020
Subject: Dinner plans Subject: Dinner plans
Let's meet at Rama's Roti Shop at 8pm and go to the park Let's meet at Rama's Roti Shop at 8pm and go to the park
from there. from there.
Appendix F. Other Header Protection Schemes Appendix F. Other Header Protection Schemes
Other Header Protection schemes have been proposed in the past. Other Header Protection schemes have been proposed in the past.
However, those typically have drawbacks such as sparse However, those typically have drawbacks such as sparse
implementation, known problems with legacy interoperability (in implementation, known problems with legacy interoperability (in
particular with rendering), lack of clear signalling of sender particular with rendering), lack of clear signaling of sender intent,
intent, and/or incomplete cryptographic protections. This section and/or incomplete cryptographic protections. This section lists such
lists such schemes known at the time of the publication of this schemes known at the time of the publication of this document out of
document out of historical interest. historical interest.
F.1. Original RFC 8551 Header Protection F.1. Original RFC 8551 Header Protection
S/MIME [RFC8551] (as well as its predecessors [RFC5751] and S/MIME [RFC8551] (as well as its predecessors [RFC5751] and
[RFC3851]) defined a form of cryptographic Header Protection that has [RFC3851]) defined a form of cryptographic Header Protection that has
never reached wide adoption, and has significant drawbacks compared never reached wide adoption and has significant drawbacks compared to
to the mechanism in this draft. See Section 1.1.1 for more the mechanism in this document. See Section 1.1.1 for more
discussion of the differences and Section 4.10 for guidance on how to discussion of the differences and Section 4.10 for guidance on how to
handle such a message. handle such a message.
F.2. Pretty Easy Privacy (pEp) F.2. Pretty Easy Privacy (pEp)
The pEp (pretty Easy privacy) [I-D.pep-general] project specifies two The pretty Easy privacy (pEp) [PEP-GENERAL] project specifies two
different MIME schemes that include Header Protection for Signed-and- different MIME schemes that include Header Protection for Signed-and-
Encrypted e-mail messages in [I-D.pep-email]: One scheme -- referred Encrypted email messages in [PEP-EMAIL]: One scheme -- referred as
as pEp Email Format 1 (PEF-1) -- is generated towards MUAs not known pEp Email Format 1 (PEF-1) -- is generated towards MUAs not known to
to be pEp-capable, while the other scheme -- referred as PEF-2 -- is be pEp-capable, while the other scheme -- referred as PEF-2 -- is
used between MUAs discovered to be compatible with pEp. Signed-only used between MUAs discovered to be compatible with pEp. Signed-only
messages are not recommended in pEp. messages are not recommended in pEp.
Although the PEF-2 scheme is only meant to be used between PEF-2 Although the PEF-2 scheme is only meant to be used between PEF-
compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 2-compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2
(in which case they typically render badly). This is due to (in which case, they typically render badly). This is due to
signalling mechanism limitations. signaling mechanism limitations.
As the PEF-2 scheme is an enhanced variant of the RFC8551HP scheme As the PEF-2 scheme is an enhanced variant of the RFC8551HP scheme
(with an additional MIME Layer), it is similar to the RFC8551HP (with an additional MIME Layer), it is similar to the RFC8551HP
scheme (see Section 4.10). The basic PEF-2 MIME structure looks as scheme (see Section 4.10). The basic PEF-2 MIME structure looks as
follows: follows:
A └┬╴multipart/encrypted [Outer Message] A └┬╴multipart/encrypted [Outer Message]
B ├─╴application/pgp-encrypted B ├─╴application/pgp-encrypted
C └─╴application/octet-stream inline [Cryptographic Payload] C └─╴application/octet-stream inline [Cryptographic Payload]
D ↧ (decrypts to) D ↧ (decrypts to)
skipping to change at page 261, line 4 skipping to change at line 12063
A └┬╴multipart/encrypted [Outer Message] A └┬╴multipart/encrypted [Outer Message]
B ├─╴application/pgp-encrypted B ├─╴application/pgp-encrypted
C └─╴application/octet-stream inline [Cryptographic Payload] C └─╴application/octet-stream inline [Cryptographic Payload]
D ↧ (decrypts to) D ↧ (decrypts to)
E └┬╴multipart/mixed E └┬╴multipart/mixed
F ├─╴text/plain F ├─╴text/plain
G ├┬╴message/rfc822 G ├┬╴message/rfc822
H │└─╴[Inner Message] H │└─╴[Inner Message]
I └─╴application/pgp-keys I └─╴application/pgp-keys
The MIME structure at part H contains the Inner Message to be The MIME structure at part H contains the Inner Message to be
rendered to the user. rendered to the user.
It is possible for a normal MUA to accidentally produce a message It is possible for a normal MUA to accidentally produce a message
that happens to have the same MIME structure as used for PEF-2 that happens to have the same MIME structure as used for PEF-2
messages. Therefore, a PEF-2 message cannot be identified by MIME messages. Therefore, a PEF-2 message cannot be identified by the
structure alone. MIME structure alone.
The lack of a mechanism comparable to HP-Outer (see Section 2.2) The lack of a mechanism comparable to HP-Outer (see Section 2.2)
makes it impossible for the recipient of a PEF-2 message to safely makes it impossible for the recipient of a PEF-2 message to safely
determine which Header Fields are confidential or not, while determine which Header Fields are confidential or not while
forwarding or replying to a message (see Section 6). forwarding or replying to a message (see Section 6).
Note: As this document is not normative for PEF-2 messages, it does Note: As this document is not normative for PEF-2 messages, it does
not provide any guidance for handling them. Please see not provide any guidance for handling them. Please see [PEP-EMAIL]
[I-D.pep-email] for more guidance. for more guidance.
F.3. "draft-autocrypt" Protected Headers F.3. Protected Email Headers
[I-D.autocrypt-lamps-protected-headers] describes a scheme similar to [PROTECTED-HEADERS] describes a scheme similar to the Header
the Header Protection scheme specified in this document. However, Protection scheme specified in this document. However, instead of
instead of adding Legacy Display Elements to existing MIME parts (see adding Legacy Display Elements to existing MIME parts (see
Section 5.2.2), "draft-autocrypt" injects a new MIME element "Legacy Section 5.2.2), [PROTECTED-HEADERS] suggests injecting a new MIME
Display Part", thus modifying the MIME structure of the Cryptographic element "Legacy Display Part", thus modifying the MIME structure of
Payload. These modified Cryptographic Payloads cause significant the Cryptographic Payload. These modified Cryptographic Payloads
rendering problems on some common Legacy MUAs. cause significant rendering problems on some common Legacy MUAs.
The lack of a mechanism comparable to hp="cipher" and hp="clear" (see The lack of a mechanism comparable to hp="cipher" and hp="clear" (see
Section 2.1.1) means the recipient of an encrypted "draft-autocrypt" Section 2.1.1) means the recipient of an encrypted message as
message cannot be cryptographically certain whether the sender described in [PROTECTED-HEADERS] cannot be cryptographically certain
intended for the message to be confidential or not. The lack of a whether the sender intended for the message to be confidential or
mechanism comparable to HP-Outer (see Section 2.2) makes it not. The lack of a mechanism comparable to HP-Outer (see
impossible for the recipient of an encrypted "draft-autocrypt" to Section 2.2) makes it impossible for the recipient of an encrypted
safely determine which Header Fields are confidential or not, while message as described in [PROTECTED-HEADERS] to safely determine which
forwarding or replying to a message (see Section 6). Header Fields are confidential or not while forwarding or replying to
a message (see Section 6).
Appendix G. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]]
* draft-ietf-lamps-header-protection-25
- Address editorial clarifications from IESG review
- Update acknowledgements
* draft-ietf-lamps-header-protection-24
- Deal with From spoofing risk: when inner and outer From differ
with no valid signature, render outer From and warn
- Add test vectors to show historical 8551HP variants
- clarify PEF-2 and draft-autocrypt commentary
* draft-ietf-lamps-header-protection-23
- normalize on "signed-and-encrypted" across the document
- replace hcp_strong with hcp_shy
- Remove "Wrapped Message" scheme
- Rename "Injected Headers" to "Header Protection"
- Add guidance about From Header Field spoofing risk
- offer guidance on handling RFC8551HP messages when received
* draft-ietf-lamps-header-protection-22
- Reorganize document for better readability.
- Add more details about problems with draft-autocrypt.
- Rename hcp_minimal to hcp_baseline: in addition to obscuring
Subject, it now removes other Informational Header Fields
Comments and Keywords.
- Add an example message up front for easier explainability.
- Unwrap sample message test vectors.
- Name pseudocode algorithms, number steps.
- Reply guidance also applies to forwarded messages.
- hcp_strong: stop rewriting Message-Id.
* draft-ietf-lamps-header-protection-21
- HP-Outer mechanism replaces HP-Removed and HP-Obscured. This
enables the recipient to easily calculate the sender's actions
around header confidentiality.
- Replace Content-Type parameter protected-headers= with hp= and
hp-scheme=. The presence of hp= indicates that the sender used
Header Protection according to this document, and the value
indicates whether the sender tried to encrypt and sign the
message or just sign it. hp-scheme="wrapped" advises the
recipient that they should look for the protected Header Fields
in subtly different place.
- Provide a clear algorithm for reasonably safe handling of
confidential headers during Reply and Forward operations.
- Do not register the example HCP hcp_hide_cc, rename to
hcp_example_hide_cc
- Rename hcp_null to hcp_no_confidentiality
- Provide a clear algorithm for the recipient to compute the
protection state of each Header Field.
* draft-ietf-lamps-header-protection-20
- clarify IANA guidance about registration policy and designated
expert review
- emphasize that Content-Type parameter hp-legacy-display=1
belongs on all main body parts with a legacy display element
- clean up/normalize pseudocode variable names and text (no
algorithm changes)
* draft-ietf-lamps-header-protection-19
- improve text, capitalize defined terms, fix typos
- Clean up from AD review:
- updates RFC 8551 explicitly
- add "Legacy Signed Message" and "Ordinary User" explicitly to
terms
- tighten up SHOULDs/MUSTs for conformant MUAs
- expand references to other relevant Security Considerations
- drop nudge about non-existent Content-Type Parameters registry
- clarify IANA notes to align with table columns
- explicitly request HCP registry
- add references to other header protections schemes, but move
all of them to appendix
* draft-ietf-lamps-header-protection-18
- only allow US-ASCII as modified output of HCP, adjusted ABNF to
match
* draft-ietf-lamps-header-protection-17
- More edits from WGLC:
- clean up definition of "Header Field"
- note leakage of encrypted recipient hints
- clarify explanation of LDE generation
- clarify how some obscured headers might not actually be private
* draft-ietf-lamps-header-protection-16
- correct variable names in message composition algorithms
- make text more readable
* draft-ietf-lamps-header-protection-15
- include clarifications, typos, etc from comments received
during WGLC
* draft-ietf-lamps-header-protection-14
- provide section references for draft-ietf-lamps-e2e-mail-
guidance
- encouarge a future IANA named HCP registry if HCP development
takes off
* draft-ietf-lamps-header-protection-13
- Retitle from "Header Protection for S/MIME" to "Header
Protection for Cryptographically Protected E-mail"
* draft-ietf-lamps-header-protection-12
- MUST produce HP-Obscured and HP-Removed when generating
encrypted messages with non-null HCP
- Wrapped Message: move from forwarded=no to protected-
headers=wrapped
- Wrapped Message: recommend Content-Disposition: inline
* draft-ietf-lamps-header-protection-11
- Remove most of the Bcc text (transferred general discussion to
e2e-mail-guidance)
- Fix bug in algorithm for generating HP-Obscured and HP-Removed
- More detail about handling Reply messages
- Considerations around handling risky Legacy Display Elements
- Narrative descriptions of some worked examples
- Describe potential leaks to recipients
- Clarify debugging/troubleshooting UX affordances
* draft-ietf-lamps-header-protection-10
- Clarify that HCP doesn't apply to Structural Header Fields
- Drop out-of-date "Open Issues" section
- Brief commentary on UI of messages with intermediate/mixed
protections
- Deprecation prospects for messages without protected headers
- Describe generating replies to encrypted messages with stronger
HCP
* draft-ietf-lamps-header-protection-09
- clarify terminology
- add privacy and security considerations
- clarify HCP examples and baselines
- recommend hcp_minimal as default HCP
- add HP-Obscured and HP-Removed (avoids reasoning about
differences between outside and inside the Cryptographic
Envelope)
- regenerated test vectors
* draft-ietf-lamps-header-protection-08
- MUST compose injected headers, MAY compose wrapped messages
- MUST parse both schemes
- cleanup and restructure document
* draft-ietf-lamps-header-protection-07
- move from legacy display MIME part to legacy display elements
within main body part
* draft-ietf-lamps-header-protection-06
- document observed problems with legacy MUAs
- avoid duplicated outer Message-IDs in hcp_strong test vectors
* draft-ietf-lamps-header-protection-05
- fix multipart/signed wrapped test vectors
* draft-ietf-lamps-header-protection-04
- add test vectors
- add "problems with Injected Messages" subsection
* draft-ietf-lamps-header-protection-03
- dkg takes over from Bernie as primary author
- Add Usability section
- describe two distinct formats "Wrapped Message" and "Injected
Headers"
- Introduce Header Confidentiality Policy model
- Overhaul message composition guidance
- Simplify document creation workflow, move public face to gitlab
* draft-ietf-lamps-header-protection-02
- editorial changes / improve language
* draft-ietf-lamps-header-protection-01
- Add DKG as co-author
- Partial Rewrite of Abstract and Introduction [HB/AM/DKG]
- Adding definitions for Cryptographic Layer, Cryptographic
Payload, and Cryptographic Envelope (reference to
[I-D.ietf-lamps-e2e-mail-guidance]) [DKG]
- Enhanced MITM Definition to include Machine- / Meddler-in-the-
middle [HB]
- Relaxed definition of Original message, which may not be of
type "message/rfc822" [HB]
- Move "memory hole" option to the Appendix (on request by Chair
to only maintain one option in the specification) [HB]
- Updated Scope of Protection Levels according to WG discussion
during IETF-108 [HB]
- Obfuscation recommendation only for Subject and Message-Id and Acknowledgements
distinguish between Encrypted and Unencrypted Messages [HB]
- Removed (commented out) Header Field Flow Figure (it appeared Alexander Krotov identified the risk of From address spoofing (see
to be confusing as is was) [HB] Section 10.1) and helped provide guidance to MUAs.
* draft-ietf-lamps-header-protection-00 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.
- Initial version (text partially taken over from draft-ietf- Additionally, the authors would like to thank the following people
lamps-header-protection-requirements 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, Rohan Mahy, Roman Danyliw, Russ Housley, Sofia
Balicka, Steve Kille, Volker Birk, Warren Kumari, and Wei Chuang.
Index Index
C H R C H R
C C
Compose Table 6 Compose Table 5
ComposeNoHeaderProtection Table 6 ComposeNoHeaderProtection Table 5
H H
HCP Section 1.7, Paragraph 2.12.1; Section 3, Paragraph 2; HCP Section 1.7; Section 1.7; Section 3, Paragraph 2;
Section 3, Paragraph 5; Section 3.1, Paragraph 3; Section 3, Paragraph 5; Section 3.1, Paragraph 3;
Section 3.1, Paragraph 9; Section 3.1.1, Paragraph 1; Section 3.1, Paragraph 9; Section 3.1.1, Paragraph 1;
Section 3.2, Paragraph 2; Section 3.2, Paragraph 3; Section 3.2, Paragraph 2; Section 3.2, Paragraph 3;
Section 3.2.1, Paragraph 3; Section 3.2.2, Paragraph 1; Section 3.2.1, Paragraph 3; Section 3.2.2, Paragraph 1;
Section 3.2.2, Paragraph 4; Section 3.3, Paragraph 1; Section 3.2.2, Paragraph 4; Section 3.3, Paragraph 1;
Section 3.4.1, Paragraph 1; Section 3.4.2, Paragraph 1; Section 3.4.1, Paragraph 1; Section 3.4.2, Paragraph 1;
Section 3.4.2, Paragraph 2.1.1; Section 3.4.2, Paragraph Section 3.4.2, Paragraph 2.1.1; Section 3.4.2, Paragraph
2.3.1; Section 3.4.2, Paragraph 2.4.1; Section 3.4.2, 2.3.1; Section 3.4.2, Paragraph 2.4.1; Section 3.4.2,
Paragraph 3; Section 4.8.2, Paragraph 3; Section 5.2.1, Paragraph 3; Section 4.8.2, Paragraph 3; Section 5.2.1,
Paragraph 4.5.2.2.2.1.1; Section 6.1, Paragraph 5; Paragraph 4.5.2.2.2.1.1; Section 6.1, Paragraph 5;
Section 6.1, Paragraph 7; Section 6.1.1, Paragraph 7.8.1; Section 6.1, Paragraph 7; Section 6.1.1, Paragraph 7.8.1;
Section 6.1.1, Paragraph 8; Section 8.2, Paragraph 1; Section 6.1.1, Paragraph 8; Section 8.2, Paragraph 1;
Section 8.2, Paragraph 4; Section 8.2, Paragraph 5; Section 8.2, Paragraph 4; Section 8.2, Paragraph 5;
Section 8.2, Paragraph 6; Section 9.2, Paragraph 2; Section 8.2, Paragraph 6; Section 9.2, Paragraph 2;
Section 9.2, Paragraph 3; Section 11.2, Paragraph 1; Section 9.2, Paragraph 3; Section 11.2, Paragraph 1;
Section 11.2.1, Paragraph 1; Section 11.2.3, Paragraph 1; Section 11.2.1, Paragraph 1; Section 11.2.3, Paragraph 1;
Section 11.2.3, Paragraph 2; Section 11.3, Paragraph 2; Section 11.2.3, Paragraph 2; Section 11.3, Paragraph 2;
Section 11.4, Paragraph 2; Section 12, Paragraph 1; Table 6; Section 11.4, Paragraph 2; Section 12, Paragraph 1; Table 5;
Appendix D.1.2, Paragraph 1; Appendix D.2.2, Paragraph 3; Appendix D.1.2, Paragraph 1; Appendix D.2.2, Paragraph 3;
Appendix D.2.2, Paragraph 6; Appendix G, Paragraph Appendix D.2.2, Paragraph 6
2.5.2.4.1; Appendix G, Paragraph 2.7.2.9.1; Appendix G,
Paragraph 2.8.2.1.1; Appendix G, Paragraph 2.12.2.2.1;
Appendix G, Paragraph 2.14.2.1.1; Appendix G, Paragraph
2.16.2.1.1; Appendix G, Paragraph 2.16.2.5.1; Appendix G,
Paragraph 2.17.2.3.1; Appendix G, Paragraph 2.17.2.4.1
Header Confidentiality Policy Section 1.2, Paragraph 4; Header Confidentiality Policy Section 1.2, Paragraph 4;
Section 1.7, Paragraph 2.12.1; Section 3, Paragraph 2; Section 1.7; Section 3, Paragraph 2; Section 3.1, Paragraph
Section 3.1, Paragraph 1; Section 3.2.1, Paragraph 1; 1; Section 3.2.1, Paragraph 1; Section 3.2.2, Paragraph 1;
Section 3.2.2, Paragraph 1; Section 3.3, Paragraph 1; Section 3.3, Paragraph 1; Section 3.4, Paragraph 1;
Section 3.4, Paragraph 1; Section 3.4.1, Paragraph 2; Section 3.4.1, Paragraph 2; Section 3.4.2, Paragraph 1;
Section 3.4.2, Paragraph 1; Section 4, Paragraph 5.4.1; Section 4, Paragraph 5.4.1; Section 5.2, Paragraph 2.2.1;
Section 5.2, Paragraph 2.2.1; Section 6.1, Paragraph 5; Section 6.1, Paragraph 5; Section 6.1, Paragraph 7;
Section 6.1, Paragraph 7; Section 6.1.1, Paragraph 3; Section 6.1.1, Paragraph 3; Section 8.2, Paragraph 1;
Section 8.2, Paragraph 1; Section 9.2, Paragraph 1; Section 9.2, Paragraph 1; Section 11.2.1, Paragraph 3;
Section 11.2.1, Paragraph 3; Section 12.3, Paragraph 5.1.1; Section 12.3; Appendix C.2, Paragraph 1; Appendix C.3.1,
Appendix C.2, Paragraph 1; Appendix C.3.1, Paragraph 1; Paragraph 1; Appendix C.3.2, Paragraph 1; Appendix C.3.3,
Appendix C.3.2, Paragraph 1; Appendix C.3.3, Paragraph 1; Paragraph 1; Appendix C.3.4, Paragraph 1; Appendix C.3.5,
Appendix C.3.4, Paragraph 1; Appendix C.3.5, Paragraph 1; Paragraph 1; Appendix C.3.6, Paragraph 1; Appendix C.3.7,
Appendix C.3.6, Paragraph 1; Appendix C.3.7, Paragraph 1; Paragraph 1; Appendix C.3.8, Paragraph 1; Appendix C.3.9,
Appendix C.3.8, Paragraph 1; Appendix C.3.9, Paragraph 1; Paragraph 1; Appendix C.3.10, Paragraph 1; Appendix C.3.11,
Appendix C.3.10, Paragraph 1; Appendix C.3.11, Paragraph 1; Paragraph 1; Appendix C.3.12, Paragraph 1; Appendix C.3.13,
Appendix C.3.12, Paragraph 1; Appendix C.3.13, Paragraph 1; Paragraph 1; Appendix C.3.14, Paragraph 1; Appendix C.3.15,
Appendix C.3.14, Paragraph 1; Appendix C.3.15, Paragraph 1; Paragraph 1; Appendix C.3.16, Paragraph 1; Appendix C.3.17,
Appendix C.3.16, Paragraph 1; Appendix C.3.17, Paragraph 1; Paragraph 1
Appendix G, Paragraph 2.23.2.4.1 HeaderFieldProtection Section 4.10.2, Paragraph 2.2.1; Table 5
HeaderFieldProtection Section 4.10.2, Paragraph 2.2.1; Table 6
HeaderSetsFromMessage Section 4.3.1, Paragraph 4.2.1; HeaderSetsFromMessage Section 4.3.1, Paragraph 4.2.1;
Section 4.10.2, Paragraph 2.2.1; Section 4.10.2, Paragraph Section 4.10.2, Paragraph 2.2.1; Section 4.10.2, Paragraph
2.4.1; Table 6 2.4.1; Table 5
R R
ReferenceHCP Table 6 ReferenceHCP Table 5
RFC8551HP Section 1.1, Paragraph 1; Section 1.1, Paragraph 2; RFC8551HP Section 1.1, Paragraph 1; Section 1.1, Paragraph 2;
Section 1.1.1, Paragraph 1; Section 1.1.1, Paragraph 2; Section 1.1.1, Paragraph 1; Section 1.1.1, Paragraph 2;
Section 1.1.1, Paragraph 5; Section 1.1.1, Paragraph 7; Section 1.1.1, Paragraph 5; Section 1.1.1, Paragraph 7;
Section 1.1.1, Paragraph 8; Section 4.10, Paragraph 1; Section 1.1.1, Paragraph 8; Section 4.10, Paragraph 1;
Section 4.10, Paragraph 2; Section 4.10.1, Paragraph 1; Section 4.10, Paragraph 2; Section 4.10.1, Paragraph 1;
Section 4.10.1, Paragraph 3; Section 4.10.1, Paragraph 5; Section 4.10.1, Paragraph 3; Section 4.10.1, Paragraph 5;
Section 4.10.2, Paragraph 1; Section 4.10.2, Paragraph Section 4.10.2, Paragraph 1; Section 4.10.2, Paragraph
2.1.1; Appendix C.2.5, Paragraph 1; Appendix C.2.6, 2.1.1; Appendix C.2.5, Paragraph 1; Appendix C.2.6,
Paragraph 1; Appendix C.3.17, Paragraph 1; Appendix F.2, Paragraph 1; Appendix C.3.17, Paragraph 1; Appendix F.2,
Paragraph 3; Appendix G, Paragraph 2.3.2.6.1 Paragraph 3
Authors' Addresses Authors' Addresses
Daniel Kahn Gillmor Daniel Kahn Gillmor
American Civil Liberties Union American Civil Liberties Union
125 Broad St. 125 Broad St.
New York, NY, 10004 New York, NY 10004
United States of America United States of America
Email: dkg@fifthhorseman.net Email: dkg@fifthhorseman.net
Bernie Hoeneisen Bernie Hoeneisen
pEp Project pEp Project
Oberer Graben 4 Oberer Graben 4
CH- 8400 Winterthur CH- 8400 Winterthur
Switzerland Switzerland
Email: bernie@ietf.hoeneisen.ch Email: bernie@ietf.hoeneisen.ch
URI: https://pep-project.org/ URI: https://pep-project.org/
 End of changes. 542 change blocks. 
1517 lines changed or deleted 1169 lines changed or added

This html diff was produced by rfcdiff 1.48.