Internet-Draft | Cryptographic MIME Header Protection | September 2023 |
Gillmor, et al. | Expires 16 March 2024 | [Page] |
S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message.¶
This document updates the S/MIME specification to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. The header protection schemes described here are also applicable to messages with PGP/MIME cryptographic protections. Furthermore, this document offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers.¶
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.¶
This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 16 March 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Privacy and security issues regarding e-mail Header Protection in S/MIME and PGP/MIME have been identified for some time. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. For example, lack of header protection allows an attacker to substitute the message subject and/or author.¶
This document describes two different schemes for how message headers can be cryptographically protected, and provides guidance for implementers of MUAs that generate and interpret such messages. It uses the term "legacy MUA" to refer to a MUA that does not implement either scheme. This document takes particular care to ensure that messages interact reasonably well with legacy MUAs.¶
This document addresses two different schemes for cryptographically protecting e-mail header sections or fields and provides guidance to implementers. One scheme ("Injected Headers") is more interoperable with legacy clients, and is mandatory to implement and interpret. The other, older scheme ("Wrapped Message") is described here to enable interpretation of archived messages.¶
The older scheme was first specified in S/MIME 3.1 and later, and involves wrapping a message/rfc822
or message/global
MIME object with a Cryptographic Envelope around the message to protect.
This document calls this scheme "Wrapped Message", and it is documented in more detail in [RFC8551].
Experience has shown that this form does not interact well with some legacy MUAs (see Section 1.2).¶
The more interoperable scheme of header protection is introduced in this document.
In this scheme, the protected header fields are placed directly on the Cryptographic Payload, without using an intervening message/*
MIME object.
This document calls this scheme "Injected Headers", and it is documented in more detail in this document, in Section 2.3.4 and Section 2.5.3.¶
Several legacy MUAs have revealed rendering issues when dealing with a message that uses the Wrapped Message header protection scheme.¶
In some cases, some mail user agents cannot render message/rfc822
message subparts at all, in violation of baseline MIME requirements as described on page 5 of [RFC2049].
This leaves all wrapped messages unreadable by any recipient using such a MUA.¶
In other cases, the user sees an attachment suggesting a forwarded e-mail message, which -- in fact -- contains the protected e-mail message that should be rendered directly. In most of these cases, the user can click on the attachment to view the protected message.¶
However, viewing the protected message as an attachment in isolation may strip it of any security indications, leaving the user unable to assess the cryptographic properties of the message. Worse, for encrypted messages, interacting with the protected message in isolation may leak contents of the cleartext, for example, if the reply is not also encrypted.¶
A legacy MUA dealing with an encrypted message that has some header fields obscured using the Injected Headers scheme will not render the obscured header fields to the user at all. A workaround "legacy display" mechanism is provided in this document, which most legacy MUAs should render to the user, albeit not in the same location that the header fields would normally be rendered.¶
Users generally do not understand the distinction between message body and message header. When an e-mail message has cryptographic protections that cover the message body, but not the header fields, several attacks become possible.¶
For example, a legacy signed message has a signature that covers the body but not the header fields. An attacker can therefore modify the header fields (including the Subject header) without invalidating the signature. Since most readers consider a message body in the context of the message's Subject header, the meaning of the message itself could change drastically (under the attacker's control) while still retaining the same cryptographic indicator of authenticity.¶
In another example, a legacy encrypted message has its body effectively hidden from an adversary that snoops on the message. But if the header fields are not also encrypted, significant information about the message (such as the message Subject) will leak to the inspecting adversary.¶
However, if the sending and receiving MUAs ensure that cryptographic protections cover the message headers as well as the message body, these attacks are defeated.¶
If the sending MUA is unwilling to generate such a fully-protected message due to the potential for rendering, usability, deliverability, or security issues, these defenses cannot be realized.¶
The sender cannot know what MUA (or MUAs) the recipient will use to handle the message. Thus, an outbound message format that is backward-compatible with as many legacy implementations as possible is a more effective vehicle for providing the whole-message cryptographic protections described above.¶
This document aims for backward compatibility with legacy clients to the extent possible. In some cases, like when a user-visible header like the Subject is cryptographically hidden, the message cannot behave entirely identically to a legacy client. But accommodations are described here that ensure a rough semantic equivalence for legacy clients even in these cases.¶
A message with perfect cryptographic protections that cannot be delivered is less useful than a message with imperfect cryptographic protections that can be delivered. Senders want their messages to reach the intended recipients.¶
Given the current state of the Internet mail ecosystem, encrypted messages in particular cannot shield all of their header fields from visibility and still be guaranteed delivery to their intended recipient.¶
This document accounts for this concern by providing a mechanism (Section 2.3.2) that prioritizes initial deliverability (at the cost of some header leakage) while facilitating future message variants that shield more header metadata from casual inspection.¶
A separate pair of protocols also provides some cryptographic protection for the e-mail message header integrity: DomainKeys Identified Mail (DKIM) [RFC6376], as used in combination with Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489]. This pair of protocols provides a domain-based reputation mechanism that can be used to mitigate some forms of unsolicited e-mail (spam).¶
However, the DKIM+DMARC suite provides cryptographic protection at a different scope than the mechanisms described here. In particular, the message integrity and authentication signals provided by DKIM+DMARC correspond to the domain name of the sending e-mail address, not the sending address itself, so the DKIM+DMARC suite does not provide end-to-end protection. DKIM and DMARC are typically applied to messages by (and interpreted by) mail transfer agents, not mail user agents. The mechanisms in this document are typically applied to messages by (and interpreted by) mail user agents.¶
Furthermore, the DKIM+DMARC suite only provides cryptographic integrity and authentication, not encryption. So cryptographic confidentiality is not available from that suite.¶
The DKIM+DMARC suite can be used on any message, including messages formed as described in this document. There should be no conflict between these schemes.¶
Though not strictly e-mail, similar protections have been in use on Usenet for signing and verification of message headers for years. See ([PGPCONTROL] and [PGPVERIFY-FORMAT] for more details. Like DKIM, these Usenet control protections offer only integrity and authentication, not encryption.¶
This document describes end-to-end cryptographic protections for e-mail messages in reference to S/MIME ([RFC8551]).¶
Comparable end-to-end cryptographic protections can also be provided by PGP/MIME ([RFC3156]).¶
The mechanisms in this document should be applicable in the PGP/MIME protections as well as S/MIME protections, but analysis and implementation in this document focuses on S/MIME.¶
To the extent that any divergence from the mechanism described here is necessary for PGP/MIME, that divergence is out of scope for this document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are defined for the scope of this document:¶
Message: An E-Mail Message consisting of Header Fields (collectively called "the Header Section of the message") followed, optionally, by a Body; see [RFC5322].¶
Note: To avoid ambiguity, this document avoids using the terms "Header" or "Headers" in isolation, but instead always uses "Header Field" to refer to the individual field and "Header Section" to refer to the entire collection.¶
message/rfc822
or message/global
MIME object.
(see Section 2.2).¶
This document describes sensible, simple behavior for a program that generates an e-mail message with standard end-to-end cryptographic protections, following the guidance in [I-D.ietf-lamps-e2e-mail-guidance]. An implementation conformant to this draft will produce messages that have cryptographic protection that covers the message's headers as well as its body.¶
This document also describes sensible, simple behavior for a program that interprets such a message, in a way that can take advantage of these protections covering the header fields as well as the body.¶
The message generation guidance aims to minimize negative interactions with any legacy receiving client while providing actionable cryptographic properties for modern receiving clients.¶
In particular, this document focuses on two standard types of cryptographic protection that cover the entire message:¶
The message composition guidance in this document (in Section 2.3.4) aims to provide minimal disruption for any legacy client that receives such a message. However, a legacy client by definition does not implement any of the guidance here. Therefore, the document does not attempt to provide guidance for legacy clients directly.¶
Furthermore, this document does not explicitly contemplate other variants of cryptographic message protections, including any of these:¶
All such messages are out of scope of this document.¶
As mentioned in Section 1.1, this document describes two ways to provide end-to-end cryptographic protection for an e-mail message that includes all header fields known to the sender at message composition time.¶
A receiving MUA MUST be able to handle both header protection schemes, as described in Section 2.5.¶
A sending MUA MUST be able to generate the Injected Headers scheme (Section 2.3.4), and MAY generate the Wrapped Message scheme (Section 2.3.5).¶
A message that uses the Injected Headers scheme has protected header fields in the header section of the Cryptographic Payload.¶
For an encrypted message that has at least one user-visible header field omitted or obscured outside of the Cryptographic Payload, those header fields MAY also be duplicated into decorative copies in the Main Body MIME part of the Cryptographic Payload itself. These decorative copies within the message are known as "legacy display elements".¶
Such a legacy display element can be useful for a legacy receiving MUA that doesn't yet understand how to interpret or display a cryptographically-protected confidential header. See Section 3.1 for more details about how the ecosystem could shift so that a sending MUA could avoid the need to generate any legacy display element.¶
Composing a message with the Injected Headers scheme is described in Section 2.3.4. Rendering such a message is described in Section 2.5.3.¶
A message that uses the Wrapped Message scheme has a Cryptographic Payload of a single message/rfc822
(or message/global
) MIME object, which itself contains the original message (including the protected header section).¶
Composing a message with the Wrapped Message scheme is described in Section 2.3.5. Rendering such a message is described in Section 2.5.4.¶
This section describes the process an MUA should use to apply cryptographic protection to an e-mail message with header protection. We start by describing the legacy message composition process as a baseline.¶
Section 5.1 of [I-D.ietf-lamps-e2e-mail-guidance] describes the typical process for a legacy crypto MUA to apply cryptographic protections to an e-mail message. That guidance and terminology is replicated here for reference:¶
origbody
: the traditional unprotected message body as a well-formed MIME tree (possibly just a single MIME leaf part).
As a well-formed MIME tree, origbody
already has structural headers (Content-*
) present.¶
origheaders
: the intended non-structural headers for the message, represented here as a list of (h,v)
pairs, where h
is a header field name and v
is the associated value.
Note that these are header fields that the MUA intends to be visible to the recipient of the message.
In particular, if the MUA uses the Bcc
header during composition, but plans to omit it from the message (see section 3.6.3 of [RFC5322]), it will not be in origheaders
.¶
crypto
: The series of cryptographic protections to apply (for example, "sign with the secret key corresponding to X.509 certificate X, then encrypt to X.509 certificates X and Y").
This is a routine that accepts a MIME tree as input (the Cryptographic Payload), wraps the input in the appropriate Cryptographic Envelope, and returns the resultant MIME tree as output.¶
The algorithm returns a MIME object that is ready to be injected into the mail system:¶
When composing an encrypted message with header protection, the composing MUA needs a Header Confidentiality Policy (HCP).
In this document, we represent that Header Confidentiality Policy as a function hcp
:¶
hcp(name, val_in) → val_out
: this function takes a non-structural header field identified by name
with initial value val_in
as arguments, and returns a replacement header value val_out
.
If val_out
is the special value null
, it mean that the header field in question should be omitted from the set of header fields visible outside the Cryptographic Envelope.¶
Note that hcp
is only applied to non-structural header fields.
When composing a message, structural header fields are dealt with separately, as described in Section 2.3.4 and Section 2.3.5.¶
As an example, an MUA that obscures the Subject
header field by replacing it with the literal string "[...]
", hides all Cc'ed recipients, and does not offer confidentiality to any other header fields would be represented as (in pseudocode):¶
hcp_example(name, val_in) → val_out: if name is 'Subject': return '[...]' else if name is 'Cc': return null else: return val_in¶
Note that such a policy is only needed when the end-to-end protections include encryption (confidentiality). No comparable policy is needed for other end-to-end cryptographic protections (integrity and authenticity), as they are simply uniformly applied so that all header fields known by the sender have these protections.¶
This asymmetry is an unfortunate consequence of complexities in message delivery systems, some of which may reject, drop, or delay messages where all header fields are removed from the top-level MIME object.¶
This document does not mandate any particular Header Confidentiality Policy, though it offers guidance for MUA implementers in selecting one in Section 2.4. Future documents may recommend or mandate such a policy for an MUA with specific needs. Such a recommendation might be motivated by descriptions of metadata-derived attacks, or stem from research about message deliverability, or describe new signalling mechanisms, but these topics are out of scope for this document.¶
This document defines 2 new header fields used for conveying the effect of sender's Header Confidentiality Policy: HP-Removed and HP-Obscured. These header fields enable the MUA receiving an encrypted message to reliably identify whether the sending MUA intended to make a header field confidential (see Section 6.2.3).¶
An implementation that composes encrypted e-mail and hides any of the header fields as described in this document (for example, due to a non-null HCP) MUST include the appropriate HP-Removed or HP-Obscured headers in the Cryptographic Payload. These two MIME header fields should only ever appear directly within the header section of the Cryptographic Payload of a Cryptographic Envelope offering confidentiality. They MUST be ignored if they appear in other places.¶
HP-Removed includes a comma separated list of header field names that were omitted from the outer header when the message with header protection was generated. The HP-Removed header field can appear at most once in the header section of a Cryptographic Payload.¶
Each instance of HP-Obscured contains a header field name and the value that this header field was modified to in the outer header. The HP-Obscured header field can appear multiple times in the header section of a Cryptographic Payload.¶
If a header field name A doesn't appear in an HP-Obscured header field value, then the header field A was either removed (and thus would appear in the HP-Removed header field) or it was copied without any modifications to the outer header.¶
Syntax of these new header fields is defined using the following ABNF [RFC5234]:¶
hp-removed = "HP-Removed:" field-name-list CRLF field-name-list = [FWS] field-name *([FWS] "," [FWS] field-name) [FWS] hp-obscured = "HP-Obscured:" [FWS] field-name ": " field-value CRLF field-value = unstructured¶
The "Injected Headers" header protection scheme places the header fields to be protected directly on the Cryptographic Payload. Unlike in the "Wrapped Scheme" (see compose-wrapped-message), there is no wrapping of the message body in any additional message/*
MIME part.
This section describes how to generate such a message.¶
To compose a message using "Injected Headers" header protection, the composing MUA needs one additional input in addition to the Header Confidentiality Policy hcp
defined in Section 2.3.2.¶
legacy
: a boolean value, indicating whether any recipient of the message is believed to have a legacy client.
If all recipients are known to implement this draft, legacy
should be set to false
.
(How a MUA determines the value of legacy
is out of scope for this document; an initial implementation can simply set it to true
)¶
Enabling visibility of obscured header fields for decryption-capable legacy clients requires transforming a header list into a readable form and including it as a decorative "Legacy Display" element in specially-marked parts of the message.
This document recommends two different 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 Body part.
This document does not recommend adding a Legacy Display element to any other part.¶
Please see Section 7.1 of [I-D.ietf-lamps-e2e-mail-guidance] for guidance on identifying the parts of a message that are a Main Body Part.¶
To build such a message, we replace the algorithm described in Section 2.3.1 with a more sophisticated approach. The the algorithm for applying "Injected Headers" cryptographic protection to a message is as follows:¶
if crypto
contains encryption, and legacy
is true
:¶
ldlist
, an empty list of (header, value)
pairs¶
For each header field name and value (h,v)
in origheaders
:¶
If h
is user-facing (see Section 1.1.2 of [I-D.ietf-lamps-e2e-mail-guidance]):¶
If ldlist
is not empty:¶
origbody
that represents the "main body" of the message.¶
For each "Main Body Part" bodypart
of type text/plain
or text/html
:¶
ldlist
into the content of bodypart
(see Section 2.3.4.1 for text/plain
and Section 2.3.4.2 for text/html
)¶
Content-Type
parameter hp-legacy-display
with value 1
to bodypart
¶
For each header field name and value (h,v)
in origheaders
:¶
h
to MIME part origbody
with value v
¶
protected-headers
parameter on the Content-Type
of origbody
to v1
¶
If crypto
contains encryption:¶
newh
¶
hpr
be an empty comma-separated list of header field names¶
For header field name and value (h,v)
in origheaders
:¶
If hpr
is not empty:¶
HP-Removed
" to MIME part origbody
with value hpr
¶
origheaders
to newh
¶
crypto
to origbody
, producing MIME tree output
¶
For each header field name and value (h,v)
in origheaders
:¶
h
to output
with value v
¶
output
¶
Note that both new parameters (hcp
and legacy
) are effectively ignored if crypto
does not contain encryption.
This is by design, because they are irrelevant for signed-only cryptographic protections.¶
For a list of obscured header fields represented as (header, value)
pairs, concatenate them as a set of lines, with one newline at the end of each pair.
Add an additional trailing newline after the resultant text, and prepend the entire list to the body of the text/plain
part.¶
For example, if the list of obscured header fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")]
, then a text/plain
part that originally contained:¶
I think we should skip the meeting.¶
Would become:¶
Subject: Thursday's meeting Cc: alice@example.net I think we should skip the meeting.¶
Adding a Legacy Display Element to a text/html
part is similar to how it is added to a text/plain
part (see Section 2.3.4.1).
Instead of adding the obscured header fields to a block of text delimited by a blank line, the composing MUA injects them in an HTML <div>
element annotated with a class
attribute of header-protection-legacy-display
.¶
The content and formatting of this decorative <div>
have no strict requirements, but they SHOULD represent all the obscured header fields in a readable fashion.
A simple approach is to assemble the text in the same way as Section 2.3.4.1, wrap it in a verbatim <pre>
element, and put that element in the annotated <div>
.¶
The annotated <div>
should be placed as close to the start of the <body>
as possible, where it will be visible when viewed with a standard HTML renderer.¶
For example, if the list of obscured header fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")]
, then a text/html
part that originally contained:¶
<html><head><title></title></head><body> <p>I think we should skip the meeting.</p> </body></html>¶
Would become:¶
<html><head><title></title></head><body> <div class="header-protection-legacy-display"> <pre>Subject: Thursday's meeting Cc: alice@example.net</pre></div> <p>I think we should skip the meeting.</p> </body></html>¶
A composing MUA MAY insert the Legacy Display Element anywhere reasonable within the message as long as it prioritizes visibility for the reader using a legacy decryption-capable MUA. This decision may take into account special message-specific HTML formatting expectations if the MUA is aware of them. However, some MUAs may not have any special insight into the user's preferred HTML formatting, and still want to insert a legacy display element. This section offers a non-normative, simple, and minimal step-by-step approach for a composing MUA that has no other information or preferences to fall back on.¶
The process below assumes that the MUA already has the full HTML object that it intends to send, including all of the text supplied by the user.¶
text/plain
(see Section 2.3.4.1).¶
<pre>
element.¶
<pre>
element in a <div>
element annotated with the class header-protection-legacy-display
.¶
<body>
element of the full HTML object.¶
<div>
element as the first child of the <body>
element.¶
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 an attached text file or a downloaded webpage.
Attached documents need to be preserved as intended in the transmission, without modification.¶
The composing MUA MUST NOT add a Legacy Display element to any part of the message that is not a main body part.
In particular, if a part is annotated with Content-Disposition: attachment
, or if it does not descend via the first child of any of its multipart/mixed
or multipart/related
ancestors, it is not a main body part, and MUST NOT be modified.¶
See Section 7.1 of [I-D.ietf-lamps-e2e-mail-guidance] for more guidance about common ways to distinguish main body parts from other MIME parts in a message.¶
The purpose of injecting a Legacy Display element into each Main Body MIME part is to enable rendering of otherwise obscured header fields in legacy clients that are capable of message decryption, but don't know how to follow the rest of the guidance in this document.¶
The authors are unaware of any legacy client that would render any MIME part type other than text/plain
and text/html
as the Main Body.
A generating MUA SHOULD NOT add a Legacy Display element to any MIME part with any other Content-Type
.¶
The Wrapped Message header protection scheme is briefly documented in Section 3.1 [RFC8551].
This section provides a more detailed explanation of how to build such a message, and augments it with the protected-headers
parameter with the value wrapped
.
It also recommends marking such a wrapped message as Content-Disposition: inline
to encourage legacy MUAs to render the inner message directly rather than treating it as an attachment.¶
To compose a message using "Wrapped Message" header protection, we use those inputs described in Section 2.3.1 plus the Header Confidentiality Policy hcp
defined in Section 2.3.2.
The new algorithm is:¶
For header field name and value (h,v)
in origheaders
:¶
h
to origbody
with value v
¶
If crypto
contains encryption:¶
newh
¶
hpr
be an empty comma-separated list of header field names¶
For header field name and value (h,v)
in origheaders
:¶
If hpr
is not empty:¶
HP-Removed
" to MIME part origbody
with value hpr
¶
If any of the header fields in origbody
, including header fields in the nested internal MIME structure, contain any 8-bit UTF-8 characters (see section section 3.7 of [RFC6532]):¶
payload
be a new MIME part with one header field: Content-Type: message/global; protected-headers=wrapped
, and whose body is origbody
.¶
Else:¶
payload
be a new MIME part with one header field: Content-Type: message/rfc822; protected-headers=wrapped
, and whose body is origbody
.¶
Content-Disposition
header field to payload
with value inline
¶
crypto
to payload
, yielding MIME tree output
¶
If crypto
contains encryption:¶
origheaders
to newh
¶
For header field name and value (h,v)
in origheaders
:¶
h
to output
with value v
¶
output
¶
Note that the Header Confidentiality Policy hcp
is ignored if crypto
does not contain encryption.
This is by design.¶
When composing a message with end-to-end cryptographic protections, an MUA SHOULD protect the header fields of that message as well as the body, using one of the formats described here.¶
A compatible MUA MUST be capable of generating a message with header protection using the Injected Headers Section 2.3.4 format.¶
An MUA SHOULD have a sensible default Header Confidentiality Policy, and SHOULD NOT require the user to select one.
At the time this document was written, a good choice for default HCP is the conservative approach described by hcp_minimal
(Section 2.4.1).¶
Any default Header Confidentiality Policy SHOULD provide confidentiality for the Subject
header field by replacing it with the literal string "[...]
".
Most users treat the Subject of a message the same way that they treat the body, and they are surprised to find that the Subject of an encrypted message is visible.¶
The most conservative recommended Header Confidentiality Policy only protects the Subject
header field:¶
hcp_minimal(name, val_in) → val_out: if name is 'Subject': return '[...]' else: return val_in¶
hcp_minimal
is the recommended default HCP for a new implementation, as it provides meaningful confidentiality protections, and is unlikely to cause deliverability or usability problems.¶
Alternately, a more aggressive (and therefore more privacy-preserving) Header Confidentiality Policy only leaks a handful of fields whose absence is known to increase rates of delivery failure, and simultaneously obscures the Message-ID
behind a random new one:¶
hcp_strong(name, val_in) → val_out: if name in ['From', 'To', 'Cc', 'Date']: return val_in else if name is 'Subject': return '[...]' else if name is 'Message-ID': return generate_new_message_id() else: return null¶
The function generate_new_message_id()
represents whatever process the MUA typically uses to generate a Message-ID
for a new outbound message.¶
hcp_strong
is known to cause usability problems with message threading for many legacy MUAs, and is not recommended as a default HCP for new implementations.¶
Legacy MUAs can be conceptualized as offering a null Header Confidentiality Policy, which offers no confidentiality protection to any header field:¶
hcp_null(name, val_in) → val_out: return val_in¶
A MUA offering header protection SHOULD NOT use hcp_null
by default.¶
A MUA MAY offer even stronger confidentiality for header fields of an encrypted message than described in Section 2.4.2.
For example, it might implement an HCP that obfuscates the From
field, or omits the Cc
field, or ensures Date
is represented in UTC
(obscuring the local timezone).¶
The authors of this document hope that implementers with deployment experience will document their chosen Header Confidentiality Policy and the rationale behind their choice.¶
This document defines hcp_null
, hcp_minimal
, hcp_example
, and hcp_strong
as a way to compare and contrast different possible behavioral choices for a composing MUA.
Since the HCP is not strictly a protocol element, there is currently no explicit registry of named Header Confidentiality Policies.
However, the first Internet Draft that attempts to define another HCP as a possible recommendation for the public should ask IANA to establish such a registry to avoid potential future namespace confusion.¶
An MUA that receives a cryptographically-protected e-mail will render it for the user.¶
The receiving MUA will render the message body, a selected subset of header fields, and (as described in Section 3 of [I-D.ietf-lamps-e2e-mail-guidance]) provide a summary of the cryptographic properties of the message.¶
Most MUAs only render a subset of header fields by default.
For example, few MUAs typically render Message-Id
or Received
header fields for the user, but most do render From
, To
, Cc
, Date
, and Subject
.¶
A MUA that knows how to handle a message with header protection makes the following two changes to its behavior when rendering a message:¶
A MUA that handles a message with header protection does not need to render any new header fields that it did not render before.¶
An incoming message can be identified as having header protection based on one of two signals:¶
Content-Type: message/rfc822
or Content-Type: message/global
and the parameter protected-headers
has a value of wrapped
.
See Section 2.5.4 for rendering guidance.¶
Content-Type
and it has parameter protected-headers
set to v1
.
See Section 2.5.3 for rendering guidance.¶
Messages of both types exist in the wild, and a compliant MUA MUST be able to handle them both. They provide the same semantics and the same meaning.¶
Regardless of whether a cryptographically-protected message has protected header fields, the cryptographic summary of the message should be modified to indicate what protections the header fields have. This field-by-field status is complex and isn't necessarily intended to be presented in full to the user. Rather, it represents the state of the message internally within the MUA, and may be used to influence behavior like replying to the message (see Section 2.5.8.1).¶
Each header field individually has exactly one the following protections:¶
unprotected
(this is the case for all header fields in messages that have no header protection)¶
signed-only
(bound into the same validated signature as the enclosing message, but also visible in transit)¶
encrypted-only
(only appears within the Cryptographic Payload; the corresponding external header field was either omitted or obfuscated)¶
signed-and-encrypted
(same as encrypted-only, but additionally is under a validated signature)¶
Note that while the message itself may be signed-and-encrypted
, some header fields may be replicated on the outside of the message (e.g. Date
).
Those header fields would be signed-only
, despite the message itself being signed-and-encrypted
.
Additionally, the data from some encrypted
or signed-and-encrypted
header fields may not be fully private (see Section 6.1 for more details).¶
Rendering the cryptographic status of each header field is likely to be complex and messy --- users may not understand it. It is beyond the scope of this document to suggest any specific graphical affordances or user experience. Future work should include examples of successful rendering of this information.¶
When the Cryptographic Payload does not have a Content-Type
of message/rfc822
or message/global
, and the parameter protected-headers
is set to v1
, the values of the protected header fields are drawn from the header fields of the Cryptographic Payload, and the body that is rendered is the Cryptographic Payload itself.¶
A └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) B └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] C ├─╴text/plain D └─╴text/html¶
The message body should be rendered the same way as this message:¶
B └┬╴multipart/alternative C ├─╴text/plain D └─╴text/html¶
It should render header fields taken from part B
.¶
Its cryptographic summary should indicate that the message was signed and all rendered header fields were included in the signature.¶
The MUA should ignore header fields from part A
for the purposes of rendering.¶
Because this message is signed-only, none of its parts will have a Legacy Display Element.¶
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
E └─╴application/pkcs7-mime; smime-type="enveloped-data" ↧ (decrypts to) F └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) G └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] H ├─╴text/plain I └─╴text/html¶
The message body should be rendered the same way as this message:¶
G └┬╴multipart/alternative H ├─╴text/plain I └─╴text/html¶
It should render header fields taken from part G
.¶
Its cryptographic summary should indicate that the message was signed and encrypted.
Each rendered header field found in G
should be considered against any HP-Removed
header field found in G
and all HP-Obscured
header fields found in G
.
If the field's name is found in the list of header field names in HP-Removed
, or if one of the HP-Obscured
fields refers to the field name, then the header field should be marked as signed-and-encrypted
.
Otherwise, the header field should be marked as signed-only
.¶
If any of the user-facing headers are removed or obscured, the composer of this message MAY place Legacy Display Elements in parts H and I.¶
The MUA should ignore header fields from part E
for the purposes of rendering.¶
As described in Section 2.1, a message with cryptographic confidentiality protection MAY include "Legacy Display" elements for backward-compatibility with legacy MUAs. These Legacy Display elements are strictly decorative, unambiguously identifiable, and will be discarded by compliant implementations.¶
The receiving MUA SHOULD avoid rendering the identified Legacy Display elements to the user at all, since it is aware of header protection and can render the actual protected header fields.¶
If a text/html
or text/plain
part within the Cryptographic Envelope is identified as containing Legacy Display elements, those elements SHOULD be hidden when rendering and SHOULD be dropped when generating a draft reply or inline forwarded message.
Whenever a Message or MIME subtree is exported, downloaded or otherwise further processed, implementers should consider whether or not to drop the Legacy Display elements.¶
A receiving MUA acting on a message that contains an encrypting Cryptographic Layer identifies a MIME subpart within the Cryptographic Payload as containing Legacy Display elements based on the Content-Type of the subpart.¶
hp-legacy-display
with value set to 1
¶
text/html
(see Section 2.5.3.3.3) or text/plain
(see Section 2.5.3.3.2)¶
Note that the term "subpart" above is used in the general sense: if the Cryptographic Payload is a single part, that part itself may contain a Legacy Display element if it is marked with the hp-legacy-display=1
parameter.¶
If a text/plain
part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1"
, it should be processed before rendering in the following fashion:¶
Note that implementing this strategy is dependent on the charset used by the MIME part.¶
See Appendix D.1 for an example.¶
If a text/html
part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1"
, it should be processed before rendering in the following fashion:¶
<body>
is a <div>
with class
attribute header-protection-legacy-display
, that entire element should be omitted.¶
This cleanup could be done, for example, as a custom rule in the MUA's HTML sanitizer, if one exists. Another implementation strategy for an HTML-capable MUA would b to add an entry to the [CSS] stylesheet for such a part:¶
body div.header-protection-legacy-display { display: none; }¶
Some MUAs may compose and send a message with end-to-end cryptographic protections that offer header protection using the Wrapped Message scheme described in Section 3.1 of [RFC8551]. This section describes how a receiving MUA should identify and render such a message.¶
When the Cryptographic Payload has Content-Type
of message/rfc822
or message/global
, and the parameter protected-headers
is set to wrapped
, the values of the protected header fields are drawn from the header fields of the Cryptographic Payload, and the body that is rendered is the body of the Cryptographic Payload.¶
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
J └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) K └┬╴message/rfc822 [Cryptographic Payload] L └┬╴multipart/alternative [Rendered Body] M ├─╴text/plain N └─╴text/html¶
The message body should be rendered the same way as this message:¶
L └┬╴multipart/alternative M ├─╴text/plain N └─╴text/html¶
It should render header fields taken from part K
.¶
Its cryptographic summary should indicate that the message was signed and all rendered header fields were included in the signature.¶
The MUA SHOULD ignore header fields from part J
for the purposes of rendering.¶
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
O └─╴application/pkcs7-mime; smime-type="enveloped-data" ↧ (decrypts to) P └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) Q └┬╴message/rfc822 [Cryptographic Payload] R └┬╴multipart/alternative [Rendered Body] S ├─╴text/plain T └─╴text/html¶
The message body should be rendered the same way as this message:¶
R └┬╴multipart/alternative S ├─╴text/plain T └─╴text/html¶
It should render header fields taken from part Q
.¶
Its cryptographic summary should indicate that the message was signed and encrypted.
As in Section 2.5.3.2, each rendered header field found in Q
should be considered against any HP-Removed
header field found in Q
and all HP-Obscured
header fields found in Q
.
If the field's name is found in the list of header field names in HP-Removed
, or if one of the HP-Obscured
fields refers to the field name, then the header field should be marked as signed-and-encrypted
.
Otherwise, the header field should be marked as signed-only
.¶
Some automated systems have a control channel that is operated by e-mail. For example, an incoming e-mail message could subscribe someone to a mailing list, initiate the purchase of a specific product, approve another message for redistribution, or adjust the state of some shared object.¶
To the extent that such a system depends on end-to-end cryptographic guarantees about the e-mail control message, header protection as described in this document should improve the system's security. This section provides some specific guidance for systems that use e-mail messages as a control channel that want to benefit from these security improvements.¶
Consider the situation where an e-mail-based control channel depends on the message's cryptographic signature and the action taken depends on some header field of the message.¶
In this case, the automated system MUST rely on information from the header field that is protected by the mechanism described in this document. It MUST NOT rely on any header field found outside the Cryptographic Payload.¶
For example, consider an administrative interface for a mailing list manager that only accepts control messages that are signed by one of its administrators.
When an inbound message for the list arrives, it is queued (waiting for administrative approval) and the system generates and listens for two distinct e-mail addresses related to the queued message -- one that approves the message, and one that rejects it.
If an administrator sends a signed control message to the approval address, the mailing list verifies that the protected To:
header field of the signed control message contains the approval address before approving the queued message for redistribution.
If the protected To:
header field does not contain that address, or there is no protected To:
header field, then the mailing list logs or reports the error, and does not act on that control message.¶
Consider the situation where an e-mail based control channel expects to receive an end-to-end encrypted message -- for example, where the control messages need confidentiality guarantees -- and where the action taken depends on the contents of some MIME part within message body.¶
In this case, the automated system that decrypts the incoming messages and scans the relevant MIME part SHOULD identify when the MIME part contains a legacy display element (see Section 2.5.3.3.1), and it SHOULD parse the relevant MIME part with the legacy display element removed.¶
For example, consider an administrative interface of a confidential issue tracking software.
An authorized user can confidentially adjust the status of a tracked issue by a specially-formatted first line of the message body (for example, severity #183 serious
).
When the user's MUA encrypts a plain text control message to this issue tracker, depending on the MUA's HCP and its choice of legacy
value, it may add a legacy display element.
If it does so, then the first line of the message body will contain a decorative copy of the confidential Subject:
header field.
The issue tracking software decrypts the incoming control message, identifies that there is a legacy display element in the part (see Section 2.5.3.3.1), strips the legacy display lines (including the first blank line), and only then parses the remaining top line to look for the expected special formatting.¶
Note that advanced users of an MUA may need access to the original message, for example to troubleshoot problems with the rendering MUA itself, or problems with the SMTP transport path taken by the message.¶
A MUA that applies these rendering guidelines SHOULD ensure that the full original source of the message as it was received remains available to such a user for debugging and troubleshooting.¶
If a troubleshooting scenario demands information about the cryptographically-protected values of headers, and the message is encrypted, the debugging interface SHOULD also provide a "source" view of the Cryptographic Payload itself, alongside the full original source of the message as received.¶
Other MUAs may have generated different structures of messages that aim to offer end-to-end cryptographic protections that include header protection.¶
While this document is not normative for those schemes, it offers guidance for how to identify and handle these other formats. In the following a list of systems that are known to generate e-mail messages with end-to-end cryptographic protections that include header protection using a different MIME scheme.¶
The pEp (pretty Easy privacy) [I-D.pep-general] project specifies MIME schemes for Signed-and-Encrypted e-mail messages that also provide header protection [I-D.pep-email]. Similar to the "Wrapped Messages" scheme described in Section 2.3.5 and Section 2.5.4, pEp e-mail messages are fully encapsulated in the Cryptographic Payload.¶
More information can be found in [I-D.pep-email].¶
When composing a reply to an encrypted message with header protection, the MUA is acting both as a receiving MUA and as a sending MUA. Special guidance applies here, as things can go wrong in at least two ways: leaking previously-confidential information, and replying to the wrong party.¶
As noted in Section 5.4 of [I-D.ietf-lamps-e2e-mail-guidance], an MUA in this position MUST NOT leak previously-encrypted content in the clear in a follow-up message. The same is true for protected header fields.¶
Values from any header field that was identified as either encrypted-only
or signed-and-encrypted
based on the steps outlined above MUST NOT be placed in cleartext output when generating a message.¶
In particular, if Subject
was encrypted, and it is copied into the draft encrypted reply, the replying MUA MUST obfuscate the unprotected (cleartext) Subject
header field as described above.¶
When crafting the headers for a reply message, the composing MUA can make use of the HP-Removed and HP-Obscured headers from within the Cryptographic Envelope of the reference message to ensure that headers derived from the reference message do not leak in the reply.¶
Consider a header field in a reply message that is generated by derivation from a header field in the reference message.
For example, the To
header field is typically derived from the reference message's Reply-To
or From
header fields.
When generating the outer copy of the header field, the composing MUA first applies its own header confidentiality policy.
If the header field's value is changed by the HCP, then it is applied to the outside header and noted in the protected header section using HP-Removed
or HP-Obscured
as appropriate, as described in Section 2.3.3.
Otherwise, if the header field's value is unchanged, the composing MUA re-generates the header field using the source header fields from the values within the Cryptographic Payload of the reference message, as modified by the HP-Obscured
or HP-Removed
headers.
If that value is itself different than the protected value, then it is applied to the outside header and noted in the protected header section using HP-Obscured
.
If the value is the same as the protected value, then it is simply copied to the outside header directly.¶
See Appendix C.2 for a simple worked example of this process.¶
When replying to a message, the Composing MUA typically decides who to send the reply to based on:¶
Reply-To
, Mail-Followup-To
, or From
header fields¶
To
or Cc
header fields (if the user chose to "reply all")¶
When a message has header protection, the replying MUA MUST populate the destination fields of the draft message using the protected header fields, and ignore any unprotected header fields.¶
This mitigates against an attack where Mallory gets a copy of an encrypted message from Alice to Bob, and then replays the message to Bob with an additional Cc
to Mallory's own e-mail address in the message's outer (unprotected) header section.¶
If Bob knows Mallory's certificate already, and he replies to such a message without following the guidance in this section, it's likely that his MUA will encrypt the cleartext of the message directly to Mallory.¶
While From
and To
and Cc
and Subject
and Date
are often explicitly rendered to the user, some header fields do affect message display, without being explicitly rendered.¶
For example, Message-Id
, References
, and In-Reply-To
header fields may collectively be used to place a message in a "thread" or series of messages.¶
In another example, Section 2.5.8.2 observes that the value of the Reply-To
field can influence the draft reply message.
So while the user may never see the Reply-To
header field directly, it is implicitly "rendered" when the user interacts with the message by replying to it.¶
An MUA that depends on any implicitly-rendered header field in a message with header protection SHOULD use the value from the protected header field, and SHOULD NOT use any value found outside the cryptographic protection.¶
Some header fields are legitimately added in transit, and could not have been known to the sender at message composition time.¶
The most common of these header fields are Received
and DKIM-Signature
, neither of which are typically rendered, either explicitly or implicitly.¶
If a receiving MUA has specific knowledge about a given header field, including that:¶
then the MUA MAY decide to operate on the value of that header field from the unprotected header section, even though the message has header protection.¶
The MUA MAY prefer to verify that the header fields in question have additional transit-derived cryptographic protections before rendering or acting on them.
For example, the MUA could verify whether these header fields are covered by an appropriate and valid ARC-Authentication-Results
(see [RFC8617]) or DKIM-Signature
(see [RFC6376]) header field.¶
Specific examples of user-meaningful header fields commonly added by transport agents appear below.¶
If the message arrives through a mailing list, the list manager itself may inject header fields (most of which start with List-
) in the message:¶
For some MUAs, these header fields are implicitly rendered, by providing buttons for actions like "Subscribe", "View Archived Version", "Reply List", "List Info", etc.¶
An MUA that receives a message with header protection that contains these header fields in the unprotected section, and that has reason to believe the message is coming through a mailing list MAY decide to render them to the user (explicitly or implicitly) even though they are not protected.¶
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 significant disruption. Some elements of this specification are present for transitional purposes, but would not exist if the system were designed from scratch.¶
This section describes these transitional mechanisms, as well as some suggestions for how they might eventually be phased out.¶
Any decorative Legacy Display element added to an encrypted message that uses the Injected Header scheme is present strictly for enabling header field visibility (most importantly, the Subject header field) when the message is viewed with a decryption-capable legacy client.¶
Eventually, the hope is that most decryption-capable MUAs will conform to this specification, and there will be no need for injection of Legacy Display elements in the message body. A survey of widely-used decryption-capable MUAs might be able to establish when most of them do support this specification.¶
At that point, a composing MUA could make the legacy
parameter described in {#compose-injected-headers} to false
by default, or could even hard-code it to false
, yielding a much simpler message construction set.¶
Until that point, an end user might want to signal that their receiving MUAs are conformant to this draft so that a peer composing a message to them can set legacy
to false
.
A signal indicating capability of handling messages with header protection might be placed in the user's cryptographic certificate, or in outbound messages.¶
This draft doesn't attempt to define the syntax or semantics of such a signal.¶
This draft defines two different forms of Header Confidentiality Policy.
A MUA implementing an HCP for the first time SHOULD deploy hcp_minimal
as recommended in Section 2.4.
This HCP offers the most commonly-expected protection (obscuring the Subject header field) without risking deliverability or rendering issues.¶
The HCPs proposed in this draft are relatively conservative and still leak a significant amount of metadata for encrypted messages. This is largely done to ensure deliverability (see Section 1.4.2) and usability, as messages without some critical header fields are more likely to not reach their intended recipient.¶
In the future, some mail transport systems may accept and deliver messages with even less publicly-visible metadata. Many MTA operators today would ask for additional guarantees about such a message to limit the risks associated with abusive or spammy mail.¶
This specification offers the HCP formalism itself as a way for MUA developers and MTA operators to describe their expectations around message deliverability. MUA developers can propose a stronger default HCP, and ask MTA operators (or simply test) whether their MTAs would be likely to deliver or reject encrypted mail with that HCP applied. Proponents of a stronger HCP should explicitly document the HCP, and name it clearly and unambiguously to facilitate this kind of interoperability discussion.¶
Reaching widespread consensus around a stronger global default HCP is a challenging problem of coordinating many different actors. A piecemeal approach might be more feasible, where some signalling mechanism allows a message recipient, MTA operator, or third-party clearinghouse to announce what kinds of HCPs are likely to be deliverable for a given recipient. In such a situation, the default HCP for a MUA might involve consulting the signalled acceptable HCPs for all recipients, and combining them (along with a default for when no signal is present) in some way.¶
If such a signal were to reach widespread use, it could also be used to guide reasonable statistical default HCP choices for recipients with no signal.¶
This draft doesn't attempt to define the syntax or semantics of such a signal.¶
At some point, when the majority of MUA clients that can generate cryptographically protected messages with header protection, it should be possible to deprecate any cryptographically protected message that does not have header protection.¶
For example, as noted in Section 4.1, it's possible for a MUA to decline to render a signed-only
message that has no header protection the same as an unsigned message.
And a signed-and-encrypted
message without header protection could likewise be marked as not fully protected.¶
These stricter rules could be adopted immediately for all messages. Or a MUA developer could roll them out immediately for any new message, but still treat an old message (based on the Date header field and cryptographic signature timestamp) more leniently.¶
A decision like this by any popular receiving MUA could drive adoption of this standard for sending MUAs.¶
This section describes concerns for MUAs that are interested in easy adoption of header protection by normal users.¶
While they are not protocol-level artifacts, these concerns motivate the protocol features described in this document.¶
See also the Usability commentary in Section 2 of [I-D.ietf-lamps-e2e-mail-guidance].¶
When rendering a message to the user, the ideal circumstance is to present a single cryptographic status for any given message. However, when message headers are present, some message headers do not have the same cryptographic protections as the main message.¶
Representing such a mixed set of protection statuses is very difficult to do in a way that a normal user can understand without training. There are at least three scenarios that are likely to be common, and poorly understood:¶
A MUA should have a reasonable strategy for clearly communicating each of these scenarios to the user. For example, a MUA operating in an environment where it expects most cryptographically-protected messages to have header protection could use the following rendering strategy:¶
signed-only
cryptographic status but no header protection, an MUA may decline to indicate a positive security status overall, and only indicate the cryptographic status to a user in a message properties or diagnostic view.
That is, the message may appear identical to an unsigned message except if a user verifies the properties through a menu option.¶
signed-and-encrypted
or encrypted-only
cryptographic status but no header protection, overlay a warning flag on the typical cryptographic status indicator.
That is, if a typical signed-and-encrypted
message displays a lock icon, display a lock icon with a warning sign (e.g., an exclamation point in a triangle) overlaid.
See, for example, the graphics in [chrome-indicators].¶
signed-and-encrypted
or encrypted-only
cryptographic status, with header protection, but where the Subject header field has not been removed or obscured, place a warning sign on the on the Subject line.¶
Other simple rendering strategies could also be reasonable.¶
This document defines the abstraction of a Header Confidentiality Policy object for the sake of communication between implementers and deployments.¶
Most e-mail users are unlikely to understand the tradeoffs between different policies. In particular, the potential negative side effects (e.g. poor deliverability) may not be easily attributable by a normal user to a particular HCP.¶
Therefore, MUA implementers should be conservative in their choice of default HCP, and should not require the ordinary user to make an incomprehensible choice that could cause unfixable, undiagnosable problems.
The safest option is for the MUA developer to select a known, stable HCP (this document recommends hcp_minimal
in Section 2.4) on the user's behalf.
A MUA should not not expose the ordinary user to a configuration option where they are expected to manually select (let alone define) an HCP.¶
In the event that a MUA implementer gets user complaints about problems with removed or obscured header fields due to the MUA's defined HCP, the implementer may offer the user an option to drop header confidentiality altogether for freshly composed messages (thereby reverting to hcp_null
).
But when handling such a scenario for a reply to a message with some header confidentiality policy in place, note the guidance in Section 2.5.8.1 to avoid accidental leakage.¶
This document also describes two different header protection schemes: Wrapped Messages in Section 2.2 and Injected Headers in Section 2.1.¶
These distinct schemes are described for the sake of implementers who may have to deal with messages found in the wild, but their intended semantics are identical. They represent different tradeoffs in terms of rendering and user experience on the recipient's side, things that a given user writing a message is not prepared to select.¶
When composing a message with cryptographic protections, the ordinary user should not be confronted with any choices about which header protection scheme to use. Rather, the MUA developer should use a single scheme for all outboud cryptographically-protected messages.¶
This document recommends the Injected Headers scheme for generating messages with cryptographic protections, as described in Section 2. A MUA should not expose the ordinary user to any configuration option where they are expected to manually select, enable, or disable header protections for new cryptographically-protected messages.¶
This document describes a mechanism for improving the security of cryptographically-protected e-mail messages. Following the guidance in this document should improve security for users of these technologies by more directly aligning the underlying messages with user expectations about confidentiality, authenticity, and integrity.¶
However, many existing messages with cryptographic protections will not have these protections, and MUAs encountering these messages will need to handle older forms (without header protection) for quite some time. An implementation that deals with legacy message archives will need to deal with all the various formats forever. Helping the user distinguish between cryptographic protections of various messages is a difficult job for message renderers.¶
However, on the message generation side, the situation is much clearer: there is a standard form that a protected message can take, and an implementer can always generate the standard form. Generating the standard form also makes it more likely that any receiving implementation will be able to handle the generated message appropriately.¶
When composing a message, it's possible for a Legacy Display Element to contain risky data that could trigger errors in a rendering client.¶
For example, if the value for a header field to be included in a Legacy Display Element within a given body part contains folding whitespace, it should be "unfolded" before generating the Legacy Display Element: all contiguous folding whitespace should be replaced with a single space character. Likewise, if the header value was originally encoded with [RFC2047], it should be decoded first to a standard string and re-encoded using the charset appropriate to the target part.¶
When including a Legacy Display Element in a text/plain
part (see Section 2.3.4.1), if the decoded Subject header field contains a pair of newlines (e.g., if it is broken across multiple lines by encoded newlines), any newline MUST be stripped from the Legacy Display Element.
If the pair of newlines is not stripped, a receiving MUA that follows the guidance in Section 2.5.3.3.2 might leave the later part of the Legacy Display Element in the rendered message.¶
When including a Legacy Display Element in a text/html
part (see Section 2.3.4.2), any material in the header values should be explicitly HTML escaped to avoid being rendered as part of the HTML.
At a minimum, the characters <
, >
, and &
should be escaped to <
, >
, and &
, respectively (see for example [HTML-ESCAPES]).
If unescaped characters from removed or obscured header values end up in the Legacy Display element, a receiving MUA that follows the guidance in Section 2.5.3.3.3 might fail to identify the boundaries of the Legacy Display Element, cutting out more than it should, or leaving remnants visible.
And a legacy client parsing such a message might misrender the entire HTML stream, depending on the content of the removed or obscured header values.¶
The Legacy Display Element is a decorative addition solely to enable visibility of obscured or removed header fields in legacy, decryption-capable MUAs. When it is produced, it should be generated conservatively and narrowly, to avoid damaging the rest of the message.¶
For encrypted messages, depending on the sender's HCP, some header fields may appear both within the Cryptographic Envelope and on the outside of the message.
Section 2.5.2 identifies those messages as signed-only
.
These header fields are clearly not private at all, despite a copy being inside the Cryptographic Envelope.¶
A header field whose name can be found in the HP-Removed
or in any HP-Obscured
header field from the same part will have encrypted-only
or signed-and-encrypted
status.
But even header fields with these stronger levels of cryptographic confidentiality protection might not be as private as the user would like.¶
For encrypted messages, even with a powerful HCP that successfully obscures most header fields from all transport agents, header fields will be ultimately visible to all intended recipients. This can be especially problematic for header fields that are not user-facing, which the sender may not expect to be injected by their MUA. Consider the three following examples:¶
User-Agent
header field that describes itself to every recipient, even though the sender may not want the recipient to know the exact version of their OS, hardware platform, or MUA.¶
Message-ID
header, which could embed the choice of MUA, a timezone, a hostname, or other subtle information to a knowledgeable recipient.¶
Bcc
header field in the origheaders
of a copy of a message sent to the named recipient, defeating the purpose of using Bcc
instead of Cc
(see Section 6.3 for more details about risks related to Bcc
).¶
Clearly, no end-to-end cryptographic protection of any header field as described in this document will hide such a sensitive field from the intended recipient.
Instead, the composing MUA MUST judiciously populate the origheaders
list for any outbound message with only information that the user reasonably intends the recipient to have access to.
This is true for messages without any cryptographic protection as well, of course, and it is even worse there: such a leak is exposed to the transport agents as well as the recipient.
An encrypted message with header protection and a strong header confidentiality policy avoid these leaks exposing information to the transport agents, but cannot defend against such a leak to the recipient.¶
For example, if the To:
and Cc:
header fields are omitted from the unprotected header section, the values in those fields might still be inferred with high probability by an adversary who looks at the message either in transit or at rest.
If the message is found in, or being delivered to a mailbox for bob@example.org
, it's likely that Bob was in either To:
or Cc:
.
Additionally, an MTA that handles the message may add a Received:
header field (or some other custom header field) that leaks some information about the nature of the delivery.¶
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) and to convert the local timezone to UTC, 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 date will be present on the message.
Additionally, headers like Received
that are added during message delivery might include higher-resolution timestamps.
And if the message lands in a mailbox that is ordered by time of receipt, even its placement in the mailbox and the non-obscured Date:
header fields of the surrounding messages could leak this information.¶
Some fields like From:
may be impossible to fully obscure, as many modern message delivery systems depend on at least domain information in the From:
field for determining whether a message is coming from a domain with "good reputation" (that is, from a domain that is not known for leaking spam).
So even if an aggressive HCP opts to remove the human-readable part from any From:
header field, and to standardize/genericize the local part of the From:
address, the domain will still leak.¶
When an encrypted (or signed-and-encrypted) message is in transit, an active intermediary can strip or tamper with any header field that appears outside the Cryptographic Envelope. A receiving MUA that naively infers cryptographic status from differences between the external header fields and those found in the Cryptographic Envelope could be tricked into overestimating the protections afforded to some header fields.¶
For example, if the original sender's HCP passes through the Cc:
header field unchanged, a cleanly-delivered message would indicate that the Cc:
header field has a cryptographic status of signed
.
But if an intermediary attacker simply removes the header field from the unprotected header section before forwarding the message, then the naive recipient might believe that the field has a cryptographic status of signed-and-encrypted
.¶
This draft offers protection against such an attack by way of the HP-Obscured
and HP-Removed
header fields that can be found on the Cryptographic Payload.
If a header field appears to have been obscured, but no HP-Obscured
header matches it; or if the header field appears to have been removed, but the HP-Removed
header does not include its field name, the receiving MUA can indicate to the user that the header field in question may not have been confidential.¶
In such a case, a conservative MUA may render the header field in question as signed
(because the sender did not hide it), but still treat it as signed-and-encrypted
during reply, to avoid accidental leakage of the cleartext value in the reply message, as described in Section 2.5.8.1.¶
In the abstract sense, the above concerns are of course also true for any encrypted data, including the body of the message: if the sender isn't careful, the message contents or session keys could leak in many different ways that are beyond the scope of this draft. The message recipient has no way in principle to tell whether the apparent confidentiality of any given piece of encrypted content has been broken via channels that they cannot perceive. And an active intermediary aware of the recipient's public key can always encrypt a cleartext message in transit to give the recipient a false sense of security.¶
A receiving MUA should be cautious about how it represents the cryptographic status of encrypted-only
and signed-and-encrypted
header fields to the user, to avoid overpromising.
However, the MUA should also strive to avoid additional leakage of these header fields, as described in Section 2.5.8.1.¶
As noted in Section 9.3 of [I-D.ietf-lamps-e2e-mail-guidance], handling Bcc when generating an encrypted e-mail message can be particularly tricky.
With header protection, there is an additional wrinkle.
When an encrypted e-mail message with header protection has a Bcc'ed recipient, and the composing MUA explicitly includes the Bcc'ed recipient's address in their copy of the message (see the "second method" in Section 3.6.3 of [RFC5322]), that Bcc
header field will always be visible to the Bcc'ed recipient.¶
In this scenario, though, the composing MUA has one additional choice: whether to hide the Bcc
header field from intervening message transport agents, by returning null
when the HCP is invoked for Bcc
.
If the composing MUA's rationale for including an explicit Bcc
in the copy of the message sent to the Bcc recipient is to ensure deliverability via a message transport agent that inspects message headers, then stripping the Bcc
field during encryption may cause the intervening transport agent to drop the message entirely.
This is why Bcc
is not explicitly stripped in hcp_minimal
.¶
If, on the other hand, deliverability to a Bcc
'ed recipient is not a concern, the most privacy-preserving option is to simply omit the Bcc
header field from the protected header section in the first place.
A MUA that is capable of receiving and processing such a message can infer that since their user's address was not mentioned in any To
or Cc
header field, they were likely a Bcc
recipient.¶
Please also see Section 9.3 of [I-D.ietf-lamps-e2e-mail-guidance] for more discussion about Bcc and encrypted messages.¶
This document requests IANA to register the following two header fields in the "Permanent Message Header Field Names" registry within "Message Headers" in accordance with [RFC3864].¶
Header Field Name | Template | Protocol | Status | Reference | Author/Change Controller |
---|---|---|---|---|---|
HP-Removed
|
standard | Section 2.3.3 of RFCXXXX | IETF | ||
HP-Obscured
|
standard | Section 2.3.3 of RFCXXXX | IETF |
This document also defines the Content-Type
parameter known as protected-headers
.
There does not appear to be an IANA registry for parameters for Content-Type
.
In the absence of such a registry, 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] |
Should be updated to have the following values:¶
Header Field Name | Template | Protocol | Status | Reference |
---|---|---|---|---|
Content-Type
|
MIME | [RFC4021] [RFCXXXX] |
If a registry of Content-Type
parameters is created, the parameter protected-headers
should refer to this document.
Its possible values are v1
(meaning Injected Headers, see Section 2.1) and wrapped
(meaning Wrapped Message, see Section 2.2).¶
The authors would like to thank the following people who have provided helpful comments and suggestions for this document: Berna Alp, Bernhard E. Reiter, Carl Wallace, Claudio Luck, David Wilson, Hernani Marques, juga, Krista Bennett, Kelly Bristol, Lars Rohwedder, Nicolas Lidzborski, Robert Williams, Russ Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.¶
When an e-mail message with end-to-end cryptographic protection is received by a mail user agent, the user might experience many different possible problematic interactions. A message with header protection may introduce new forms of user experience failure.¶
In this section, the authors enumerate different kinds of failures we have observed when reviewing, rendering, and replying to messages with different forms of header protection in different legacy MUAs. Different legacy MUAs demonstrate different subsets of these problems.¶
Hopefully, a non-legacy MUA would not exhibit any of these problems. An implementer updating their legacy MUA to be compliant with this specification should consider these concerns and try to avoid them.¶
Note that the use case here is:¶
This section also uses the shorthand UI:x to mean "the UI element that the user can edit that they think of as x."¶
This uses the same use case(s) and shorthand as Appendix A.3.¶
This section contains sample messages using the different schemes described in this document. Each sample contains a MIME object, a textual and diagrammatic view of its structure, and examples of how an MUA might render it.¶
The cryptographic protections used in this document use the S/MIME standard, and keying material and certificates come from [I-D.ietf-lamps-samples].¶
These messages should be accessible to any IMAP client at imap://bob@header-protection.cmrg.net/
(any password should authenticate to this read-only IMAP mailbox).¶
You can also download copies of these test vectors separately at https://header-protection.cmrg.net
.¶
If any of the messages downloaded differ from those offered here, this document is the canonical source.¶
These messages offer no header protection at all, and can be used as a baseline. They are provided in this document as a counterexample. An MUA implementer can use these messages to verify that the reported cryptographic summary of the message indicates no header protection.¶
This message uses no cryptographic protection at all. Its body is a text/plain message.¶
It has the following structure:¶
└─╴text/plain 152 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 3852 bytes ⇩ (unwraps to) └─╴text/plain 204 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└┬╴multipart/signed 4191 bytes ├─╴text/plain 224 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 6720 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 3960 bytes ⇩ (unwraps to) └─╴text/plain 239 bytes¶
Its contents are:¶
This message uses no cryptographic protection at all. Its body is a multipart/alternative message with an inline image/png attachment.¶
It has the following structure:¶
└┬╴multipart/mixed 1406 bytes ├┬╴multipart/alternative 794 bytes │├─╴text/plain 206 bytes │└─╴text/html 304 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 5249 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1288 bytes ├┬╴multipart/alternative 882 bytes │├─╴text/plain 258 bytes │└─╴text/html 353 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└┬╴multipart/signed 5234 bytes ├┬╴multipart/mixed 1344 bytes │├┬╴multipart/alternative 938 bytes ││├─╴text/plain 278 bytes ││└─╴text/html 376 bytes │└─╴image/png inline 232 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8690 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5426 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1356 bytes ├┬╴multipart/alternative 950 bytes │├─╴text/plain 293 bytes │└─╴text/html 388 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
These messages are signed-only, using different schemes of header protection and different S/MIME structure. The use no Header Confidentiality Policy because the hcp is only relevant when a message is encrypted.¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 4319 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 642 bytes └─╴text/plain 228 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└┬╴multipart/signed 4562 bytes ├┬╴message/rfc822 inline 672 bytes │└─╴text/plain 256 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 4234 bytes ⇩ (unwraps to) └─╴text/plain 239 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses the Injected Headers header protection scheme.¶
It has the following structure:¶
└┬╴multipart/signed 4487 bytes ├─╴text/plain 258 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 5737 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 1689 bytes └┬╴multipart/mixed 1584 bytes ├┬╴multipart/alternative 946 bytes │├─╴text/plain 282 bytes │└─╴text/html 380 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└┬╴multipart/signed 5653 bytes ├┬╴message/rfc822 inline 1747 bytes │└┬╴multipart/mixed 1642 bytes │ ├┬╴multipart/alternative 1002 bytes │ │├─╴text/plain 310 bytes │ │└─╴text/html 408 bytes │ └─╴image/png inline 232 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 5700 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1614 bytes ├┬╴multipart/alternative 950 bytes │├─╴text/plain 293 bytes │└─╴text/html 388 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme.¶
It has the following structure:¶
└┬╴multipart/signed 5580 bytes ├┬╴multipart/mixed 1672 bytes │├┬╴multipart/alternative 1006 bytes ││├─╴text/plain 312 bytes ││└─╴text/html 410 bytes │└─╴image/png inline 232 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
These messages are encrypted and signed. They use PKCS#7 signedData inside envelopedData, with different header protection schemes and different Header Confidentiality Policies.¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7540 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4580 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 783 bytes └─╴text/plain 321 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7435 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4498 bytes ⇩ (unwraps to) └─╴text/plain 333 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7670 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4674 bytes ⇩ (unwraps to) └─╴text/plain 423 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7735 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4712 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 878 bytes └─╴text/plain 319 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7605 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4630 bytes ⇩ (unwraps to) └─╴text/plain 331 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7845 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4806 bytes ⇩ (unwraps to) └─╴text/plain 420 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7800 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4770 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 920 bytes └─╴text/plain 327 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7695 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4692 bytes ⇩ (unwraps to) └─╴text/plain 339 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7975 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4898 bytes ⇩ (unwraps to) └─╴text/plain 435 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8020 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4930 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 1038 bytes └─╴text/plain 325 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7930 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4856 bytes ⇩ (unwraps to) └─╴text/plain 337 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8190 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5058 bytes ⇩ (unwraps to) └─╴text/plain 432 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 9665 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6148 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 1923 bytes └┬╴multipart/mixed 1818 bytes ├┬╴multipart/alternative 1132 bytes │├─╴text/plain 375 bytes │└─╴text/html 473 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 9620 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6114 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1848 bytes ├┬╴multipart/alternative 1136 bytes │├─╴text/plain 387 bytes │└─╴text/html 482 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10205 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6548 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2157 bytes ├┬╴multipart/alternative 1431 bytes │├─╴text/plain 485 bytes │└─╴text/html 637 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 9840 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6276 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 2016 bytes └┬╴multipart/mixed 1911 bytes ├┬╴multipart/alternative 1128 bytes │├─╴text/plain 373 bytes │└─╴text/html 471 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 9795 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6246 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1941 bytes ├┬╴multipart/alternative 1132 bytes │├─╴text/plain 385 bytes │└─╴text/html 480 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10380 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6676 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2248 bytes ├┬╴multipart/alternative 1425 bytes │├─╴text/plain 482 bytes │└─╴text/html 634 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 9970 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6366 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 2082 bytes └┬╴multipart/mixed 1977 bytes ├┬╴multipart/alternative 1144 bytes │├─╴text/plain 381 bytes │└─╴text/html 479 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 9925 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6342 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2009 bytes ├┬╴multipart/alternative 1148 bytes │├─╴text/plain 393 bytes │└─╴text/html 488 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10510 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6766 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2314 bytes ├┬╴multipart/alternative 1435 bytes │├─╴text/plain 487 bytes │└─╴text/html 639 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10185 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6526 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 2198 bytes └┬╴multipart/mixed 2093 bytes ├┬╴multipart/alternative 1140 bytes │├─╴text/plain 379 bytes │└─╴text/html 477 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10140 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6502 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2125 bytes ├┬╴multipart/alternative 1144 bytes │├─╴text/plain 391 bytes │└─╴text/html 486 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10790 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6968 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2460 bytes ├┬╴multipart/alternative 1449 bytes │├─╴text/plain 494 bytes │└─╴text/html 646 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This section offers step-by-step examples of message composition.¶
A typical MUA composition interface offers the user a place to indicate the message recipients, the subject, and the body. Consider a composition window filled out by the user like so:¶
When Bob clicks "Send", his MUA generates values for Message-ID
, From
, and Date
header fields, and converts the message body into the appropriate format.¶
The resulting message would look something like this if it was sent without cryptographic protections:¶
Date: Wed, 11 Jan 2023 16:08:43 -0500 From: Bob <bob@example.net> To: Alice <alice@example.net> Subject: Handling the Jones contract Message-ID: <20230111T210843Z.1234@lhp.example> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Please review and approve or decline by Thursday, it's critical! Thanks, Bob -- Bob Gonzalez ACME, Inc.¶
hcp_minimal
and Legacy Display
Now consider the message to be generated if it is to be cryptographically signed and encrypted, using HCP hcp_minimal
, and the legacy
variable is set.¶
For each header field, Bob's MUA passes its name and value through hcp_minimal
.
This returns the same value for every header field, except that:¶
hcp_minimal
("Subject
", "Handling the Jones contract
") yields "[...]
".¶
The Cryptographic Payload that will be signed and then encrypted is very similar to the unprotected message in Appendix C.1.1. Note the addition of:¶
protected-headers="v1"
parameter for the Content-Type
¶
HP-Obscured
header for Subject
,¶
hp-legacy-display="1"
parameter for the Content-Type
¶
Date: Wed, 11 Jan 2023 16:08:43 -0500 From: Bob <bob@example.net> To: Alice <alice@example.net> Subject: Handling the Jones contract Message-ID: <20230111T210843Z.1234@lhp.example> Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; protected-headers="v1" MIME-Version: 1.0 HP-Obscured: Subject: [...] Subject: Handling the Jones contract Please review and approve or decline by Thursday, it's critical! Thanks, Bob -- Bob Gonzalez ACME, Inc.¶
The Cryptographic Payload from Appendix C.1.2.1 is then wrapped in the appropriate cryptographic layers.
For this example, using S/MIME, it is wrapped in an application/pkcs7-mime; smime-type="signed-data"
layer, which is in turn wrapped in a application/pkcs7-mime; smime-type="enveloped-data"
layer.¶
Then an external header section is applied to the outer MIME object, which looks like this:¶
Date: Wed, 11 Jan 2023 16:08:43 -0500 From: Bob <bob@example.net> To: Alice <alice@example.net> Subject: [...] Message-ID: <20230111T210843Z.1234@lhp.example> Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-mime; name="smime.p7m"; smime-type="enveloped-data" MIME-Version: 1.0¶
Note that the Subject
header field has been obscured appropriately by hcp_minimal
.
The output of the CMS enveloping operation is base64-encoded and forms the body of the message.¶
This section offers example Cryptographic Payloads (the content within the Cryptographic Envelope) that contain Legacy Display elements.¶
Here is a simple one-part Cryptographic Payload (headers and body) of a message that includes Legacy Display elements:¶
Date: Fri, 21 Jan 2022 20:40:48 -0500 From: Alice <alice@example.net> To: Bob <bob@example.net> Subject: Dinner plans Message-ID: <text-plain-legacy-display@lhp.example> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; protected-headers="v1" Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A compatible MUA will recognize the hp-legacy-display="1"
parameter and render the body of the message as:¶
Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A legacy decryption-capable MUA that is unaware of this mechanism will ignore the hp-legacy-display="1"
parameter and instead render the body including the Legacy Display elements:¶
Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
Here is a modern one-part Cryptographic Payload (headers and body) of a message that includes Legacy Display elements:¶
Date: Fri, 21 Jan 2022 20:40:48 -0500 From: Alice <alice@example.net> To: Bob <bob@example.net> Subject: Dinner plans Message-ID: <text-html-legacy-display@lhp.example> MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii"; hp-legacy-display="1"; protected-headers="v1" <html><head><title></title></head><body> <div class="header-protection-legacy-display"> <pre>Subject: Dinner plans</pre> </div> <p> Let's meet at Rama's Roti Shop at 8pm and go to the park from there. </p> </body> </html>¶
A compatible MUA will recognize the hp-legacy-display="1"
parameter and mask out the Legacy Display div
, rendering the body of the message as a simple paragraph:¶
Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A legacy decryption-capable MUA that is unaware of this mechanism will ignore the hp-legacy-display="1"
parameter and instead render the body including the Legacy Display elements:¶
Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
[[ RFC Editor: This section is to be removed before publication ]]¶
draft-ietf-lamps-header-protection-16¶
draft-ietf-lamps-header-protection-15¶
draft-ietf-lamps-header-protection-14¶
draft-ietf-lamps-header-protection-13¶
draft-ietf-lamps-header-protection-12¶
draft-ietf-lamps-header-protection-11¶
draft-ietf-lamps-header-protection-10¶
draft-ietf-lamps-header-protection-09¶
draft-ietf-lamps-header-protection-08¶
draft-ietf-lamps-header-protection-07¶
draft-ietf-lamps-header-protection-06¶
draft-ietf-lamps-header-protection-05¶
draft-ietf-lamps-header-protection-04¶
draft-ietf-lamps-header-protection-03¶
draft-ietf-lamps-header-protection-02¶
draft-ietf-lamps-header-protection-01¶
draft-ietf-lamps-header-protection-00¶