Internet-Draft | Header Protection S/MIME | March 2022 |
Gillmor, et al. | Expires 8 September 2022 | [Page] |
- Workgroup:
- LAMPS Working Group
- Internet-Draft:
- draft-ietf-lamps-header-protection-08
- Published:
- Intended Status:
- Standards Track
- Expires:
Header Protection for S/MIME
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 to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers.¶
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 8 September 2022.¶
Copyright Notice
Copyright (c) 2022 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 email Header Protection in S/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 structures for how message headers can be cryptographically protected, and provides guidance for implementers of MUAs that generate and interpret such messages. It 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 email header sections or fields and provides guidance to implementers.¶
One scheme is the form specified in S/MIME 3.1 and later, which involves wrapping a message/rfc822
or message/global
MIME object with a Cryptographic Envelope around the message to protect.
This document calls this scheme "Wrapped Message", and it is documented in more detail in [RFC8551].
Experience has shown that this form does not interact well with some legacy MUAs (see Section 1.2).¶
Consequently, another form of header protection is introduced, where the protected header fields are placed directly on the Cryptographic Payload, without using an intervening message/*
MIME object.
This document calls this scheme "Injected Headers", and it is documented in more detail in this document, in Section 2.3.3 and Section 2.5.3.¶
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 the worst cases, some mail user agents cannot render message/rfc822
message subparts at all, in violation of baseline MIME requirements as described on page 5 of [RFC2049].
This leaves all wrapped messages unreadable by any recipient using such a MUA.¶
In other cases, the user sees an attachment suggesting a forwarded email message, which -- in fact -- contains the protected email message that should be rendered directly. In most of these cases, the user can click on the attachment to view the protected message.¶
However, viewing the protected message as an attachment in isolation may strip it of any security indications, leaving the user unable to assess the cryptographic properties of the message. Worse, for encrypted messages, interacting with the protected message in isolation may leak contents of the cleartext, for example, if the reply is not also encrypted.¶
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 headers 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 clients to the extent possible. In some cases, like when a user-visible header like the Subject is cryptographically hidden, the message cannot behave entirely identically to a legacy client. But accommodations are described here that ensure a rough semantic equivalence for legacy clients even in these cases.¶
1.4.2. Deliverability
A message that cannot be delivered is less useful than a message with perfect cryptographic protections. 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 Email Header Fields
A separate pair of protocols also provides some cryptographic protection for the email message header integrity: DomainKeys Identified Mail (DKIM) [RFC6376], as used in combination with Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489]. This pair of protocols provides a domain-based reputation mechanism that can be used to mitigate some forms of unsolicited email (spam).¶
However, the DKIM+DMARC suite provides cryptographic protection at a different scope 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 DKIM+DMARC not provide end-to-end protection. DKIM+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, DKIM+DMARC only provides cryptographic integrity and authentication, not encryption. So cryptographic confidentiality is not available from that suite.¶
DKIM+DMARC can be used on any message, including messages formed as described in this document. There should be no conflict between these schemes.¶
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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
1.8. Terms
The following terms are defined for the scope of this document:¶
- S/MIME: Secure/Multipurpose Internet Mail Extensions (see [RFC8551])¶
- PGP/MIME: MIME Security with OpenPGP (see [RFC3156])¶
-
Message: An Email 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 is a line beginning with a field name, followed by a colon (":"), followed by a field body (value), and terminated by CRLF; see [RFC5322].¶
- Header Section: The Header Section is a sequence of lines of characters with special syntax as defined in [RFC5322]. It is the top section of a Message, and it contains the Header Fields associated with the Message itself.¶
- 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: cryptographic protection of email Header Sections (or parts of it) for signatures and/or encryption¶
- Cryptographic Layer, Cryptographic Payload, Cryptographic Envelope, Structural Headers, Main Body Part, User-Facing Headers, and MUA are all used as defined in [I-D.ietf-lamps-e2e-mail-guidance]¶
- Legacy MUA: a 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.¶
- 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. (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: a functional specification of which header fields should be obscured when composing an encrypted message with header protection. See Section 2.3.2.¶
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 headers as well as its body.¶
This document also describes sensible, simple behavior for a program that interprets such a message, in a way that can take advantage of these protections covering the header fields as well as the body.¶
The message generation guidance aims to minimize negative interactions with any legacy receiving client while providing actionable cryptographic properties for modern receiving clients.¶
In particular, this document focuses on two standard types of cryptographic protection that cover the entire message:¶
- A cleartext message with a single signature, and¶
- An encrypted message that contains a single cryptographic signature.¶
1.9.1. Out of Scope
While the generation guidance aims to provide minimal disruption for any legacy client, such a client by definition does not implement this document.¶
Therefore, the document does not attempt to provide guidance for legacy clients.¶
Furthermore, this document does not explicitly contemplate unusual (and tricky) 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.¶
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.3), and MAY generate the Wrapped Message scheme (Section 2.3.4).¶
2.1. Injected Headers Scheme
The Injected Headers scheme places all header fields to be protected directly into 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 Cryptograhic Payload itself. These decorative copies within the message are known as "legacy display elements".¶
Composing a message with the Injected Headers scheme is described in Section 2.3.3. Rendering such a message is described in Section 2.5.3.¶
2.2. Wrapped Message Scheme
The Wrapped Message scheme creates a message/rfc822
(or message/global
) MIME object containing the message and all header fields to be protected, and then uses that encapsulated MIME part as the Cryptographic Payload.¶
Composing a message with the Wrapped Message scheme is described in Section 2.3.4. 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
[I-D.ietf-lamps-e2e-mail-guidance] describes the typical process for a legacy crypto MUA to apply cryptographic protections to an e-mail message. That guidance and terminology is replicated here for reference:¶
-
origbody
: the traditional unprotected message body as a well-formed MIME tree (possibly just a single MIME leaf part). As a well-formed MIME tree,origbody
already has structural headers (Content-*
) present.¶ -
origheaders
: the intended non-structural headers for the message, represented here as a list of(h,v)
pairs, 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 header field namename
and initial valueval_in
as arguments, and returns a replacement header valueval_out
. Ifval_out
is the special valuenull
, it mean that the header field in question should be omitted from the set of header fields visible outside the Cryptographic Envelope.¶
For example, an MUA that only obscures the Subject
header field by replacing it with the literal string [...]
and does not offer confidentiality to any other header fields would be represented as (in pseudocode):¶
hcp(name, val_in) → val_out: if name is 'Subject': return '[...]' 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.¶
2.3.3. 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 needs one additional input in addition to the Header Confidentiality Policy hcp
defined in Section 2.3.2.¶
-
legacy
: a boolean value, indicating whether any recipient of the message is believed to have a legacy client. If all recipients are known to implement this draft,legacy
should be set tofalse
. (How a 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 [I-D.ietf-lamps-e2e-mail-guidance] for guidance on identifying the parts of a message that are a Main Body Part.¶
The revised algorithm for applying cryptographic protection to a message is as follows:¶
-
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 [I-D.ietf-lamps-e2e-mail-guidance]):¶
-
-
If
ldlist
is not empty:¶- Identify each leaf MIME part of
payload
that represents the "main body" of the message.¶ -
For each "Main Body Part"
bodypart
of typetext/plain
ortext/html
:¶- Insert Legacy Display element header list
ldlist
into the content ofbodypart
(see Section 2.3.3.1 fortext/plain
and Section 2.3.3.2 fortext/html
)¶ - Add
Content-Type
parameterhp-legacy-display
with value1
tobodypart
¶
- Insert Legacy Display element header list
- Identify each leaf MIME part of
- Create
-
For each header field name and value
(h,v)
inorigheaders
:¶- Add header field
h
of MIME partpayload
with valuev
¶
- Add header field
- Set the
protected-headers
parameter on theContent-Type
ofpayload
tov1
¶ - Apply
crypto
topayload
, producing MIME treeoutput
¶ -
If
crypto
contains encryption:¶ -
For each header field name and value
(h,v)
inorigheaders
:¶- Add header field
h
ofoutput
with valuev
¶
- Add header field
- 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.3.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.¶
For example, if the list of obscured header fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")]
, then a text/plain
part that originally contained:¶
I think we should skip the meeting.¶
Would become:¶
Subject: Thursday's meeting Cc: alice@example.net I think we should skip the meeting.¶
2.3.3.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.3.1).
Instead of adding the obscured header fields to a block of text delimited by a blank line, the composing MUA injects them in an HTML <div>
element annotated with a class
attribute of header-protection-legacy-display
.¶
The content and formatting of this decorative <div>
have no strict requirements, but they SHOULD represent all the obscured header fields in a readable fashion.
A simple approach is to assemble the text in the same way as Section 2.3.3.1, wrap it in a verbatim <pre>
element, and put that element in the annotated <div>
.¶
The annotated <div>
should be placed as close to the start of the <body>
as possible, where it will be visible when viewed with a standard HTML renderer.¶
For example, if the list of obscured header fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")]
, then a text/html
part that originally contained:¶
<html><head><title></title></head><body> <p>I think we should skip the meeting.</p> </body></html>¶
Would become:¶
<html><head><title></title></head><body> <div class="header-protection-legacy-display"> <pre>Subject: Thursday's meeting Cc: alice@example.net</pre></div> <p>I think we should skip the meeting.</p> </body></html>¶
2.3.3.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 [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.3.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 clients that are capable of message decryption, but don't know how to follow the rest of the guidance in this document.¶
The authors are unaware of any legacy client that would render any MIME part type other than text/plain
and text/html
as the Main Body.
A generating MUA SHOULD NOT add a Legacy Display element to any MIME part with any other Content-Type
.¶
2.3.4. Composing with "Wrapped Message" Header Protection
The Wrapped Message header protection scheme is briefly documented in Section 3.1 [RFC8551].
This section provides a more detailed explanation of how to build such a message, and augments it with the forwarded
parameter as described in [I-D.melnikov-iana-reg-forwarded].¶
To compose a message using "Wrapped Message" header protection, we use those inputs described in Section 2.3.1 plus the Header Confidentiality Policy hcp
defined in Section 2.3.2.
The new algorithm is:¶
-
For header field name and value
(h,v)
inorigheaders
:¶- Add header field
h
oforigbody
with valuev
¶
- Add header field
-
If any of the header fields in
origbody
, including header fields in the nested internal MIME structure, contain any 8-bit UTF-8 characters (see section section 3.7 of [RFC6532]):¶- Let
payload
be a new MIME part with one header field:Content-Type: message/global; forwarded=no
, and whose body isorigbody
.¶
- Let
-
Else:¶
- Let
payload
be a new MIME part with one header field:Content-Type: message/rfc822; forwarded=no
, and whose body isorigbody
.¶
- Let
- Apply
crypto
topayload
, yielding MIME treeoutput
¶ -
If
crypto
contains encryption:¶ -
For header field name and value
(h,v)
inorigheaders
:¶- Add header field
h
ofoutput
with valuev
¶
- Add header field
- Return
output
¶
Note that the Header Confidentiality Policy hcp
is ignored if crypto
does not contain encryption.
This is by design.¶
2.3.5. 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.3 format.¶
2.4. Default Header Confidentiality Policy
An MUA SHOULD have a sensible default Header Confidentiality Policy, and SHOULD NOT require the user to select one.¶
The default Header Confidentiality Policy SHOULD provide confidentiality for the Subject
header field by replacing it with the literal string [...]
.
Most users treat the Subject of a message the same way that they treat the body, and they are surprised to find that the Subject of an encrypted message is visible.¶
[[ TODO: select one of the two policies below the recommended default ]]¶
2.4.1. Minimalist Header Confidentiality Policy
Accordingly, the most conservative recommended Header Confidentiality Policy only protects the Subject
:¶
hcp_minimal(name, val_in) → val_out: if name is 'Subject': return '[...]' else: return val_in¶
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.¶
2.4.3. Offering Stronger Header Confidentiality
A MUA MAY offer even stronger confidentiality for header fields of an encrypted message than described in Section 2.4.2.
For example, it might implement an HCP that obfuscates the From
field, or omits the Cc
field, or ensures Date
is represented in UTC
(obscuring the local timezone).¶
The authors of this document hope that implementers with deployment experience will document their chosen Header Confidentiality Policy and the rationale behind their choice.¶
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 [I-D.ietf-lamps-e2e-mail-guidance]) provide a summary of the cryptographic properties of the message.¶
Most MUAs only render a subset of header fields by default.
For example, few MUAs typically render Message-Id
or Received
header fields for the user, but most do render From
, To
, Cc
, Date
, and Subject
.¶
A MUA that knows how to handle a message with header protection makes the following two changes to its behavior when rendering a message:¶
- 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).¶
A 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 parameterforwarded
has a value ofno
. 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.¶
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
.¶
Rendering this information 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.¶
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.
As in Section 2.5.4.2, each rendered header field found in G
should be compared against the header field of the same name from E
.
If the value found in E
matches the value found in G
, the header field should be marked as signed-only
.
If no matching header field was found in E
, or the value found did not match the value from G
, the header field should be marked as signed-and-encrypted
.¶
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 or generating a draft reply.¶
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 with 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.¶
A straightforward way for an HTML-capable MUA to do this is 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]. 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 forwarded
is set to no
, 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.¶
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.
Each rendered header field found in Q
should be compared against the header field of the same name from O
.
If the value found in O
matches the value found in Q
, the header field should be marked as signed-only
.
If no matching header field was found in O
, or the value found did not match the value from Q
, the header field should be marked as signed-and-encrypted
.¶
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 mssages and scans the relevant MIME part SHOULD identify when the MIME part contains a legacy display element (see Section 2.5.3.3.1), and it SHOULD parse the relevant MIME part with the legacy display element removed.¶
For example, consider an administrative interface of a confidential issue tracking software.
An authorized user can confidentially adjust the status of a tracked issue by a specially-formatted first line of the message body (for example, severity #183 serious
).
When the user's MUA encrypts a plain text control message to this issue tracker, depending on the MUA's HCP and its choice of legacy
value, it may add a legacy display element.
If it does so, then the first line of the message body will contain a decorative copy of the confidential Subject:
header field.
The issue tracking software decrypts the incoming control message, identifies that there is a legacy display element in the part (see Section 2.5.3.3.1), strips the legacy display lines (including the first blank line), and only then parses the remaining top line to look for the expected special formatting.¶
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 MUA itself, or problems with the SMTP transport path taken by the message.¶
A MUA that applies these rendering guidelines SHOULD ensure that the full original source of the message as it was received remains available to such a user for debugging and troubleshooting.¶
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.¶
While this document is not normative for those schemes, it offers guidance for how to identify and handle these other formats. In the following a list of systems that are known to generate email messages with end-to-end cryptographic protections that include header protection using a different MIME scheme.¶
2.5.7.1. Pretty Easy Privacy (pEp)
The pEp (pretty Easy privacy) [I-D.pep-general] project specifies MIME schemes for Signed-and-Encrypted email messages that also provide header protection [I-D.pep-email]. Similar to the "Wrapped Messages" scheme described in Section 2.3.4 and Section 2.5.4, pEp email messages are fully encapsulated in the Cryptographic Payload.¶
More information can be found in [I-D.pep-email].¶
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 Headers in Reply
As noted in [I-D.ietf-lamps-e2e-mail-guidance], an MUA in this position MUST NOT leak previously-encrypted content in the clear in a followup message. The same is true for protected header fields.¶
Values from any header field that was identified as either encrypted
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.¶
[[ TODO: formally describe how a replying MUA should generate a message-specific Header Protection policy based on the cryptographic status of the headers of the incoming message ]]¶
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 SHOULD use the value from the protected header field, and SHOULD NOT use any value found outside the cryptographic protection.¶
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 (e.g., to test whether they are covered by a valid DKIM-Signature
, see [RFC6376]) before rendering or acting on them.¶
Specific examples 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.¶
FIXME: other examples of unprotected transit header fields?¶
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 client.¶
Eventually, the hope is that most decryption-capable MUAs will conform to this specification, and there will be no need for injection of Legacy Display elements in the message body. A survey of widely-used decryption-capable MUAs might be able to establish when most of them do support this specification.¶
At that point, a composing MUA could make the legacy
parameter described in {#compose-injected-headers} to false
by default, or could even hard-code it to false
, yielding a much simpler message construction set.¶
Until that point, an end user might want to signal that their receiving MUAs are conformant to this draft so that a peer composing a message to them can set legacy
to false
.
A signal indicating capability of handling messages with header protection might be placed in the user's cryptographic certificate, or in outbound messages.¶
This draft doesn't attempt to define the syntax or semantics of such a signal.¶
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 section in [I-D.ietf-lamps-e2e-mail-guidance].¶
5. Security Considerations
[[ TODO ]]¶
6. Privacy Considerations
[[ TODO ]]¶
7. IANA Considerations
This document requests no action from IANA.¶
[[ RFC Editor: This section may be removed before publication. ]]¶
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, Claudio Luck, David Wilson, Hernani Marques, juga, Krista Bennett, Kelly Bristol, Lars Rohwedder, Robert Williams, 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., "Guidance on End-to-End E-mail Security", Work in Progress, Internet-Draft, draft-ietf-lamps-e2e-mail-guidance-02, , <https://www.ietf.org/archive/id/draft-ietf-lamps-e2e-mail-guidance-02.txt>.
- [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://www.ietf.org/archive/id/draft-ietf-lamps-header-protection-requirements-01.txt>.
- [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/info/rfc2045>.
- [RFC2046]
- Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, , <https://www.rfc-editor.org/info/rfc2046>.
- [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/info/rfc2119>.
- [RFC5322]
- Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, , <https://www.rfc-editor.org/info/rfc5322>.
- [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/info/rfc8551>.
9.2. Informative References
- [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/>.
- [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://www.ietf.org/archive/id/draft-ietf-lamps-samples-08.txt>.
- [I-D.melnikov-iana-reg-forwarded]
- Melnikov, A. and B. Hoeneisen, "IANA Registration of Content-Type Header Field Parameter 'forwarded'", Work in Progress, Internet-Draft, draft-melnikov-iana-reg-forwarded-00, , <https://www.ietf.org/archive/id/draft-melnikov-iana-reg-forwarded-00.txt>.
- [I-D.pep-email]
- Marques, H., "pretty Easy privacy (pEp): Email Formats and Protocols", Work in Progress, Internet-Draft, draft-pep-email-01, , <https://www.ietf.org/archive/id/draft-pep-email-01.txt>.
- [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-00, , <https://www.ietf.org/archive/id/draft-pep-general-00.txt>.
- [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/info/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/info/rfc3156>.
- [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/info/rfc6376>.
- [RFC6532]
- Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, , <https://www.rfc-editor.org/info/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/info/rfc7489>.
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.¶
Hopefully, a non-legacy MUA would not exhibit any of these problems. An implementer updating their legacy MUA to be compliant with this specification should consider these concerns and try to avoid them.¶
A.2. Problems when Rendering a signed+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+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 4156 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 1371 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 5199 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] 4213 bytes ⇩ (unwraps to) └┬╴message/rfc822 566 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 4451 bytes ├┬╴message/rfc822 596 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] 4185 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 4417 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] 5631 bytes ⇩ (unwraps to) └┬╴message/rfc822 1613 bytes └┬╴multipart/mixed 1549 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 5542 bytes ├┬╴message/rfc822 1671 bytes │└┬╴multipart/mixed 1607 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] 5651 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1579 bytes ├┬╴multipart/alternative 950 bytes │├─╴text/plain 292 bytes │└─╴text/html 387 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 5510 bytes ├┬╴multipart/mixed 1637 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] 7345 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4436 bytes ⇩ (unwraps to) └┬╴message/rfc822 679 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] 7305 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4406 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] 7565 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4584 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] 7345 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4432 bytes ⇩ (unwraps to) └┬╴message/rfc822 675 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] 7305 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4402 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] 7540 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4576 bytes ⇩ (unwraps to) └─╴text/plain 419 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] 7605 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4626 bytes ⇩ (unwraps to) └┬╴message/rfc822 816 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] 7585 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4600 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] 7845 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4806 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] 7605 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4616 bytes ⇩ (unwraps to) └┬╴message/rfc822 810 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] 7565 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4592 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] 7845 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4794 bytes ⇩ (unwraps to) └─╴text/plain 431 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] 9470 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6002 bytes ⇩ (unwraps to) └┬╴message/rfc822 1819 bytes └┬╴multipart/mixed 1755 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] 9515 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6028 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1785 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] 10100 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6456 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2094 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] 9470 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5994 bytes ⇩ (unwraps to) └┬╴message/rfc822 1813 bytes └┬╴multipart/mixed 1749 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] 9490 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6020 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1779 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] 10075 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6444 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2086 bytes ├┬╴multipart/alternative 1425 bytes │├─╴text/plain 481 bytes │└─╴text/html 633 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] 9775 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6222 bytes ⇩ (unwraps to) └┬╴message/rfc822 1978 bytes └┬╴multipart/mixed 1914 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] 9815 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6250 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1946 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] 10445 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6720 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2283 bytes ├┬╴multipart/alternative 1455 bytes │├─╴text/plain 497 bytes │└─╴text/html 649 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] 9750 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6210 bytes ⇩ (unwraps to) └┬╴message/rfc822 1970 bytes └┬╴multipart/mixed 1906 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] 9795 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6238 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1938 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] 10425 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6704 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2273 bytes ├┬╴multipart/alternative 1449 bytes │├─╴text/plain 493 bytes │└─╴text/html 645 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
Appendix C. Additional information
C.1. Stored Variants of Messages with Bcc
Messages containing at least one recipient address in the Bcc header field may appear in up to three different variants:¶
- The Message for the recipient addresses listed in To or Cc header fields, which must not include the Bcc header field neither for signature calculation nor for encryption.¶
-
The Message(s) sent to the recipient addresses in the Bcc header field, which depends on the implementation:¶
a) One Message for each recipient in the Bcc header field separately, with a Bcc header field containing only the address of the recipient it is sent to.¶
b) The same Message for each recipient in the Bcc header field with a Bcc header field containing an indication such as "Undisclosed recipients", but no addresses.¶
c) The same Message for each recipient in the Bcc header field which does not include a Bcc header field (this Message is identical to 1. / see above).¶
- The Message stored in the 'Sent'-Folder of the sender, which usually contains the Bcc unchanged from the original Message, i.e., with all recipient addresses.¶
The most privacy preserving method of the alternatives (2a, 2b, and 2c) is to standardize 2a, as in the other cases (2b and 2c), information about hidden recipients is revealed via keys. In any case, the Message has to be cloned and adjusted depending on the recipient.¶
Appendix D. 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 (headers and body) of a message that includes Legacy Display elements:¶
Date: Fri, 21 Jan 2022 20:40:48 -0500 From: Alice <alice@example.net> To: Bob <bob@example.net> Subject: Dinner plans Message-ID: <text-plain-legacy-display@lhp.example> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; protected-headers="v1" Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A compatible MUA will recognize the hp-legacy-display="1"
parameter and render the body of the message as:¶
Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A legacy decryption-capable MUA that is unaware of this mechanism will ignore the hp-legacy-display="1"
parameter and instead render the body including the Legacy Display elements:¶
Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
D.2. Example text/html Cryptographic Payload with Legacy Display Elements
Here is a modern one-part Cryptographic Payload (headers and body) of a message that includes Legacy Display elements:¶
Date: Fri, 21 Jan 2022 20:40:48 -0500 From: Alice <alice@example.net> To: Bob <bob@example.net> Subject: Dinner plans Message-ID: <text-html-legacy-display@lhp.example> MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii"; hp-legacy-display="1"; protected-headers="v1" <html><head><title></title></head><body> <div class="header-protection-legacy-display"> <pre>Subject: Dinner plans</pre> </div> <p> Let's meet at Rama's Roti Shop at 8pm and go to the park from there. </p> </body> </html>¶
A compatible MUA will recognize the hp-legacy-display="1"
parameter and mask out the Legacy Display div
, rendering the body of the message as a simple paragraph:¶
Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A legacy decryption-capable MUA that is unaware of this mechanism will ignore the hp-legacy-display="1"
parameter and instead render the body including the Legacy Display elements:¶
Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
Appendix E. Document Considerations
[[ RFC Editor: This section is to be removed before publication ]]¶
This draft is built from markdown source, and its development is tracked in a git repository.¶
You may also be interested in the latest editor's copy.¶
While minor editorial suggestions and nit-picks can be made as merge
requests, please
direct all substantive discussion to the LAMPS mailing
list at spasm@ietf.org
.¶
Appendix F. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]]¶
-
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]¶
Appendix G. Open Issues
[[ RFC Editor: This section should be empty and is to be removed before publication. ]]¶
- Ensure "protected header" (Ex-Memory-Hole) option is (fully) compliant with the MIME standard, in particular also [RFC2046], Section 5.1. (Multipart Media Type).¶
- Decide on whether or not merge requirements from [I-D.ietf-lamps-header-protection-requirements] into this document.¶
- Decide on whether or not specification for more legacy HP requirements should be added to this document.¶
- Verify ability to distinguish between Messages with Header Protection as specified in this document and messages without header protection, and update receiving guidance accordingly.¶
- Privacy Considerations Section 6¶
- Security Considerations Section 5¶