Guidance on End-to-End E-mail Security

1.1. 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, and/or integrity.¶
• Cryptographic Layer, Cryptographic Envelope, Cryptographic Payload, Cryptographic Summary, and Errant Cryptographic Layer are defined in Section 4¶
• A well-formed e-mail message with cryptographic protection has both a Cryptographic Envelope and a Cryptographic Payload.¶
• Structural Headers are documented in Section 1.1.1.¶
• User-Facing Headers are documented in Section 1.1.2.¶
• Main Body Part is the part (or parts) that are typically rendered to the user as the message itself (not "as an attachment"). See Section 7.1.¶

2.1. Simplicity

The end user (the operator of the MUA) is unlikely to understand complex end-to-end cryptographic protections on any e-mail message, so keep it simple.¶

For clarity to the user, any cryptographic protections should apply to the message as a whole, not just to some subparts.¶

This is true for message composition: the standard message composition user interface of an MUA should offer minimal controls which indicate which types of protection to apply to the new message as a whole.¶

This is also true for message interpretation: the standard message rendering user interface of an MUA should offer a minimal, clear indicator about the end-to-end cryptographic status of the message as a whole.¶

See Section 3 for more detail about mental models and cryptographic status.¶

(It is of course possible that a message forwarded as a MIME attachment could have its own cryptographic status while still being a message subpart; but that status should be distinct from the status of the enclosing message.)¶

2.2. E-mail Users Want a Familiar Experience

A person communicating over the Internet today often has many options for reaching their desired correspondent, including web-based bulletin boards, contact forms, and instant messaging services.¶

E-mail offers a few distinctions from these other systems, most notably features like:¶

• Ubiquity: Most correspondents will have an e-mail address, while not everyone is present on every alternate messaging service,¶
• Federation: interaction between users on distinct domains who have not agreed on a common communications provider is still possible, and¶
• User Control: the user can interact with the e-mail system using a MUA of their choosing, including automation and other control over their preferred and/or customized workflow.¶

Other systems (like some popular instant messaging applications, such as WhatsApp and Signal Private Messenger) offer built-in end-to-end cryptographic protections by default, which are simpler for the user to understand. ("All the messages I see on Signal are confidential and integrity-protected" is a clean user story)¶

A user of e-mail is likely using e-mail instead of other systems because of the distinctions outlined above. When adding end-to-end cryptographic protection to an e-mail endpoint, care should be taken not to negate any of the distinct features of e-mail as a whole. If these features are violated to provide end-to-end crypto, the user may just as well choose one of the other systems that don't have the drawbacks that e-mail has. Implmenters should try to provide end-to-end protections that retain the familiar experience of e-mail itself.¶

Furthermore, an e-mail user is likely to regularly interact with other e-mail correspondents who cannot handle or produce end-to-end cryptographic protections. Care should be taken that enabling cryptography in a MUA does not inadvertently limit the ability of the user to interact with legacy correspondents.¶

2.3. Warning About Failure vs. Announcing Success

Moving the web from http to https offers useful historical similarities to adding end-to-end encryption to e-mail.¶

In particular, the indicators of what is "secure" vs. "insecure" for web browsers have changed over time. For example, years ago the default experience was http, and https sites were flagged with "secure" indicators like a lock icon. In 2018, some browsers reversed that process by downplaying https, and instead visibly marking http as "not secure" (see [chrome-indicators]).¶

By analogy, when the user of a MUA first enables end-to-end cryptographic protection, it's likely that they will want to see which messages have protection. But a user whose private e-mail communications with a given correspondent, or within a given domain are known to be entirely end-to-end protected might instead want to know which messages do not have the expected protections.¶

Note also that some messages may be expected to be confidential, but other messages are expected to be public -- the types of protection (see Section 3) that apply to each particular message will be different. And the types of protection that are expected to be present in any context might differ (for example, by sender, by thread, or by date).¶

It is out of scope for this document to define expectations about protections for any given message, but an implementer who cares about usable experience should be deliberate and judicious about the expectations their interface assumes that the user has in a given context. See also Appendix A.8 for future work.¶

3.1. Simplified Mental Model

To the extent that an e-mail message actually does have end-to-end cryptographic protections, those protections need to be visible and comprehensible to the end user. If the user is unaware of the protections, then they do not extend all the way to the "end".¶

However, most users do not have (or want to have) a sophisticated mental model of what kinds of protections can be associated with a given message. Even the four states above approach the limits of complexity for an interface for normal users.¶

While Section 5.3 recommends avoiding deliberate creation of encrypted-only messages, some messages may end up in the encrypted-only state due to signature failure or certificate revocation.¶

A simple model for the user could be that a message is in one of three normal states:¶

• Unprotected¶
• Verified (has a valid signature from the apparent sender of the message)¶
• Confidential (meaning, encrypted, with a valid signature from the apparent sender of the message)¶

And one error state:¶

• Encrypted But Unverified (meaning, encrypted without a valid signature from the apparent sender of the message)¶

Note that this last state is not "Confidential" (a secret shared exclusively between the participants in the communication) because the recipient does not know for sure who sent it.¶

In an ecosystem where encrypted-only messages are never deliberately sent (see Section 5.3), representing an Encrypted But Unverified message as a type of user-visible error is not unreasonable.¶

Alternately, a MUA may prefer to represent the state of a Encrypted but Unverified message to the user as though it was Unprotected, since no verification is possible. However the MUA represents the message to the user, though, it MUST NOT leak cleartext of an encrypted message (even an Encrypted but Unverified message) in subsequent replies (see Section 5.4) or similar replications of the message.¶

Note that a cleartext message with an invalid signature SHOULD NOT be represented to the user as anything other than Unprotected (see Section 6.4).¶

In a messy legacy ecosystem, a MUA may prefer instead to represent "Signed" and "Encrypted" as orthogonal states of any given message, at the cost of an increase in the complexity of the user's mental model.¶

3.2. One Cryptographic Status Per Message

Some MUAs may attempt to generate multiple copies of a given e-mail message, with different copies offering different types of protection (for example, opportunistically encrypting on a per-recipient basis). A message resulting from this approach will have a cryptographic state that few users will understand. Even if the sender understands the different statuses of the different copies, the recipients of the messages may not understand (each recipient might not even know about the other copies). See for example the discussion in Section 9.6 for how this can go wrong.¶

For comprehensibility, a MUA SHOULD NOT create multiple copies of a given message that differ in the types of end-to-end cryptographic protections afforded.¶

For opportunistic cryptographic protections that are not surfaced to the user (that is, that are not end-to-end), other mechanisms like transport encryption ([RFC3207]) or domain-based signing ([RFC6376]) may be preferable due to ease of implementation and deployment. These opportunistic transport protections are orthogonal to the end-to-end protections described in this document.¶

To the extent that opportunistic message protections are made visible to the user for a given copy of a message, a reasonable MUA will distinguish that status from the message's end-to-end cryptographic status. But the potential confusion caused by rendering this complex, hybrid state may not be worth the value of additional knowledge gained by the user. The benefits of opportunistic protections accrue (or don't) even without visibility to the user (see [RFC7435]).¶

The user needs a single clear, simple, and correct indication about the end-to-end cryptographic status of any given message. See Section 4.6 for more details.¶

4.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.¶

In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7) indicates "decrypts to", and "⇩" (DOWNWARDS WHITE ARROW, U+21E9) indicates "unwraps to".¶

└┬╴multipart/signed; protocol="application/pkcs7-signature"
 ├─╴[protected part]
 └─╴application/pkcs7-signature

└─╴application/pkcs7-mime; smime-type="signed-data"
 ⇩ (unwraps to)
 └─╴[protected part]

└─╴application/pkcs7-mime; smime-type="enveloped-data"
 ↧ (decrypts to)
 └─╴[protected part]

└─╴application/pkcs7-mime; smime-type="authEnveloped-data"
 ↧ (decrypts to)
 └─╴[protected part]

└┬╴multipart/signed; protocol="application/pgp-signature"
 ├─╴[protected part]
 └─╴application/pgp-signature

└┬╴multipart/encrypted
 ├─╴application/pgp-encrypted
 └─╴application/octet-stream
  ↧ (decrypts to)
  └─╴[protected part]

4.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. They are Errant Cryptographic Layers (see Section 4.5).¶

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. See Section 5.2.¶

4.3. Cryptographic Payload

The Cryptographic Payload of a message is the first non-Cryptographic Layer -- the "protected part" -- within the Cryptographic Envelope.¶

4.4. Types of Cryptographic Envelope

A └─╴application/pkcs7-mime; smime-type="enveloped-data"
B  ↧ (decrypts to)
C  └─╴application/pkcs7-mime; smime-type="signed-data"
D   ⇩ (unwraps to)
E   └─╴[protected part]

4.5. Errant Cryptographic Layers

Due to confusion, malice, or well-intentioned tampering, a message may contain a Cryptographic Layer that is not part of the Cryptographic Envelope. Such a layer is an Errant Cryptographic Layer.¶

An Errant Cryptographic Layer SHOULD NOT contribute to the message's overall cryptographic state.¶

Guidance for dealing with Errant Cryptographic Layers can be found in Section 6.2.¶

H └┬╴multipart/mixed
I  ├┬╴multipart/signed
J  │├─╴text/plain
K  │└─╴application/pgp-signature
L  └─╴text/plain

M └┬╴multipart/encrypted
N  ├─╴application/pgp-encrypted
O  └─╴application/octet-stream
P   ↧ (decrypts to)
Q   └┬╴multipart/signed
R    ├┬╴multipart/mixed
S    │├┬╴multipart/signed
T    ││├─╴text/plain
U    ││└─╴application/pgp-signature
V    │└─╴text/plain
W    └─╴application/pgp-signature

4.6. Cryptographic Summary

The cryptographic status of an e-mail message with end-to-end cryptographic protections is known as the Cryptographic Summary. A reasonable, simple Cryptographic Summary is derived from the aggregate properties of the layers in the Cryptographic Envelope. This is a conceptual tool and a feature that a MUA can use to guide behavior and user experience, but it is not necessarily always directly exposed in any given user interface. See Section 6.1 for guidance and considerations about rendering the Cryptographic Summary to the user.¶

5.1. Message Composition Algorithm

This section roughly describes the steps that a MUA should use to compose a cryptographically-protected message that has a proper cryptographic envelope and payload.¶

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.1.1).¶
• 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.¶
• 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:¶

• Apply crypto to origbody, yielding MIME tree output¶

• For each header name and value (h,v) in origheaders:¶

  • Add header h to output with value v¶
• Return output¶

5.2. Encryption Outside, Signature Inside

Users expect any message that is both signed and encrypted to be signed inside the encryption, and not the other way around. For example, when crafting an encrypted and signed message using a simple Cryptographic Envelope of a single layer (Section 4.4.1) with PGP/MIME, the OpenPGP Encrypted Message object should contain an OpenPGP Signed Message. Likewise, when using a multilayer Cryptographic Envelope (Section 4.4.2), the outer layer should be an encryption layer and the inner layer should be a signing layer.¶

Putting the signature inside the encryption has two advantages:¶

• The details of the signature remain confidential, visible only to the parties capable of decryption.¶
• Any mail transport agent that modifies the message is unlikely to be able to accidentally break the signature.¶

A MUA SHOULD NOT generate an encrypted and signed message where the only signature is outside the encryption.¶

5.3. Avoid Offering Encrypted-only Messages

When generating an e-mail, the user has options about what forms of end-to-end cryptographic protections to apply to it.¶

In some cases, offering any end-to-end cryptographic protection is harmful: it may confuse the recipient and offer no benefit.¶

In other cases, signing a message is useful (authenticity and integrity are desirable) but encryption is either impossible (for example, if the sender does not know how to encrypt to all recipients) or meaningless (for example, an e-mail message to a mailing list that is intended to be be published to a public archive).¶

In other cases, full end-to-end confidentiality, authenticity, and integrity are desirable.¶

It is unclear what the use case is for an e-mail message with end-to-end confidentiality but without authenticity or integrity.¶

A reasonable MUA will keep its message composition interface simple, so when presenting the user with a choice of cryptographic protection, it SHOULD offer no more than three choices:¶

• no end-to-end cryptographic protection¶
• Verified (signed only)¶
• Confidential (signed and encrypted)¶

Note that these choices correspond to the simplified mental model in Section 3.1.¶

5.4. Composing a Reply Message

When replying to a message, most MUAs compose an initial draft of the reply that contains quoted text from the original message. A responsible MUA will take precautions to avoid leaking the cleartext of an encrypted message in such a reply.¶

If the original message was end-to-end encrypted, the replying MUA MUST either:¶

• compose the reply with end-to-end encryption, or¶
• avoid including quoted text from the original message.¶

In general, MUAs SHOULD prefer the first option: to compose an encrypted reply. This is what users expect.¶

However, in some circumstances, the replying MUA cannot compose an encrypted reply. For example, the MUA might not have a valid, unexpired, encryption-capable certificate for all recipients. This can also happen during composition when a user adds a new recipient into the reply, or manually toggles the cryptographic protections to remove encryption.¶

In this circumstance, the composing MUA SHOULD strip the quoted text from the original message.¶

Note additional nuance about replies to malformed messages that contain encryption in Section 6.2.2.1.¶

6.1. Rendering Well-formed Messages

A message is well-formed when it has a Cryptographic Envelope, a Cryptographic Payload, and no Errant Cryptographic Layers. Rendering a well-formed message is straightforward.¶

The receiving MUA should evaluate and assemble the cryptographic properties of the Cryptographic Envelope into a Cryptographic Summary and display that status to the user in a secure, strictly-controlled part of the UI. In particular, the part of the UI used to render the Cryptographic Summary of the message MUST NOT be spoofable, modifiable, or otherwise controllable by the received message itself.¶

Aside from this Cryptographic Summary, the message itself should be rendered as though the Cryptographic Payload is the body of the message. The Cryptographic Layers themselves SHOULD not be rendered otherwise.¶

6.2. Errant Cryptographic Layers

If an incoming message has any Errant Cryptographic Layers, the interpreting MUA SHOULD ignore those layers when rendering the Cryptographic Summary of the message to the user.¶

A └┬╴multipart/mixed
B  ├╴text/plain
C  ├┬╴multipart/signed
D  │├─╴image/jpeg
E  │└─╴application/pgp-signature
F  └─╴text/plain

A └┬╴multipart/mixed
B  ├─╴text/plain
D  ├─╴image/jpeg
F  └─╴text/plain

H └┬╴multipart/mixed
I  ├┬╴multipart/signed
J  │├─╴[protected part, may be arbitrary MIME subtree]
K  │└─╴application/{pgp,pkcs7}-signature
L  └─╴[footer, typically text/plain]

H └┬╴multipart/mixed
I  ├─╴application/pkcs7-mime; smime-type="signed-data"
   │⇩ (unwraps to)
J  │└─╴[protected part, may be an arbitrary MIME subtree]
L  └─╴[footer, typically text/plain]

Cryptographic Protections: none
H └┬╴multipart/mixed
J  ├─╴[protected part, may be arbitrary MIME subtree]
L  └─╴[footer, typically text/plain]

Cryptographic Protections: signed [details from part I]
J └─╴[protected part, may be arbitrary MIME subtree]

6.3. Forwarded Messages with Cryptographic Protection

An incoming e-mail message may include an attached forwarded message, typically as a MIME subpart with Content-Type: message/rfc822 ([RFC5322]) or Content-Type: message/global ([RFC5355]).¶

Regardless of the cryptographic protections and structure of the incoming message, the internal forwarded message may have its own Cryptographic Envelope.¶

The Cryptographic Layers that are part of the Cryptographic Envelope of the forwarded message are not Errant Cryptographic Layers of the surrounding message -- they are simply layers that apply to the forwarded message itself.¶

The rendering MUA MUST NOT conflate the cryptographic protections of the forwarded message with the cryptographic protections of the incoming message.¶

The rendering MUA MAY render a Cryptographic Summary of the protections afforded to the forwarded message by its own Cryptographic Envelope, as long as that rendering is unambiguously tied to the forwarded message itself, and cannot be spoofed either by the enclosing message or by the forwarded message.¶

6.4. Signature failures

A cryptographic signature may fail in multiple ways. A receiving MUA that discovers a failed signature should treat the message as though the signature did not exist. This is similar to the standard guidance for about failed DKIM signatures (see Section 6.1 of [RFC6376]).¶

A MUA SHOULD NOT render a message with a failed signature as more dangerous or more dubious than a comparable message without any signature at all.¶

A MUA that encounters an encrypted-and-signed message where the signature is invalid SHOULD treat the message the same way that it would treat a message that is encryption-only.¶

Some different ways that a signature may be invalid on a given message:¶

• the signature is not cryptographically valid (the math fails).¶
• the signature relies on suspect cryptographic primitives (e.g. over a legacy digest algorithm, or was made by a weak key, e.g., 1024-bit RSA)¶
• the signature is made by a certificate which the receiving MUA does not have access to.¶
• the certificate used to verify the signature was revoked.¶
• the certificate used to verify the signature was expired at the time that the signature was made.¶
• the certificate used to verify the signature does not correspond to the author of the message. (for X.509, there is no subjectAltName of type RFC822Name whose value matches an e-mail address found in From: or Sender:)¶
• the certificate used to verify the signature was not issued by an authority that the MUA user is willing to rely on for certifying the sender's e-mail address, and the user has no other reasonable indication that the certificate belongs to the sender's e-mail address.¶
• the signature indicates that it was made at a time much before or much after from the date of the message itself.¶
• The signature covers a message that depends on an external subresource that might change (see Section 9.9).¶

A valid signature must pass all these tests, but of course invalid signatures may be invalid in more than one of the ways listed above.¶

7.1. Main Body Part

When an e-mail message is composed or rendered to the user there is typically one main view that presents a (mostly textual) part of the message.¶

While the message itself may be constructed of several distinct MIME parts in a tree, the part that is rendered to the user is the "Main Body Part".¶

When rendering a message, one of the primary jobs of the receiving MUA is identifying which part (or parts) is the Main Body Part. Typically, this is found by traversing the MIME tree of the message looking for a leaf node that has a primary content type of text (e.g. text/plain or text/html) and is not Content-Disposition: attachment.¶

MIME tree traversal follows the first child of every multipart node, with the exception of multipart/alternative. When traversing a multipart/alternative node, all children should be scanned, with preference given to the last child node with a MIME type that the MUA is capable of rendering directly.¶

A MUA MAY offer the user a mechanism to prefer a particular MIME type within multipart/alternative instead of the last renderable child. For example, a user may explicitly prefer a text/plain alternative part over text/html.¶

Note that due to uncertainty about the capabilities and configuration of the receiving MUA, the composing MUA SHOULD consider that multiple parts might be rendered as the Main Body Part when the message is ultimately viewed.¶

When composing a message, an originating MUA operating on behalf of an active user can identify which part (or parts) are the "main" parts: these are the parts the MUA generates from the user's editor. Tooling that automatically generates e-mail messages should also have a reasonable estimate of which part (or parts) are the "main" parts, as they can be programmatically identified by the message author.¶

For a filtering program that attempts to transform an outbound message without any special knowledge about which parts are Main Body Parts, it can identify the likely parts by following the same routine as a receiving MUA.¶

7.2. Attachments

A message may contain one or more separated MIME parts that are intended for download or extraction. Such a part is commonly called an "attachment", and is commonly identified by having Content-Disposition: attachment.¶

An MUA MAY identify a subpart as an attachment, or permit extraction of a subpart even when the subpart does not have Content-Disposition: attachment.¶

For a message with end-to-end cryptographic protection, any attachment MUST be included within the Cryptographic Payload. If an attachment is found outside the Cryptographic Payload, then the message is not well-formed (see Section 6.1).¶

Some MUAs have tried to compose messages where each attachment is placed in its own cryptographic envelope. Such a message is problematic for several reasons:¶

• The attachments can be stripped, replaced, or reordered without breaking any cryptographic integrity mechanism.¶
• The resulting message may have a mix of cryptographic statuses (e.g. if a signature on one part fails but another succeeds, or if one part is encrypted and another is not). This mix of statuses is difficult to represent to the user in a comprehensible way.¶

7.3. MIME Part Examples

Consider a common message with the folloiwing MIME structure:¶

M └─╴application/pkcs7-mime
   ↧ (decrypts to)
N  └─╴application/pkcs7-mime
    ⇩ (unwraps to)
O   └┬╴multipart/mixed
P    ├┬╴multipart/alternative
Q    │├─╴text/plain
R    │└─╴text/html
S    └─╴image/png

Parts M and N comprise the Cryptographic Envelope.¶

Parts Q and R are both Main Body Parts.¶

If part S is Content-Disposition: attachment, then it is an attachment. If part S has no Content-Disposition header, it is potentially ambiguous whether it is an attachment or not. If the sender prefers a specific behavior, it should explicitly set the Content-Disposition header on part S to either inline or attachment as guidance to the receiving MUA.¶

Consider also this alternate structure:¶

M └─╴application/pkcs7-mime
   ↧ (decrypts to)
N  └─╴application/pkcs7-mime
    ⇩ (unwraps to)
O   └┬╴multipart/alternative
P    ├─╴text/plain
Q    └┬╴multipart/related
R     ├─╴text/html
S     └─╴image/png

In this case, parts M and N are still the Cryptographic Envelope.¶

Parts P and R (the first two leaf nodes within each subtree of part O) are the Main Body Parts.¶

Part S is more likely not to be an attachment, as the subtree layout suggests that it is only relevant for the HTML version of the message. For example, it might be rendered as an image within the HTML alternative.¶

8.1. Peer Certificates

Most certificates that a cryptographically-capable MUA will use will be certificates belonging to the parties that the user communicates with through the MUA. This section discusses how to manage the certificates that belong to such a peer.¶

The MUA will need to be able to discover X.509 certificates for each peer, cache them, and select among them when composing an encrypted message.¶

Detailed guidance about how to do this is beyond the scope of this document, but future revisions may bring it into scope (see Appendix A.2).¶

8.2. Local Certificates

The MUA also needs to know about one or more certificates associated with the user's e-mail account. It is typically expected to have access to the secret key material associated with the public keys in those certificates.¶

While some basic guidance is offered here, it is beyond the scope of this document to describe all possible relevant guidance for local certificate and key material handling. See Appendix A.3 for suggestions of guidance that a future version might bring into scope.¶

9.1. Reading Sent Messages

When composing a message, a typical MUA will store a copy of the message sent in sender's Sent mail folder so that the sender can read it later. If the message is an encrypted message, storing it encrypted requires some forethought to ensure that the sender can read it in the future.¶

It is a common and simple practice to encrypt the message not only to the recipients of the message, but also to the sender. One advantage of doing this is that the message that is sent on the wire can be identical to the message stored in the sender's Sent mail folder. This allows the sender to review and re-read the message even though it was encrypted.¶

There are at least three other approaches that are possible to ensure future readability by the sender of the message, but with different tradeoffs:¶

• Encrypt two versions of the message: one to the recipients (this version is sent on the wire), and one to the sender only (this version is stored in the sender's Sent folder). This approach means that the message stored in the Sent folder is not byte-for-byte identical to the message sent to the recipients. In the event that message delivery has a transient failure, the MUA cannot simply re-submit the stored message into the SMTP system and expect it to be readable by the recipient.¶
• Store a cleartext version of the message in the Sent folder. This presents a risk of information leakage: anyone with access to the Sent folder can read the contents of the message. Furthermore, any attempt to re-send the message needs to also re-apply the cryptographic transformation before sending, or else the message contents will leak upon re-send.¶
• A final option is that the MUA can store a copy of the message's encryption session key. Standard e-mail encryption mechanisms (e.g. S/MIME and PGP/MIME) are hybrid mechanisms: the asymmetric encryption steps simply encrypt a symmetric "session key", which is used to encrypt the message itself. If the MUA stores the session key itself, it can use the session key to decrypt the Sent message without needing the Sent message to be decryptable by the user's own asymmetric key. An MUA doing this must take care to store (and backup) its stash of session keys, because if it loses them it will not be able to read the sent messages; and if someone else gains access to them, they can decrypt the sent messages. This has the additional consequence that any other MUA accessing the same Sent folder cannot decrypt the message unless it also has access to the stashed session key.¶

9.2. Reading Encrypted Messages after Certificate Expiration

When encrypting a message, the sending MUA should decline to encrypt to an expired certificate (see Section 8.1.1). But when decrypting a message, as long as the viewing MUA has access to the appropriate secret key material, it should permit decryption of the message, even if the associated certificate is expired. That is, the viewing MUA should not prevent the user from reading a message that they have already received.¶

The viewing MUA may warn the user when decrypting a message that appears to have been encrypted to an encryption-capable certificate that was expired at the time of encryption (e.g., based on the Date: header field of the message, or the timestamp in the cryptographic signature), but otherwise should not complain.¶

The primary goal of certificate expiration is to facilitate rotation of secret key material, so that secret key material does not need to be retained indefinitely. Certificate expiration permits the user to destroy an older secret key if access to the messages received under it is no longer necessary (see also Appendix A.9).¶

9.3. Unprotected Message Headers

Many legacy cryptographically-aware MUAs only apply cryptographic protections to the body of the message, but leave the headers unprotected. This gives rise to vulnerabilities like information leakage (e.g., the Subject line is visible to a passive intermediary) or message tampering (e.g., the Subject line is replaced, effectively changing the semantics of a signed message). These are not only security vulnerabilities, but usability problems, because the distinction between what is a header and what is the body of a message is unclear to many end users, and requires a more complex mental model than is necessary. Useful security comes from alignment between simple mental models and tooling.¶

To avoid these concerns, a MUA SHOULD implement header protection as described in [I-D.ietf-lamps-header-protection].¶

Note that some message header fields, like List-*, Archived-At, and Resent-* are typically added by an intervening MUA (see Section 9.8), not by one of the traditional "ends" of an end-to-end e-mail exchange. A receiving MUA may choose to consider the contents of these header fields on an end-to-end protected message as markers added during message transit, even if they are not covered by the end-to-end cryptographic protection.¶

9.4. Composing an Encrypted Message with Bcc

When composing an encrypted message containing at least one recipient address in the Bcc header field, there is a risk that the encrypted message itself could leak information about the actual recipients, even if the Bcc header field does not mention the recipient. For example, if the message clearly indicates which certificates it is encrypted to, the set of certificates can identify the recipients even if they are not named in the message headers.¶

Because of these complexities, there are several interacting factors that need to be taken into account when composing an encrypted message with Bcc'ed recipients.¶

• Section 3.6.3 of [RFC5322] describes a set of choices about whether (and how) to populate the Bcc field explicitly on Bcc'ed copies of the message, and in the copy stored in the sender's Sent folder.¶
• When separate copies are made for Bcced recipients, should each separate copy also be encrypted to the named recipients, or just to the designated Bcc recipient?¶
• When a copy is stored in the Sent folder, should that copy also be encrypted to Bcced recipients? (see also Section 9.1)¶
• When a message is encrypted, if there is a mechanism to include the certificates of the recipients, whose certificates should be included?¶

9.5. Draft Messages

When composing a message, most MUAs offer the opportunity to save a copy of the as-yet-unsent message to a "Drafts" folder. If that folder is itself stored somewhere not under the user's control (e.g. and IMAP mailbox), it would be a mistake to store the draft message in the clear, because its contents could leak.¶

This is the case even if the message is ultimately sent deliberately in the clear. During message composition, the MUA does not know whether the message is intended to be sent encrypted or not. For example, just before sending, the sender could decide to encrypt the message, and the MUA would have had no way of knowing.¶

Furthermore, when encrypting a draft message, the message SHOULD only be encrypted to the user's own certificate, or to some equivalent secret key that only the user possesses. A draft message encrypted in this way can be decrypted when the user wants to resume composing the message, but cannot be read by anyone else, including a potential intended recipient. Note that a draft message encrypted in this way will only be resumable by another MUA attached to the same mailbox if that other MUA has access to the user's decryption-capable secret key. This shared access to key material is also likely necessary for useful interoperability, but is beyond the scope of this document (see Appendix A.3.1).¶

The message should only be encrypted to its recipients upon actually sending the message. No reasonable user expects their message's intended recipients to be able to read a message that is not yet complete.¶

9.6. Composing a Message to Heterogeneous Recipients

When sending a message that the user intends to be encrypted, it's possible that some recipients will be unable to receive an encrypted copy. For example, when Carol composes a message to Alice and Bob, Carol's MUA may be able to find a valid encryption-capable certificate for Alice, but none for Bob.¶

In this situation, there are four possible strategies, each of which has a negative impact on the experience of using encrypted mail. Carol's MUA can:¶

1. send encrypted to Alice and Bob, knowing that Bob will be unable to read the message.¶
2. send encrypted to Alice only, dropping Bob from the message recipient list.¶
3. send the message in the clear to both Alice and Bob.¶
4. send an encrypted copy of the message to Alice, and a cleartext copy to Bob.¶

Each of these strategies has different drawbacks.¶

The problem with approach 1 is that Bob will receive unreadable mail.¶

The problem with approach 2 is that Carol's MUA will not send the message to Bob, despite Carol asking it to.¶

The problem with approach 3 is that Carol's MUA will not encrypt the message, despite Carol asking it to.¶

Approach 4 has two problems:¶

• Carol's MUA will release a cleartext copy of the message, despite Carol asking it to send the message encrypted.¶
• If Alice wants to "reply all" to the message, she may not be able to find an encryption-capable certificate for Bob either. This puts Alice in an awkward and confusing position, one that users are unlikely to understand. In particular, if Alice's MUA is following the guidance about replies to encrypted messages in Section 5.4, having received an encrypted copy will make Alice's Reply buffer behave in an unusual fashion.¶

This is particularly problematic when the second recipient is not "Bob" but in fact a public mailing list or other visible archive, where messages are simply never encrypted.¶

Carol is unlikely to understand the subtleties and negative downstream interactions involved with approaches 1 and 4, so presenting the user with those choices is not advised.¶

The most understandable approach for a MUA with an active user is to ask the user (when they hit "send") to choose between approach 2 and approach 3. If the user declines to choose between 2 and 3, the MUA can drop them back to their message composition window and let them make alternate adjustments.¶

See also further discussion of these scenarios in [I-D.dkg-mail-cleartext-copy].¶

9.7. Message Transport Protocol Proxy: A Dangerous Implementation Choice

An implementor of end-to-end cryptographic protections may be tempted by a simple software design that piggybacks off of a mail protocol like SMTP Submission ([RFC6409]), IMAP ([RFC3501]), or JMAP ([RFC8621]) to handle message assembly and interpretation. In such an architecture, a naive MUA speaks something like a "standard" protocol like SMTP, IMAP, or JMAP to a local proxy, and the proxy handles signing and encryption (outbound), and decryption and verification (inbound) internally on behalf of the user. While such a "pluggable" architecture has the advantage that it is likely to be easy to apply to any mail user agent, it is problematic for the goals of end-to-end communication, especially in an existing cleartext ecosystem like e-mail, where any given message might be unsigned or signed, cleartext or encrypted. In particular:¶

• the user cannot easily and safely identify what protections any particular message has (including messages currently being composed), and¶
• the proxy itself is unaware of subtle nuances about the message that the MUA actually knows.¶

With a trustworthy and well-synchronized sidechannel or protocol extension between the MUA and the proxy, it is possible to deploy such an implementation safely, but the requirement for the sidechannel or extension eliminates the universal-deployability advantage of the scheme.¶

Similar concerns apply to any implementation bound by an API which operates on message objects alone, without any additional contextual parameters.¶

This section attempts to document some of the inherent risks involved with such an architecture.¶

9.8. Intervening MUAs Do Not Handle End-to-End Cryptographic Protections

Some Mail User Agents (MUAs) will resend a message in identical form (or very similar form) to the way that they received it. For example, consider the following use cases:¶

• A mail expander or mailing list that receives a message and re-sends it to all subscribers.¶
• An individual user who "bounces" a message they received to a different e-mail address (see Section 3.6.6 of [RFC5322]).¶
• An automated e-mail intake system that forwards a report to the mailboxes of responsible staffers.¶

These MUAs intervene in message transport by receiving and then re-injecting messages into the mail transport system. In some cases, the original sender or final recipient of a message that has passed through such an MUA may be unaware of the intervention. (Note that an MUA that forwards a received message as a attachment (MIME subpart) of type message/rfc822 or message/global or "inline" in the body of a message is not acting as an intervening MUA in this sense, because the forwarded message is encapsulated within a visible outer message that is clearly from the MUA itself.)¶

An intervening MUA should be aware of end-to-end cryptographic protections that might already exist on messages that they re-send. In particular, it is unclear what the "end-to-end" properties are of a message that has been handled by an intervening MUA. For signed-only messages, if the intervening MUA makes any substantive modifications to the the message as it passes it along, it may break the signature from the original sender. In many cases, breaking the original signature is the appropriate result, since the original message has been modified, and the original sender has no control over the modifications made by the intervening MUA. For encrypted-and-signed messages, if the intervening MUA is capable of decrypting the message, it must be careful when re-transmitting the message. Will the new recipient be able to decrypt it? If not, will the message be useful to the recipient? If not, it may not make sense to re-send the message.¶

Beyond the act of re-sending, an intervening MUA should not itself try to apply end-to-end cryptographic protections on a message that it is resending unless directed otherwise by some future specification. Additional layers of cryptographic protection added in an ad-hoc way by an intervening MUA are more likely to confuse the recipient and will not be interpretable as end-to-end protections as they do not originate with the original sender of the message.¶

9.9. External Subresources in MIME Parts Break Cryptographic Protections

A MIME part with a content type that can refer to external resources (like text/html) may itself have some sort of end-to-end cryptographic protections. However, retrieving or rendering these external resources may violate the properties that users expect from cryptographic protection.¶

For example, an signed e-mail message with at text/html part that refers to an external image (i.e. via <img src="https://example.com/img.png">) may render differently if the hosting webserver decides to serve different content at the source URL for the image. This effectively breaks the goals of integrity and authenticity that the user should be able to rely on for signed messages, unless the external subresource has strict integrity guarantees (e.g. via [SRI]).¶

Likewise, fetching an external subresource for an encrypted-and-signed message effectively breaks goals of privacy and confidentiality for the user.¶

This is loosely analogous to security indicator problems that arose for web browsers as described in [mixed-content]. However, while fetching the external subresource over https is sufficient to avoid a "mixed content" warning from most browsers, it is insufficicent for a MUA that wants to offer its users true end-to-end guarantees for e-mail messages.¶

A sending MUA that applies signing-only cryptographic protection to a new e-mail message with an external subresource should take one of the following options:¶

• pre-fetch the external subresource and include it in the message itself,¶
• use a strong integrity mechanism like Subresource Integrity ([SRI]) to guarantee the content of the subresource, or¶
• prompt the composing user to remove the subresource from the message.¶

A sending MUA that applies encryption to a new e-mail message with an external resource cannot depend on subresource integrity to protect the privacy and confidentiality of the message, so it should either pre-fetch the external resource to include it in the message, or prompt the composing user to remove it before sending.¶

A receiving MUA that encounters a message with end-to-end cryptographic protections that contain a subresource should either refuse to retrieve and render the external subresource, or it should decline to treat the message as having cryptographic protections. For example, it could decline to indicate that the message is signed, or it could treat the message as not properly encrypted.¶

A.1. Test Vectors

A future version of this document (or a companion document) could contain examples of well-formed and malformed messages using cryptographic key material and certificates from [I-D.ietf-openpgp-crypto-refresh] and [RFC9216].¶

It may also include example renderings of these messages.¶

A.2. Further Guidance on Peer Certificates

A.3. Further Guidance on Local Certificates and Secret Keys

A.4. Certification Authorities

A future document could offer guidance on how an MUA should select and manage root certification authorities (CAs).¶

For example:¶

• Should the MUA cache intermediate CAs?¶
• Should the MUA share such a cache with other PKI clients (e.g., web browsers)?¶
• What distinctions are there between a CA for S/MIME and a CA for the web?¶

A.5. Indexing and Search of Encrypted Messages

A common use case for MUAs is search of existing messages by keyword or topic. This is done most efficiently for large mailboxes by assembling an index of message content, rather than by a linear scan of all message content.¶

When message contents and headers are encrypted, search by index is complicated. If the cleartext is not indexed, then messages cannot be found by search. On the other hand, if the cleartext is indexed, then the index effectively contains the sensitive contents of the message, and needs to be protected.¶

Detailed guidance on the tradeoff here, including choices about remote search vs local search, are beyond the scope of this document, but a future version of the document may bring them into scope.¶

A.6. Cached Signature Validation

Asymmetric signature validation can be computationally expensive, and the results can also potentially vary over time (e.g. if a signing certificate is discovered to be revoked). In some cases, the user may care about the signature validation that they saw when they first read or received the message, not only about the status of the signature verification at the current time.¶

So, for both performance reasons and historical perspective, it may be useful for an MUA to cache signature validation results in a way that they can be easily retrieved and compared. Documenting how and when to cache signature validation, as well as how to indicate it to the user, is beyond the scope of this document, but a future version of the document may bring these topics into scope.¶

A.7. Aggregate Cryptographic Status

This document limits itself to consideration of the cryptographic status of single messages as a baseline concept that can be clearly and simply communicated to the user. However, some users and some MUAs may find it useful to contemplate even higher-level views of cryptographic status which are not considered directly here.¶

For example, a future version of the document may also consider how to indicate a simple cryptographic status of message threads (groups of explicitly related messages), conversations (groups of messages with shared sets of participants), peers, or other perspectives that a MUA can provide.¶

A.8. Expectations of Cryptographic Protection

As mentioned in Section 2.3, the types of security indicators displayed to the user may well vary based on the expectations of the user for a given communication. At present, there is no widely shared method for the MUA to establish and maintain reasonable expectations about whether a specific received message should have cryptographic protections.¶

If such a standard is developed, a future version of this document should reference it and encourage the deployment of clearer and simpler security indicators.¶

A.9. Secure Deletion

One feature many users desire from a secure communications medium is the ability to reliably destroy a message such that it cannot be recovered even by a determined adversary. Doing this with standard e-mail mechanisms like S/MIME and PGP/MIME is challenging because of two interrelated factors:¶

• A copy of of an e-mail message may be retained by any of the mail transport agents that handle it during delivery, and¶
• The secret key used to decrypt an encrypted e-mail message is typically retained indefinitely.¶

This means that an adversary aiming to recover the cleartext contents of a deleted message can do so by getting access to a copy of the encrypted message and the long-term secret key material.¶

Some mitigation measures may be available to make it possible to delete some encrypted messages securely, but this document considers this use case out of scope. A future version of the document may elaborate on secure message deleton in more detail.¶

A.10. Interaction with Opportunistic Encryption

This document focuses on guidance for strong, user-comprehensible end-to-end cryptographic protections for e-mail. Other approaches are possible, including various forms of opportunistic and transport encryption, which are out of scope for this document.¶

A future version of this document could describe the interaction between this guidance and more opportunistic forms of encryption, for example some of the scenarios contemplated in [I-D.dkg-mail-cleartext-copy].¶

B.1. Substantive changes from draft-ietf-...-10 to draft-ietf-...-11

• Mention List-* and Archived-At message header fields¶
• Add additional references to papers that describe flaws in e2e e-mail¶

B.2. Substantive changes from draft-ietf-...-09 to draft-ietf-...-10

• Introduction: describe one major theme of Future Work¶

B.3. Substantive changes from draft-ietf-...-08 to draft-ietf-...-09

• Clarify goals of document¶
• Identify cross-protocol attacks in more detail to justify prescription against key reuse¶
• Add informative references to Opportunistic Encryption RFC and Certificate Best Practice draft¶
• Add "Reading Encrypted Messages after Certificate Expiration" section to Common Pitfalls and Guidelines¶
• Clean up nits identified by Stephen Farrell and Eliot Lear¶

B.4. Substantive changes from draft-ietf-...-07 to draft-ietf-...-08

• Add guidance about importing and exporting secret key material¶
• More explanation about "encryption outside, signature inside"¶
• Guidance about Intervening (resending) MUAs¶
• Include Sender and Resent-* as user-facing headers¶
• Guidance about external subresources for cryptographically protected messages¶
• Relax "user-facing" definition to be more advisory¶

B.5. Substantive changes from draft-ietf-...-06 to draft-ietf-...-07

• Add Bernie Hoeneisen and Alexey Melnikov as editors¶
• Explicitly avoid requiring anything from IANA¶
• Simplify description of "attachments"¶
• Add concrete detail on how to compare e-mail addresses¶
• Explicitly define "Cryptographic Summary"¶

B.6. Substantive changes from draft-ietf-...-05 to draft-ietf-...-06

• Expand proxy implementation warning to comparable APIs¶
• Move many marked TODO and FIXME items to "Future Work"¶
• More detailed guidance on local certificates¶
• Provide guidance on encrypting draft messages¶
• More detailed guidanc eon shipping certificates in outbound messages¶
• Recommend implementing header protection¶
• Added "Future Work" subsection about interactions with opportunistic approaches¶

B.7. Substantive changes from draft-ietf-...-04 to draft-ietf-...-05

• Adopt and update text about Bcc from draft-ietf-lamps-header-protection¶
• Add section about the dangers of an implementation based on a network protocol proxy¶

B.8. Substantive changes from draft-ietf-...-03 to draft-ietf-...-04

• Added reference to multipart/oracle attacks¶
• Clarified that "Structural Headers" are the same as RFC2045's "MIME Headers"¶

B.9. Substantive changes from draft-ietf-...-02 to draft-ietf-...-03

• Added section about mixed recipients¶
• Noted SMIMEA and OPENPGPKEY DNS RR cert discovery mechanisms¶
• Added more notes about simplified mental models¶
• More clarification on one-status-per-message¶
• Added guidance to defend against EFAIL¶

B.10. Substantive changes from draft-ietf-...-01 to draft-ietf-...-02

• Added definition of "user-facing" headers¶

B.11. Substantive changes from draft-ietf-...-00 to draft-ietf-...-01

• Added section about distinguishing Main Body Parts and Attachments¶
• Updated document considerations section, including reference to auto-built editor's copy¶

B.12. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00

• WG adopted draft¶
• moved Document History and Document Considerations sections to end of appendix, to avoid section renumbering when removed¶

B.13. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01

• consideration of success/failure indicators for usability¶
• clarify extendedKeyUsage and keyUsage algorithm-specific details¶
• initial section on certificate management¶
• added more TODO items¶