Protected Headers for Cryptographic E-mail
draft-autocrypt-lamps-protected-headers-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Bjarni Rúnar Einarsson , "juga" , Daniel Kahn Gillmor | ||
| Last updated | 2019-11-04 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-autocrypt-lamps-protected-headers-00
openpgp B.R. Einarsson
Internet-Draft Mailpile ehf
Intended status: Informational . juga
Expires: 7 May 2020 Independent
D.K. Gillmor
ACLU
4 November 2019
Protected Headers for Cryptographic E-mail
draft-autocrypt-lamps-protected-headers-00
Abstract
This document describes a common strategy to extend the end-to-end
cryptographic protections provided by PGP/MIME, etc. to protect
message headers in addition to message bodies. In addition to
protecting the authenticity and integrity of headers via signatures,
it also describes how to preserve the confidentiality of the Subject
header.
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 7 May 2020.
Copyright Notice
Copyright (c) 2019 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
Einarsson, et al. Expires 7 May 2020 [Page 1]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. User-Facing Headers . . . . . . . . . . . . . . . . . 5
1.2.2. Structural Headers . . . . . . . . . . . . . . . . . 6
2. Protected Headers Summary . . . . . . . . . . . . . . . . . . 6
3. Cryptographic MIME Message Structure . . . . . . . . . . . . 7
3.1. Cryptographic Layers . . . . . . . . . . . . . . . . . . 7
3.1.1. PGP/MIME Signing Cryptographic Layer (multipart/
signed) . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. PGP/MIME Encryption Cryptographic Layer
(multipart/encrypted) . . . . . . . . . . . . . . . . 7
3.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 8
3.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 8
3.3.1. Simple Cryptographic Payloads . . . . . . . . . . . . 8
3.3.2. Multilayer Cryptographic Envelopes . . . . . . . . . 8
3.3.3. A Baroque Example . . . . . . . . . . . . . . . . . . 9
3.4. Exposed Headers are Outside . . . . . . . . . . . . . . . 9
4. Message Composition . . . . . . . . . . . . . . . . . . . . . 10
4.1. Copying All Headers . . . . . . . . . . . . . . . . . . . 10
4.2. Confidential Subject . . . . . . . . . . . . . . . . . . 10
4.3. Obscured Headers . . . . . . . . . . . . . . . . . . . . 10
4.4. Message Composition without Protected Headers . . . . . . 10
4.5. Message Composition with Protected Headers . . . . . . . 11
5. Legacy Display . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Message Generation: Including a Legacy Display
Part . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Legacy Display Transformation . . . . . . . . . . . . 14
5.1.2. When to Generate Legacy Display . . . . . . . . . . . 14
5.2. Message Rendering: Omitting a Legacy Display Part . . . . 14
5.2.1. Legacy Display Detection Algorithm . . . . . . . . . 15
5.3. Legacy Display is Decorative and Transitional . . . . . . 15
6. Message Interpretation . . . . . . . . . . . . . . . . . . . 16
6.1. Reverse-Copying . . . . . . . . . . . . . . . . . . . . . 16
6.2. Signature Invalidation . . . . . . . . . . . . . . . . . 16
6.3. The Legacy Display Part . . . . . . . . . . . . . . . . . 17
6.4. Replying to a Message with Obscured Headers . . . . . . . 17
7. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 17
7.1. Misunderstood Obscured Subjects . . . . . . . . . . . . . 17
7.2. Reply/Forward Losing Subjects . . . . . . . . . . . . . . 18
7.3. Usability Impact of Reduced Metadata . . . . . . . . . . 18
7.4. Usability Impact of Obscured Message-ID . . . . . . . . . 19
Einarsson, et al. Expires 7 May 2020 [Page 2]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
7.5. Usability Impact of Obscured From/To/Cc . . . . . . . . . 19
7.6. Mailing List Header Modifications . . . . . . . . . . . . 20
8. Comparison with Other Header Protection Schemes . . . . . . . 20
8.1. S/MIME 3.1 Header Protection . . . . . . . . . . . . . . 20
8.2. The Content-Type Property "forwarded=no"
{forwarded=no} . . . . . . . . . . . . . . . . . . . . . 21
8.3. pEp Header Protection . . . . . . . . . . . . . . . . . . 21
8.4. DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.5. S/MIME "Secure Headers" . . . . . . . . . . . . . . . . . 22
8.6. Triple-Wrapping . . . . . . . . . . . . . . . . . . . . . 22
9. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Signed Message with Protected Headers . . . . . . . . . . 23
9.2. Signed and Encrypted Message with Protected
Headers . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.3. Signed and Encrypted Message with Protected Headers and
Legacy Display Part . . . . . . . . . . . . . . . . . . . 27
9.4. Multilayer Message with Protected Headers . . . . . . . . 30
9.5. Multilayer Message with Protected Headers and Legacy
Display Part . . . . . . . . . . . . . . . . . . . . . . 34
9.6. An Unfortunately Complex Example . . . . . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11.1. Subject Leak . . . . . . . . . . . . . . . . . . . . . . 41
11.2. Signature Replay . . . . . . . . . . . . . . . . . . . . 41
11.3. Participant Modification . . . . . . . . . . . . . . . . 42
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42
13. Document Considerations . . . . . . . . . . . . . . . . . . . 43
13.1. Document History . . . . . . . . . . . . . . . . . . . . 43
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
15.1. Normative References . . . . . . . . . . . . . . . . . . 43
15.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction
E-mail end-to-end security with OpenPGP and S/MIME standards can
provide integrity, authentication, non-repudiation and
confidentiality to the body of a MIME e-mail message. However, PGP/
MIME ([RFC3156]) alone does not protect message headers. And the
structure to protect headers defined in S/MIME 3.1 ([RFC3851]) has
not seen widespread adoption.
This document defines a scheme, "Protected Headers for Cryptographic
E-mail", which has been adopted by multiple existing e-mail clients
in order to extend the cryptographic protections provided by PGP/MIME
to also protect the message headers.
Einarsson, et al. Expires 7 May 2020 [Page 3]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
This document describes how these protections can be applied to
cryptographically signed messages, and also discusses some of the
challenges of encrypting many transit-oriented headers.
It offers guidance for protecting the confidentiality of non-transit-
oriented headers like Subject, and also offers a means to preserve
backwards compatibility so that an encrypted Subject remains
available to recipients using software that does not implement
support for the Protected Headers scheme.
The document also discusses some of the compatibility constraints and
usability concerns which motivated the design of the scheme, as well
as limitations and a comparison with other proposals.
While the document (and the authors') focus is primarily PGP/MIME, we
believe the technique is broadly applicable and would also apply to
other MIME-compatible cryptographic e-mail systems, including S/MIME
([RFC8551]). Furthermore, this technique has already proven itself
as a useful building block for other improvements to cryptographic
e-mail, such as the Autocrypt Level 1.1 ([Autocrypt]) "Gossip"
mechanism.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology
For the purposes of this document, we define the following concepts:
* _MUA_ is short for Mail User Agent; an e-mail client.
* _Protection_ of message data refers to cryptographic encryption
and/or signatures, providing confidentiality, authenticity or
both.
* _Cryptographic Layer_, _Cryptographic Envelope_ and _Cryptographic
Payload_ are defined in Section 3
* _Original Headers_ are the [RFC2822] message headers as known to
the sending MUA at the time of message composition.
* _Protected Headers_ are any headers protected by the scheme
described in this document.
Einarsson, et al. Expires 7 May 2020 [Page 4]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
* _Exposed Headers_ are any headers outside the Cryptographic
Payload (protected or not).
* _Obscured Headers_ are any Protected Headers which have been
modified or removed from the set of Exposed Headers.
* _Legacy Display Part_ is a MIME construct which provides
visibility for users of legacy clients of data from the Original
Headers which may have been removed or obscured from the Exposed
Headers. It is defined in Section 5.
* _User-Facing Headers_ are explained and enumerated in
Section 1.2.1.
* _Structural Headers_ are documented in Section 1.2.2.
1.2.1. User-Facing Headers
Of all the headers that an e-mail message may contain, only a handful
are typically presented directly to the user. The user-facing
headers are:
* "Subject"
* "From"
* "To"
* "Cc"
* "Date"
* "Reply-To"
* "Followup-To"
The above is a complete list. No other headers are considered "user-
facing".
Other headers may affect the visible rendering of the message (e.g.,
"References" and "In-Reply-To" may affect the placement of a message
in a threaded discussion), but they are not directly displayed to the
user and so are not considered "user-facing" for the purposes of this
document.
Einarsson, et al. Expires 7 May 2020 [Page 5]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
1.2.2. Structural Headers
A message header whose name begins with "Content-" is referred to in
this document as a "structural" header.
These headers indicate something about the specific MIME part they
are attached to, and cannot be transferred or copied to other parts
without endangering the readability of the message.
This includes (but is not limited to):
* "Content-Type"
* "Content-Transfer-Encoding"
* "Content-Disposition"
Note that no "user-facing" headers (Section 1.2.1) are also
"structural" headers. Of course, many headers are neither "user-
facing" nor "structural".
FIXME: are there any non-"Content-*" headers we should consider as
structural?
2. Protected Headers Summary
The Protected Headers scheme relies on three backward-compatible
changes to a cryptographically-protected e-mail message:
* Headers known to the composing MUA at message composition time are
(in addition to their typical placement as Exposed Headers on the
outside of the message) also present in the MIME header of the
root of the Cryptographic Payload. These Protected Headers share
cryptographic properties with the rest of the Cryptographic
Payload.
* When the Cryptographic Envelope includes encryption, any Exposed
Header MAY be _obscured_ by a transformation (including deletion).
* If the composing MUA intends to obscure any user-facing headers,
it MAY add a decorative "Legacy Display" MIME part to the
Cryptographic Payload which additionally duplicates the original
values of the obscured user-facing headers.
When a composing MUA encrypts a message, it SHOULD obscure the
"Subject:" header, by using the literal string "..." (three U+002E
FULL STOP characters) as the value of the exposed "Subject:" header.
Einarsson, et al. Expires 7 May 2020 [Page 6]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
When a receiving MUA encounters a message with a Cryptographic
Envelope, it treats the headers of the Cryptographic Payload as
belonging to the message itself, not just the subpart. In
particular, when rendering a header for any such message, the
renderer SHOULD prefer the header's Protected value over its Exposed
value.
A receiving MUA that understands Protected Headers and discovers a
Legacy Display part SHOULD hide the Legacy Display part when
rendering the message.
The following sections contain more detailed discussion.
3. Cryptographic MIME Message Structure
Implementations use the structure of an e-mail message to protect the
headers. This section establishes some conventions about how to
think about message structure.
3.1. Cryptographic Layers
"Cryptographic Layer" refers to a MIME substructure that supplies
some cryptographic protections to an internal MIME subtree. The
internal subtree is known as the "protected part" though of course it
may itself be a multipart object.
For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers,
signing and encryption.
In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7) is used
to indicate "decrypts to".
3.1.1. PGP/MIME Signing Cryptographic Layer (multipart/signed)
└┬╴multipart/signed
├─╴[protected part]
└─╴application/pgp-signature
3.1.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted)
└┬╴multipart/encrypted
├─╴application/pgp-encrypted
└─╴application/octet-stream
↧ (decrypts to)
└─╴[protected part]
Einarsson, et al. Expires 7 May 2020 [Page 7]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
3.2. Cryptographic Envelope
The Cryptographic Envelope is the largest contiguous set of
Cryptographic Layers of an e-mail message starting with the outermost
MIME type (that is, with the Content-Type of the message itself).
If the Content-Type of the message itself is not a Cryptographic
Layer, then the message has no cryptographic envelope.
"Contiguous" in the definition above indicates that if a
Cryptographic Layer is the protected part of another Cryptographic
Layer, the layers together comprise a single Cryptographic Envelope.
Note that if a non-Cryptographic Layer intervenes, all Cryptographic
Layers within the non-Cryptographic Layer _are not_ part of the
Cryptographic Envelope (see the example in Section 3.3.3).
Note also that the ordering of the Cryptographic Layers implies
different cryptographic properties. A signed-then-encrypted message
is different than an encrypted-then-signed message.
3.3. Cryptographic Payload
The Cryptographic Payload of a message is the first non-Cryptographic
Layer - the "protected part" - within the Cryptographic Envelope.
Since the Cryptographic Payload itself is a MIME part, it has its own
set of headers.
Protected headers are placed on (and read from) the Cryptographic
Payload, and should be considered to have the same cryptographic
properties as the message itself.
3.3.1. Simple Cryptographic Payloads
As described above, if the "protected part" identified in
Section 3.1.1 or Section 3.1.2 is not itself a Cryptographic Layer,
that part _is_ the Cryptographic Payload.
If the application wants to generate a message that is both encrypted
and signed, it MAY use the simple MIME structure from Section 3.1.2
by ensuring that the [RFC4880] Encrypted Message within the
"application/octet-stream" part contains an [RFC4880] Signed Message.
3.3.2. Multilayer Cryptographic Envelopes
It is possible to construct a Cryptographic Envelope consisting of
multiple layers for PGP/MIME, typically of the following structure:
Einarsson, et al. Expires 7 May 2020 [Page 8]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
A └┬╴multipart/encrypted
B ├─╴application/pgp-encrypted
C └─╴application/octet-stream
D ↧ (decrypts to)
E └┬╴multipart/signed
F ├─╴[Cryptographic Payload]
G └─╴application/pgp-signature
When handling such a message, the properties of the Cryptographic
Envelope are derived from the series "A", "E".
As noted in Section 3.3.1, PGP/MIME applications also have a simpler
MIME construction available with the same cryptographic properties.
3.3.3. A Baroque Example
Consider a message with the following overcomplicated structure:
H └┬╴multipart/encrypted
I ├─╴application/pgp-encrypted
J └─╴application/octet-stream
K ↧ (decrypts to)
L └┬╴multipart/signed
M ├┬╴multipart/mixed
N │├┬╴multipart/signed
O ││├─╴text/plain
P ││└─╴application/pgp-signature
Q │└─╴text/plain
R └─╴application/pgp-signature
The 3 Cryptographic Layers in such a message are rooted in parts "H",
"L", and "N". But the Cryptographic Envelope of the message consists
only of the properties derived from the series "H", "L". The
Cryptographic Payload of the message is part "M".
It is NOT RECOMMENDED to generate messages with such complicated
structures. Even if a receiving MUA can parse this structure
properly, it is nearly impossible to render in a way that the user
can reason about the cryptographic properties of part "O" compared to
part "Q".
3.4. Exposed Headers are Outside
The Cryptographic Envelope fully encloses the Cryptographic Payload,
whether the message is signed or encrypted or both. The Exposed
Headers are considered to be outside of both.
Einarsson, et al. Expires 7 May 2020 [Page 9]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
4. Message Composition
This section describes the composition of a cryptographically-
protected message with Protected Headers.
We document legacy composition of cryptographically-protected
messages (without protected headers) in Section 4.4, and then
describe a revised version of that algorithm in Section 4.5 that
produces conformant Protected Headers.
4.1. Copying All Headers
All non-structural headers known to the composing MUA are copied to
the MIME header of the Cryptographic Payload. The composing MUA
SHOULD protect all known non-structural headers in this way.
If the composing MUA omits protection for some of the headers, the
receiving MUA will have difficulty reasoning about the integrity of
the headers (see Section 11.2).
4.2. Confidential Subject
When a message is encrypted, the Subject should be obscured by
replacing the Exposed Subject with three periods: "..."
This value ("...") was chosen because it is believed to be language
agnostic and avoids communicating any potentially misleading
information to the recipient (see Section 7.1 for a more detailed
discussion).
4.3. Obscured Headers
Due to compatibility and usability concerns, a Mail User Agent SHOULD
NOT obscure any of: "From", "To", "Cc", "Message-ID", "References",
"Reply-To", "In-Reply-To", (FIXME: MORE?) unless the user has
indicated they have security constraints which justify the potential
downsides (see Section 7 for a more detailed discussion).
Aside from that limitation, this specification does not at this time
define or limit the methods a MUA may use to convert Exposed Headers
into Obscured Headers.
4.4. Message Composition without Protected Headers
This section roughly describes the steps that a legacy MUA might use
to compose a cryptographically-protected message _without_ Protected
Headers.
Einarsson, et al. Expires 7 May 2020 [Page 10]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
The message composition algorithm takes three parameters:
* "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
present (see Section 1.2.2).
* "origheaders": the intended non-structural headers for the
message, represented here as a table mapping from header names to
header values.. For example, "origheaders['From']" refers to the
value of the "From" header that the composing MUA would typically
place on the message before sending it.
* "crypto": The series of cryptographic protections to apply (for
example, "sign with the secret key corresponding to OpenPGP
certificate X, then encrypt to OpenPGP 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:
* Apply "crypto" to "origbody", yielding MIME tree "output"
* For header name "h" in "origheaders":
- Set header "h" of "output" to "origheaders[h]"
* Return "output"
4.5. Message Composition with Protected Headers
A reasonable sequential algorithm for composing a message _with_
protected headers takes two more parameters in addition to
"origbody", "origheaders", and "crypto":
* "obscures": a table of headers to be obscured during encryption,
mapping header names to their obscuring values. For example, this
document recommends only obscuring the subject, so that would be
represented by the single-entry table "obscures = {'Subject':
'...'}". If header "Foo" is to be deleted entirely,
"obscures['Foo']" should be set to the special value "null".
* "legacy": a boolean value, indicating whether any recipient of the
message is believed to have a legacy client (that is, a MUA that
Einarsson, et al. Expires 7 May 2020 [Page 11]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
is capable of decryption, but does not understand protected
headers).
The revised algorithm for applying cryptographic protection to a
message is as follows:
* if "crypto" contains encryption, and "legacy" is "true", and
"obscures" contains any user-facing headers (see Section 1.2.1),
wrap "orig" in a structure that carries a Legacy Display part:
- Create a new MIME leaf part "legacydisplay" with header
"Content-Type: text/rfc822-headers; protected-headers="v1""
- For each obscured header name "obh" in "obscures":
o If "obh" is user-facing:
+ Add "obh: origheaders[ob]" to the body of
"legacydisplay". For example, if
"origheaders['Subject']" is "lunch plans?", then add the
line "Subject: lunch plans?" to the body of
"legacydisplay"
- Construct a new MIME part "wrapper" with "Content-Type:
multipart/mixed"
- Give "wrapper" exactly two subarts: "legacydisplay" and
"origbody", in that order.
- Let "payload" be MIME part "wrapper"
* Otherwise:
- Let "payload" be MIME part "origbody"
* For each header name "h" in "origheaders":
- Set header "h" of MIME part "payload" to "origheaders[h]"
* FIXME: Enigmail adds "protected-headers="v1"" parameter to
"payload" here. Is this necessary?
* Apply "crypto" to "payload", producing MIME tree "output"
* If "crypto" contains encryption:
- For each obscured header name "obh" in "obscures":
Einarsson, et al. Expires 7 May 2020 [Page 12]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
o If "obscures[obh]" is "null":
+ Drop "obh" from "origheaders"
o Else:
+ Set "origheaders[obh]" to "obscures[obh]"
* For each header name "h" in "origheaders":
- Set header "h" of "output" to "origheaders[h]"
* return "output"
Note that both new parameters, "obscured" and "legacy", are
effectively ignored if "crypto" does not contain encryption. This is
by design, because they are irrelevant for signed-only cryptographic
protections.
5. Legacy Display
MUAs typically display user-facing headers (Section 1.2.1) directly
to the user. An encrypted message may be read by a decryption-
capable legacy MUA that is unaware of this standard. The user of
such a legacy client risks losing access to any obscured headers.
This section presents a workaround to mitigate this risk by
restructuring the Cryptographic Payload before encrypting to include
a "Legacy Display" part.
5.1. Message Generation: Including a Legacy Display Part
A generating MUA that wants to make an Obscured Subject (or any other
user-facing header) visible to a recipient using a legacy MUA SHOULD
modify the Cryptographic Payload by wrapping the intended body of the
message in a "multipart/mixed" MIME part that prefixes the intended
body with a Legacy Display part.
The Legacy Display part MUST be of Content-Type "text/
rfc822-headers", and MUST contain a "protected-headers" parameter
whose value is "v1". It SHOULD be marked with "Content-Disposition:
inline" to encourage recipients to render it.
The contents of the Legacy Display part MUST be only the user-facing
headers that the sending MUA intends to obscure after encryption.
The original body (now a subpart) SHOULD also be marked with
Einarsson, et al. Expires 7 May 2020 [Page 13]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
"Content-Disposition: inline" to discourage legacy clients from
presenting it as an attachment.
5.1.1. Legacy Display Transformation
Consider a message whose Cryptographic Payload, before encrypting,
that would have a traditional "multipart/alternative" structure:
X └┬╴multipart/alternative
Y ├─╴text/plain
Z └─╴text/html
When adding a Legacy Display part, this structure becomes:
V └┬╴multipart/mixed
W ├─╴text/rfc822-headers ("Legacy Display" part)
X └┬╴multipart/alternative ("original body")
Y ├─╴text/plain
Z └─╴text/html
Note that with the inclusion of the Legacy Display part, the
Cryptographic Payload is the "multipart/mixed" part (part "V" in the
example above), so Protected Headers should be placed at that part.
5.1.2. When to Generate Legacy Display
A MUA SHOULD transform a Cryptographic Payload to include a Legacy
Display part only when:
* The message is going to be encrypted, and
* At least one user-facing header (see Section 1.2.1) is going to be
obscured
Additionally, if the sender knows that the recipient's MUA is capable
of interpreting Protected Headers, it SHOULD NOT attempt to include a
Legacy Display part. (Signalling such a capability is out of scope
for this document)
5.2. Message Rendering: Omitting a Legacy Display Part
A MUA that understands Protected Headers may receive an encrypted
message that contains a Legacy Display part. Such an MUA SHOULD
avoid rendering the Legacy Display part to the user at all, since it
is aware of and can render the actual Protected Headers.
If a Legacy Display part is detected, the Protected Headers should
still be pulled from the Cryptographic Payload (part "V" in the
Einarsson, et al. Expires 7 May 2020 [Page 14]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
example above), but the body of message SHOULD be rendered as though
it were only the original body (part "X" in the example above).
5.2.1. Legacy Display Detection Algorithm
A receiving MUA acting on a message SHOULD detect the presence of a
Legacy Display part and the corresponding "original body" with the
following simple algorithm:
* Check that all of the following are true for the message:
* The Cryptographic Envelope must contain an encrypting
Cryptographic Layer
* The Cryptographic Payload must have a "Content-Type" of
"multipart/mixed"
* The Cryptographic Payload must have exactly two subparts
* The first subpart of the Cryptographic Payload must have a
"Content-Type" of "text/rfc822-headers"
* The first subpart of the Cryptographic Payload's "Content-Type"
must contain a property of "protected-headers", and its value must
be "v1".
* If all of the above are true, then the first subpart is the Legacy
Display part, and the second subpart is the "original body".
Otherwise, the message does not have a Legacy Display part.
5.3. Legacy Display is Decorative and Transitional
As the above makes clear, the Legacy Display part is strictly
decorative, for the benefit of legacy decryption-capable MUAs that
may handle the message. As such, the existence of the Legacy Display
part and its "multipart/mixed" wrapper are part of a transition plan.
As the number of decryption-capable clients that understand Protected
Headers grows in comparison to the number of legacy decryption-
capable clients, it is expected that some senders will decide to stop
generating Legacy Display parts entirely.
A MUA developer concerned about accessiblity of the Subject header
for their users of encrypted mail when Legacy Display parts are
omitted SHOULD implement the Protected Headers scheme described in
this document.
Einarsson, et al. Expires 7 May 2020 [Page 15]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
6. Message Interpretation
This document does not currently provide comprehensive
recommendations on how to interpret Protected Headers. This is
deliberate; research and development is still ongoing. We also
recognize that the tolerance of different user groups for false
positives (benign conditions misidentified as security risks), vs.
their need for strong protections varies a great deal and different
MUAs will take different approaches as a result.
Some common approaches are discussed below.
6.1. Reverse-Copying
One strategy for interpreting Protected Headers on an incoming
message is to simply ignore any Exposed Header for which a Protected
counterpart is available. This is often implemented as a copy
operation (copying header back out of the Cryptographic Payload into
the main message header) within the code which takes care of parsing
the message.
A MUA implementing this strategy should pay special attention to any
user facing headers (Section 1.2.1). If a message has Protected
Headers, and a user-facing header is among the Exposed Headers but
missing from the Protected Headers, then an MUA implementing this
strategy SHOULD delete the identified Exposed Header before
presenting the message to the user.
This strategy does not risk raising a false alarm about harmless
deviations, but conversely it does nothing to inform the user if they
are under attack. This strategy does successfully mitigate and
thwart some attacks, including signature replay attacks
(Section 11.2) and participant modification attacks (Section 11.3).
6.2. Signature Invalidation
An alternate strategy for interpreting Protected Headers is to
consider the cryptographic signature on a message to be invalid if
the Exposed Headers deviate from their Protected counterparts.
This state should be presented to the user using the same interface
as other signature verification failures.
A MUA implementing this strategy MAY want to make a special exception
for the "Subject:" header, to avoid invalidating the signature on any
signed and encrypted message with a confidential subject.
Einarsson, et al. Expires 7 May 2020 [Page 16]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
Note that simple signature invalidation may be insufficient to defend
against a participant modification attack (Section 11.3).
6.3. The Legacy Display Part
This part is purely decorative, for the benefit of any recipient
using a legacy decryption-capable MUA. See Section 5.2 for details
and recommendations on how to handle the Legacy Display part.
6.4. Replying to a Message with Obscured Headers
When replying to a message, many MUAs copy headers from the original
message into their reply.
When replying to an encrypted message, users expect the replying MUA
to generate an encrypted message if possible. If encryption is not
possible, and the reply will be cleartext, users typically want the
MUA to avoid leaking previously-encrypted content into the cleartext
of the reply.
For this reason, an MUA replying to an encrypted message with
Obscured Headers SHOULD NOT leak the cleartext of any Obscured
Headers into the cleartext of the reply, whether encrypted or not.
In particular, the contents of any Obscured Protected Header from the
original message SHOULD NOT be placed in the Exposed Headers of the
reply message.
7. Common Pitfalls and Guidelines
Among the MUA authors who already implemented most of this
specification, several alternative or more encompasing specifications
were discussed and sometimes tried out in practice. This section
highlights a few "pitfalls" and guidelines based on these discussions
and lessons learned.
7.1. Misunderstood Obscured Subjects
There were many discussions around what text phrase to use to obscure
the "Subject:". Text phrases such as "Encrypted Message" were tried
but resulted in both localization problems and user confusion.
If the natural language phrase for the obscured "Subject:" is not
localized (e.g. just English "Encrypted Message"), then it may be
incomprehensible to a non-English-speaking recipient who uses a
legacy MUA that renders the obscured "Subject:" directly.
Einarsson, et al. Expires 7 May 2020 [Page 17]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
On the other hand, if it is localized based on the sender's MUA
language settings, there is no guarantee that the recipient prefers
the same language as the sender (consider a German speaker sending
English text to an Anglophone). There is no standard way for a
sending MUA to infer the language preferred by the recipient (aside
from statistical inference of language based on the composed message,
which would in turn leak information about the supposedly-
confidential message body).
Furthermore, implementors found that the phrase "Encrypted Message"
in the subject line was sometimes understood by users to be an
indication from the MUA that the message was actually encrypted. In
practice, when some MUA failed to encrypt a message in a thread that
started off with an obscured "Subject:", the value "Re: Encrypted
Message" was retained even on those cleartext replies, resulting in
user confusion.
In contrast, using "..." as the obscured "Subject:" was less likely
to be seen as an indicator from the MUA of message encryption, and it
also neatly sidesteps the localization problems.
7.2. Reply/Forward Losing Subjects
When the user of a legacy MUA replies to or forwards a message where
the Subject has been obscured, it is likely that the new subject will
be "Fwd: ..." or "Re: ..." (or the localized equivalent). This
breaks an important feature: people are used to continuity of subject
within a thread. It is especially unfortunate when a new participant
is added to a conversation who never saw the original subject.
At this time, there is no known workaround for this problem. The
only solution is to upgrade the MUA to support Protected Headers.
The authors consider this to be only a minor concern in cases where
encryption is being used because confidentiality is important.
However, in more opportunistic cases, where encryption is being used
routinely regardless of the sensitivity of message contents, this
cost becomes higher.
7.3. Usability Impact of Reduced Metadata
Many mail user agents maintain an index of message metadata
(including header data), which is used to rapidly construct mailbox
overviews and search result listings. If the process which generates
this index does not have access to the encrypted payload of a
message, or does not implement Protected Headers, then the index will
only contain the obscured versions Exposed Headers, in particular an
obscured Subject of "...".
Einarsson, et al. Expires 7 May 2020 [Page 18]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
For sensitive message content, especially in a hosted MUA-as-
a-service situation ("webmail") where the metadata index is
maintained and stored by a third party, this may be considered a
feature as the subject is protected from the third-party. However,
for more routine communications, this harms usability and goes
against user expectations.
Two simple workarounds exist for this use case:
1. If the metadata index is considered secure enough to handle
confidential data, the protected content may be stored directly
in the index once it has been decrypted.
2. If the metadata index is not trusted, the protected content could
be re-encrypted and encrypted versions stored in the index
instead, which are then decrypted by the client at display time.
In both cases, the process which decrypts the message and processes
the Protected Headers must be able to update the metadata index.
FIXME: add notes about research topics and other non-simple
workarounds, like oblivious server-side indexing, or searching on
encrypted data.
7.4. Usability Impact of Obscured Message-ID
Current MUA implementations rely on the outermost Message-ID for
message processing and indexing purposes. This processing often
happens before any decryption is even attempted. Attempting to send
a message with an obscured Message-ID header would result in several
MUAs not correctly processing the message, and would likely be seen
as a degradation by users.
Furthermore, a legacy MUA replying to a message with an obscured
"Message-ID:" would be likely to produce threading information
("References:", "In-Reply-To:") that would be misunderstood by the
original sender. Implementors generally disapprove of breaking
threads.
7.5. Usability Impact of Obscured From/To/Cc
The impact of obscuring "From:", "To:", and "Cc:" headers has similar
issues as discussed with obscuring the "Message-ID:" header in
Section 7.4.
In addition, obscuring these headers is likely to cause difficulties
for a legacy client attempting formulate a correct reply (or "reply
all") to a given message.
Einarsson, et al. Expires 7 May 2020 [Page 19]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
7.6. Mailing List Header Modifications
Some popular mailing-list implementations will modify the Exposed
Headers of a message in specific, benign ways. In particular, it is
common to add markers to the "Subject" line, and it is also common to
modify either "From" or "Reply-To" in order to make sure replies go
to the list instead of directly to the author of an individual post.
Depending on how the MUA resolves discrepancies between the Protected
Headers and the Exposed Headers of a received message, these mailing
list "features" may either break or the MUA may incorrectly interpret
them as a security breach.
Implementors may for this reason choose to implement slightly
different strategies for resolving discrepancies, if a message is
known to come from such a mailing list. MUAs should at the very
least avoid presenting false alarms in such cases.
8. Comparison with Other Header Protection Schemes
Other header protection schemes have been proposed (in the IETF and
elsewhere) that are distinct from this mechanism. This section
documents the differences between those earlier mechanisms and this
one, and hypothesizes why it has seen greater interoperable adoption.
The distinctions include:
* backward compatibility with legacy clients
* compatibility across PGP/MIME and S/MIME
* protection for both confidentiality and signing
8.1. S/MIME 3.1 Header Protection
S/MIME 3.1 ([RFC3851]) introduces header protection via "message/
rfc822" header parts.
The problem with this mechanism is that many legacy clients
encountering such a message were likely to interpret it as either a
forwarded message, or as an unreadable substructure.
For signed messages, this is particularly problematic - a message
that would otherwise have been easily readable by a client that knows
nothing about signed messages suddenly shows up as a message-within-
a-message, just by virtue of signing. This has an impact on _all_
clients, whether they are cryptographically-capable or not.
Einarsson, et al. Expires 7 May 2020 [Page 20]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
For encrypted messages, whose interpretation only matters on the
smaller set of cryptographically-capable legacy clients, the
resulting message rendering is awkward at best.
Furthermore, Formulating a reply to such a message on a legacy client
can also leave the user with badly-structured quoted and attributed
content.
Additionally, a message deliberately forwarded in its own right
(without preamble or adjacent explanatory notes) could potentially be
confused with a message using the declared structure.
The mechanism described here allows cryptographically-incapable
legacy MUAs to read and handle cleartext signed messages without any
modifications, and permits cryptographically-capable legacy MUAs to
handle encrypted messages without any modifications.
In particular, the Legacy Display part described in {#legacy-display}
makes it feasible for a conformant MUA to generate messages with
obscured Subject lines that nonetheless give access to the obscured
Subject header for recipients with legacy MUAs.
8.2. The Content-Type Property "forwarded=no" {forwarded=no}
[I-D.draft-ietf-lamps-header-protection-requirements-00] contains a
proposal that attempts to mitigate one of the drawbacks of the scheme
described in S/MIME 3.1 (Section 8.1).
In particular, it allows _non-legacy_ clients to distinguish between
deliberately forwarded messages and those intended to use the defined
structure for header protection.
However, this fix has no impact on the confusion experienced by
legacy clients.
8.3. pEp Header Protection
[I-D.draft-luck-lamps-pep-header-protection-03] is applicable only to
signed+encrypted mail, and does not contemplate protection of signed-
only mail.
In addition, the pEp header protection involved for "pEp message
format 2" has an additional "multipart/mixed" layer designed to
facilitate transfer of OpenPGP Transferable Public Keys, which seems
orthogonal to the effort to protect headers.
Finally, that draft suggests that the exposed Subject header be one
of "=?utf-8?Q?p=E2=89=A1p?=", "pEp", or "Encrypted message". "pEp" is
Einarsson, et al. Expires 7 May 2020 [Page 21]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
a mysterious choice for most users, and see Section 7.1 for more
commentary on why "Encrypted message" is likely to be problematic.
8.4. DKIM
[RFC6736] offers DKIM, which is often used to sign headers associated
with a message.
DKIM is orthogonal to the work described in this document, since it
is typically done by the domain operator and not the end user
generating the original message. That is, DKIM is not "end-to-end"
and does not represent the intent of the entity generating the
message.
Furthermore, a DKIM signer does not have access to headers inside an
encrypted Cryptographic Layer, and a DKIM verifier cannot effectively
use DKIM to verify such confidential headers.
8.5. S/MIME "Secure Headers"
[RFC7508] describes a mechanism that embeds message header fields in
the S/MIME signature using ASN.1.
The mechanism proposed in that draft is undefined for use with PGP/
MIME. While all S/MIME clients must be able to handle CMS and ASN.1
as well as MIME, a standard that works at the MIME layer itself
should be applicable to any MUA that can work with MIME, regardess of
whether end-to-end security layers are provided by S/MIME or PGP/
MIME.
That mechanism also does not propose a means to provide
confidentiality protection for headers within an encrypted-but-not-
signed message.
Finally, that mechanism offers no equivalent to the Legacy Display
described in Section 5. Instead, sender and receiver are expected to
negotiate in some unspecified way to ensure that it is safe to remove
or modify Exposed Headers in an encrypted message.
8.6. Triple-Wrapping
[RFC2634] defines "Triple Wrapping" as a means of providing cleartext
signatures over signed and encrypted material. This can be used in
combination with the mechanism described in [RFC7508] to authenticate
some headers for transport using S/MIME.
But it does not offer confidentiality protection for the protected
Einarsson, et al. Expires 7 May 2020 [Page 22]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
headers, and the signer of the outer layer of a triple-wrapped
message may not be the originator of the message either.
In practice on today's Internet, DKIM ([RFC6736] provides a more
widely-accepted cryptographic header-verification-for-transport
mechanism than triple-wrapped messages.
9. Test Vectors
The subsections below provide example messages that implement the
Protected Header scheme.
The secret keys and OpenPGP certificates from
[I-D.draft-bre-openpgp-samples-00] can be used to decrypt and verify
them.
They are provided in textual source form as [RFC2822] messages.
9.1. Signed Message with Protected Headers
This shows a clearsigned message. Its MIME message structure is:
└┬╴multipart/signed
├─╴text/plain ← Cryptographic Payload
└─╴application/pgp-signature
Note that if this message had been generated without Protected
Headers, then an attacker with access to it could modify the Subject
without invalidating the signature. Such an attacker could cause Bob
to think that Alice wanted to cancel the contract with BarCorp
instead of FooCorp.
Einarsson, et al. Expires 7 May 2020 [Page 23]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
Received: from localhost (localhost [127.0.0.1]);
Sun, 20 Oct 2019 09:18:28 -0400 (UTC-04:00)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="904b809781";
protocol="application/pgp-signature"; micalg="pgp-sha512"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Sun, 20 Oct 2019 09:18:11 -0400
Subject: The FooCorp contract
Message-ID: <signed-only@protected-headers.example>
--904b809781
Content-Type: text/plain; charset="us-ascii"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Sun, 20 Oct 2019 09:18:11 -0400
Subject: The FooCorp contract
Message-ID: <signed-only@protected-headers.example>
Bob, we need to cancel this contract.
Please start the necessary processes to make that happen today.
Thanks, Alice
--
Alice Lovelace
President
OpenPGP Example Corp
--904b809781
content-type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
wnUEARYKAB0FAl2sXpMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj
jjvKAPwOVIBTcSVKcji7kBw0ljyBwpOgoQ7UGaY6cINfhGg5HAEA4jjbHaEuGZ29
WDTKxW/exLlcW1WqY0fva3t6jbniyQI=
=IsHn
-----END PGP SIGNATURE-----
--904b809781--
9.2. Signed and Encrypted Message with Protected Headers
This shows a simple encrypted message with protected headers. The
encryption also contains an signature in the OpenPGP Message
structure. Its MIME message structure is:
Einarsson, et al. Expires 7 May 2020 [Page 24]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
└┬╴multipart/encrypted
├─╴application/pgp-encrypted
└─╴application/octet-stream
↧ (decrypts to)
└─╴text/plain ← Cryptographic Payload
The "Subject:" header is successfully obscured.
Note that if this message had been generated without Protected
Headers, then an attacker with access to it could have read the
Subject. Such an attacker would know details about Alice and Bob's
business that they wanted to keep confidential.
The protected headers also protect the authenticity of subject line
as well.
The session key for this message's crypto layer is an AES-256 key
with value
"8df4b2d27d5637138ac6de46415661be0bd01ed12ecf8c1db22a33cf3ede82f2"
(in hex).
If Bob's MUA is capable of interpreting these protected headers, it
should render the "Subject:" of this message as "BarCorp contract
signed, let's go!".
Received: from localhost (localhost [127.0.0.1]);
Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00)
MIME-Version: 1.0
Content-Type: multipart/encrypted; boundary="bcde3ce988";
protocol="application/pgp-encrypted"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Mon, 21 Oct 2019 07:18:11 -0700
Message-ID: <signed+encrypted@protected-headers.example>
Subject: ...
--bcde3ce988
content-type: application/pgp-encrypted
Version: 1
--bcde3ce988
content-type: application/octet-stream
-----BEGIN PGP MESSAGE-----
wV4DR2b2udXyHrYSAQdAk4rw/q9TK6dtIBm42jF6Z7z34KmNIDAKF4v4f09n5l0w
OAgtdmIHyUu3ZOHSb8cFRbjAGQ3RcgIAe4DdsZIy/m9eLEDXEzf9yMSufBtap6xb
Einarsson, et al. Expires 7 May 2020 [Page 25]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
wcDMA3wvqk35PDeyAQwAgFIzERxgt1aZlcA29Ds10pv0Y3oZ5yKvMNxd+WEEZNcT
rJBOFNlhek5/9/nkATGiDBaKOsu5o9VyDfKMAV0TYwZxuMgUNtvVpf0XL21dghYt
KVqEHeOTXzprUBdztG4Lp4e0vsG0jPZS+CvTLjbcvO+/lzb314mwN8s8vZiQ7Vlj
DxubIqKypY3jL66U0Acwk85IsXdK4CB4nousr2JFK3Y3zv7cQBtPKHEG8HkmvT0R
tl0QoAkdHfw0q4rpc6183FA9e8EUV88XRJrKIYn86IaTPuMkp8ULWSsboalkJH3J
rSq8kzAFFd/A6G8wSj/hVpH6U+NBGW3Z/DQnRmwHqSJfu/Tnue6TFLdDN1EYzk/L
Nlr4YsH6eIB8v3H4u6kY/SwhHCv/F0jItHYVSsIeJz81L0vh28H6hLIMvSDFofJP
fBgIJfZIJ8nzgFpLphVpk0mcI7jHElxEPRg/M5Lmlav9srYHbKbJ0LT67Z9AFnZB
LHRa/p1eZnjpTxrYU2qZ0sHaAS0MB1TwpiucDRH2VN1z8vSKb1qizJ6ZH3qT3zQ8
EAf6Lar5B6l3v/WwhjMPgu/pLlvZgDAo0cWkBYqzWpOcwviAeC7OwqnZY9/BFm/F
RefFysUIu7fWpvBbKtdch9lhb3baetWKI9uAwsaublwgSGZ4dBR2hfVaX72/8oDW
3oJoUvlw59J1r5Ai1l1YtyU8ctNGT2CqbKp6OgVzqm8BOhyQS1ayjMNU0VJs0s3N
BJ0B1rctk5QykDAu3rVf+sgyqzQ7ohFqlG0W/7haocAQqW++Wy9PW/n0oNAuwugv
W4zisCSB916z7whso00e1Ee3Fl7xgubzrGCHU3JNO5X73+gQHZ+jzuyGdBM5NTxd
UcT89ekkd9XqfR2kJrhgiUOe15znWks5JB6VGKWfz2kp2wu1AVxSkbii1Qk/tRhX
PUpHGwkin41WCPlUFA6xMLk9RmLjer2Wkg9zYosnzEIHdPj+WisWY86NRSZ/tJiw
qZvzNwIgkzvqs1T/8aU5Z5rUOqI1l0Kd+tVjlkPyLrZOrvEeYwOwbAzlCdLxsCdq
pY4ckpU/kMbfXXk21YWYFKDCopT7iRkuzDYlyGN4w/LPKQCMZrQxSms9uPNU5XG7
Au4yYdZVMkCLuLQ0kktuLe/CCX4bX82eF/AJ5DEFxWB3CT8FbVhdKrQ2RrLKwE7b
0jBdmT3NoJMtCbq68TBJO3MmOu6AaW7cD4INREbiD+Vr8ukqsnWkFiJ3NigQiT/4
PppJ2bAABRy9Gloa434PN3zgoWzmv80EfyNbZNfY7nGAOhAzBs8FqhrOY2WIBTp+
YEkvEjS5YOwgEj1/zcHts1pOWczY/AfVi2sLkCT8FqsNlfPPebdR4Oq+CEav/M52
A+CS0s7j1gklNfNd
=87qA
-----END PGP MESSAGE-----
--bcde3ce988--
Unwrapping the Cryptographic Layer yields the following content:
Einarsson, et al. Expires 7 May 2020 [Page 26]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
Content-Type: text/plain; charset="us-ascii"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Mon, 21 Oct 2019 07:18:11 -0700
Subject: BarCorp contract signed, let's go!
Message-ID: <signed+encrypted@protected-headers.example>
Hi Bob!
I just signed the contract with BarCorp and they've set us up with an account
on their system for testing.
The account information is:
Site: https://barcorp.example/
Username: examplecorptest
Password: correct-horse-battery-staple
Please get the account set up and apply the test harness.
Let me know when you've got some results.
Thanks, Alice
--
Alice Lovelace
President
OpenPGP Example Corp
9.3. Signed and Encrypted Message with Protected Headers and Legacy
Display Part
If Alice's MUA wasn't sure whether Bob's MUA would know to render the
obscured "Subject:" header correctly, it might include a legacy
display part in the cryptographic payload.
This message is structured in the following way:
└┬╴multipart/encrypted
├─╴application/pgp-encrypted
└─╴application/octet-stream
↧ (decrypts to)
└┬╴multipart/mixed ← Cryptographic Payload
├─╴text/rfc822-headers ← Legacy Display Part
└─╴text/plain
The example below shows the same message as Section 9.2.
Einarsson, et al. Expires 7 May 2020 [Page 27]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
If Bob's MUA is capable of handling protected headers, the two
messages should render in the same way as the message in Section 9.2,
because it will know to omit the Legacy Display part as documented in
Section 5.2.
But if Bob's MUA is capable of decryption but is unaware of protected
headers, it will likely render the Legacy Display part for him so
that he can at least see the originally-intended "Subject:" line.
For this message, the session key is an AES-256 key with value
"95a71b0e344cce43a4dd52c5fd01deec5118290bfd0792a8a733c653a12d223e"
(in hex).
Received: from localhost (localhost [127.0.0.1]);
Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00)
MIME-Version: 1.0
Content-Type: multipart/encrypted; boundary="73c8655345";
protocol="application/pgp-encrypted"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Mon, 21 Oct 2019 07:18:11 -0700
Message-ID: <signed+encrypted+legacy-display@protected-headers.example>
Subject: ...
--73c8655345
content-type: application/pgp-encrypted
Version: 1
--73c8655345
content-type: application/octet-stream
-----BEGIN PGP MESSAGE-----
wV4DR2b2udXyHrYSAQdAS0G0tRGi0cGe2INISDT7xS8b5e1iezXzXuFOrAa1fWgw
JK32KLaTpnHegkEVB/cdMLMEEq56BkktxtC94YNSoeKJOTmNPhR+YWLruWRmZoAk
wcDMA3wvqk35PDeyAQv6Ag30fne2jVFaH+oStUEoX/BEaclWJfpIgu9Ex5SYLmEg
tNHJtLMbKWYKQHhpMiyONeVvfgkus8cPZMtpc+eZEP9FaEdQ69CqkB9Cmqt4Hs2q
yNk14ec0KtL9/b5IPx4rVBrBuFSqxxiS0r0bMsTvKss1p4UGgPN9UPhJSj4dsmDP
w+gLkxsUKL6i37QJIOmarMawS4iK7/MN+GbjzlMduw/VuLV80DYgIt4l96E9xJ+1
u7S6/TKXyUSuxG1Wo+3tCEpy+hTKeS8mYnjD8OYVF5To+TCMnznCiEEwebd44ild
54Bt4QS/G+x/s/aSFRM8pN2O8qz5D5sy+Mzp4dG6w/9fAhIt9mp8W/6Vn+Cgy8kD
0dHy3pN5dVavmsBqzy0uaf4xAoLLJZQBzyR+0UWygUyfc2N6VHkXo+S30LhSfkJO
BMNKqkCaUoLFlHQLstZXETfXMJzpuUySH99ZTeyVnfB/eiEr9CByQqTeN9Uqtu0R
QYWEpTvvYei/vJCNDBqT0sIxAftxmF/H2K4hCW2qD3eE/zSe2PpabgStHmfdZrcx
X1sdOYZ7nOE0L3J/zE3jASEyQUZHr5rdt/RI5qwD2a7zirp8RNAyvk93InQuseX7
mgHADtk9LdNTWumiUd8pvm/ChXoRKvqjSV7mHpdBil0D4JKpZTGAQieP4fF71IYw
4E+VwiZZKIDSiYMUEljA3U7+M9siELlvKRACrrPZKr6OE58JywlIgRdewzroMWIO
Einarsson, et al. Expires 7 May 2020 [Page 28]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
HoNJ4EOzij5rJfd6fAF4A3lH3wRu8dcuqrKwK2DhL+as1Zc/AABZD9Ov8t97/A/t
b6jWJqVAVWilgarv9wwI4icN6q9hdwPZF5OaLgvpskGAtG3z51vkJuAiMogWP2Iv
T0GuamZb5177yH5ShtowlTZN6D5WR7ShYbdHAPKRWFcYz4S9b7UZiWH1Ts2lHglJ
5mUbpTI1EvJFO1nwUcVLTuqB2N7lwVvD0oM9lSDcgUmrS04lqBDEax1V+PoKXYAi
Q0z3eH6EDzw0xYWZhiBjgvor2qmGuIEqjBa+5qIOMrzBZK+7y0KOlkgaPik0BeYB
jC/107Us+5i7c3EfQXj4K5XP72/SR0KC9cr//q9tRBOGki8yVicyOGbtSGsNgul/
5T0VlrTecw+3ZOH4mQRGCJmxkes1amdDeklISfBeOe+LBx/tjkyixeXeh05i1doy
n9VY/utOqu3Oo6XnTWktxajuhfvwSA2wNB/JnRFqu8QEVmqVzD/jwNvsvETQC83j
GPKYo+P1PpAHeqRs4tMq18JQzzytXzr5llLp26qT4Sgul+8tqafkfS6zGL1xShMQ
V1uMtoAt5KBfO4nfiGUAiZeR2RqRrT4YLHEZvpblIE8y7l3y8WV8gdiFfOXZ21mg
gGntqnxU0hrC0IggGVBBY7zHVrcQxJOGsnAsqhQJpVBSnP0YgyrKCEVgDF4ibPBz
y2bRxKP4es0advuEVKGAHULhzoV26Siz8h9MkeI6o+d28vestHng++2DsmCrdpSv
EatA
=MxXQ
-----END PGP MESSAGE-----
--73c8655345--
Unwrapping the Cryptographic Layer yields the following content:
Einarsson, et al. Expires 7 May 2020 [Page 29]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
Content-Type: multipart/mixed; boundary="6ae0cc9247"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Mon, 21 Oct 2019 07:18:11 -0700
Subject: BarCorp contract signed, let's go!
Message-ID: <signed+encrypted+legacy-display@protected-headers.example>
--6ae0cc9247
Content-Type: text/rfc822-headers; charset="us-ascii"; protected-headers="v1"
Content-Disposition: inline
Subject: BarCorp contract signed, let's go!
--6ae0cc9247
Content-Type: text/plain; charset="us-ascii"
Hi Bob!
I just signed the contract with BarCorp and they've set us up with an account
on their system for testing.
The account information is:
Site: https://barcorp.example/
Username: examplecorptest
Password: correct-horse-battery-staple
Please get the account set up and apply the test harness.
Let me know when you've got some results.
Thanks, Alice
--
Alice Lovelace
President
OpenPGP Example Corp
--6ae0cc9247--
9.4. Multilayer Message with Protected Headers
Some mailers may generate signed and encrypted messages with a
multilayer cryptographic envelope. We show here how such a mailer
might generate the same message as Section 9.2.
A typical message like this has the following structure:
Einarsson, et al. Expires 7 May 2020 [Page 30]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
└┬╴multipart/encrypted
├─╴application/pgp-encrypted
└─╴application/octet-stream
↧ (decrypts to)
└┬╴multipart/signed
├─╴text/plain ← Cryptographic Payload
└─╴application/pgp-signature
For this message, the session key is an AES-256 key with value
"5e67165ed1516333daeba32044f88fd75d4a9485a563d14705e41d31fb61a9e9"
(in hex).
Received: from localhost (localhost [127.0.0.1]);
Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00)
MIME-Version: 1.0
Content-Type: multipart/encrypted; boundary="15d01ebd43";
protocol="application/pgp-encrypted"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Mon, 21 Oct 2019 07:18:11 -0700
Message-ID: <multilayer@protected-headers.example>
Subject: ...
--15d01ebd43
content-type: application/pgp-encrypted
Version: 1
--15d01ebd43
content-type: application/octet-stream
-----BEGIN PGP MESSAGE-----
wV4DR2b2udXyHrYSAQdArQ8apKY0ciE47ZyBKgbOditGO6OBizW/VeQItRdCxA0w
KaoRJewLgRnuvwaEisHWjiA0IHB9+0BSja+GFIh6gBWCFqzAfJQxoywAZMHznn6k
wcDMA3wvqk35PDeyAQv/X3CYHUgNH81gAKZK/Cb7+WDbjmHcgskkvtceANQbEBEr
/yVoou5BSlXsEni2wn1dtrIsrkhj6OF+B1mwGELw/3qcXdhT46iIrjn547b8Wycp
saey8JqqX8FdfrxEYyOeBJn9CMDm0Dawfv+kNEdbfZtZ2IUONRgigKfcs+Pvrv3e
hoY3KUe47cbiqKvw11VFTu2e4+rIPXW4sB3/95Epvo+RSo58p62kbvJDmBPt5E06
mEykcvyd6GP0eyTTbtaHNcNWd8jvGUobfikwibADcmjXmbPwTJefMCBbsYov86bK
72QOWbp39JcmwUWdo850+sU0XoCHmqditFfZqEdcKRFJOl+Rt+pMSrDixHb8Thdi
WcxUXetpDvACrmjsipKHbxBZAgEU0K71zvbUPk930jOqJgsyXKX0WI8u32gNZDfc
enHAAnALKvwoTGU3EM6do0XRMUKYL6+ON1F1L9S1Rm9Fa+WQKcO04ZvdeHbQXkt3
Fx6ZvZT/Bn3fcIWBpHfs0sI0AfeSpGjSejaZvZQ8qoOTQkOqrjuRnpU8232/ngsC
46mObydGJZ5qEMnmdDOfQB6L1LR9dQTCzA6swlG4U62MoO0n6yILCxLZTPVKYm7c
6r4KnQcvrGk1pgozdW1QjFBOjiDXbitHnqGorxKUcVVorXSEU919wKm11tGGyZ7/
2sta4WQq9ILVvPqB2I1hLfbteBUYWgB/rJcc6JsZyRItEKjSSXZoanYyuCPf0m5r
rpzf18kz8gYk92RTLzefALgMiIuU9CXFtd673/MalsZ2DRYjnI3tC9AXEdV9yVVa
Einarsson, et al. Expires 7 May 2020 [Page 31]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
KYX/ECbFPHNxxulu/HU7hL7QQbgxA1E41RM2KjEzmwUEA8EomuNN7eQ5AJjDP0qk
EIjIxIsW8at8FB4vB4sxh95OiF3hHFZj8q6/VZW8K8LspERCdrKmtu46xt2g7uKx
8ifdwqMT5OPu4VD5EPuOZLJRnSnYskTBwjZnX+ZqRdz/7z7XdUhvn4CjjiFt804a
4uunVgTeVXQay97a7oz+SCrNc+Gvv7K0dt7oUt512+0hQAJ3W9J3Chlht4UKs759
QymPx4smS8kY7c57OWpab481cqeQZLMIftBconhzSzAGl1LZhc5MVoc7l3dEABcx
G+zcTIiRT+io8PwaBvnUg3nE0xP201s5vpK2vbBBMDh3O3titYMBDJp3riyp81AR
Rm6tymUZaRMxq17T6BJ0b0fXyQ2fiz5vuudK5L/zDBvkOSIlhvaV2zxJqMhlSS54
W2RrwNjxkgBCiz1u1Yzi/HQ+jUwO/p8uGn0hyyIEEDIX50gPe2IQjgEjGteIBrDF
sfi9jCEhK/Y0xANG4Mt01Ukt6cgGQhrKuBnyy9KRG+US7aaPdMQuPLfOlhPZOjIQ
Bytek3JyT/QCsKPSjcGiNinllYk+Za8gL6SCNfZam1y/E802xX4z30t7Z6EBSRLi
+qwzOCu7wTkJkoOPLfZFLY41OrVaR8lyBG1eZmtJXbER1GuuRv/7IC2xcDZv/2VO
ahdnPLy7
=rOD1
-----END PGP MESSAGE-----
--15d01ebd43--
Unwrapping the encryption Cryptographic Layer yields the following
content:
Einarsson, et al. Expires 7 May 2020 [Page 32]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
Content-Type: multipart/signed; boundary="a6b911f1d1";
protocol="application/pgp-signature"; micalg="pgp-sha512"
--a6b911f1d1
Content-Type: text/plain; charset="us-ascii"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Mon, 21 Oct 2019 07:18:11 -0700
Subject: BarCorp contract signed, let's go!
Message-ID: <multilayer@protected-headers.example>
Hi Bob!
I just signed the contract with BarCorp and they've set us up with an account
on their system for testing.
The account information is:
Site: https://barcorp.example/
Username: examplecorptest
Password: correct-horse-battery-staple
Please get the account set up and apply the test harness.
Let me know when you've got some results.
Thanks, Alice
--
Alice Lovelace
President
OpenPGP Example Corp
--a6b911f1d1
content-type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj
jk5oAQCUL+lTDVp2pMOgcDuwnYtYCU9XMRxLgG4bZERZaYf1jQEAj85xO9Cjd7dZ
jBU3m8KYcHe5P5QtOYMw8snpliWXXgA=
=Vh3K
-----END PGP SIGNATURE-----
--a6b911f1d1--
Note the placement of the Protected Headers on the Cryptographic
Payload specifically, which is not the immediate child of the
encryption Cryptographic Layer.
Einarsson, et al. Expires 7 May 2020 [Page 33]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
9.5. Multilayer Message with Protected Headers and Legacy Display Part
And, a mailer that generates a multilayer cryptographic envelope
might want to provide a Legacy Display part, if it is unsure of the
capabilities of the recipient's MUA. We show here how sucha mailer
might generate the same message as Section 9.2.
Such a message might have the following structure:
└┬╴multipart/encrypted
├─╴application/pgp-encrypted
└─╴application/octet-stream
↧ (decrypts to)
└┬╴multipart/signed
├┬╴multipart/mixed ← Cryptographic Payload
│├─╴text/rfc822-headers ← Legacy Display Part
│└─╴text/plain
└─╴application/pgp-signature
For this message, the session key is an AES-256 key with value
"b346a2a50fa0cf62895b74e8c0d2ad9e3ee1f02b5d564c77d879caaee7a0aa70"
(in hex).
Received: from localhost (localhost [127.0.0.1]);
Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00)
MIME-Version: 1.0
Content-Type: multipart/encrypted; boundary="750bb87f7c";
protocol="application/pgp-encrypted"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Mon, 21 Oct 2019 07:18:11 -0700
Message-ID: <multilayer+legacy-display@protected-headers.example>
Subject: ...
--750bb87f7c
content-type: application/pgp-encrypted
Version: 1
--750bb87f7c
content-type: application/octet-stream
-----BEGIN PGP MESSAGE-----
wV4DR2b2udXyHrYSAQdAQL6ivBlSduqtPTk/Y3+ijcQ+N5NYfDl+o474FT/BUBIw
iZzmY+CQgrHf2iRPm2GuOoN+XuZtFYk4cIhwe0gAK7+p/44osZGipnzcw0NDbMC3
wcDMA3wvqk35PDeyAQwAtPLguH2X/uqQupJWoF5bnpcxogM2hr+7W5FSFNCiTh6L
ZWYY9B1M+qQqOsTSqpA9mhOoqlnUGiRWYFU164mla3KmMu4rDKSrP761E9ozQl4k
Einarsson, et al. Expires 7 May 2020 [Page 34]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
o7+xjvWEBsVeU6KZLPpi9r5KDxwiGO8PT7qsNHv+OTSvJbOv1azLcSo4g67J03uU
rSbMDjPD1BAZDyf7TwKpg4MXVmJtnuHURjzIQ/VtS6eZ0FYzvPZX0rMo00G4bNkR
t1w06hEUemFRtEI/JhD8H3hDkx4Xo/XBWuiVD/UWrlXh1rGjTCfezd4p7F74/+t+
VHxLWWkyeNXnQqFZX6nIclvoW/ZQr2RycA8j7L/BSYEeINxE4gau+Mh/9IN460G5
Aabjok1FIv8D3inMDI9MgxHYOkAReCMJ4btObtLlzQy+f6aE3BPihIvAYlRzCBel
9Cl604BDGmVug+UeYJ7+1S55HB5vbWzx88IwELw4FCFaYwiK2FOB53tXSc/sGkBQ
Eh7hf2RLSq0c17fMBuNa0sKDAY5PKwukRG+RDz/TeM0e2Y42hPsVm6rOPKNIjygd
oGHLfXw/vYtpxVcdipa9LRAnoJ4JNSaB3vOLz54yxeXuOJrg6nT9JvSRuQ1AlZHq
7Sf2i0kbYkNYZOig54PVJ1/ESkzyrNlmxlRrmo/I9tCr7Wa5bMlgh0S7wm5wPUm4
sEEf+WeqU9cAQKGz4gmY87/ErvPUnudcl21SKyFZ6SlgXdo1GEAUagf3YPL/eOaW
KSG/c69L3K2nBr8NnsTH054AokKOEJKM0+Tu+z8dSRFfa8vJt+fbaV/wL3xK9yEQ
KxJurGTCQ3uKyaeVEyyc5oscv005iaaS9cskkU2eArjAoXNcS7dFMuNXJBbn9WZc
vDmlUSnpob6ZEVySNiQLKyVPsd50VQALv9ySsVT/LNx1N+QR4PSg7uX029itcXbp
zuJgBg8hnpZxKD1vWPzWslmyaC6iS4Q0qiD4XL669NEmtrSpXjX1xFv5SGLWO7IE
TQttUOUgH2tarrFESGOV+354h8kW/CewMO3yR/rTV19HsZfBbuzCLMiURPmK51gb
diZCD9mxd+LPuMPKo0nnoKgloFMgiono9bimJonGNKdfwhoRFFP8tIHZhkue9zqb
AnjZazfsI6YyfGsshfjQ2xHUuT8tTXtNCA/yhhld3yp1b2LfWdWdGxcGrVugFhy3
fUBgeiL2cIf09cn10Y19cIISwa++LpkVWLWuINORu+d2z5Yi9E2I3Tqoi7kt3PvA
GVfKK+Vpytf5f19vm53gfYPGHeF+V9fLZq2JrD4ewSzHSzbSf0Lo2uIUCRv9gTXV
scKiRvA7O0tjQHKFQKcrZLcUd1YE3uRcLqL4GMlHZMdRIQ2SfEvZe8Ad5ZxoacTW
nthYxDipYMheaLmXmePyTGXV0yo/btUe9q0vErhxIrWxnonhQxronVR2go9695Ia
w/b1FdihjhBvVmymHdYXxCsbIKIPsE7MeAt0YXEmOly2MsqlbYv+XVwFpw9gYa6E
QwMRS3Kd1bJgpuqZ4nOnHgZ1Qewhi1WbF9M3Kz6EryAgQJ6Sgy7syHqdYh4MzVOE
+VMThZ5Q92DIQcJsPpEKpDIfnbEYm7N6Icfmz6fj1L9s7X1oew==
=KH2Q
-----END PGP MESSAGE-----
--750bb87f7c--
Unwrapping the encryption Cryptographic Layer yields the following
content:
Content-Type: multipart/signed; boundary="4e3b9ccaba";
protocol="application/pgp-signature"; micalg="pgp-sha512"
--4e3b9ccaba
Content-Type: multipart/mixed; boundary="6ae0cc9247"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Mon, 21 Oct 2019 07:18:11 -0700
Subject: BarCorp contract signed, let's go!
Message-ID: <multilayer+legacy-display@protected-headers.example>
--6ae0cc9247
Content-Type: text/rfc822-headers; charset="us-ascii"; protected-headers="v1"
Content-Disposition: inline
Subject: BarCorp contract signed, let's go!
Einarsson, et al. Expires 7 May 2020 [Page 35]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
--6ae0cc9247
Content-Type: text/plain; charset="us-ascii"
Hi Bob!
I just signed the contract with BarCorp and they've set us up with an account
on their system for testing.
The account information is:
Site: https://barcorp.example/
Username: examplecorptest
Password: correct-horse-battery-staple
Please get the account set up and apply the test harness.
Let me know when you've got some results.
Thanks, Alice
--
Alice Lovelace
President
OpenPGP Example Corp
--6ae0cc9247--
--4e3b9ccaba
content-type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj
jgzVAQCXwrEyApDaRBeUX1kQOCbb3RVpXcSO+BdROF1T5K3FxAEAs4hYWZXJD1lp
UBe7D64qKa+fyQE1akkIWgoqoaTSlgk=
=zdtG
-----END PGP SIGNATURE-----
--4e3b9ccaba--
9.6. An Unfortunately Complex Example
For all of the potential complexity of the Cryptographic Envelope,
the Cryptographic Payload itself can be complex. The Cryptographic
Envelope in this example is the same as the previous example
(Section 9.5). The Cryptographic Payload has protected headers and a
legacy display part (also the same as Section 9.5), but in addition
Alice's MUA composes a message with both plaintext and HTML variants,
and Alice includes a single attachment as well.
Einarsson, et al. Expires 7 May 2020 [Page 36]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
While this message is complex, a modern MUA could also plausibly
generate such a structure based on reasonable commands from the user
composing the message (e.g., Alice composes the message with a rich
text editor, and attaches a file to the message).
The key takeaway of this example is that the complexity of the
Cryptographic Payload (which may contain a Legacy Display part) is
independent of and distinct from the complexity of the Cryptographic
Envelope.
This message has the following structure:
└┬╴multipart/encrypted
├─╴application/pgp-encrypted
└─╴application/octet-stream
↧ (decrypts to)
└┬╴multipart/signed
├┬╴multipart/mixed ← Cryptographic Payload
│├─╴text/rfc822-headers ← Legacy Display Part
│└┬╴multipart/mixed
│ ├┬╴multipart/alternative
│ │├─╴text/plain
│ │└─╴text/html
│ └─╴text/x-diff ← attachment
└─╴application/pgp-signature
For this message, the session key is an AES-256 key with value
"1c489cfad9f3c0bf3214bf34e6da42b7f64005e59726baa1b17ffdefe6ecbb52"
(in hex).
Received: from localhost (localhost [127.0.0.1]);
Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00)
MIME-Version: 1.0
Content-Type: multipart/encrypted; boundary="241c1d8182";
protocol="application/pgp-encrypted"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Mon, 21 Oct 2019 07:18:11 -0700
Message-ID: <unfortunately-complex@protected-headers.example>
Subject: ...
--241c1d8182
content-type: application/pgp-encrypted
Version: 1
--241c1d8182
content-type: application/octet-stream
Einarsson, et al. Expires 7 May 2020 [Page 37]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
-----BEGIN PGP MESSAGE-----
wV4DR2b2udXyHrYSAQdA6Hrr6FR4JVEu7eJP/tRMX/kaargXF/e5wrUW2Et3Ty8w
HbZhbIWW4vt9reojwemfCX99j9s6zmKCEaAYVwyDZTZd+28AJNIScDgUVD9346cA
wcDMA3wvqk35PDeyAQwAlCnRuVFh7GjzxzLpu6he63MNsKNKFFDKz/mXp5i0O7Je
EUzUd1Hbrmn4OP/fznXrgPoi62DGlJkH/Al31EF5SqkxR71A9v9S3DnJ3PEjNAM9
lrOgEmJnKLGMoFy3wkDDs6c/qQqjLZTtdTrfteQtH9rlLqrPLqV+wbfxGi6qBh07
mUBqbdidqOpBKRs3k5vTXDrsAhGuKK0vTZd5yYJ0emBLtEnKm6MpJdaGWgO7CVnq
8/i4UoMV1lKEQQMB2gnrZ2wGXBD24jkaPefpPhLYa6WSOwL9E49fuo4AJy1CDxm8
aN2PQa+8VsBovsavh2BF50Auy0dGmjdru1O0t8hD1KyFrogeGJ/JgEJFkX5kK0M6
jgW+UZDws0ex3b7ikxM2Gboq2WeOoWqrP7Q09vPUo7fabR74ngj1VpjAdnY5v+cO
HVG+hdAB5dgxXXzI8xYIP7z3bm2refQ1dbomlc8cXb7UJwKhpVgTPdwjcheZDeE9
RVLwradRXPmTqGfWTWSS0sPcAXU5DkOUxi7PiRObKeCAmw2sUnwh9t6vTq+ZFIqQ
JmvsI++VftKg5hiqnPV88pF5fvjDbbcTvHNEAMtMFXLFjGHtcz1dRNwAn8DOXj5F
JpBwGGtY19JZrHPP98gFioqwTQja+7M6b7KTuWKx9+bZ0JjsALxSFW+1taZN0+SB
Ox60tfD0kTp3Wq+W13IYBqSniFkFkWRoua5ta9LUrVPHAnG1d8utycGsroXK/9sl
/dshobLC3qmrInLh6VeryVZBFBOcOW7w5FzxZbAt6xuEvU/ooRepBwIbYkfc66OD
3yEXh6OJmMX6Cqs/HpN66lDRlm4IHD6y88j+Ot9Pwxid1GcEH6Y89rnNqCcoTRDf
94tIXtLb7a1JZlOBOLcM5B/0Qlk3YtuSw945jynqYWJ9sOG+jX0sZ0ZwwRY/gIAz
vPzGzO5UDUiusL5Go1xiJjXvbXW+LKSzgzjOLkUlz1SP5OEkntigMQvsFsKRtE6K
sPeHf8b5INp8tOaHiYX9tnbS8Ozok+BBQTvT0f1tYSlQkGLfvLDFyat1f7ChdTpo
tZBKX+VBycblXzbIo8+BlVRIT0CiNIZwujN50IBfXGbBrxJqbNcA0GQwtLIgZSHG
+1k6nGLPaHJjgN44AfH9JREZD3pMTih9zjfDnOA/dij8XOSIwuQkS0wVrkcvnT9v
ByMn5QYUMUxajAMthP7YLd3uBjvhpqtYPhi8pXB6PuTsLk2nHMIWoKh/WqckZcjx
pccjLia74y+O06XHI2SPG/BtjF7S9s71VcXdmQwzpJ7BP6hCHJ/AIb9W1+UdCCSX
7DHgn7wHqmbQ+LVQDMw2qvBLAXL2D2hn5uXcVMzvL9XuS00UnaKUoYILmhmkBdgl
EVqW/ZeKYv5erZUkTB1f179aXrtoQ4cMRoZfE4S7+j2yCiee8tJRvOQBQjg8KsdZ
b0gR1v8rkEHC9KhURsDmCGaZuFYyl5e4pne2jHDwkyEmTAygdcJpMqbdLb+KGw0V
pacv7pOQj0U0oaEn6JQuiZD1fTjsyNqSVS3whHe/wf5LKeIFNrTqVXi0GwKiZBrp
pvsr4I4H/luVqSg7QKJGpt/tmXY+RPAMts+8FnHBN0SrON2yuVZh3oXv/j8L1qBV
BeUGnA2FYMfCpJti5UBQThZjFieNRT3xVzezGSnhQHeLAB08weAqEOfXP9HBcRng
yNTRKTCfA7NCYHpqjT7+A9d83PEmbX9dAeJxVbIgwkqVVmeW0LmLJi3Lh9qilOJ+
66xTQQtreq2GUHY5jHapu1mTB2FRmbLftQ+yPsooNVvtzAroEwo2+NKNsHZdyqma
28ECmCbHbCkoVkDyyZDwx9HF8V+0vVxWlW2feYI5IfEbsRlo00s5gMT6e+NZ7lLt
OmwxtPM9UZk6HxoCb+ZaqQDiZljp6NypFhz4rxbgZHU4oUgQ0QndLk9NlipCKj2Q
FX7WBggqXtjMPUHCR6xH2+VPNOQN5O3exT1TCnrT9k2t+8IXB/hgVP/OQSHiI+og
AZQrFl2jObo6CvsOOojsy4rxfawiTo5HafaFBz8GpqQuUt4IGHZIofGIMLU1OQ==
=XtUM
-----END PGP MESSAGE-----
--241c1d8182--
Unwrapping the encryption Cryptographic Layer yields the following
content:
Einarsson, et al. Expires 7 May 2020 [Page 38]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
Content-Type: multipart/signed; boundary="c72d4fa142";
protocol="application/pgp-signature"; micalg="pgp-sha512"
--c72d4fa142
Content-Type: multipart/mixed; boundary="6ae0cc9247"
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Date: Mon, 21 Oct 2019 07:18:11 -0700
Subject: BarCorp contract signed, let's go!
Message-ID: <unfortunately-complex@protected-headers.example>
--6ae0cc9247
Content-Type: text/rfc822-headers; charset="us-ascii"; protected-headers="v1"
Content-Disposition: inline
Subject: BarCorp contract signed, let's go!
--6ae0cc9247
Content-Type: multipart/mixed; boundary="8dfc0e9ecf"
--8dfc0e9ecf
Content-Type: multipart/alternative; boundary="32c4d5a901"
--32c4d5a901
Content-Type: text/plain; charset="us-ascii"
Hi Bob!
I just signed the contract with BarCorp and they've set us up with an account
on their system for testing.
The account information is:
Site: https://barcorp.example/
Username: examplecorptest
Password: correct-horse-battery-staple
Please get the account set up and apply the test harness.
Let me know when you've got some results.
Thanks, Alice
--
Alice Lovelace
President
OpenPGP Example Corp
--32c4d5a901
Einarsson, et al. Expires 7 May 2020 [Page 39]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
Content-Type: text/html; charset="us-ascii"
<html><head></head><body><p>Hi Bob!
</p><p>
I just signed the contract with BarCorp and they've set us up with an account on their system for testing.
</p><p>
The account information is:
</p><dl>
<dt>Site</dt><dd><a href="https://barcorp.example/">https://barcorp.example/</a></dd>
<dt>Username</dt><dd><tt>examplecorptest</tt></dd>
<dt>Password</dt><dd>correct-horse-battery-staple</dd>
</dl><p>
Please get the account set up and apply the test harness.
</p><p>
Let me know when you've got some results.
</p><p>
Thanks, Alice<br/>
-- <br/>
Alice Lovelace<br/>
President<br/>
OpenPGP Example Corp<br/>
</p></body></html>
--32c4d5a901--
--8dfc0e9ecf
Content-Type: text/x-diff; charset="us-ascii"
Content-Disposition: inline; filename="testharness-config.diff"
diff -ruN a/testharness.cfg b/testharness.cfg
--- a/testharness.cfg
+++ b/testharness.cfg
@@ -13,3 +13,8 @@
endpoint = https://openpgp.example/test/
username = testuser
password = MJVMZlHR75mILg
+
+[barcorp]
+endpoint = https://barcorp.example/
+username = examplecorptest
+password = correct-horse-battery-staple
--8dfc0e9ecf--
--6ae0cc9247--
--c72d4fa142
content-type: application/pgp-signature
Einarsson, et al. Expires 7 May 2020 [Page 40]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
-----BEGIN PGP SIGNATURE-----
wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj
juFdAQDjMySpe88yowVduslDi/IGFTGNn1d0ZxpA3IGW5Ss8ZQD9H2zbBtiKXtc7
axmvtiKF4z1DdY/IgOKFfmyGX2WZrws=
=Sv5w
-----END PGP SIGNATURE-----
--c72d4fa142--
10. IANA Considerations
FIXME: register content-type parameter for legacy-display part
MAYBE: provide a list of user-facing headers, or a new "user-facing"
column in some table of known RFC5322 headers?
MAYBE: provide a comparable indicator for which headers are
"structural" ?
11. Security Considerations
This document describes a technique that can be used to defend
against two security vulnerabilities in traditional end-to-end
encrypted e-mail.
11.1. Subject Leak
While e-mail structure considers the Subject header to be part of the
message metadata, nearly all users consider the Subject header to be
part of the message content.
As such, a user sending end-to-end encrypted e-mail may inadvertently
leak sensitive material in the Subject line.
If the user's MUA uses Protected Headers and obscures the Subject
header as described in Section 4.2 then they can avoid this breach of
confidentiality.
11.2. Signature Replay
A message without Protected Headers may be subject to a signature
replay attack, which attempts to violate the recipient's expectations
about message authenticity and integrity. Such an attack works by
taking a message delivered in one context (e.g., to someone else, at
a different time, with a different subject, in reply to a different
message), and replaying it with different message headers.
Einarsson, et al. Expires 7 May 2020 [Page 41]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
A MUA that generates all its signed messages with Protected Headers
gives recipients the opportunity to avoid falling victim to this
attack.
Guidance for how a message recipient can use Protected Headers to
defend against a signature replay attack are out of scope for this
document.
11.3. Participant Modification
A trivial (if detectable) attack by an active network adversary is to
insert an additional e-mail address in a "To" or "Cc" or "Reply-To"
or "From" header. This is a staging attack against message
confidentiality - it relies on followup action by the recipient.
For an encrypted message that is part of an ongoing discussion where
users are accustomed to doing "reply all", such an insertion would
cause the replying MUA to encrypt the replying message to the
additional party, giving them access to the conversation. If the
replying MUA quotes and attributes cleartext from the original
message within the reply, then the attacker learns the contents of
the encrypted message.
As certificate discovery becomes more automated and less noticeable
to the end user, this is an increasing risk.
An MUA that rejects Exposed Headers in favor of Protected Headers
should be able to avoid this attack when replying to a signed
message.
12. Privacy Considerations
This document only explicitly contemplates confidentiality protection
for the Subject header, but not for other headers which may leak
associational metadata. For example, "From" and "To" and "Cc" and
"Reply-To" and "Date" and "Message-Id" and "References" and "In-
Reply-To" are not explicitly necessary for messages in transit, since
the SMTP envelope carries all necessary routing information, but an
encrypted [RFC2822] message as described in this document will
contain all this associational metadata in the clear.
Although this document does not provide guidance for protecting the
privacy of this metadata directly, it offers a platform upon which
thoughtful implementations may experiment with obscuring additional
e-mail headers.
Einarsson, et al. Expires 7 May 2020 [Page 42]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
13. Document Considerations
[ RFC Editor: please remove this section before publication ]
This document is currently edited as markdown. Minor editorial
changes can be suggested via merge requests at
https://github.com/autocrypt/protected-headers or by e-mail to the
authors. Please direct all significant commentary to the public IETF
LAMPS mailing list: spasm@ietf.org
13.1. Document History
14. Acknowledgements
The set of constructs and algorithms in this document has a previous
working title of "Memory Hole", but that title is no longer used as
different implementations gained experience in working with it.
These ideas were tested and fine-tuned in part by the loose
collaboration of MUA developers known as [Autocrypt].
Additional feedback and useful guidance was contributed by attendees
of the OpenPGP e-mail summit ([OpenPGP-Email-Summit-2019]).
The following people have contributed implementation experience,
documentation, critique, and other feedback:
* Holger Krekel
* Patrick Brunschwig
* Vincent Breitmoser
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
DOI 10.17487/RFC2822, April 2001,
<https://www.rfc-editor.org/info/rfc2822>.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156,
Einarsson, et al. Expires 7 May 2020 [Page 43]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
DOI 10.17487/RFC3156, August 2001,
<https://www.rfc-editor.org/info/rfc3156>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
15.2. Informative References
[Autocrypt]
"Autocrypt Specification 1.1", 13 October 2019,
<https://autocrypt.org/level1.html>.
[I-D.draft-bre-openpgp-samples-00]
Einarsson, B., juga, j., and D. Gillmor, "OpenPGP Example
Keys and Certificates", Work in Progress, Internet-Draft,
draft-bre-openpgp-samples-00, 15 October 2019,
<http://www.ietf.org/internet-drafts/draft-bre-openpgp-
samples-00.txt>.
[I-D.draft-ietf-lamps-header-protection-requirements-00]
Melnikov, A. and B. Hoeneisen, "Problem Statement and
Requirements for Header Protection", Work in Progress,
Internet-Draft, draft-ietf-lamps-header-protection-
requirements-00, 8 July 2019, <http://www.ietf.org/
internet-drafts/draft-ietf-lamps-header-protection-
requirements-00.txt>.
[I-D.draft-luck-lamps-pep-header-protection-03]
Luck, C., "pretty Easy privacy (pEp): Progressive Header
Disclosure", Work in Progress, Internet-Draft, draft-luck-
lamps-pep-header-protection-03, 5 July 2019,
<http://www.ietf.org/internet-drafts/draft-luck-lamps-pep-
header-protection-03.txt>.
[OpenPGP-Email-Summit-2019]
"OpenPGP Email Summit 2019", 13 October 2019,
<https://wiki.gnupg.org/OpenPGPEmailSummit201910>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
RFC 2634, DOI 10.17487/RFC2634, June 1999,
<https://www.rfc-editor.org/info/rfc2634>.
Einarsson, et al. Expires 7 May 2020 [Page 44]
Internet-Draft Protected Headers for Cryptographic E-mail November 2019
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, DOI 10.17487/RFC3851, July 2004,
<https://www.rfc-editor.org/info/rfc3851>.
[RFC6736] Brockners, F., Bhandari, S., Singh, V., and V. Fajardo,
"Diameter Network Address and Port Translation Control
Application", RFC 6736, DOI 10.17487/RFC6736, October
2012, <https://www.rfc-editor.org/info/rfc6736>.
[RFC7508] Cailleux, L. and C. Bonatti, "Securing Header Fields with
S/MIME", RFC 7508, DOI 10.17487/RFC7508, April 2015,
<https://www.rfc-editor.org/info/rfc7508>.
[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,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
Authors' Addresses
Bjarni Rúnar Einarsson
Mailpile ehf
Baronsstigur
Iceland
Email: bre@mailpile.is
juga
Independent
Email: juga@riseup.net
Daniel Kahn Gillmor
American Civil Liberties Union
125 Broad St.
New York, NY, 10004
United States of America
Email: dkg@fifthhorseman.net
Einarsson, et al. Expires 7 May 2020 [Page 45]