Internet-Draft | Header Protection S/MIME | March 2022 |
Gillmor, et al. | Expires 8 September 2022 | [Page] |
S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message.¶
This document updates the S/MIME specification to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers.¶
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 (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.¶
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.¶
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.¶
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.¶
A legacy MUA dealing with an encrypted message that has some header fields obscured using the Injected Headers scheme will not render the obscured header fields to the user at all. A workaround "legacy display" mechanism is provided in this document, which most legacy MUAs should render to the user, albeit not in the same location that the header fields would normally be rendered.¶
Users generally do not understand the distinction between message body and message header. When an e-mail message has cryptographic protections that cover the message body, but not the header fields, several attacks become possible.¶
For example, a legacy signed message has a signature that covers the body but not the header fields. An attacker can therefore modify the header fields (including the Subject header) without invalidating the signature. Since most readers consider a message body in the context of the message's Subject header, the meaning of the message itself could change drastically (under the attacker's control) while still retaining the same cryptographic indicator of authenticity.¶
In another example, a legacy encrypted message has its body effectively hidden from an adversary that snoops on the message. But if the header fields are not also encrypted, significant information about the message (such as the message Subject) will leak to the inspecting adversary.¶
However, if the sending and receiving MUAs ensure that cryptographic protections cover the message headers as well as the message body, these attacks are defeated.¶
If the sending MUA is unwilling to generate such a fully-protected message due to the potential for rendering, usability, deliverability, or security issues, these defenses cannot be realized.¶
The sender cannot know what MUA (or MUAs) the recipient will use to handle the message. Thus, an outbound message format that is backward-compatible with as many legacy implementations as possible is a more effective vehicle for providing the whole-message cryptographic protections described above.¶
This document aims for backward compatibility with legacy clients to the extent possible. In some cases, like when a user-visible header like the Subject is cryptographically hidden, the message cannot behave entirely identically to a legacy client. But accommodations are described here that ensure a rough semantic equivalence for legacy clients even in these cases.¶
A message 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.¶
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.¶
This document describes end-to-end cryptographic protections for e-mail messages in reference to S/MIME ([RFC8551]).¶
Comparable end-to-end cryptographic protections can also be provided by PGP/MIME ([RFC3156]).¶
The mechanisms in this document should be applicable in the PGP/MIME protections as well as S/MIME protections, but analysis and implementation in this document focuses on S/MIME.¶
To the extent that any divergence from the mechanism described here is necessary for PGP/MIME, that divergence is out of scope for this document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
The following terms are defined for the scope of this document:¶
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.¶
message/rfc822
or message/global
MIME object.
(see Section 2.2).¶
This document describes sensible, simple behavior for a program that generates an e-mail message with standard end-to-end cryptographic protections, following the guidance in [I-D.ietf-lamps-e2e-mail-guidance]. An implementation conformant to this draft will produce messages that have cryptographic protection that covers the message's headers as well as its body.¶
This document also describes sensible, simple behavior for a program that interprets such a message, in a way that can take advantage of these protections covering the header fields as well as the body.¶
The message generation guidance aims to minimize negative interactions with any legacy receiving client while providing actionable cryptographic properties for modern receiving clients.¶
In particular, this document focuses on two standard types of cryptographic protection that cover the entire message:¶
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:¶
All such messages are out of scope.¶
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).¶
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.¶
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.¶
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.¶
[I-D.ietf-lamps-e2e-mail-guidance] describes the typical process for a legacy crypto MUA to apply cryptographic protections to an e-mail message. That guidance and terminology is replicated here for reference:¶
origbody
: the traditional unprotected message body as a well-formed MIME tree (possibly just a single MIME leaf part).
As a well-formed MIME tree, origbody
already has structural headers (Content-*
) present.¶
origheaders
: the intended non-structural headers for the message, represented here as a list of (h,v)
pairs, where h
is a header field name and v
is the associated value.
Note that these are header fields that the MUA intends to be visible to the recipient of the message.
In particular, if the MUA uses the Bcc
header during composition, but plans to omit it from the message (see section 3.6.3 of [RFC5322]), it will not be in origheaders
.¶
crypto
: The series of cryptographic protections to apply (for example, "sign with the secret key corresponding to X.509 certificate X, then encrypt to X.509 certificates X and Y").
This is a routine that accepts a MIME tree as input (the Cryptographic Payload), wraps the input in the appropriate Cryptographic Envelope, and returns the resultant MIME tree as output.¶
The algorithm returns a MIME object that is ready to be injected into the mail system:¶
When composing an encrypted message with header protection, the composing MUA needs a Header Confidentiality Policy (HCP).
In this document, we represent that Header Confidentiality Policy as a function hcp
:¶
hcp(name, val_in) --> val_out
: this function takes a header field name name
and initial value val_in
as arguments, and returns a replacement header value val_out
.
If val_out
is the special value null
, it mean that the header field in question should be omitted from the set of header fields visible outside the Cryptographic Envelope.¶
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.¶
The "Injected Headers" header protection scheme places the header fields to be protected directly on the cryptographic payload. Unlike in the "Wrapped Scheme" (see compose-wrapped-message), there is no wrapping of the message body in any additional message/*
MIME part.
This section describes how to generate such a message.¶
To compose a message using "Injected Headers" header protection, the composing MUA needs one additional input in addition to the Header Confidentiality Policy hcp
defined in Section 2.3.2.¶
legacy
: a boolean value, indicating whether any recipient of the message is believed to have a legacy client.
If all recipients are known to implement this draft, legacy
should be set to false
.
(How a MUA determines the value of legacy
is out of scope for this document; an initial implementation can simply set it to true
)¶
Enabling visibility of obscured header fields for decryption-capable legacy clients requires transforming a header list into a readable form and including it as a decorative "Legacy Display" element in specially-marked parts of the message.
This document recommends two different mechanisms for such a decorative adjustment: one for a text/html
Main Body part of the e-mail message, and one for a text/plain
Main Body part.
This document does not recommend adding a Legacy Display element to any other part.¶
Please see [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, and legacy
is true
:¶
ldlist
, an empty list of (header, value)
pairs¶
For each header field name and value (h,v)
in origheaders
:¶
If h
is user-facing (see [I-D.ietf-lamps-e2e-mail-guidance]):¶
If ldlist
is not empty:¶
payload
that represents the "main body" of the message.¶
For each "Main Body Part" bodypart
of type text/plain
or text/html
:¶
ldlist
into the content of bodypart
(see Section 2.3.3.1 for text/plain
and Section 2.3.3.2 for text/html
)¶
Content-Type
parameter hp-legacy-display
with value 1
to bodypart
¶
For each header field name and value (h,v)
in origheaders
:¶
h
of MIME part payload
with value v
¶
protected-headers
parameter on the Content-Type
of payload
to v1
¶
crypto
to payload
, producing MIME tree output
¶
If crypto
contains encryption:¶
For each header field name and value (h,v)
in origheaders
:¶
h
of output
with value v
¶
output
¶
Note that both new parameters (hcp
and legacy
) are effectively ignored if crypto
does not contain encryption.
This is by design, because they are irrelevant for signed-only cryptographic protections.¶
For a list of obscured header fields represented as (header, value)
pairs, concatenate them as a set of lines, with one newline at the end of each pair.
Add an additional trailing newline after the resultant text, and prepend the entire list to the body of the text/plain
part.¶
For example, if the list of obscured header fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")]
, then a text/plain
part that originally contained:¶
I think we should skip the meeting.¶
Would become:¶
Subject: Thursday's meeting Cc: alice@example.net I think we should skip the meeting.¶
Adding a Legacy Display Element to a text/html
part is similar to how it is added to a text/plain
part (see Section 2.3.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>¶
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.¶
The purpose of injecting a Legacy Display element into each Main Body MIME part is to enable rendering of otherwise obscured header fields in legacy clients that are capable of message decryption, but don't know how to follow the rest of the guidance in this document.¶
The authors are unaware of any legacy client that would render any MIME part type other than text/plain
and text/html
as the Main Body.
A generating MUA SHOULD NOT add a Legacy Display element to any MIME part with any other Content-Type
.¶
The Wrapped Message header protection scheme is briefly documented in Section 3.1 [RFC8551].
This section provides a more detailed explanation of how to build such a message, and augments it with the 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)
in origheaders
:¶
h
of origbody
with value v
¶
If any of the header fields in origbody
, including header fields in the nested internal MIME structure, contain any 8-bit UTF-8 characters (see section section 3.7 of [RFC6532]):¶
payload
be a new MIME part with one header field: Content-Type: message/global; forwarded=no
, and whose body is origbody
.¶
Else:¶
payload
be a new MIME part with one header field: Content-Type: message/rfc822; forwarded=no
, and whose body is origbody
.¶
crypto
to payload
, yielding MIME tree output
¶
If crypto
contains encryption:¶
For header field name and value (h,v)
in origheaders
:¶
h
of output
with value v
¶
output
¶
Note that the Header Confidentiality Policy hcp
is ignored if crypto
does not contain encryption.
This is by design.¶
When composing a message with end-to-end cryptographic protections, an MUA SHOULD protect the header fields of that message as well as the body, using one of the formats described here.¶
A compatible MUA MUST be capable of generating a message with header protection using the Injected Headers Section 2.3.3 format.¶
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 ]]¶
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¶
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.¶
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.¶
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:¶
A MUA that handles a message with header protection does not need to render any new header fields that it did not render before.¶
An incoming message can be identified as having header protection based on one of two signals:¶
Content-Type: message/rfc822
or Content-Type: message/global
and the parameter forwarded
has a value of no
.
See Section 2.5.4 for rendering guidance.¶
Content-Type
and it has parameter protected-headers
set to v1
.
See Section 2.5.3 for rendering guidance.¶
Messages of both types exist in the wild, and a compliant MUA MUST be able to handle them both. They provide the same semantics and the same meaning.¶
Regardless of whether a cryptographically-protected message has protected header fields, the cryptographic summary of the message should be modified to indicate what protections the header fields have.¶
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.¶
When the Cryptographic Payload does not have a Content-Type
of message/rfc822
or message/global
, and the parameter protected-headers
is set to v1
, the values of the protected header fields are drawn from the header fields of the Cryptographic Payload, and the body that is rendered is the Cryptographic Payload itself.¶
A └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) B └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] C ├─╴text/plain D └─╴text/html¶
The message body should be rendered the same way as this message:¶
B └┬╴multipart/alternative C ├─╴text/plain D └─╴text/html¶
It should render header fields taken from part B
.¶
Its cryptographic summary should indicate that the message was signed and all rendered header fields were included in the signature.¶
The MUA SHOULD ignore header fields from part A
for the purposes of rendering.¶
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
.¶
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.¶
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.¶
hp-legacy-display
with value set to 1
¶
text/html
(see Section 2.5.3.3.3) or text/plain
(see Section 2.5.3.3.2)¶
Note that the term "subpart" above is used in the general sense: if the Cryptographic Payload is a single part, that part itself may contain a Legacy Display element if it is marked with the hp-legacy-display=1
parameter.¶
If a text/plain
part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1"
, it should be processed before rendering in the following fashion:¶
Note that implementing this strategy is dependent on the charset used by the MIME part.¶
See Appendix D.1 for an example.¶
If a text/html
part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1"
, it should be processed before rendering in the following fashion:¶
<body>
is a <div>
with class
attribute header-protection-legacy-display
, that entire element should be omitted.¶
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; }¶
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.¶
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
J └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) K └┬╴message/rfc822 [Cryptographic Payload] L └┬╴multipart/alternative [Rendered Body] M ├─╴text/plain N └─╴text/html¶
The message body should be rendered the same way as this message:¶
L └┬╴multipart/alternative M ├─╴text/plain N └─╴text/html¶
It should render header fields taken from part K
.¶
Its cryptographic summary should indicate that the message was signed and all rendered header fields were included in the signature.¶
The MUA SHOULD ignore header fields from part J
for the purposes of rendering.¶
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
O └─╴application/pkcs7-mime; smime-type="enveloped-data" ↧ (decrypts to) P └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) Q └┬╴message/rfc822 [Cryptographic Payload] R └┬╴multipart/alternative [Rendered Body] S ├─╴text/plain T └─╴text/html¶
The message body should be rendered the same way as this message:¶
R └┬╴multipart/alternative S ├─╴text/plain T └─╴text/html¶
It should render header fields taken from part Q
.¶
Its cryptographic summary should indicate that the message was signed and encrypted.
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
.¶
Some automated systems have a control channel that is operated by e-mail. For example, an incoming e-mail message could subscribe someone to a mailing list, initiate the purchase of a specific product, approve another message for redistribution, or adjust the state of some shared object.¶
To the extent that such a system depends on end-to-end cryptographic guarantees about the e-mail control message, header protection as described in this document should improve the system's security. This section provides some specific guidance for systems that use e-mail messages as a control channel that want to benefit from these security improvements.¶
Consider the situation where an e-mail-based control channel depends on the message's cryptographic signature and the action taken depends on some header field of the message.¶
In this case, the automated system MUST rely on information from the header field that is protected by the mechanism described in this document. It MUST NOT rely on any header field found outside the cryptographic payload.¶
For example, consider an administrative interface for a mailing list manager that only accepts control messages that are signed by one of its administrators.
When an inbound message for the list arrives, it is queued (waiting for administrative approval) and the system generates and listens for two distinct e-mail addresses related to the queued message -- one that approves the message, and one that rejects it.
If an administrator sends a signed control message to the approval address, the mailing list verifies that the protected To:
header field of the signed control message contains the approval address before approving the queued message for redistribution.
If the protected To:
header field does not contain that address, or there is no protected To:
header field, then the mailing list logs or reports the error, and does not act on that control message.¶
Consider the situation where an e-mail based control channel expects to receive an end-to-end encrypted message -- for example, where the control messages need confidentiality guarantees -- and where the action taken depends on the contents of some MIME part within message body.¶
In this case, the automated system that decrypts the incoming 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.¶
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.¶
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.¶
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].¶
When composing a reply to an encrypted message with header protection, the MUA is acting both as a receiving MUA and as a sending MUA. Special guidance applies here, as things can go wrong in at least two ways: leaking previously-confidential information, and replying to the wrong party.¶
As noted in [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 ]]¶
When replying to a message, the Composing MUA typically decides who to send the reply to based on:¶
Reply-To
, Mail-Followup-To
, or From
header fields¶
To
or Cc
header fields (if the user chose to "reply all")¶
When a message has header protection, the replying MUA MUST populate the destination fields of the draft message using the protected header fields, and ignore any unprotected header fields.¶
This mitigates against an attack where Mallory gets a copy of an encrypted message from Alice to Bob, and then replays the message to Bob with an additional Cc
to Mallory's own e-mail address in the message's outer (unprotected) header section.¶
If Bob knows Mallory's certificate already, and he replies to such a message without following the guidance in this section, it's likely that his MUA will encrypt the cleartext of the message directly to Mallory.¶
While From
and To
and Cc
and Subject
and Date
are often explicitly rendered to the user, some header fields do affect message display, without being explicitly rendered.¶
For example, Message-Id
, References
, and In-Reply-To
header fields may collectively be used to place a message in a "thread" or series of messages.¶
In another example, Section 2.5.8.2 observes that the value of the Reply-To
field can influence the draft reply message.
So while the user may never see the Reply-To
header field directly, it is implicitly "rendered" when the user interacts with the message by replying to it.¶
An MUA that depends on any implicitly-rendered header field in a message with header protection SHOULD use the value from the protected header field, and SHOULD NOT use any value found outside the cryptographic protection.¶
Some header fields are legitimately added in transit, and could not have been known to the sender at message composition time.¶
The most common of these header fields are Received
and DKIM-Signature
, neither of which are typically rendered, either explicitly or implicitly.¶
If a receiving MUA has specific knowledge about a given header field, including that:¶
then the MUA MAY decide to operate on the value of that header field from the unprotected header section, even though the message has header protection.¶
The MUA MAY prefer to verify that the header fields in question have additional transit-derived cryptographic protections (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.¶
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?¶
This document is intended to offer tooling needed to improve the state of the e-mail ecosystem in a way that can be deployed without significant disruption. Some elements of this specification are present for transitional purposes, but would not exist if the system were designed from scratch.¶
This section describes these transitional mechanisms, as well as some suggestions for how they might eventually be phased out.¶
Any decorative Legacy Display element added to an encrypted message that uses the Injected Header scheme is present strictly for enabling header field visibility (most importantly, the Subject header field) when the message is viewed with a decryption-capable legacy client.¶
Eventually, the hope is that most decryption-capable MUAs will conform to this specification, and there will be no need for injection of Legacy Display elements in the message body. A survey of widely-used decryption-capable MUAs might be able to establish when most of them do support this specification.¶
At that point, a composing MUA could make the legacy
parameter described in {#compose-injected-headers} to false
by default, or could even hard-code it to false
, yielding a much simpler message construction set.¶
Until that point, an end user might want to signal that their receiving MUAs are conformant to this draft so that a peer composing a message to them can set legacy
to false
.
A signal indicating capability of handling messages with header protection might be placed in the user's cryptographic certificate, or in outbound messages.¶
This draft doesn't attempt to define the syntax or semantics of such a signal.¶
This 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].¶
[[ TODO ]]¶
[[ TODO ]]¶
This document requests no action from IANA.¶
[[ RFC Editor: This section may be removed before publication. ]]¶
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.¶
When an e-mail message with end-to-end cryptographic protection is received by a mail user agent, the user might experience many different possible problematic interactions. A message with header protection may introduce new forms of user experience failure.¶
In this section, the authors enumerate different kinds of failures we have observed when reviewing, rendering, and replying to messages with different forms of header protection in different legacy MUAs. Different legacy MUAs demonstrate different subsets of these problems.¶
Hopefully, a non-legacy MUA would not exhibit any of these problems. An implementer updating their legacy MUA to be compliant with this specification should consider these concerns and try to avoid them.¶
Note that the use case here is:¶
This section also uses the shorthand UI:x to mean "the UI element that the user can edit that they think of as x."¶
This uses the same use case(s) and shorthand as Appendix A.3.¶
This section contains sample messages using the different schemes described in this document. Each sample contains a MIME object, a textual and diagrammatic view of its structure, and examples of how an MUA might render it.¶
The cryptographic protections used in this document use the S/MIME standard, and keying material and certificates come from [I-D.ietf-lamps-samples].¶
These messages should be accessible to any IMAP client at imap://bob@header-protection.cmrg.net/
(any password should authenticate to this read-only IMAP mailbox).¶
You can also download copies of these test vectors separately at https://header-protection.cmrg.net
.¶
If any of the messages downloaded differ from those offered here, this document is the canonical source.¶
These messages offer no header protection at all, and can be used as a baseline. They are provided in this document as a counterexample. An MUA implementer can use these messages to verify that the reported cryptographic summary of the message indicates no header protection.¶
This message uses no cryptographic protection at all. Its body is a text/plain message.¶
It has the following structure:¶
└─╴text/plain 152 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 3852 bytes ⇩ (unwraps to) └─╴text/plain 204 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└┬╴multipart/signed 4156 bytes ├─╴text/plain 224 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 6720 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 3960 bytes ⇩ (unwraps to) └─╴text/plain 239 bytes¶
Its contents are:¶
This message uses no cryptographic protection at all. Its body is a multipart/alternative message with an inline image/png attachment.¶
It has the following structure:¶
└┬╴multipart/mixed 1371 bytes ├┬╴multipart/alternative 794 bytes │├─╴text/plain 206 bytes │└─╴text/html 304 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 5249 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1288 bytes ├┬╴multipart/alternative 882 bytes │├─╴text/plain 258 bytes │└─╴text/html 353 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└┬╴multipart/signed 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:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8690 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5426 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1356 bytes ├┬╴multipart/alternative 950 bytes │├─╴text/plain 293 bytes │└─╴text/html 388 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
These messages are signed-only, using different schemes of header protection and different S/MIME structure. The use no Header Confidentiality Policy because the hcp is only relevant when a message is encrypted.¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 4213 bytes ⇩ (unwraps to) └┬╴message/rfc822 566 bytes └─╴text/plain 228 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└┬╴multipart/signed 4451 bytes ├┬╴message/rfc822 596 bytes │└─╴text/plain 256 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 4185 bytes ⇩ (unwraps to) └─╴text/plain 239 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses the Injected Headers header protection scheme.¶
It has the following structure:¶
└┬╴multipart/signed 4417 bytes ├─╴text/plain 258 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 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:¶
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:¶
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:¶
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:¶
These messages are encrypted and signed. They use PKCS#7 signedData inside envelopedData, with different header protection schemes and different Header Confidentiality Policies.¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7345 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4436 bytes ⇩ (unwraps to) └┬╴message/rfc822 679 bytes └─╴text/plain 321 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7305 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4406 bytes ⇩ (unwraps to) └─╴text/plain 333 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7565 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4584 bytes ⇩ (unwraps to) └─╴text/plain 423 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7345 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4432 bytes ⇩ (unwraps to) └┬╴message/rfc822 675 bytes └─╴text/plain 319 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7305 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4402 bytes ⇩ (unwraps to) └─╴text/plain 331 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7540 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4576 bytes ⇩ (unwraps to) └─╴text/plain 419 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7605 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4626 bytes ⇩ (unwraps to) └┬╴message/rfc822 816 bytes └─╴text/plain 327 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7585 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4600 bytes ⇩ (unwraps to) └─╴text/plain 339 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7845 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4806 bytes ⇩ (unwraps to) └─╴text/plain 435 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7605 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4616 bytes ⇩ (unwraps to) └┬╴message/rfc822 810 bytes └─╴text/plain 325 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7565 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4592 bytes ⇩ (unwraps to) └─╴text/plain 337 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7845 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4794 bytes ⇩ (unwraps to) └─╴text/plain 431 bytes¶
Its contents are:¶
This is a encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
Messages containing at least one recipient address in the Bcc header field may appear in up to three different variants:¶
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 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.¶
This section offers example cryptographic payloads (the content within the cryptographic envelope) that contain Legacy Display elements.¶
Here is a simple one-part Cryptographic Payload (headers and body) of a message that includes Legacy Display elements:¶
Date: Fri, 21 Jan 2022 20:40:48 -0500 From: Alice <alice@example.net> To: Bob <bob@example.net> Subject: Dinner plans Message-ID: <text-plain-legacy-display@lhp.example> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; protected-headers="v1" Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A compatible MUA will recognize the hp-legacy-display="1"
parameter and render the body of the message as:¶
Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A legacy decryption-capable MUA that is unaware of this mechanism will ignore the hp-legacy-display="1"
parameter and instead render the body including the Legacy Display elements:¶
Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
Here is a modern one-part Cryptographic Payload (headers and body) of a message that includes Legacy Display elements:¶
Date: Fri, 21 Jan 2022 20:40:48 -0500 From: Alice <alice@example.net> To: Bob <bob@example.net> Subject: Dinner plans Message-ID: <text-html-legacy-display@lhp.example> MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii"; hp-legacy-display="1"; protected-headers="v1" <html><head><title></title></head><body> <div class="header-protection-legacy-display"> <pre>Subject: Dinner plans</pre> </div> <p> Let's meet at Rama's Roti Shop at 8pm and go to the park from there. </p> </body> </html>¶
A compatible MUA will recognize the hp-legacy-display="1"
parameter and mask out the Legacy Display div
, rendering the body of the message as a simple paragraph:¶
Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A legacy decryption-capable MUA that is unaware of this mechanism will ignore the hp-legacy-display="1"
parameter and instead render the body including the Legacy Display elements:¶
Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
[[ RFC Editor: This section is to be removed before publication ]]¶
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
.¶
[[ RFC Editor: This section is to be removed before publication ]]¶
draft-ietf-lamps-header-protection-08¶
draft-ietf-lamps-header-protection-07¶
draft-ietf-lamps-header-protection-06¶
draft-ietf-lamps-header-protection-05¶
draft-ietf-lamps-header-protection-04¶
draft-ietf-lamps-header-protection-03¶
draft-ietf-lamps-header-protection-02¶
draft-ietf-lamps-header-protection-01¶
draft-ietf-lamps-header-protection-00¶
[[ RFC Editor: This section should be empty and is to be removed before publication. ]]¶