Internet-Draft | Cryptographic MIME Header Protection | March 2024 |
Gillmor, et al. | Expires 2 September 2024 | [Page] |
- Workgroup:
- LAMPS Working Group
- Internet-Draft:
- draft-ietf-lamps-header-protection-20
- Updates:
- 8551 (if approved)
- Published:
- Intended Status:
- Standards Track
- Expires:
Header Protection for Cryptographically Protected E-mail
Abstract
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 ([RFC8551]) 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.¶
About This Document
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://dkg.gitlab.io/lamps-header-protection/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/.¶
Discussion of this document takes place on the LAMPS Working Group mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/.¶
Source for this draft and an issue tracker can be found at https://gitlab.com/dkg/lamps-header-protection.¶
Status of This Memo
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 2 September 2024.¶
Copyright Notice
Copyright (c) 2024 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.¶
1. Introduction
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 an MUA that does not implement either scheme. This document takes particular care to ensure that messages interact reasonably well with Legacy MUAs.¶
1.1. Two Schemes of Header Protection
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 MUAs, 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 ([RFC8551]), 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 updates the scheme described in that document, effectively replacing the final two paragraphs of Section 3.1 of [RFC8551].
However, experience has shown that even the updated "Wrapped Message" form does not interact well with some Legacy MUAs (see Section 1.2).¶
The more interoperable "Injected Headers" scheme of Header Protection is introduced in this document, and is preferred over the "Wrapped Message" scheme.
In the "Injected Headers" scheme, the protected Header Fields are placed directly on the Cryptographic Payload, without using an intervening message/*
MIME object.
See Section 2.3.4 and Section 2.5.3 for more details.¶
1.2. Problems with Wrapped Messages
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 an 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.¶
1.3. Problems with Injected Headers
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.¶
1.4. Motivation
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 Header Section as well as the message body, these attacks are defeated.¶
1.4.1. Backward Compatibility
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 MUAs 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 MUA. But accommodations are described here that ensure a rough semantic equivalence for Legacy MUA even in these cases.¶
1.4.2. Deliverability
A message with perfect cryptographic protections that cannot be delivered is less useful than a message with imperfect cryptographic protections that can be delivered. Senders want their messages to reach the intended recipients.¶
Given the current state of the Internet mail ecosystem, encrypted messages in particular cannot shield all of their Header Fields from visibility and still be guaranteed delivery to their intended recipient.¶
This document accounts for this concern by providing a mechanism (Section 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.¶
1.5. Other Protocols to Protect E-Mail Header Fields
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.¶
1.6. Applicability to PGP/MIME
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.¶
1.7. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The key words "SPECIFICATION REQUIRED" and "IETF REVIEW" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC8126].¶
1.8. Terms
The following terms are defined for the scope of this document:¶
-
S/MIME: Secure/Multipurpose Internet Mail Extensions (see [RFC8551])¶
-
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.¶
-
Header Field: A Header Field includes a field name, followed by a colon (":"), followed by a field body (value), and terminated by CRLF; see Section 2.2 of [RFC5322] for more details.¶
-
Header Section: The Header Section is a sequence of lines of characters with special syntax as defined in [RFC5322]. The Header Section of a Message contains the Header Fields associated with the Message itself. The Header Section of a MIME part (that is, a subpart of a message) typically contains Header Fields associated with that particular MIME part.¶
-
Body: The Body is the part of a Message that follows the Header Section and is separated from the Header Section by an empty line (i.e., a line with nothing preceding the CRLF); see [RFC5322]. It is the (bottom) section of Message containing the payload of a Message. Typically, the Body consists of a (possibly multipart) MIME [RFC2045] construct.¶
-
Header Protection (HP): cryptographic protection of e-mail Header Sections (or parts of it) for signatures and/or encryption¶
-
Cryptographic Layer, Cryptographic Payload, Cryptographic Envelope, Cryptographic Summary, Structural Header Fields, Main Body Part, User-Facing Header Fields, and MUA are all used as defined in [I-D.ietf-lamps-e2e-mail-guidance]¶
-
Legacy MUA: an MUA that does not understand Header Protection as described in this document. A Legacy Non-Crypto MUA is incapable of doing any end-to-end cryptographic operations. A Legacy Crypto MUA is capable of doing cryptographic operations, but does not understand or generate messages with Header Protection.¶
-
Legacy Signed Message: an e-mail message that was signed by a Legacy MUA (and therefore has no cryptographic authenticity or integrity protections on its Header Fields.¶
-
Wrapped Message: The Header Protection scheme that uses the mechanism described in [RFC8551], where the Cryptographic Payload is a
message/rfc822
ormessage/global
MIME object, augmented with a Content-Type parameter to indicate that this is the explicit intent. (see Section 2.2).¶ -
Injected Headers: The Header Protection scheme that uses the mechanism described in this document (see Section 2.1), where the protected Header Fields are inserted on the Cryptographic Payload directly.¶
-
Header Confidentiality Policy (HCP): a functional specification of which Header Fields should be obscured when composing an encrypted message with Header Protection. See Section 2.3.2.¶
-
Ordinary User: a user of an MUA who follows a simple and minimal experience, focused on sending and receiving e-mails. A user who opts into advanced configuration, expert mode, or the like is not an "Ordinary User".¶
1.9. Document Scope
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 Header Fields as well as its body.¶
1.9.1. In Scope
This document also describes sensible, simple behavior for a program that interprets such a message, in a way that can take advantage of these protections covering the Header Fields as well as the body.¶
The message generation guidance aims to minimize negative interactions with any Legacy receiving MUA 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:¶
1.9.2. Out of Scope
The message composition guidance in this document (in Section 2.3.4) aims to provide minimal disruption for any Legacy MUA that receives such a message. However, a Legacy MUA by definition does not implement any of the guidance here. Therefore, the document does not attempt to provide guidance for Legacy MUAs directly.¶
Furthermore, this document does not explicitly contemplate other variants of cryptographic message protections, including any of these:¶
-
Encrypted-only message (without a cryptographic signature)¶
-
Triple-wrapped message¶
-
Signed message with multiple signatures¶
-
Encrypted message with a cryptographic signature outside the encryption.¶
All such messages are out of scope of this document.¶
2. Specification
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).¶
2.1. Injected Headers Scheme
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.¶
2.2. Wrapped Message Scheme
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).¶
The Wrapped Message Header Protection scheme is very similar to that described in Section 3.1 of [RFC8551]. The main augmentations this document provides to that scheme are:¶
-
an explicit discussion of how to obscure or remove Header Fields,¶
-
an additional
protected-headers=wrapped
parameter to theContent-Type
Header Field of the Cryptographic Payload to indicate the explicit intent, and¶ -
a recommendation to mark 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.¶
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.¶
2.3. Sending Side
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.¶
2.3.1. Composing a Cryptographically-Protected Message Without Header Protection
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 Header Fields (Content-*
) present.¶ -
origheaders
: the intended non-structural Header Fields for the message, represented here as a list of(h,v)
pairs, whereh
is a Header Field name andv
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 theBcc
header during composition, but plans to omit it from the message (see Section 3.6.3 of [RFC5322]), it will not be inorigheaders
.¶ -
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:¶
2.3.2. Header Confidentiality Policy
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 byname
with initial valueval_in
as arguments, and returns a replacement header valueval_out
. Ifval_out
is the special valuenull
, it means 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_hide_cc(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.¶
For alignment with common practice as well as the ABNF in Section 2.3.3 for HP-Obscured
, val_out
MUST be one of the following:¶
-
identical to
val_in
, or¶ -
the special value
null
, or¶ -
a sequence of printable and whitespace (that is, space or tab) 7-bit clean US-ASCII characters (of course, non-ASCII text can be encoded as US-ASCII using the
encoded-word
construct from [RFC2047])¶
The HCP can compute val_out
using any technique describable in pseudocode, such as copying a fixed string or invocations of other pseudocode functions.
If it alters the value, it MUST NOT include control or NUL characters in val_out
.¶
2.3.3. Definition of HP-Removed and HP-Obscured Header Fields
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 Header Fields 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], where field-name
, WSP
, VCHAR
, and FWS
are defined in [RFC5322]:¶
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 ": " replacement-value CRLF replacement-value = (*([FWS] VCHAR) *WSP)¶
Note that replacement-value
is the same as unstructured
from [RFC5322], but without the obsolete obs-unstructured
option.¶
2.3.4. Composing with "Injected Headers" Header Protection
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 uses the following inputs:¶
-
All the inputs described in Section 2.3.1¶
-
hcp
: a Header Confidentiality Policy, as defined in Section 2.3.2¶ -
legacy
: a boolean value, indicating whether any recipient of the message is believed to have a Legacy MUA. If all recipients are known to implement this draft,legacy
should be set tofalse
. (How an MUA determines the value oflegacy
is out of scope for this document; an initial implementation can simply set it totrue
)¶
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 algorithm for applying "Injected Headers" cryptographic protection to a message is as follows:¶
-
Let
newbody
be a copy oforigbody
¶ -
If
crypto
contains encryption, andlegacy
istrue
:¶-
Create
ldlist
, an empty list of(header, value)
pairs¶ -
For each Header Field name and value
(h,v)
inorigheaders
:¶-
If
h
is user-facing (see Section 1.1.2 of [I-D.ietf-lamps-e2e-mail-guidance]):¶
-
-
If
ldlist
is not empty:¶-
Identify each leaf MIME part of
newbody
that represents the "main body" of the message.¶ -
For each "Main Body Part"
bodypart
of typetext/plain
ortext/html
:¶-
Adjust
bodypart
by inserting a Legacy Display Element header listldlist
into its content, and adding aContent-Type
parameterhp-legacy-display
with value1
(see Section 2.3.4.1 fortext/plain
and Section 2.3.4.2 fortext/html
)¶
-
-
-
-
For each Header Field name and value
(h,v)
inorigheaders
:¶-
Add Header Field
h
to MIME partnewbody
with valuev
¶
-
-
Set the
protected-headers
parameter on theContent-Type
of MIME partnewbody
tov1
¶ -
If
crypto
does not contain encryption:¶-
Let
newheaders
be a copy oforigheaders
¶
-
-
Else (if
crypto
contains encryption):¶-
Create new empty list of Header Field names and values
newheaders
¶ -
Let
hpr
be an empty comma-separated list of Header Field names¶ -
For each Header Field name and value
(h,v)
inorigheaders
:¶ -
If
hpr
is not empty:¶-
Add Header Field "
HP-Removed
" to MIME partnewbody
with valuehpr
¶
-
-
-
Apply
crypto
to MIME partnewbody
, producing MIME treeoutput
¶ -
For each Header Field name and value
(h,v)
innewheaders
:¶-
Add Header Field
h
tooutput
with valuev
¶
-
-
Return
output
¶
Note that both new parameters (hcp
and legacy
) are effectively ignored if crypto
does not contain encryption.
This is by design, because they are irrelevant for signed-only cryptographic protections.¶
2.3.4.1. Adding a Legacy Display Element to a text/plain Part
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.¶
The MUA MUST also add a Content-Type
parameter of hp-legacy-display
with value 1
to the MIME part to indicate that a Legacy Display Element was added.¶
For example, if the list of obscured Header Fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")]
, then a text/plain
Main Body Part that originally looked like this:¶
Content-Type: text/plain; charset=UTF-8 I think we should skip the meeting.¶
Would become:¶
Content-Type: text/plain; charset=UTF-8; hp-legacy-display=1 Subject: Thursday's meeting Cc: alice@example.net I think we should skip the meeting.¶
Note that the Legacy Display Element (the lines beginning with Subject:
and Cc:
) are part of the body of the MIME part in question.¶
This example assumes that the Main Body Part in question is not the root of the Cryptographic Payload.
For instance, it could be a leaf of a multipart/alternative
Cryptographic Payload.
This is why no additional Header Fields have been injected into the MIME part in this example.¶
2.3.4.2. Adding a Legacy Display Element to a text/html Part
Adding a Legacy Display Element to a text/html
part is similar to how it is added to a text/plain
part (see Section 2.3.4.1).
Instead of adding the obscured or removed User-Facing Header Fields to a block of text delimited by a blank line, the composing MUA injects them in an HTML <div>
element annotated with a class
attribute of header-protection-legacy-display
.¶
The content and formatting of this decorative <div>
have no strict requirements, but they MUST represent all the obscured and removed User-Facing Header Fields in a readable fashion.
A simple approach is to assemble the text in the same way as Section 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.¶
The MUA MUST also add a Content-Type
parameter of hp-legacy-display
with value 1
to the MIME part to indicate that a Legacy Display Element was added.¶
For example, if the list of obscured Header Fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")]
, then a text/html
Main Body Part that originally looked like this:¶
Content-Type: text/html; charset=UTF-8 <html><head><title></title></head><body> <p>I think we should skip the meeting.</p> </body></html>¶
Would become:¶
Content-Type: text/html; charset=UTF-8; hp-legacy-display=1 <html><head><title></title></head><body> <div class="header-protection-legacy-display"> <pre>Subject: Thursday's meeting Cc: alice@example.net</pre></div> <p>I think we should skip the meeting.</p> </body></html>¶
This example assumes that the Main Body Part in question is not the root of the Cryptographic Payload.
For instance, it could be a leaf of a multipart/alternative
Cryptographic Payload.
This is why no additional Header Fields have been injected into the MIME part in this example.¶
2.3.4.2.1. Step-by-step Example for Inserting Legacy Display Element to text/html
A composing MUA MAY insert the Legacy Display Element anywhere reasonable within the message as long as it prioritizes visibility for the reader using a Legacy 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.¶
-
Assemble the text exactly as specified for
text/plain
(see Section 2.3.4.1).¶ -
Wrap that text in a verbatim
<pre>
element.¶ -
Wrap that
<pre>
element in a<div>
element annotated with the classheader-protection-legacy-display
.¶ -
Find the
<body>
element of the full HTML object.¶ -
Insert the
<div>
element as the first child of the<body>
element.¶
2.3.4.3. Only Add a Legacy Display Element to Main Body Parts
Some messages may contain a text/plain
or text/html
subpart that is not a Main Body Part.
For example, an 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.¶
2.3.4.4. Do Not Add a Legacy Display Element to Other Content-Types
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 MUAs that are capable of message decryption, but don't know how to follow the rest of the guidance in this document.¶
The authors are unaware of any Legacy MUA that would render any MIME part type other than text/plain
and text/html
as the Main Body.
A generating MUA SHOULD NOT add a Legacy Display Element to any MIME part with any other Content-Type
.¶
2.3.5. Composing with "Wrapped Message" Header Protection
The Wrapped Message Header Protection scheme is very similar to that described in Section 3.1 of [RFC8551]. The differences are outlined in Section 2.2.¶
To compose a message using "Wrapped Message" Header Protection, the composing MUA uses the following inputs:¶
-
All the inputs described in Section 2.3.1¶
-
hcp
: a Header Confidentiality Policy, as defined in Section 2.3.2¶
To build such a message, we replace the algorithm described in Section 2.3.1 with a more sophisticated approach. The algorithm for applying "Wrapped Message" cryptographic protection to a message is as follows:¶
-
Let
newbody
be a copy oforigbody
¶ -
For each Header Field name and value
(h,v)
inorigheaders
:¶-
Add Header Field
h
to MIME partnewbody
with valuev
¶
-
-
If
crypto
does not contain encryption:¶-
Let
newheaders
be a copy oforigheaders
¶
-
-
Else (if
crypto
contains encryption):¶-
Create new empty list of Header Field names and values
newheaders
¶ -
Let
hpr
be an empty comma-separated list of Header Field names¶ -
For each Header Field name and value
(h,v)
inorigheaders
:¶ -
If
hpr
is not empty:¶-
Add Header Field "
HP-Removed
" to MIME partnewbody
with valuehpr
¶
-
-
-
If any of the Header Fields in MIME part
newbody
, including Header Fields in the nested internal MIME structure, contain any 8-bit UTF-8 characters (see Section 3.7 of [RFC6532]):¶-
Let
payload
be a new MIME part with one Header Field:Content-Type: message/global; protected-headers=wrapped
, and whose body isnewbody
.¶
-
-
Else:¶
-
Let
payload
be a new MIME part with one Header Field:Content-Type: message/rfc822; protected-headers=wrapped
, and whose body isnewbody
.¶
-
-
Add a
Content-Disposition
Header Field to MIME partpayload
with valueinline
¶ -
Apply
crypto
to MIME partpayload
, producing MIME treeoutput
¶ -
For each Header Field name and value
(h,v)
innewheaders
:¶-
Add Header Field
h
tooutput
with valuev
¶
-
-
Return
output
¶
Note that the Header Confidentiality Policy hcp
parameter is effectively ignored if crypto
does not contain encryption.
This is by design, because it is irrelevant for signed-only cryptographic protections.¶
2.3.6. Choosing Between Wrapped Message and Injected Headers
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.¶
2.4. Default Header Confidentiality Policy
An MUA MUST have a default Header Confidentiality Policy that offers at least the protections provided by hcp_minimal
as described in Section 2.4.1.
Local policy and configuration may alter this default, but the MUA SHOULD NOT require the user to select an HCP.¶
hcp_minimal
provides confidentiality for the Subject
Header Field by replacing it with the literal string "[...]
".
This is a sensible minimal default because 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.¶
2.4.1. Minimal Header Confidentiality Policy
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.¶
2.4.2. Strong Header Confidentiality Policy
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.¶
2.4.3. Null Header Confidentiality Policy
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 conformant MUA that is not modified by local policy or configuration MUST NOT use hcp_null
by default.¶
2.4.4. Offering Stronger Header Confidentiality
An 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_hide_cc
, and hcp_strong
as a way to compare and contrast different possible behavioral choices for a composing MUA.
While the HCP is not strictly a protocol element, this document creates a registry of named Header Confidentiality Policies for ease of communication.¶
2.4.4.1. Expert Guidance for Registering Header Confidentiality Policies
There is no formal syntax specified for the Header Confidentiality Policy, but any attempt to specify an HCP for inclusion in the registry needs to provide:¶
-
a stable reference document clearly indicating the distinct name for the proposed HCP¶
-
pseudocode that other implementers can clearly and unambiguously interpret¶
-
a clear explanation of why this HCP is different from all other registered HCPs¶
-
any relevant considerations related to deployment of the HCP (for example, known or expected deliverability, rendering, or privacy challenges and possible mitigations)¶
An entry should not be marked as "Recommended" unless it has been shown to offer confidentiality or privacy improvements over the status quo and have minimal or mitigatable negative impact on messages to which it is applied, considering factors such as message deliverability and security.
Only one entry in the table (hcp_minimal
) is initially marked as "Recommended".
In the future, more than one entry may be marked as "Recommended".¶
2.5. Receiving Side
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
.¶
An MUA that knows how to handle a message with Header Protection makes the following two changes to its behavior when rendering a message:¶
-
If it detects that an incoming message had protected Header Fields, it renders Header Fields for the message from the protected Header Fields, ignoring the external (unprotected) Header Fields.¶
-
It includes information in the message's Cryptographic Summary to indicate the types of protection that applied to each rendered Header Field (if any).¶
An MUA that handles a message with Header Protection does not need to render any new Header Fields that it did not render before.¶
2.5.1. Identifying that a Message has Header Protection
An incoming message can be identified as having Header Protection based on one of two signals:¶
-
The Cryptographic Payload has
Content-Type: message/rfc822
orContent-Type: message/global
and the parameterprotected-headers
has a value ofwrapped
. See Section 2.5.4 for rendering guidance.¶ -
The Cryptographic Payload has some other
Content-Type
and it has parameterprotected-headers
set tov1
. 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.¶
2.5.2. Updating the Cryptographic Summary
Regardless of whether a cryptographically-protected message has protected Header Fields, the Cryptographic Summary of the message should be modified to indicate what protections the Header Fields have. This field-by-field status is complex and isn't necessarily intended to be presented in full to the user. Rather, it represents the state of the message internally within the MUA, and may be used to influence behavior like replying to 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.¶
2.5.3. Rendering a Message with Injected Headers
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.¶
2.5.3.1. Example Signed-only Message with Injected Headers
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.¶
2.5.3.2. Example Signed-and-Encrypted Message with Injected Headers
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 Header Fields 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.¶
2.5.3.3. Do Not Render Legacy Display Elements
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.¶
2.5.3.3.1. Identifying a Part with 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.¶
-
The subpart's Content-Type contains a parameter
hp-legacy-display
with value set to1
¶ -
The subpart's Content-Type is either
text/html
(see Section 2.5.3.3.3) ortext/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.¶
2.5.3.3.2. Omitting Legacy Display Elements from text/plain
If a text/plain
part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1"
, it should be processed before rendering in the following fashion:¶
-
Discard the leading lines of the body of the part up to and including the first entirely blank line.¶
Note that implementing this strategy is dependent on the charset used by the MIME part.¶
See Appendix D.1 for an example.¶
2.5.3.3.3. Omitting Legacy Display Elements from text/html
If a text/html
part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1"
, it should be processed before rendering in the following fashion:¶
-
If any element of the HTML
<body>
is a<div>
withclass
attributeheader-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; }¶
2.5.4. Rendering a Wrapped Message
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] as augmented by this document. 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.¶
2.5.4.1. Example Signed-Only Wrapped Message
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, unless it is rendering debugging information.¶
2.5.4.2. Example Signed-and-Encrypted Wrapped Message
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
.¶
2.5.5. Guidance for Automated Message Handling
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.¶
2.5.5.1. Interpret Only Protected Header Fields
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.¶
2.5.5.2. Ignore Legacy Display Elements
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 MUST identify when the MIME part contains a Legacy Display Element (see Section 2.5.3.3.1), and it MUST parse the relevant MIME part with the Legacy Display Element removed.¶
For example, consider an administrative interface of a confidential issue tracking software.
An authorized user can confidentially adjust the status of a tracked issue by a specially-formatted first line of the message body (for example, severity #183 serious
).
When the user's MUA encrypts a 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 lines comprising the Legacy Display Element (including the first blank line), and only then parses the remaining top line to look for the expected special formatting.¶
2.5.6. Affordances for Debugging and Troubleshooting
Note that advanced users of an MUA may need access to the original message, for example to troubleshoot problems with the rendering MUA itself, or problems with the SMTP transport path taken by the message.¶
An MUA that applies these rendering guidelines SHOULD ensure that the full original source of the message as it was received remains available to such a user for debugging and troubleshooting.¶
If a troubleshooting scenario demands information about the cryptographically-protected values of Header Fields, and the message is encrypted, the debugging interface SHOULD also provide a "source" view of the Cryptographic Payload itself, alongside the full original source of the message as received.¶
2.5.7. Rendering Other Schemes
Other MUAs may have generated different structures of messages that aim to offer end-to-end cryptographic protections that include Header Protection. This document is not normative for those schemes, and it is NOT RECOMMENDED to generate these other schemes, as they can either have structural flaws or simply render poorly on Legacy MUAs. A conformant MUA MAY attempt to infer Header Protection when rendering an existing message that appears to use some other scheme not documented here. Pointers to some known other schemes can be found in Appendix E.¶
2.5.8. Composing a Reply to an Encrypted Message with Header Protection
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.¶
2.5.8.1. Avoid Leaking Encrypted Header Fields in Reply
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 Header Fields for a reply message, the composing MUA can make use of the HP-Removed and HP-Obscured Header Fields from within the Cryptographic Envelope of the reference message to ensure that Header Fields 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
Header Fields.
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.¶
2.5.8.2. Avoid Misdirected Replies to Encrypted Messages with Header Protection
When replying to a message, the Composing MUA typically decides who to send the reply to based on:¶
-
the
Reply-To
,Mail-Followup-To
, orFrom
Header Fields¶ -
optionally, the other
To
orCc
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.¶
2.5.9. Implicitly-rendered Header Fields
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 MUST use the value from the protected Header Field, and SHOULD NOT use any value found outside the cryptographic protection unless it is known to be a Header Field added in transit, as specified in Section 2.5.10.¶
2.5.10. Unprotected Header Fields Added in Transit
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:¶
-
the Header Field would not have been known to the original sender, and¶
-
the Header Field might be rendered explicitly or implicitly,¶
then the MUA MAY decide to operate on the value of that Header Field from the 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.¶
2.5.10.1. Mailing list Header Fields: List-* and Archived-At
If the message arrives through a mailing list, the list manager itself may inject Header Fields (most 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.¶
2.5.11. Handling Undecryptable Messages
An MUA might receive an apparently encrypted message that it cannot currently decrypt. For example, when an MUA does not have regular access to the secret key material needed for decryption, it cannot know the cryptographically protected Header Fields, or even whether the message has any cryptographically protected Header Fields.¶
Such an undecrypted message will be rendered by the MUA as a message without any Header Protection. This means that the message summary may well change how it is rendered when the user is finally able to supply the secret key.¶
For example, the rendering of the Subject
Header Field in a mailbox summary might change from [...]
to the real message subject when the message is decrypted.
Or the message's placement in a message thread might change if, say, References
or In-Reply-To
have been removed or obscured (see Section 2.5.9).¶
Additionally, if the MUA does not retain access to the decrypting secret key, and it drops the decrypted form of a message, the message's rendering may revert to the encrypted form.
For example, if a MUA follows this behavior, the Subject
Header Field in a mailbox summary might change from the real message subject back to [...]
.
Or, the message might be yanked out of its current thread if the MUA loses access to a removed References
or In-Reply-To
header.¶
These behaviors are likely to surprise the user. However, an MUA has several possible ways of reducing or avoiding all of these surprises, including:¶
-
Ensuring that the MUA always has access to decryption-capable secret key material.¶
-
Rendering undecrypted messages in a special quarantine view until the decryption-capable secret key material is available.¶
To reduce or avoid the surprises associated with a decrypted message with removed or obscured Header Fields becoming undecryptable, the MUA could also:¶
-
Securely cache metadata from a decrypted message's protected Header Fields so that its rendering doesn't change after the first decryption.¶
-
Securely store the session key associated with a decrypted message, so that attempts to read the message when the long-term secret key are unavailable can proceed using only the session key itself. See, for example, the discussion about stashing session keys in Section 9.1 of [I-D.ietf-lamps-e2e-mail-guidance].¶
3. E-mail Ecosystem Evolution
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.¶
3.1. Dropping Legacy Display Elements
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 MUA.¶
Eventually, the hope is that most decryption-capable MUAs will conform to this specification, and there will be no need for injection of Legacy Display Elements in the message body. A survey of widely-used decryption-capable MUAs might be able to establish when most of them do support this specification.¶
At that point, a composing MUA could make the legacy
parameter described in Section 2.3.4 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.¶
3.2. Stronger Default Header Confidentiality Policy
This draft defines two different forms of Header Confidentiality Policy.
An 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 an 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.¶
3.3. Deprecation of Messages Without Header Protection
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 an 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 an MUA developer could roll them out immediately for any new message, but still treat an old message (based on the Date Header Field and cryptographic signature timestamp) more leniently.¶
A decision like this by any popular receiving MUA could drive adoption of this standard for sending MUAs.¶
4. Usability Considerations
This section describes concerns for MUAs that are interested in easy adoption of Header Protection by normal users.¶
While they are not protocol-level artifacts, these concerns motivate the protocol features described in this document.¶
See also the Usability commentary in Section 2 of [I-D.ietf-lamps-e2e-mail-guidance].¶
4.1. Mixed Protections Within a Message Are Hard To Understand
When rendering a message to the user, the ideal circumstance is to present a single cryptographic status for any given message. However, when message Header Fields are present, some message Header Fields do not have the same cryptographic protections as the main message.¶
Representing such a mixed set of protection statuses is very difficult to do in a way that a normal user can understand without training. There are at least three scenarios that are likely to be common, and poorly understood:¶
-
A signed message with no Header Protection.¶
-
A signed-and-encrypted message with no Header Protection.¶
-
An signed-and-encrypted message with Header Protection as described in this document, where some User-Facing Header Fields have confidentiality but some do not.¶
An MUA should have a reasonable strategy for clearly communicating each of these scenarios to the user. For example, an MUA operating in an environment where it expects most cryptographically-protected messages to have Header Protection could use the following rendering strategy:¶
-
When rendering a message with
signed-only
cryptographic status but no Header Protection, an MUA may decline to indicate a positive security status overall, and only indicate the cryptographic status to a user in a message properties or diagnostic view. That is, the message may appear identical to an unsigned message except if a user verifies the properties through a menu option.¶ -
When rendering a message with
signed-and-encrypted
orencrypted-only
cryptographic status but no Header Protection, overlay a warning flag on the typical cryptographic status indicator. That is, if a typicalsigned-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].¶ -
When rendering a message with
signed-and-encrypted
orencrypted-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.¶
4.2. Users Should Not Have To Choose a Header Confidentiality Policy
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.
An MUA should not expose the Ordinary User to a configuration option where they are expected to manually select (let alone define) an HCP.¶
4.3. Users Should Not Have To Choose a Header Protection Scheme
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 outbound cryptographically-protected messages.¶
This document recommends the Injected Headers scheme for generating messages with cryptographic protections, as described in Section 2. An 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.¶
5. Security Considerations
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.¶
The security considerations from Section 6 of [RFC8551] continue to apply for any MUA that offers S/MIME cryptographic protections, as well as Section 3 of [RFC5083] (Authenticated-Enveloped-Data in CMS) and Section 14 of [RFC5652] (CMS more broadly). Likewise, the security considerations from Section 8 of [RFC3156] continue to apply for any MUA that offers PGP/MIME cryptographic protections, as well as Section 13 of [I-D.ietf-openpgp-crypto-refresh-13] (OpenPGP itself). In addition, these underlying security considerations are now also applicable to the contents of the message header, not just the message body.¶
5.1. Caution about Composing with Legacy Display Elements
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 MUA 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 decryption-capable Legacy MUAs. When it is produced, it should be generated conservatively and narrowly, as described above, to avoid damaging the rest of the message.¶
6. Privacy Considerations
6.1. Some Encrypted Header Fields Are Not Always Private
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 (e.g. Date
might exist identically in both places).
Section 2.5.2 identifies such a Header Field as signed-only
.
These Header Fields are clearly not private at all, despite a copy being inside the Cryptographic Envelope.¶
A Header Field whose name 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 example, even if the Date
Header Field has been obscured, for example by normalizing the timezone to UTC or rounding to the most recent minute or hour (so that Header Field is formally signed-and-encrypted
), the MTAs which handle the message can of course record the time that they first encountered it, which is likely to be identical or very close to the original value of the field.¶
6.2. Header Fields Can Leak Unwanted Information to the Recipient
For encrypted messages, even with an aggressive 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:¶
-
The MUA may inject a
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.¶ -
The MUA may have an idiosyncratic way of generating a
Message-ID
header, which could embed the choice of MUA, a timezone, a hostname, or other subtle information to a knowledgeable recipient.¶ -
The MUA may erroneously include a
Bcc
Header Field in theorigheaders
of a copy of a message sent to the named recipient, defeating the purpose of usingBcc
instead ofCc
(see Section 6.3 for more details about risks related toBcc
).¶
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 populate the origheaders
list for any outbound message with only information recipient should 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.¶
6.2.1. Encrypted Header Fields Can Be Inferred From External or Internal Metadata
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:
.
Furthermore, encrypted message ciphertext may hint at the recipients: for S/MIME messages, the RecipientInfo
, and for PGP/MIME messages the key ID in the Public Key Encrypted Session Key (PKESK) packets will all hint at a specific set of recipients.
Additionally, an MTA that handles the message may add a Received:
Header Field (or some other custom Header Field) that leaks some information about the nature of the delivery.¶
6.2.2. HCP May Not Mask All Data in an Encrypted Header Field
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, Header Fields like Received
that are added during message delivery might include higher-resolution timestamps.
And if the message lands in a mailbox that is ordered by time of receipt, even its placement in the mailbox and the 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.¶
6.2.3. A Naive Recipient May Overestimate the Cryptographic Status of a Header Field in an Encrypted Message
When an encrypted (or signed-and-encrypted) message is in transit, an active intermediary can strip or tamper with any Header Field that appears outside the Cryptographic Envelope. A 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.¶
6.2.4. Summary and Implementation Guidance
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.¶
Despite the external inferrability of some encrypted
or signed-and-encrypted
Header Fields, the MUA should still strive to avoid additional leakage of these Header Fields, as described in Section 2.5.8.1.¶
6.3. Privacy and Deliverability Risks with Bcc and Encrypted Messages
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 Header Fields, then stripping the Bcc
field during encryption may cause the intervening transport agent to drop the message entirely.
This is why Bcc
is not explicitly stripped in hcp_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.
An MUA that is capable of receiving and processing such a message can infer that since their user's address was not mentioned in any To
or Cc
Header Field, they were likely a Bcc
recipient.¶
Please also see Section 9.3 of [I-D.ietf-lamps-e2e-mail-guidance] for more discussion about Bcc and encrypted messages.¶
7. IANA Considerations
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 |
---|---|---|---|---|
HP-Removed
|
standard | Section 2.3.3 of RFCXXXX | ||
HP-Obscured
|
standard | Section 2.3.3 of RFCXXXX |
The Author/Change Controller of these two entries (Section 4.5 of [RFC3864]) should be the IETF itself.¶
This document also defines the Content-Type
parameter known as protected-headers
.
Consequently, the Content-Type
row in the "Permanent Message Header Field Names" registry should add a reference to this RFC to its "References" column.¶
That is, the current row:¶
Header Field Name | Template | Protocol | Status | Reference |
---|---|---|---|---|
Content-Type
|
MIME | [RFC4021] |
Should be updated to have the following values:¶
Header Field Name | Template | Protocol | Status | Reference |
---|---|---|---|---|
Content-Type
|
MIME | [RFC4021] [RFCXXXX] |
This document also requests IANA to create a new registry in the "Mail Parameters" protocol group titled Mail Header Confidentiality Policies
with the following content:¶
Header Confidentiality Policy Name | Description | Reference | Recommended |
---|---|---|---|
hcp_null
|
No header confidentiality | RFCXXX (this document) | N |
hcp_minimal
|
Subject Header Field is obscured |
RFCXXX (this document) | Y |
hcp_strong
|
Remove or obscure everything but From , Date , To , and Cc
|
RFCXXX (this document) | N |
hcp_hide_cc
|
Obscure Subject , remove Cc
|
RFCXXX (this document) | N |
Please add the following textual note to this registry:¶
-
The Header Confidentiality Policy Name never appears on the wire. This registry merely tracks stable references to implementable descriptions of distinct policies. Any addition to this registry should be governed by guidance in Section 2.4.4.1 of RFC XXX (this document).¶
Adding an entry to this registry with an N
in the "Recommended" column follows the registration policy of SPECIFICATION REQUIRED.
Adding an entry to this registry with a Y
in the "Recommended" column or changing the "Recommended" column in an existing entry (from N
to Y
or vice versa) requires IETF REVIEW.
During IETF REVIEW, the designated expert must also be consulted.
Guidance for the designated expert can be found in Section 2.4.4.1.¶
8. Acknowledgments
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, Michael StJohns, Nicolas Lidzborski, Phillip Tao, Robert Williams, Roman Danyliw, Russ Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.¶
9. References
9.1. Normative References
- [I-D.ietf-lamps-e2e-mail-guidance]
- Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Guidance on End-to-End E-mail Security", Work in Progress, Internet-Draft, draft-ietf-lamps-e2e-mail-guidance-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-e2e-mail-guidance-15>.
- [I-D.ietf-lamps-header-protection-requirements]
- Melnikov, A. and B. Hoeneisen, "Problem Statement and Requirements for Header Protection", Work in Progress, Internet-Draft, draft-ietf-lamps-header-protection-requirements-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-header-protection-requirements-01>.
- [I-D.ietf-openpgp-crypto-refresh-13]
- Wouters, P., Huigens, D., Winter, J., and N. Yutaka, "OpenPGP", Work in Progress, Internet-Draft, draft-ietf-openpgp-crypto-refresh-13, , <https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-13>.
- [RFC2045]
- Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, , <https://www.rfc-editor.org/rfc/rfc2045>.
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
- [RFC3864]
- Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, , <https://www.rfc-editor.org/rfc/rfc3864>.
- [RFC5083]
- Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, , <https://www.rfc-editor.org/rfc/rfc5083>.
- [RFC5234]
- Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <https://www.rfc-editor.org/rfc/rfc5234>.
- [RFC5322]
- Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, , <https://www.rfc-editor.org/rfc/rfc5322>.
- [RFC5652]
- Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, , <https://www.rfc-editor.org/rfc/rfc5652>.
- [RFC8126]
- Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
- [RFC8174]
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
- [RFC8551]
- Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, , <https://www.rfc-editor.org/rfc/rfc8551>.
9.2. Informative References
- [chrome-indicators]
- Schechter, E., "Evolving Chrome's security indicators", , <https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html>.
- [CSS]
- World Wide Web Consortium, "Cascading Style Sheets Level 2 Revision 2 (CSS 2.2) Specification", , <https://www.w3.org/TR/2016/WD-CSS22-20160412/>.
- [HTML-ESCAPES]
- W3C, "Using character escapes in markup and CSS", n.d., <https://www.w3.org/International/questions/qa-escapes#use>.
- [I-D.autocrypt-lamps-protected-headers]
- Einarsson, B. R., "juga", and D. K. Gillmor, "Protected Headers for Cryptographic E-mail", Work in Progress, Internet-Draft, draft-autocrypt-lamps-protected-headers-02, , <https://datatracker.ietf.org/doc/html/draft-autocrypt-lamps-protected-headers-02>.
- [I-D.ietf-lamps-samples]
- Gillmor, D. K., "S/MIME Example Keys and Certificates", Work in Progress, Internet-Draft, draft-ietf-lamps-samples-08, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-samples-08>.
- [I-D.pep-email]
- Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Email Formats and Protocols", Work in Progress, Internet-Draft, draft-pep-email-02, , <https://datatracker.ietf.org/doc/html/draft-pep-email-02>.
- [I-D.pep-general]
- Birk, V., Marques, H., and B. Hoeneisen, "pretty Easy privacy (pEp): Privacy by Default", Work in Progress, Internet-Draft, draft-pep-general-02, , <https://datatracker.ietf.org/doc/html/draft-pep-general-02>.
- [PGPCONTROL]
- UUNET Technologies, Inc., "Authentication of Usenet Group Changes", , <https://ftp.isc.org/pub/pgpcontrol/>.
- [PGPVERIFY-FORMAT]
- Lawrence, D. C., "Signing Control Messages, Verifying Control Messages", n.d., <https://www.eyrie.org/~eagle/usefor/other/pgpverify>.
- [RFC2047]
- Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, , <https://www.rfc-editor.org/rfc/rfc2047>.
- [RFC2049]
- Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, DOI 10.17487/RFC2049, , <https://www.rfc-editor.org/rfc/rfc2049>.
- [RFC3156]
- Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, , <https://www.rfc-editor.org/rfc/rfc3156>.
- [RFC3851]
- Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, DOI 10.17487/RFC3851, , <https://www.rfc-editor.org/rfc/rfc3851>.
- [RFC4021]
- Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, DOI 10.17487/RFC4021, , <https://www.rfc-editor.org/rfc/rfc4021>.
- [RFC5751]
- Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, , <https://www.rfc-editor.org/rfc/rfc5751>.
- [RFC6376]
- Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, , <https://www.rfc-editor.org/rfc/rfc6376>.
- [RFC6532]
- Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, , <https://www.rfc-editor.org/rfc/rfc6532>.
- [RFC7489]
- Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, , <https://www.rfc-editor.org/rfc/rfc7489>.
- [RFC8617]
- Andersen, K., Long, B., Ed., Blank, S., Ed., and M. Kucherawy, Ed., "The Authenticated Received Chain (ARC) Protocol", RFC 8617, DOI 10.17487/RFC8617, , <https://www.rfc-editor.org/rfc/rfc8617>.
Appendix A. Possible Problems with some Legacy Clients
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.¶
A conformant MUA would not exhibit any of these problems. An implementer updating their Legacy MUA to be compliant with this specification should consider these concerns and try to avoid them.¶
A.2. Problems when Rendering a signed-and-encrypted Message
-
Unprotected Subject is visible¶
-
Protected subject (on its own) is visible in the body¶
-
Protected subject, date, from, to visible in the body¶
-
User interaction needed to view whole message¶
-
User interaction needed to view message body¶
-
User interaction needed to view protected subject¶
-
Impossible to view protected subject¶
-
Nuisance alarms during user interaction¶
-
Impossible to view message body¶
-
Appears as a forwarded message¶
-
Appears as an attachment¶
-
Security indicators not visible¶
-
User has multiple different methods to Reply: (e.g. reply to outer, reply to inner)¶
-
User sees English "Subject:" in body despite message itself being in non-English¶
-
Security indicators do not identify protection status of Header Fields¶
-
Header Fields in body render with local Header Field names (e.g. showing "Betreff" instead of "Subject") and dates (TZ, locale)¶
A.3. Problems when Replying to a signed-and-encrypted Message
Note that the use case here is:¶
-
User views message, to the point where they can read it.¶
-
User then replies to message, and they are shown a message composition window, which has some UI elements¶
-
If the MUA has multiple different methods to Reply: to a message, each way may need to be evaluated separately¶
This section also uses the shorthand UI:x to mean "the UI element that the user can edit that they think of as x."¶
-
protected subject is in UI:subject (and will leak)¶
-
protected subject is quoted in UI:body¶
-
protected subject is not anywhere in UI¶
-
message body is not visible/quoted in UI:body¶
-
user cannot reply while viewing protected message¶
-
reply is not encrypted by default (but is for normal S/MIME sign+enc messages)¶
-
unprotected From: is in UI:To¶
-
User's locale (lang, TZ) leaks in quoted body¶
-
Header Fields not protected (and in particular, Subject is not obscured) by default¶
A.5. Problems when Rendering a signed-only Message
-
Unprotected Subject is visible¶
-
Protected subject (on its own) is visible in the body¶
-
Protected subject, date, from, to visible in the body¶
-
User interaction needed to view whole message¶
-
User interaction needed to view message body¶
-
User interaction needed to view protected subject¶
-
Impossible to view protected subject¶
-
Nuisance alarms during user interaction¶
-
Impossible to view message body¶
-
Appears as a forwarded message¶
-
Appears as an attachment¶
-
Security indicators not visible¶
-
Security indicators do not identify protection status of Header Fields¶
-
User has multiple different methods to Reply: (e.g. reply to outer, reply to inner)¶
-
Header Fields in body render with local Header Fields (e.g. showing "Betreff" instead of "Subject") and dates (TZ, locale)¶
A.6. Problems when Replying to a signed-only Message
This uses the same use case(s) and shorthand as Appendix A.3.¶
Appendix B. Test Vectors
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.¶
B.1. Baseline Messages
These messages offer no header protection at all, and can be used as a baseline. They are provided in this document as a counterexample. An MUA implementer can use these messages to verify that the reported cryptographic summary of the message indicates no header protection.¶
B.1.1. No Cryptographic Protections Over a Simple Message
This message uses no cryptographic protection at all. Its body is a text/plain message.¶
It has the following structure:¶
└─╴text/plain 152 bytes¶
Its contents are:¶
B.1.2. S/MIME Signed-only signedData Over a Simple Message, No Header Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 3852 bytes ⇩ (unwraps to) └─╴text/plain 204 bytes¶
Its contents are:¶
B.1.3. S/MIME Signed-only multipart/signed Over a Simple Message, No Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└┬╴multipart/signed 4191 bytes ├─╴text/plain 224 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
B.1.4. S/MIME Encrypted and Signed Over a Simple Message, No Header Protection
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:¶
B.1.5. No Cryptographic Protections Over a Complex Message
This message uses no cryptographic protection at all. Its body is a multipart/alternative message with an inline image/png attachment.¶
It has the following structure:¶
└┬╴multipart/mixed 1406 bytes ├┬╴multipart/alternative 794 bytes │├─╴text/plain 206 bytes │└─╴text/html 304 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
B.1.6. S/MIME Signed-only signedData Over a Complex Message, No Header Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 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:¶
B.1.7. S/MIME Signed-only multipart/signed Over a Complex Message, No Header Protection
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└┬╴multipart/signed 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:¶
B.1.8. S/MIME Encrypted and Signed Over a Complex Message, No Header Protection
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:¶
B.2. Signed-only Messages
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.¶
B.2.1. S/MIME Signed-only signedData Over a Simple Message, Wrapped Message
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:¶
B.2.2. S/MIME Signed-only multipart/signed Over a Simple Message, Wrapped Message
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses the 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:¶
B.2.3. S/MIME Signed-only signedData Over a Simple Message, Injected Headers
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:¶
B.2.4. S/MIME Signed-only multipart/signed Over a Simple Message, Injected Headers
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:¶
B.2.5. S/MIME Signed-only signedData Over a Complex Message, Wrapped Message
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the 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:¶
B.2.6. S/MIME Signed-only multipart/signed Over a Complex Message, Wrapped Message
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses the 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:¶
B.2.7. S/MIME Signed-only signedData Over a Complex Message, Injected Headers
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:¶
B.2.8. S/MIME Signed-only multipart/signed Over a Complex Message, Injected Headers
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:¶
B.3. Encrypted-and-signed Messages
These messages are encrypted and signed. They use PKCS#7 signedData inside envelopedData, with different header protection schemes and different Header Confidentiality Policies.¶
B.3.1. S/MIME Encrypted and Signed Over a Simple Message, Wrapped Message With hcp_minimal
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:¶
B.3.2. S/MIME Encrypted and Signed Over a Simple Message, Injected Headers With hcp_minimal
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:¶
B.3.3. S/MIME Encrypted and Signed Over a Simple Message, Injected Headers With hcp_minimal (+ Legacy Display)
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:¶
B.3.4. S/MIME Encrypted and Signed Over a Simple Message, Wrapped Message With hcp_strong
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:¶
B.3.5. S/MIME Encrypted and Signed Over a Simple Message, Injected Headers With hcp_strong
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:¶
B.3.6. S/MIME Encrypted and Signed Over a Simple Message, Injected Headers With hcp_strong (+ Legacy Display)
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:¶
B.3.7. S/MIME Encrypted and Signed Reply Over a Simple Message, Wrapped Message With hcp_minimal
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:¶
B.3.8. S/MIME Encrypted and Signed Reply Over a Simple Message, Injected Headers With hcp_minimal
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:¶
B.3.9. S/MIME Encrypted and Signed Reply Over a Simple Message, Injected Headers With hcp_minimal (+ Legacy Display)
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:¶
B.3.10. S/MIME Encrypted and Signed Reply Over a Simple Message, Wrapped Message With hcp_strong
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:¶
B.3.11. S/MIME Encrypted and Signed Reply Over a Simple Message, Injected Headers With hcp_strong
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:¶
B.3.12. S/MIME Encrypted and Signed Reply Over a Simple Message, Injected Headers With hcp_strong (+ Legacy Display)
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:¶
B.3.13. S/MIME Encrypted and Signed Over a Complex Message, Wrapped Message With hcp_minimal
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:¶
B.3.14. S/MIME Encrypted and Signed Over a Complex Message, Injected Headers With hcp_minimal
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:¶
B.3.15. S/MIME Encrypted and Signed Over a Complex Message, Injected Headers With hcp_minimal (+ Legacy Display)
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:¶
B.3.16. S/MIME Encrypted and Signed Over a Complex Message, Wrapped Message With hcp_strong
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:¶
B.3.17. S/MIME Encrypted and Signed Over a Complex Message, Injected Headers With hcp_strong
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:¶
B.3.18. S/MIME Encrypted and Signed Over a Complex Message, Injected Headers With hcp_strong (+ Legacy Display)
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:¶
B.3.19. S/MIME Encrypted and Signed Reply Over a Complex Message, Wrapped Message With hcp_minimal
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:¶
B.3.20. S/MIME Encrypted and Signed Reply Over a Complex Message, Injected Headers With hcp_minimal
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:¶
B.3.21. S/MIME Encrypted and Signed Reply Over a Complex Message, Injected Headers With hcp_minimal (+ Legacy Display)
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:¶
B.3.22. S/MIME Encrypted and Signed Reply Over a Complex Message, Wrapped Message With hcp_strong
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:¶
B.3.23. S/MIME Encrypted and Signed Reply Over a Complex Message, Injected Headers With hcp_strong
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:¶
B.3.24. S/MIME Encrypted and Signed Reply Over a Complex Message, Injected Headers With hcp_strong (+ Legacy Display)
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:¶
Appendix C. Composition Examples
This section offers step-by-step examples of message composition.¶
C.1. New 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.¶
C.1.1. Unprotected message
The resulting message would look something like this if it was sent without cryptographic protections:¶
Date: Wed, 11 Jan 2023 16:08:43 -0500 From: Bob <bob@example.net> To: Alice <alice@example.net> Subject: Handling the Jones contract Message-ID: <20230111T210843Z.1234@lhp.example> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Please review and approve or decline by Thursday, it's critical! Thanks, Bob -- Bob Gonzalez ACME, Inc.¶
C.1.2. Encrypted with 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 "[...]
".¶
C.1.2.1. Cryptographic Payload
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:¶
-
the
protected-headers="v1"
parameter for theContent-Type
¶ -
the appropriate
HP-Obscured
header forSubject
,¶ -
the
hp-legacy-display="1"
parameter for theContent-Type
¶ -
the Legacy Display Element (the simple pseudo-header and its trailing newline) in the Main Body Part.¶
Date: Wed, 11 Jan 2023 16:08:43 -0500 From: Bob <bob@example.net> To: Alice <alice@example.net> Subject: Handling the Jones contract Message-ID: <20230111T210843Z.1234@lhp.example> Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; 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.¶
C.1.2.2. External Header Section
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.¶
Appendix D. Rendering Examples
This section offers example Cryptographic Payloads (the content within the Cryptographic Envelope) that contain Legacy Display Elements.¶
D.1. Example text/plain Cryptographic Payload with Legacy Display Elements
Here is a simple one-part Cryptographic Payload (Header Section and body) of a message that includes Legacy Display Elements:¶
Date: Fri, 21 Jan 2022 20:40:48 -0500 From: Alice <alice@example.net> To: Bob <bob@example.net> Subject: Dinner plans Message-ID: <text-plain-legacy-display@lhp.example> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; 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.¶
D.2. Example text/html Cryptographic Payload with Legacy Display Elements
Here is a modern one-part Cryptographic Payload (Header Section and body) of a message that includes Legacy Display Elements:¶
Date: Fri, 21 Jan 2022 20:40:48 -0500 From: Alice <alice@example.net> To: Bob <bob@example.net> Subject: Dinner plans Message-ID: <text-html-legacy-display@lhp.example> MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii"; hp-legacy-display="1"; 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.¶
Appendix E. Other Header Protection Schemes
Other Header Protection schemes have been proposed in the past. However, those typically have drawbacks such as sparse implementation, known problems with legacy interoperability (in particular with rendering), lack of clear signalling of sender intent, and/or incomplete cryptographic protections. This section lists such schemes known at the time of the publication of this document out of historical interest.¶
E.1. Original RFC 8551 Header Protection
S/MIME [RFC8551] (as well as its predecessors [RFC5751] and [RFC3851]) defined a form of cryptographic Header Protection that is similar to the "Wrapped Message" scheme specified in this document. In fact, the scheme originally defined in S/MIME is a subset of the "Wrapped Message" scheme specified in this document. The differences between the original and the updated scheme are outlined in Section 2.2.¶
E.2. Pretty Easy Privacy (pEp)
The pEp (pretty Easy privacy) [I-D.pep-general] project specifies two different MIME schemes that include Header Protection for Signed-and-Encrypted e-mail messages in [I-D.pep-email]: One scheme -- referred as pEp Email Format 1 (PEF-1) -- is generated towards MUAs not known to be pEp-capable, while the other scheme -- referred as PEF-2 -- is used between MUAs discovered to be compatible with pEp. Signed-only messages are not recommended in pEp.¶
E.3. "draft-autocrypt" Protected Headers
[I-D.autocrypt-lamps-protected-headers] describes a scheme similar to the "Injected Headers" scheme specified in this document. However, instead of adding Legacy Display Elements to existing MIME parts (cf. Section 2.3.4.1), "draft-autocrypt" injects a new MIME element "Legacy Display Part", thus modifying the MIME structure of the Cryptographic Payload.¶
Appendix F. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]]¶
-
draft-ietf-lamps-header-protection-20¶
-
draft-ietf-lamps-header-protection-19¶
-
improve text, capitalize defined terms, fix typos¶
-
Clean up from AD review:¶
-
updates RFC 8551 explicitly¶
-
add "Legacy Signed Message" and "Ordinary User" explicitly to terms¶
-
tighten up SHOULDs/MUSTs for conformant MUAs¶
-
expand references to other relevant Security Considerations¶
-
drop nudge about non-existent Content-Type Parameters registry¶
-
clarify IANA notes to align with table columns¶
-
explicitly request HCP registry¶
-
add references to other header protections schemes, but move all of them to appendix¶
-
-
draft-ietf-lamps-header-protection-18¶
-
only allow US-ASCII as modified output of HCP, adjusted ABNF to match¶
-
-
draft-ietf-lamps-header-protection-17¶
-
draft-ietf-lamps-header-protection-16¶
-
draft-ietf-lamps-header-protection-15¶
-
include clarifications, typos, etc from comments received during WGLC¶
-
-
draft-ietf-lamps-header-protection-14¶
-
draft-ietf-lamps-header-protection-13¶
-
Retitle from "Header Protection for S/MIME" to "Header Protection for Cryptographically Protected E-mail"¶
-
-
draft-ietf-lamps-header-protection-12¶
-
draft-ietf-lamps-header-protection-11¶
-
Remove most of the Bcc text (transferred general discussion to e2e-mail-guidance)¶
-
Fix bug in algorithm for generating HP-Obscured and HP-Removed¶
-
More detail about handling Reply messages¶
-
Considerations around handling risky Legacy Display Elements¶
-
Narrative descriptions of some worked examples¶
-
Describe potential leaks to recipients¶
-
Clarify debugging/troubleshooting UX affordances¶
-
-
draft-ietf-lamps-header-protection-10¶
-
Clarify that HCP doesn't apply to Structural Header Fields¶
-
Drop out-of-date "Open Issues" section¶
-
Brief commentary on UI of messages with intermediate/mixed protections¶
-
Deprecation prospects for messages without protected headers¶
-
Describe generating replies to encrypted messages with stronger HCP¶
-
-
draft-ietf-lamps-header-protection-09¶
-
draft-ietf-lamps-header-protection-08¶
-
draft-ietf-lamps-header-protection-07¶
-
move from legacy display MIME part to legacy display elements within main body part¶
-
-
draft-ietf-lamps-header-protection-06¶
-
draft-ietf-lamps-header-protection-05¶
-
fix multipart/signed wrapped test vectors¶
-
-
draft-ietf-lamps-header-protection-04¶
-
draft-ietf-lamps-header-protection-03¶
-
draft-ietf-lamps-header-protection-02¶
-
editorial changes / improve language¶
-
-
draft-ietf-lamps-header-protection-01¶
-
Add DKG as co-author¶
-
Partial Rewrite of Abstract and Introduction [HB/AM/DKG]¶
-
Adding definitions for Cryptographic Layer, Cryptographic Payload, and Cryptographic Envelope (reference to [I-D.ietf-lamps-e2e-mail-guidance]) [DKG]¶
-
Enhanced MITM Definition to include Machine- / Meddler-in-the-middle [HB]¶
-
Relaxed definition of Original message, which may not be of type "message/rfc822" [HB]¶
-
Move "memory hole" option to the Appendix (on request by Chair to only maintain one option in the specification) [HB]¶
-
Updated Scope of Protection Levels according to WG discussion during IETF-108 [HB]¶
-
Obfuscation recommendation only for Subject and Message-Id and distinguish between Encrypted and Unencrypted Messages [HB]¶
-
Removed (commented out) Header Field Flow Figure (it appeared to be confusing as is was) [HB]¶
-
-
draft-ietf-lamps-header-protection-00¶
-
Initial version (text partially taken over from [I-D.ietf-lamps-header-protection-requirements]¶
-