Guidance on End-to-End E-mail Security

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] and [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, and/or integrity.¶
• Cryptographic Layer, Cryptographic Envelope, Cryptographic Payload, 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.2.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.¶

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 e-mail communications are entirely end-to-end protected might instead want to know which messages do not have the expected protections.¶

Note also that some messages are 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.¶

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 Crytptographic 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

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.2.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 of 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.¶

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¶
• signing-only¶
• signed and encrypted¶

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 summarize the cryptographic properties of the Cryptographic Envelope, 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 cryptograpic 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.¶

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 R.SA)¶
• the signature is made by a certificate which the receiving MUA does not have access to.¶
• the certificate that made the signature was revoked.¶
• the certificate that made the signature was expired at the time that the signature was made.¶
• the certificate that made 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 that made 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.¶
• the signature indicates that it was made at a time much before or much after from the date of the message itself.¶

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

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

7.3. Certificate Authorities

TODO: how should the MUA select root certificate authorities?¶

TODO: should the MUA cache intermediate CAs?¶

TODO: should the MUA share such a cache with other PKI clients (e.g., web browsers)? Are there distinctions between a CA for S/MIME and for the web?¶

11.1. Document History