RFC 9787
Guidance on End-to-End Email Security
RFC 9787: Guidance on End-to-End Email Security 💌
okay bestie, this is the title block, and it's giving very official 🎀
- RFC number: 9787
- Title: Guidance on End-to-End Email Security
- Published by: the Internet Engineering Task Force (IETF) 🌸
- Authors (all editors): D. K. Gillmor, Ed. (ACLU), A. Melnikov, Ed. (Isode Ltd), and B. Hoeneisen, Ed. (pEp Project)
- Category: Informational ✨
- ISSN: 2070-1721
- Date: August 2025
- Obsoletes / Updates: the title block doesn't list any RFCs it obsoletes or updates 🦋
Abstract
ok so end-to-end encryption and signatures for email can be genuinely useful 🔐 but the standards are SO flexible that users can get trapped and things can fail in surprising ways 😭 this doc gives guidance for Mail User Agent (MUA) implementers (aka email client devs) so that end-to-end email is simple and secure for the actual human using it 💖 it gives a useful set of vocabulary and recommendations to dodge common failures, and it also calls out a bunch of usability and interoperability problems that are still unsolved 👑
Status of This Memo
this one is not an Internet Standards Track spec, it's published just for information 🧚
it IS a product of the IETF and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, see Section 2 of RFC 7841 for that tea ☕
for the current status, errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9787 🔗
Copyright Notice
Copyright (c) 2025 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. please actually read these, they spell out your rights and restrictions for this doc 📜 and any Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 💅
Table of Contents
1. Introduction
1.1. Terminology
1.1.1. Structural Header Fields
1.1.2. User-Facing Header Fields
2. Usability
2.1. Simplicity
2.2. Email Users Want a Familiar Experience
2.3. Warning About Failure vs. Announcing Success
3. Types of Protection
3.1. Simplified Mental Model
3.2. One Cryptographic Status per Message
4. Cryptographic MIME Message Structure
4.1. Cryptographic Layers
4.1.1. S/MIME Cryptographic Layers
4.1.2. PGP/MIME Cryptographic Layers
4.2. Cryptographic Envelope
4.3. Cryptographic Payload
4.4. Types of Cryptographic Envelope
4.4.1. Simple Cryptographic Envelopes
4.4.2. Multilayer Cryptographic Envelopes
4.5. Errant Cryptographic Layers
4.5.1. Mailing List Wrapping
4.5.2. A Baroque Example
4.6. Cryptographic Summary
5. Message Composition
5.1. Message Composition Algorithm
5.2. Encryption Outside, Signature Inside
5.3. Avoid Offering Encrypted-Only Messages
5.4. Composing a Reply Message
6. Message Interpretation
6.1. Rendering Well-Formed Messages
6.2. Errant Cryptographic Layers
6.2.1. Errant Signing Layer
6.2.2. Errant Encryption Layer
6.2.3. Avoiding Non-MIME Cryptographic Mechanisms
6.3. Forwarded Messages with Cryptographic Protection
6.4. Signature Failures
6.5. Weak Encryption
7. Reasoning about Message Parts
7.1. Main Body Part
7.2. Attachments
7.3. MIME Part Examples
8. Certificate Management
8.1. Peer Certificates
8.1.1. Peer Certificate Selection
8.2. Local Certificates
8.2.1. Getting Certificates for the User
8.2.2. Local Certificate Maintenance
8.2.3. Shipping Certificates in Outbound Messages
9. Common Pitfalls and Guidelines
9.1. Reading Sent Messages
9.2. Reading Encrypted Messages after Certificate Expiration
9.3. Unprotected Message Header Fields
9.4. Composing an Encrypted Message with Bcc
9.4.1. Simple Encryption with Bcc
9.5. Draft Messages
9.6. Composing a Message to Heterogeneous Recipients
9.7. Message Transport Protocol Proxy: A Dangerous
Implementation Choice
9.7.1. Dangers of a Submission Proxy for Message Composition
9.7.2. Dangers of an IMAP Proxy for Message Rendering
9.7.3. Who Controls the Proxy?
9.8. Intervening MUAs Do Not Handle End-to-End Cryptographic
Protections
9.9. External Subresources in MIME Parts Break Cryptographic
Protections
10. IANA Considerations
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Future Work
A.1. Webmail Threat Model
A.2. Test Vectors
A.3. Further Guidance on Peer Certificates
A.3.1. Certificate Discovery from Incoming Messages
A.3.2. Certificate Directories
A.3.3. Checking for Certificate Revocation
A.3.4. Further Peer Certificate Selection
A.3.5. Human-Readable Names in Peer Certificates, Header
Fields, and Address Books
A.4. Further Guidance on Local Certificates and Secret Keys
A.4.1. Cross-MUA Sharing of Local Certificates and Secret Keys
A.4.2. Use of Smart Cards or Other Portable Secret Key
Mechanisms
A.4.3. Active Local Certificate Maintenance
A.5. Certification Authorities
A.6. Indexing and Search of Encrypted Messages
A.7. Cached Signature Validation
A.8. Aggregate Cryptographic Status
A.9. Expectations of Cryptographic Protection
A.10. Secure Deletion
A.11. Interaction with Opportunistic Encryption
A.12. Split Attachments
A.13. Proxy Extensions
A.14. Mailing Lists
Acknowledgements
Authors' Addresses1. Introduction ✨
so end-to-end email security uses S/MIME [RFC8551] and PGP/MIME (Pretty Good Privacy with MIME) [RFC3156] 🔐 and together they can give you integrity, authentication, and confidentiality for MIME [RFC4289] email messages. main character energy 💅
BUT there are SO many ways an MUA handling one of these messages can misread it or accidentally break the security guarantees 😭 for example, [EFAIL] describes the "Direct Exfiltration" attack, where existing ciphertext gets spliced into a new message, and then lots of MUAs handle that optimistically (and wrongly) and leak cleartext 💀
so an MUA that interprets a message with end-to-end cryptographic protections needs to do it defensively 🛡️ it has to stay alert to all the different ways those protections can get bypassed, whether by mangling (malicious or accidental) or by a messy user experience.
an MUA that generates a message with end-to-end cryptographic protections should be aware of these defensive interpretation strategies, and should compose any new outbound message conservatively if it wants the protections to stay intact 🌸
this doc is guidance for the implementer of an MUA that provides these protections, whether it's composing, interpreting, rendering, or replying to a message. an implementation that follows it gives its users stronger, easier-to-understand security properties, and it also gets more reliable interoperability with messages from other implementations 🧚
in Appendix A, the doc also flags a bunch of interoperability and usability concerns for end-to-end email crypto that don't have a broadly accepted technical standard fix yet 👀 one big area NOT covered here is acquiring and long-term maintaining cryptographic identity info and metadata across multiple MUAs controlled by the same user. that's a whole other saga 🦋
1.1. Terminology
okay the vocab part, pay attention bestie 🎀
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. 📖
for the purposes of this doc, here's the lineup of concepts 💜
- Mail User Agent (MUA) is an email client 📱
- Protection of message data means cryptographic encryption and/or signatures, giving confidentiality, authenticity, and/or integrity 🔐
- Cryptographic Layer, Cryptographic Envelope, Cryptographic Payload, Cryptographic Summary, and Errant Cryptographic Layer are all defined in Section 4 ✨
- a well-formed email message with cryptographic protection has both a Cryptographic Envelope and a Cryptographic Payload 🎀
- Structural Header Fields are documented in Section 1.1.1 🧱
- Non-Structural Header Fields are header fields that are NOT Structural Header Fields 🌈
- User-Facing Header Fields are documented in Section 1.1.2 👑
- a Main Body Part is any part of a message that gets rendered to the user as the message itself (not "as an attachment"). see Section 7.1 🍓
this doc goes deep on end-to-end crypto in email, while admitting that lots of MUAs have zero capabilities for it at all 🙈 so we split MUAs into three distinct profiles:
- a non-cryptographic MUA has no capabilities for end-to-end cryptographic protections 🫥
- a conformant MUA follows the guidance in this doc when dealing with end-to-end cryptographic protections 💖
- a legacy MUA has capabilities for end-to-end cryptographic protections but does NOT adhere to the guidance here 😬
and at the time of writing, most MUAs with cryptographic protections are legacy MUAs. honestly iconic behavior from the industry 💀
1.1.1. Structural Header Fields
a message header field named MIME-Version, or whose name begins with Content-, is called a "structural" header field in this doc 🧩 it's a less-ambiguous name for what [RFC2045] calls "MIME header fields".
these header fields say something about the specific MIME part they're attached to, and they can't be transferred or copied to other parts without endangering the readability of the message 🫶
this includes:
MIME-VersionContent-TypeContent-Transfer-EncodingContent-Disposition
1.1.2. User-Facing Header Fields 📨✨
okay so out of ALL the header fields an email message can have, only a small subset actually gets shown to the user 👀. this doc calls them User-Facing Header Fields 💅. they're usually:
SubjectFromToCcDateReply-ToFollowup-ToSenderResent-FromResent-ToResent-CcResent-DateResent-Sender
the list above is the stuff people most often see when they open a message 🦋. an MUA is also allowed to decide that any other header field counts as "User-Facing" 🤷♀️. of course, loads of these are totally missing from any given message, and a field that isn't there just doesn't get shown at all 🙈.
ngl the resending fields (the ones starting with Resent-) are usually only slapped on by an in-between MUA (see Section 3.6.6 of [RFC5322] and Section 9.8 of this document) 🧚. so even when they do show up on screen, they usually won't have any end-to-end cryptographic protection (even if the original header fields are protected; see Section 9.3), because the original sender has no idea they exist 😭.
other fields can still change how a message looks. References and In-Reply-To can decide where a message lands in a threaded discussion, and the List-* and Archived-At fields that mailing lists add can make extra buttons pop up while rendering 🎀. but they aren't directly displayed to the user, so they don't count as "User-Facing" 💅.
2. Usability 🌷
any MUA that lets its user go from unprotected messages to messages with end-to-end cryptographic protection needs to think about how the user understands that switch 🤔. that said, the main goal of an MUA user is communication, so interface stuff that gets in the way of that should be avoided where possible 💬.
also, it's basically guaranteed the user will keep running into unprotected messages, and might even need to send them (like if a recipient can't handle cryptographic protections 😤). so the MUA needs to give the user some guidance so they get what protections any given message or conversation has. but don't overwhelm them with a million choices or give them info they can't actually do anything with 🫶.
2.1. Simplicity 💖
the end user (the operator of the MUA) is unlikely to understand complex end-to-end cryptographic protections on an email message, so keep it simple, bestie 😌.
for clarity, any cryptographic protections should apply to the message as a whole, not just to some subparts 💅.
this is true for composing: the standard compose interface of an MUA should offer minimal controls that indicate which types of protection to apply to the new message as a whole ✍️.
this is also true for reading: the standard rendering interface should offer a minimal, clear indicator about the end-to-end cryptographic status of the message as a whole 👀.
see Section 3 for more details 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. Email Users Want a Familiar Experience 🌸
a person communicating over the Internet today has SO many options to reach their people: web-based bulletin boards, contact forms, instant messaging services 📱.
email has a few distinctions from these other systems, most notably features like:
- Ubiquity: most correspondents will have an email address, while not everyone is on the various non-email messaging services, especially the ones with reliable end-to-end cryptographic protections.
- Federation: interaction between users on distinct domains who haven't agreed on a common communications provider is still possible.
- User Control: the user can interact with the email system using an MUA of their choosing, including automation and other control over their preferred and/or customized workflow.
other systems (like WhatsApp and Signal Private Messenger) come with 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 email is probably using email instead of other systems because of those distinctions 🤍. when you add end-to-end cryptographic protection to an email endpoint, be careful not to negate any of the distinct features of email as a whole. if those features get violated to provide end-to-end protection, the user may as well choose one of the other systems that don't have the drawbacks email has 😬. implementers should aim for end-to-end protections that keep the familiar experience of email itself 🎀.
also, an email user is likely to regularly interact with other email correspondents who cannot handle or produce end-to-end cryptographic protections. be careful when enabling cryptography in an MUA so it doesn't accidentally limit the user's ability to talk to people who use legacy or non-cryptographic MUAs 🙈.
2.3. Warning About Failure vs. Announcing Success ⚠️
moving the Web from http to https is a super useful historical parallel for adding end-to-end encryption to email 🔒.
specifically, the indicators of what's "secure" vs. "insecure" for web browsers have changed over time. years ago the default experience was http, and https sites got "secure" indicators like a lock icon 🔐. starting in 2018, some browsers flipped that: they downplayed https and instead visibly marked http as "not secure" (see [CHROME-INDICATORS]) 🙃.
by analogy, when the user of an MUA first turns on end-to-end cryptographic protection, they'll probably want to see which messages have protection (the security indicators a conformant MUA uses as of 2025 are most likely comparable to those of a pre-2018 web browser 🕰️). but a user whose private email 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 too (for example, by sender, by thread, or by date) 📅.
it's out of scope for this document to define expectations about protections for any given message, but an implementer who cares about offering a simple user experience should be deliberate and judicious about the expectations their interface assumes the user has in a given context 🧩. see Appendix A.9 for future work 🔭.
3. Types of Protection 🛡️
a given message might be:
- signed,
- encrypted,
- both signed and encrypted, or
- none of the above.
given that many email messages offer no cryptographic protections, the user needs to be able to detect which protections are present for any given message 🕵️♀️.
3.1. Simplified Mental Model 🧠
to the extent that an email message actually does have end-to-end cryptographic protections, those protections need to be visible and comprehensible to end users: both the composing user and the recipient who views the rendered message 👀. if either user is unaware of the protections, then they don't effectively extend all the way to the "end" 😤.
however, most users don't 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 recipient could be that a message is in one of three normal states, which line up with the only reasonable choices for message composition 📝:
- Unprotected
- Verified (has a valid signature from the apparent sender of the message)
- Confidential (encrypted with a valid signature from the apparent sender of the message)
however, one error state exists for rendered mail that doesn't correspond to a reasonable choice for message composition 🚨:
- Encrypted But Unverified (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 doesn't 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 🙆. but this isn't the state of the global email ecosystem when this document was written, since some legacy MUAs permit composing encrypted-but-unsigned mail (see Appendix A.9 for possible future guidance) 😮💨.
alternately, an MUA may prefer to represent the state of an 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, 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) unless the MUA is providing the user with debugging information 🐛.
at the time this document was written, the global email ecosystem has a heterogeneous mix of legacy and non-cryptographic MUAs 🍲. in such an ecosystem, a conformant MUA might prefer to represent "Verified" and "Encrypted" as orthogonal states of any given rendered message 🦋. while this model doesn't precisely match the choice a user makes when composing a message, it may line up better with the reality of the messages they actually encounter as a recipient 💜.
3.2. One Cryptographic Status per Message ✨
Okay so some MUAs will try to make multiple copies of the same email, with each copy getting different protection. Like, encrypting opportunistically on a per-recipient basis 💅. Bestie, this gets messy fast 💀. The message ends up with a cryptographic state that almost nobody will understand. Even if the composer gets the different statuses, the recipients might not. They might not even know the other copies exist 🙈. Check out Section 9.6 to see how this can go so wrong.
For comprehensibility, a conformant MUA SHOULD NOT create multiple copies of a given message that differ in the types of end-to-end cryptographic protections afforded. 🎀
Opportunistic protections that the user never sees (so, the ones that aren't end-to-end) might be better handled by other mechanisms, like transport encryption [RFC3207] or domain-based signing [RFC6376]. Those are easier to implement and deploy 🧚. These opportunistic transport protections are orthogonal to the end-to-end protections in this document, so they don't overlap.
To the extent that opportunistic message protections are shown to the user for a given copy of a message, a conformant MUA will keep that status separate from the message's end-to-end cryptographic status. But ngl, the confusion from rendering that complex, hybrid state might not be worth the extra knowledge the user gets 😭. The benefits of opportunistic protections happen (or don't) even when the user can't see them (see [RFC7435]) 🦋.
The user needs one clear, simple, and correct indication about the end-to-end cryptographic status of any given message. See Section 4.6 for more details. 👑
4. Cryptographic MIME Message Structure ✨
Implementations use the structure of an email message to establish (when composing) and understand (when rendering) the cryptographic status of the message. So this section sets up some conventions for how to think about message structure 🧠.
4.1. Cryptographic Layers
"Cryptographic Layer" refers to a MIME substructure that supplies some cryptographic protections to an internal MIME subtree. That internal subtree is known as the "protected part", though of course it may itself be a multipart object 🌸.
In the diagrams below, "╧" (BOX DRAWINGS UP SINGLE AND HORIZONTAL DOUBLE, U+2567) indicates "decrypts to" and "┴" (BOX DRAWINGS LIGHT UP AND HORIZONTAL, U+2534) indicates "unwraps to" 🎨.
4.1.1. S/MIME Cryptographic Layers
For S/MIME [RFC8551], there are four forms of Cryptographic Layers: multipart/signed, PKCS #7 signed-data, PKCS #7 enveloped-data, and PKCS #7 authEnveloped-data 💜.
4.1.1.1. S/MIME Multipart Signed Cryptographic Layer
└┬╴multipart/signed; protocol="application/pkcs7-signature"
├─╴[protected part]
└─╴application/pkcs7-signatureThis MIME layer offers authentication and integrity.
4.1.1.2. S/MIME PKCS #7 signed-data Cryptographic Layer
└┬╴application/pkcs7-mime; smime-type="signed-data"
┴ (unwraps to)
└─╴[protected part]This MIME layer offers authentication and integrity.
4.1.1.3. S/MIME PKCS #7 enveloped-data Cryptographic Layer
└┬╴application/pkcs7-mime; smime-type="enveloped-data"
╧ (decrypts to)
└─╴[protected part]This MIME layer offers confidentiality.
4.1.1.4. S/MIME PKCS #7 authEnveloped-data Cryptographic Layer
└┬╴application/pkcs7-mime; smime-type="authEnveloped-data"
╧ (decrypts to)
└─╴[protected part]This MIME layer offers confidentiality and integrity.
Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data (Section 4.1.1.4) have identical message structures and very similar confidentiality semantics. The only difference between the two is ciphertext malleability 👀.
The examples in this document only include enveloped-data, but the implications for that layer apply to authEnveloped-data as well ✨.
4.1.1.5. PKCS #7 Compression is NOT a Cryptographic Layer
The Cryptographic Message Syntax (CMS) provides a MIME compression layer (smime-type="compressed-data"), as defined in [RFC3274]. The compression layer is technically part of CMS, but it doesn't count as a Cryptographic Layer for the purposes of this document 🗜️.
4.1.2. PGP/MIME Cryptographic Layers
For PGP/MIME [RFC3156], there are two forms of Cryptographic Layers: signing and encryption 🔐.
4.1.2.1. PGP/MIME Signing Cryptographic Layer (multipart/signed)
└┬╴multipart/signed; protocol="application/pgp-signature"
├─╴[protected part]
└─╴application/pgp-signatureThis MIME layer offers authenticity and integrity.
4.1.2.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted)
└┬╴multipart/encrypted
├─╴application/pgp-encrypted
└┬╴application/octet-stream
╧ (decrypts to)
└─╴[protected part]This MIME layer can offer:
- confidentiality (via a Symmetrically Encrypted Data Packet, see Section 5.7 of [RFC9580]; an MUA MUST NOT generate this form due to ciphertext malleability),
- confidentiality and integrity (via a Symmetrically Encrypted and Integrity Protected Data Packet (SEIPD); see Section 5.13 of [RFC9580]), or
- confidentiality, integrity, and authenticity all together (by including an OpenPGP Signature Packet, see Section 5.2 of [RFC9580], within the SEIPD).
4.2. Cryptographic Envelope
The Cryptographic Envelope is the largest contiguous set of Cryptographic Layers of an email 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 means that if a Cryptographic Layer is the protected part of another Cryptographic Layer, the layers together make up a single Cryptographic Envelope 🔗.
Note that if a non-Cryptographic Layer gets in the way, all Cryptographic Layers within that non-Cryptographic Layer are not part of the Cryptographic Envelope. They're Errant Cryptographic Layers (see Section 4.5) 🚫.
Also note that the ordering of the Cryptographic Layers implies different cryptographic properties. A signed-then-encrypted message is different from 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
4.4.1. Simple Cryptographic Envelopes
As described above, if the "protected part" identified in the section above 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 4.1.2.2 by making sure that the [RFC9580] Encrypted Message within the application/octet-stream part contains a [RFC9580] Signed Message (the final option described in Section 4.1.2.2) ✨.
4.4.2. Multilayer Cryptographic Envelopes
It's possible to build a Cryptographic Envelope out of multiple layers with either S/MIME or PGP/MIME. For example, you could use this structure:
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]When handling a message like this, the properties of the Cryptographic Envelope are derived from the series A and C 🧩.
As noted in Section 4.4.1, PGP/MIME applications also have a simpler MIME construction available with the same cryptographic properties 🌈.
4.5. Errant Cryptographic Layers
Due to confusion, malice, message forwarding, or well-intentioned tampering, a message may contain a Cryptographic Layer that isn't part of the Cryptographic Envelope. That kind of layer is an Errant Cryptographic Layer 🕵️♀️.
An Errant Cryptographic Layer MUST NOT contribute to the message's overall cryptographic state. Period 🛑.
Guidance for dealing with Errant Cryptographic Layers can be found in Section 6.2 🗺️.
4.5.1. Mailing List Wrapping
Some mailing list software will rewrap a well-formed signed message before resending it to add a footer, so recipients end up seeing this structure 📬:
H └┬╴multipart/mixed
I ├┬╴multipart/signed
J │├─╴text/plain
K │└─╴application/pgp-signature
L └─╴text/plainIn this message, L is the footer added by the mailing list. I is now an Errant Cryptographic Layer 😬.
Note that this message has no Cryptographic Envelope at all 🫥.
It is NOT RECOMMENDED to produce email messages with this structure, because a legacy MUA may present the data in part L as though it were part of J, even though they have different cryptographic properties. In particular, if the user believes the entire message is signed but can't tell L apart from J, then the author of L can effectively tamper with the content of the signed message, and that breaks the user's expectation of integrity and authenticity 🚨.
See also Section 6.2.1.1 for guidance on how a rendering MUA might deal with this common pattern 💡.
4.5.2. A Baroque Example
Consider a message with this overcomplicated structure 🏰:
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-signatureThe three Cryptographic Layers in such a message are rooted in parts M, Q, and S. But the Cryptographic Envelope of the message consists only of the properties derived from the series M and Q. The Cryptographic Payload of the message is part R. Part S is an Errant Cryptographic Layer 🤯.
Note that this message has both a Cryptographic Envelope and an Errant Cryptographic Layer 🙃.
It is NOT RECOMMENDED to generate messages with such complicated structures. Even if a receiving MUA can parse this structure properly, it's nearly impossible to render in a way that lets the user reason about the cryptographic properties of part T compared to part V 🥴.
4.6. Cryptographic Summary
The cryptographic status of an email 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. It's a conceptual tool and a feature an MUA can use to guide behavior and user experience, but it isn't always directly shown in any given user interface. See Section 6.1 for guidance and considerations about rendering the Cryptographic Summary to the user 🎀.
5. Message Composition
This section describes the ideal composition of an email message with end-to-end cryptographic protection. A message composed this way is the most likely to achieve its end-to-end security goals 🏆.
5.1. Message Composition Algorithm 🧁
okay so this section is the recipe for how an MUA should put together a cryptographically protected message, so it ends up with a proper Cryptographic Envelope and Payload 💅
The inputs to the algorithm are:
- origbody: the unprotected message body, as a well-formed MIME tree (possibly just a single MIME leaf part). Because it's well-formed, origbody already has Structural Header Fields present (see Section 1.1.1) 🎀
- origheaders: the intended Non-Structural Header Fields for the message, written as a list of (h,v) pairs, where h is a header field name and v is its 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". It's a routine that takes a MIME tree as input (the Cryptographic Payload), wraps it in the right Cryptographic Envelope, and hands back the resulting MIME tree 🔐
The algorithm returns a MIME object that's ready to be injected into the mail system ✨
- Apply crypto to MIME part origbody, producing MIME tree output.
- For each header field name and value (h,v) in origheaders: a. Add header field h to output with value v.
- Return output.
This is the classic algorithm 👑 It only protects the Structural Header Fields of the message body and leaves the Non-Structural (including User-Facing) Header Fields unprotected 😭
So, a conformant MUA MUST implement Header Protection as described in [RFC9788] (see Section 9.3). no skipping this one bestie 🫶
5.2. Encryption Outside, Signature Inside 🦋
An email message that's both signed and encrypted is signed inside the encryption, and not the other way around. For example, when you craft a signed-and-encrypted 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 you use 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 big advantages:
- The details of the signature stay confidential, visible only to the parties who are able to decrypt it 🤫
- Any mail transport agent that modifies the message is unlikely to accidentally break the signature 💖
A conformant MUA MUST NOT generate an encrypted and signed message where the only signature is outside the encryption. no exceptions, periodt 💀
5.3. Avoid Offering Encrypted-Only Messages 🙈
When you're generating an email, there are four options for applying end-to-end cryptographic protections:
- Unprotected: in some cases, offering any end-to-end cryptographic protection is harmful. It may confuse the recipient and offer no benefit 🍓
- Signed-only: in other cases, signing a message is useful (authenticity and integrity are desirable), but encryption is either impossible (for example, if the composer doesn't know how to encrypt to all recipients) or meaningless (for example, an email to a mailing list that's meant to be published to a public archive) 📚
- Signed-and-encrypted: in other cases, full end-to-end confidentiality, authenticity, and integrity are desirable 👑
- Encrypted-only: there is no common use case for generating an email message with end-to-end confidentiality but without authenticity or integrity 🫠
- Additionally, some encryption schemes are malleable. This allows an attacker to tamper with the plaintext by modifying the ciphertext (i.e., without decrypting it). One way to prevent this is to authenticate the ciphertext, e.g., using signatures, Message Authentication Codes (MACs), or Authenticated Encryption with Associated Data (AEAD) schemes. See the Cipher Block Chaining (CBC) / Cipher FeedBack (CFB) gadget attack in [EFAIL]. 😱
A conformant MUA should keep its message composition interface simple. When it presents the user with a choice of cryptographic protection, it MUST 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 🧠
A common anti-pattern among legacy MUAs is offering two boolean choices: one to toggle signing and another to toggle encryption. This creates usability hurdles:
- A user who wants to compose a signed-and-encrypted message has to click two buttons instead of one 😩
- A user who clicks "Encrypt" but forgets to click "Signed" may not realise they're creating a message that the recipient can't authenticate 🥺
5.4. Composing a Reply Message 💌
When you reply to a message, most MUAs make an initial draft that contains quoted text from the original. A responsible MUA takes precautions to avoid leaking the cleartext of an encrypted message in that 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: composing an encrypted reply. This is what users expect 💜
However, sometimes the replying MUA can't compose an encrypted reply. For example, the MUA might not have a valid, unexpired, and 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 situation, the composing MUA SHOULD strip the quoted text from the original message, unless the user indicates that they're deliberately including previously confidential content in a non-confidential message 🛑
Note the additional nuance about replies to malformed messages that contain encryption in Section 6.2.2.1 👀
6. Message Interpretation ✨
Despite the best efforts of well-intentioned composers to create email messages with well-formed, end-to-end cryptographic protection, rendering MUAs will inevitably run into some messages with malformed end-to-end cryptographic protection 😅
This section offers guidance on dealing with both well-formed and malformed messages that contain Cryptographic Layers 🧚
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 rendering MUA evaluates and assembles the cryptographic properties of the Cryptographic Envelope into a Cryptographic Summary, then displays that status to the user in a secure and 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 rendered message itself. Think of the "lock" icon in the address bar of a web browser: no matter what the webpage says, the lock icon only shows up when the transport to the web server is adequately secured 🔐
Aside from this Cryptographic Summary, the message itself MUST be rendered as though the Cryptographic Payload is the body of the message. The Cryptographic Layers themselves SHOULD NOT be rendered as distinct objects, unless the MUA is giving the user debugging information 🛠️
6.2. Errant Cryptographic Layers 🦋
If an incoming message has any Errant Cryptographic Layers, a conformant interpreting MUA MUST ignore those layers when rendering the Cryptographic Summary of the message to the user 🙅♀️
6.2.1. Errant Signing Layer 🌸
When rendering a message with an Errant Cryptographic Layer that provides authenticity and integrity (via signatures), the message should be rendered by replacing the Cryptographic Layer with the part it encloses 🎀
For example, a message with this structure:
A └┬╴multipart/mixed
B ├╴text/plain
C ├┬╴multipart/signed
D │├─╴image/jpeg
E │└─╴application/pgp-signature
F └─╴text/plainshould be rendered identically to this:
A └┬╴multipart/mixed
B ├─╴text/plain
D ├─╴image/jpeg
F └─╴text/plainIn a situation like this, a conformant MUA MUST NOT indicate in the Cryptographic Summary that the message is signed. It MUST indicate that the message is Unprotected 🚫
6.2.1.1. Exception: Mailing List Footers 📮
The use case described in Section 4.5.1 is common enough in some contexts that a conformant MUA MAY decide to handle it as a special exception ✨
If the MUA determines that the message comes from a mailing list (for example, it has a List-ID header field), and it has a structure that appends a footer to a signing-only Cryptographic Layer with a valid signature, such as:
H └┬╴multipart/mixed
I ├┬╴multipart/signed
J │├─╴[protected part, may be arbitrary MIME subtree]
K │└─╴application/{pgp,pkcs7}-signature
L └─╴[footer, typically text/plain]or:
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]then the MUA MAY indicate to the user that this is a Verified message that has been wrapped by the mailing list 📬
In this case, the MUA MUST distinguish the footer (part L) from the protected part (part J) when rendering any information about the signature. One way to do this is to give the user two different views of the message 👀
The first is the "mailing list" view, which hides any positive Cryptographic Summary but shows the footer:
Cryptographic Protections: Unprotected
H └┬╴multipart/mixed
J ├─╴[protected part, may be arbitrary MIME subtree]
L └─╴[footer, typically text/plain]The second is the "sender's view", which shows the Cryptographic Summary as Verified but hides the footer:
Cryptographic Protections: Verified [details from part I]
J └─╴[protected part, may be arbitrary MIME subtree]6.2.2. Errant Encryption Layer 🔓
An MUA may run into a message with an Errant Cryptographic Layer that offers confidentiality (encryption), and the MUA is capable of decrypting it 🕵️♀️
The user wants to be able to see the contents of any message they have access to, so a conformant MUA in this situation SHOULD decrypt the part 🥰
However, in this case, a conformant MUA MUST NOT indicate in the message's Cryptographic Summary that the message itself was encrypted. Such an indication could be taken to mean that other (non-encrypted) parts of the message arrived with cryptographic confidentiality 🙃
Furthermore, when decrypting an Errant Cryptographic Layer, the MUA MUST treat the decrypted cleartext as a distinct MIME subtree, and it MUST NOT attempt to merge or splice it together with any other part of the message. This protects against the direct exfiltration (also known as EFAIL-DE) attacks described in [EFAIL], and so-called multipart/oracle attacks described in [ORACLE]. this is serious security stuff, so please don't skip it 🚨🔥
6.2.2.1. Replying to a Message with an Errant Encryption Layer ✨
okay bestie, there's an asymmetry between rendering and replying to a message with an Errant Encryption Layer 👀 it's giving plot twist.
When your MUA is rendering, it does not flag that the message was encrypted, even if some subpart got decrypted for display 🙈
When you're composing a reply to a message that has any encryption layer (even an errant one), the reply SHOULD be marked for encryption, unless there's no quoted and attributed text in the reply, as noted in Section 5.4. 💜
Now the important part 🚨 when a conformant MUA is replying to a message with an Errant Cryptographic Layer, it MUST NOT quote or attribute text that came from decrypting that layer. Usually that means either leaving the ciphertext itself in the reply or just not generating any quoted or attributed text at all. This protects you from the reply-based attacks described in [REPLY]. 🛡️
In all circumstances, if the reply can't be encrypted (or the user picks not to encrypt it), the composed reply MUST NOT include any material from the decrypted subpart. no exceptions, no vibes-based exceptions 💅
6.2.3. Avoiding Non-MIME Cryptographic Mechanisms
sometimes a cryptographic signature or encryption doesn't line up with a MIME boundary 🌸 so-called "PGP Inline" messages usually stuff base64-encoded ("ASCII-armored", see Section 6 of [RFC9580]) ciphertext right inside the content of a MIME part. chaotic but iconic 😭
6.2.3.1. Do Not Validate Non-MIME Signatures
when a MUA runs into signatures in these spots, a conformant MUA MUST NOT attempt to validate any signature. it's really hard to tell the user exactly which part of the message the signature covers, so it's better to leave the message marked as Unprotected 🔒 see [SPOOFING] for examples of spoofed message signatures that rely on permissive legacy clients willing to validate signatures in poorly structured messages. not them 🙅♀️
6.2.3.2. Skip or Isolate Non-MIME Decryption When Rendering
when you encounter what looks like encrypted data that's not at a MIME boundary, a conformant MUA MAY fully decline to decrypt the data 🦋
during message rendering, if a conformant MUA does attempt decryption of a non-MIME encrypted section of an email, it MUST synthesize a separate MIME part that contains only the decrypted data, and it MUST NOT try to merge or splice that part together with any other part of the message. keeping that section distinct and isolated from everything else protects you from the direct exfiltration attacks (also known as EFAIL-DE) described in [EFAIL]. stay separated, stay safe 🧚
6.2.3.3. Do Not Decrypt Non-MIME Decryption When Replying
when you're composing a reply to a message with such a non-MIME encrypted section, a conformant MUA MUST NOT decrypt any non-MIME encrypted section when generating quoted or attributed text. this is similar to the guidance in Section 6.2.2.1 🍓
this offers protection against the reply-based attacks described in [REPLY]. same energy, different layer 💅
6.3. Forwarded Messages with Cryptographic Protection
an incoming email might include an attached forwarded message, usually as a MIME subpart with Content-Type: message/rfc822 [RFC5322] or Content-Type: message/global [RFC6532] 📨
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 forwarded message's Cryptographic Envelope are Errant Cryptographic Layers with respect to the surrounding message. they're layers that only apply to the forwarded message itself, not the whole thing 🎀
a conformant rendering MUA MUST NOT conflate the cryptographic protections of the forwarded message with the cryptographic protections of the incoming message. they are NOT the same person's outfit, bestie 👗
a conformant rendering MUA MAY render a Cryptographic Summary of the protections the forwarded message gets from its own Cryptographic Envelope, as long as that rendering is unambiguously tied to the forwarded message itself and can't be spoofed by either the enclosing message or the forwarded message 🕵️♀️
6.4. Signature Failures
a cryptographic signature can fail in multiple ways 💀 when a conformant rendering MUA discovers a failed signature, it treats the message as though the signature did not exist. this is similar to the standard guidance for failed DomainKeys Identified Mail (DKIM) signatures (see Section 6.1 of [RFC6376]) 🌈
a conformant MUA MUST NOT render a message with a failed signature as more dangerous or more dubious than a comparable message without any signature at all. in both cases, the Cryptographic Summary should be Unprotected 🫶
a conformant MUA that encounters a signed-and-encrypted message where the signature is invalid SHOULD treat the message the same way it would treat an encryption-only message, unless the MUA is giving the user debugging information 🔧
these are some different ways a signature can 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 deprecated digest algorithm, or was made by a weak key, e.g., 1024-bit RSA). note that this requires the rendering MUA to have an explicit policy about which cryptographic primitives are acceptable. 🙃
- The signature is made by a certificate that the rendering 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 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 email address found in the
FromorSenderheader field.) 👀 - The certificate used to verify the signature was not issued by an authority the MUA user is willing to rely on for certifying the sender's email address, and the user has no other reasonable indication that the certificate belongs to the sender's email address. 🤨
- The signature indicates that it was made at a time much before or much after 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 of these tests, but of course, invalid signatures may be invalid in more than one of the ways listed above 💅
6.5. Weak Encryption
sometimes an MUA might get a message with a well-formed Cryptographic Envelope that uses a form of encryption with substantial known flaws 🥀 for example, a PGP/MIME message might use a Symmetrically Encrypted Data Packet, which is known to have malleable ciphertext (see Section 5.7 of [RFC9580]). another example: an S/MIME message may use an enveloped-data MIME part with a contentEncryptionAlgorithm of rc2-cbc with an rc2ParameterVersion of 160, which means a 40-bit key (see Section 5.2 of [RFC3370]). that's widely considered breakable via brute force with moderate hardware investment in 2024 😬 as cryptanalysis and hardware capacity advance, an implementation may widen the scope of which encryption mechanisms are considered weak 🔭
a rendering MUA MUST warn the user that such a message has a known weakness ⚠️ the rendering MUA MAY fully decline to decrypt such a message. if it decides to decrypt a message with a weak encryption layer, it MUST NOT indicate in the message's Cryptographic Summary that the message was encrypted, because the confidentiality of the message is suspect 🙈 this is similar to the approach taken in Section 6.2.2 for messages with an Errant Encryption Layer.
like the Errant Encryption Layer situation, there's an asymmetry between rendering and replying to a message with weak encryption 🔄 the guidance in Section 6.2.2.1 should be followed when replying to a message with weak encryption as well.
a rendering MUA MAY also treat historically archived messages with weak encryption differently than modern ones 📚 for example, if an encryption algorithm was known to be weak in 2005, then a message that appears to have been encrypted with that algorithm in 1995 might be decrypted with a warning, like an archival service would. but a message that appears to have been encrypted with that same weak algorithm in 2015 might get quarantined as a likely attack 🚨
there are several possible ways to tell a historical message from a modern one, including:
- the message timestamp (e.g., the
Dateheader field) 🗓️ - the time the message was first observed on the network (e.g., delivery of a new message via IMAP from a mailbox that had recently checked) 📬
- the timestamp in any signature observed in the message ✍️
- the message structure (a message composed using protocol elements that were invented after the encryption algorithm was known as weak is more likely to be an attack than a legitimate archival message) 🧩
7. Reasoning about Message Parts ✨
when generating or rendering messages, it's useful to know which parts of the message are likely to be displayed and how 👀 this section introduces some common terms that can be applied to parts within the Cryptographic Payload. let's get into it 💜
7.1. Main Body Part ✨
okay so whenever a message gets composed or shown to someone, there's usually ONE main view with the (mostly textual) bit of the message 💖
even if the message is built from a whole tree of MIME parts, the part that actually gets rendered to the user is the "Main Body Part" 🌸
when a rendering MUA opens a message, one of its biggest jobs is figuring out which part (or parts) is the Main Body Part 🔍 usually it walks the MIME tree looking for a leaf node that's text (like text/plain or text/html) as its primary content type and that is NOT Content-Disposition: attachment 💅
MIME tree traversal follows the first child of every multipart node, EXCEPT for multipart/alternative 🙈 when traversing a multipart/alternative node, all children should be scanned, with preference going to the last child node whose MIME type the MUA can render directly. it's giving "pick the best option" energy 🧚
An MUA MAY let the user select a preferred MIME type for rendering within multipart/alternative instead of the last renderable child 🎀 like, a user might explicitly prefer a text/plain alternative over text/html, and that's valid 🫶 but here's the tea: because nobody can be 100% sure what the rendering MUA can do or how it's configured, a conformant composing MUA should consider that multiple parts might get rendered as the Main Body Part when the message is finally viewed 👀 so the composing MUA should make sure that any part likely to be viewed as the Main Body Part has the same semantic content as every other such part. same vibes everywhere, no surprises 💜
when composing a message, an originating MUA working on behalf of an active user can figure out which part (or parts) are the "main" parts 🍓 these are the parts the MUA generates from the user's editor ✍️ tooling that automatically generates email messages should also have a reasonable estimate of which part (or parts) are the "main" parts, since the message author can identify them programmatically 🤖
and for a filtering program that tries to transform an outbound message WITHOUT any special knowledge about which parts are the Main Body Parts? no stress 😌 it can find the likely parts by following the same routine a rendering MUA would 🌈
7.2. Attachments 📎
a message may contain one or more separate MIME parts that are meant for download or extraction 📥 these are commonly called "attachments", and they're usually marked with Content-Disposition: attachment 🎀
an MUA MAY identify a subpart as an attachment, or permit extraction of a subpart, even when that subpart does NOT have Content-Disposition: attachment 🦋
now the big rule 🚨 when generating a message with end-to-end cryptographic protection, any attachment MUST be included within the Cryptographic Payload. if an attachment ends up OUTSIDE the Cryptographic Payload, the message is not well-formed (see Section 6.1) and other MUAs won't handle it as intended 💀 not okay!!
some MUAs have tried composing messages where each attachment gets its own Cryptographic Envelope 🙃 and honestly? that's problematic for a few reasons 😭
- the attachments can be stripped, replaced, or reordered without breaking any cryptographic integrity mechanism. yikes 🫠
- the resulting message may have a mix of cryptographic statuses (for example, a signature on one part fails but another succeeds, or one part is encrypted and another isn't). that mix is really hard to show the user in a way that makes sense 🌀
- the divisions between the different attachments are visible to operators of any mail transport agent (MTA) that handles the message, which could leak metadata 🕵️♀️ for example, the MTA operator might learn how many attachments there are and how big each one is.
these messages are unlikely to be usefully interoperable without some extra standardization work (see Appendix A.12) 📚
7.3. MIME Part Examples 🧩
let's look at a super common message 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/pngokay so parts M and N make up the Cryptographic Envelope 🔐
parts Q and R are BOTH Main Body Parts 💖
if part S is Content-Disposition: attachment, then it's an attachment 📎 but if part S has NO Content-Disposition header field, it's potentially ambiguous whether it's an attachment or not 🤔 so if the composer has a preference, they should explicitly set the Content-Disposition header field on part S to either inline or attachment, as guidance for the rendering MUA 🎀
now here's an 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/pngin this case, parts M and N STILL make up 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, since the subtree layout suggests it's only relevant for the HTML version of the message 🌈 for example, it might get rendered as an image inside the HTML alternative 🖼️ it's giving "I belong to the HTML crowd" 💅
8. Certificate Management 🔑
a cryptographically capable MUA typically keeps track of certificates for the user's own account(s), AND certificates for the peers it talks to 💜
8.1. Peer Certificates 👯
most of the certificates a cryptographically capable MUA will use belong to the people the user communicates with through the MUA 💌 this section talks about how to manage those peer certificates 🫶
the MUA needs to be able to discover X.509 certificates for each peer, cache them, and select among them when composing an encrypted message 🔍 detailed guidance on how to do all that is beyond the scope of this document, but future revisions might bring it into scope (see Appendix A.3) ✨
8.1.1. Peer Certificate Selection 🎯
when composing an encrypted message, the MUA needs to select an encryption-capable certificate for each recipient 🔐
to select a certificate for a given destination email address, the MUA should look through ALL of its known certificates and verify that _all_ of the conditions below are met 👑
- the certificate must be valid, not expired or revoked. no expired drama allowed 💀
- it must have a subjectAltName of type
rfc822Name(for all ASCII email addresses) orSmtpUTF8Mailbox(for Internationalized Email Addresses) whose contents match the destination email address 🌍 specifically, forrfc822Name, the local-part of the two addresses should be an exact bytewise match, and the domain parts should be matched by ensuring label equivalence across the full domain name, as described in Section 2.3.2.4 of [RFC5890] 🧠 comparison withSmtpUTF8Mailboxis specified in Section 5 of [RFC9598] 📖 - the algorithm OID in the certificate's SubjectPublicKeyInfo (SPKI) is known to the MUA and capable of encryption 🔓 examples include:
rsaEncryption(OID1.2.840.113549.1.1.1), with thekeyUsage(OID2.5.29.15) extension present and the "key encipherment" bit (value32) set 💖curveX25519(OID1.3.101.110), with thekeyUsageextension present and the "key agreement" bit (value8) set ✨
- if
extendedKeyUsage(OID2.5.29.37) is present, it contains at least one of the following OIDs: email protection (OID1.3.6.1.5.5.7.3.4), or anyExtendedKeyUsage (OID2.5.29.37.0) 🦋
a conformant MUA may include MORE considerations when selecting a peer certificate too 🌟 see Appendix A.3.4 for examples 📚
8.2. Local Certificates 🏠
the MUA also needs to know about one or more certificates associated with the user's email account 💅 it's typically expected to have access to the secret key material linked to the public keys in those certificates 🔑
some basic guidance is offered here, but it's beyond the scope of this document to describe ALL the possible guidance for local certificate and key material handling 🙈 see Appendix A.4 for suggestions a future version might bring into scope 🌸
8.2.1. Getting Certificates for the User 🪪
if a conformant MUA doesn't have a certificate or secret key for the user, it should help the user generate, acquire, or import them with minimum difficulty 🫶 no one should be stuck at step one!! 🥹
8.2.1.1. User Certificates for S/MIME 🔐
for S/MIME, the user SHOULD have BOTH a signing-capable certificate AND an encryption-capable certificate (plus the corresponding secret keys) 💖 using the same cryptographic key material for multiple algorithms (like both encryption and signing) has caused vulnerabilities in other, non-email contexts (see [DROWN] and [IKE]) 😱 the simplest way to avoid that comparable risk is to use distinct key material for each cryptographic algorithm 🧁 so a conformant MUA that generates S/MIME certificates for the user MUST generate DISTINCT S/MIME certificates to avoid possible cross-protocol key misuse: one for encryption and another for signing 🚫 no mixing!!
the simplest option for an S/MIME-capable MUA is letting the user import a PKCS #12 [RFC7292] object that is expected to contain secret key material, end entity certificates for the user, and intermediate certification authority (CA) certificates that allow chaining from the end entity certificates to widely accepted trust anchors 📦 a conformant MUA that imports such a PKCS #12 bundle SHOULD warn the user if the bundle contains an S/MIME certificate and corresponding secret key where the SAME secret key is used for both encryption and signing ⚠️ that's a big red flag, bestie 🚩
an S/MIME-capable MUA that has access to user certificates and their corresponding secret key material should also offer the ability to export those objects into a well-formed PKCS #12 object that could be imported into another MUA operated by the same user 🧳 main character portability 🌈
BUT manual handling of PKCS #12 objects is genuinely hard for most users 😩 producing the initial PKCS #12 object typically can only be done with the aid of a CA, through non-standardized, labor-intensive, and error-prone procedures that most users don't understand 💀 and manual export and import keeps creating ongoing labor for the user (for example, before certificate expiration), which most users aren't prepared to do (see Section 8.2.2) 🙃
a better approach is for the MUA to integrate some form of automated certificate issuance procedure, for example by using the Automatic Certificate Management Environment (ACME) protocol for end user S/MIME certificates [RFC8823] 🤖✨ iconic behavior, honestly 👑
another possible approach is integration with a cryptographic hardware token or smart card that can provide certificates and permit the use of isolated secret key material, for example, see [PKCS11] 🔒 though this approach delegates the complexity of acquiring and managing certificates to the management of the hardware token itself (see Appendix A.4.2) 🪙
and see also [CERT-BEST-PRACTICE] for more recommendations about managing user certificates 📚💜
8.2.1.2. User Certificates for PGP/MIME
Okay so OpenPGP [RFC9580] has its own set of common practices, and it's giving different from S/MIME 💅. One big glow-up is that a single OpenPGP certificate can hold a signing-capable key and a separate encryption-capable key 🔑. That means an email user only needs one certificate, as long as it has distinct key material for each purpose ✨.
Furthermore, a single OpenPGP certificate MAY only be self-signed, so the MUA can make one totally on its own 🫶.
An OpenPGP-capable MUA should be able to import and export OpenPGP Transferable Secret Keys (see Section 10.2 of [RFC9580]). That way the user can move their certificates and secret key material between all of their MUAs by hand 🧚.
Since an OpenPGP certificate MAY be certified by third parties (whether formal CAs or merely other well-connected peers), the MUA SHOULD offer affordances to help the user get and merge third-party certifications onto their certificate 🎀. When doing this, the MUA should prioritize third-party certifications from entities that the user's peers are likely to know about and be willing to rely on.
Since an OpenPGP certificate can grow arbitrarily large with third-party certifications, the MUA should help the user prune it so it stays a reasonable size when sending it to other people 🧹.
8.2.1.3. Generate Secret Key Material Locally
No matter the protocol (S/MIME or PGP), when making certificates for the end user, the MUA SHOULD make sure it has generated the secret key material locally, and it MUST NOT accept secret key material from an untrusted external party as the basis for the user's certificate 🔐. For example, a user who trusts their system administrator not to compromise their MUA might accept secret key material generated by that admin. But they probably should not accept secret key material generated by some random unaffiliated online web service 🙈.
An MUA that accepts secret key material from a third party can't stop that third party from keeping a copy 😭. A third party with this level of access could decrypt messages meant to be confidential for the user, or forge messages that would look like they came from the user 💀.
8.2.2. Local Certificate Maintenance
In the context of a single email account managed by an MUA, where that account is expected to be able to use end-to-end cryptographic protections, the MUA SHOULD warn the user (or proactively fix the problem) when/if:
- For S/MIME, the user's own certificate set for the account does not include a valid, unexpired encryption-capable X.509 certificate and a valid, unexpired signature-capable X.509 certificate.
- For PGP/MIME, the user's own certificate does not include a valid, unexpired signing-capable key/subkey and a valid, unexpired encryption-capable key/subkey.
- Any of the user's own certificates for the account:
- are due to expire in the next month (or at some other reasonable cadence).
- do not match the email address associated with the account in question.
- Any of the user's own S/MIME certificates for the account:
- do not have a
keyUsageextension. - do not contain an
extendedKeyUsageextension. - would be considered invalid by the MUA for any other reason if it were a peer certificate.
- do not have a
An MUA that takes active steps to fix any of these problems before they show up is even more usable than one that just throws warnings 🦋. Guidance on how to do active certificate maintenance is out of scope for this document, though (see Appendix A.4.3).
If the MUA does find any of these issues and decides to warn the user, it should use one aggregate warning. Keep the language simple, explain how the certificates might not be acceptable to other people, and recommend a course of action the user can take to fix it 🌸.
8.2.3. Shipping Certificates in Outbound Messages
When composing mail, a conformant MUA SHOULD include copies of the user's own certificates (and potentially other certificates) in each message, so future communication is easy 📨. The exception is when it has specific knowledge that the other parties already know the relevant keys. For example, that happens with mail between members of a domain that has a synchronized and up-to-date certificate directory.
The mechanism for including these certificates, and which certificates to include, are protocol specific 🧩.
8.2.3.1. Shipping Certificates in S/MIME Messages
In any S/MIME SignedData object, certificates can be shipped in the "certificates" member. In any S/MIME EnvelopedData object, certificates can be shipped in the "originatorInfo.certs" member 📦.
When a single S/MIME-protected email message is signed-and-encrypted, it's usually enough to ship all the relevant certificates in the inner SignedData object's "certificates" member ✨.
The S/MIME certificates shipped in such a message SHOULD include:
- the user's own S/MIME signing certificate, so the signature on the current message can be validated.
- the user's own S/MIME encryption-capable certificate, so the recipient can reply in encrypted form.
- on an encrypted message to multiple recipients, the encryption-capable peer certificates of the other recipients, so any recipient can easily "reply all" without having to go searching for certificates 🙌.
- any intermediate CA certificates needed to chain all of the above to a widely trusted set of root authorities.
8.2.3.2. Shipping Certificates in PGP/MIME Messages
PGP/MIME doesn't have one single standard location for shipping certificates 🤷♀️.
Some MUAs ship the relevant OpenPGP certificates in a single MIME leaf with Content-Type "application/pgp-keys". When a message like that has cryptographic protections, this kind of MIME part SHOULD be a leaf of the Cryptographic Payload and not outside of it, so the message stays well-formed 🧾. One problem with this approach is that it shows up for recipients with non-cryptographic MUAs as an "attachment", which can cause confusion if the user doesn't know what to do with it 😅.
Other implementations ship the relevant OpenPGP certificates in Autocrypt or Autocrypt-Gossip message header fields (see [AUTOCRYPT]). To make sure those header fields get the same cryptographic authenticity as the rest of the message, these header fields SHOULD be protected as described in [RFC9788] 🔒.
The OpenPGP certificates shipped in such a message SHOULD include:
- the user's own OpenPGP certificate, capable of both signing and encryption, so the user can validate the message's signature and can encrypt future messages.
- on an encrypted message to multiple recipients, the OpenPGP certificates of the other recipients, so any recipient can easily "reply all" without needing to search for certificates 💜.
9. Common Pitfalls and Guidelines
This section highlights a few "pitfalls" and guidelines based on these discussions and lessons learned 🍓.
9.1. Reading Sent Messages
When sending a message, a typical MUA stores a copy of the message in the sender's Sent mail folder so the sender can read it later 📤. If the message is encrypted, storing it encrypted takes some forethought so the sender can still read it in the future 🤔.
It's a common and simple practice to encrypt the message not only to the recipients but also to the sender 💖. One upside is that the message sent on the wire can be identical to the message stored in the sender's Sent mail folder. That means the sender can review and reread the message even though it was encrypted.
There are at least three other approaches that are possible for making sure the sender can read the message in the future, but they each come with different trade-offs:
- 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
Sentfolder). This approach means the message stored in theSentfolder is not byte-for-byte identical to the message sent to the recipients. If message delivery has a transient failure, the MUA cannot simply resubmit the stored message into the SMTP system and expect the recipient to be able to read it 🙃. - Store a cleartext version of the message in the
Sentfolder. This comes with a risk of information leakage: anyone with access to theSentfolder can read the contents of the message 😬. Furthermore, if the sender tries to resend the message, the cryptographic transformation needs to be reapplied before sending, or else the message contents will leak upon resend. A conformant MUA SHOULD NOT store a cleartext copy in theSentfolder unless it knows that theSentfolder cannot be read by an attacker. For example, if end-to-end confidentiality is desired, then storing the cleartext in an IMAP folder where a potentially adversarial server can read it totally defeats the purpose 🚫. - A final option is that the MUA can store a copy of the message's encryption session key. Standard email encryption mechanisms (e.g., S/MIME and PGP/MIME) are hybrid mechanisms: the asymmetric encryption steps simply encrypt a symmetric "session key", which is then used to encrypt the message itself 🧠. If the MUA stores the session key itself, it can use that session key to decrypt the
Sentmessage without needing theSentmessage to be decryptable by the user's own asymmetric key. An MUA doing this must take care to store (and back up) its stash of session keys, because if it loses them, it won't be able to read the sent messages. And if someone else gains access to them, they can decrypt the sent messages 👀. This also has the additional consequence that any other MUA accessing the sameSentfolder 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 composing 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. In other words, the rendering MUA should not stop the user from reading a message they have access to just because the encryption certificate has expired 📖.
The rendering 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 it should not complain 🫶.
The main goal of certificate expiration is to make it easier to rotate secret key material, so secret key material doesn't have to be kept around forever 🔄. Certificate expiration lets the user destroy an older secret key once access to the messages encrypted to it is no longer needed (see also Appendix A.10) 🗑️✨.
9.3. Unprotected Message Header Fields ✨
okay so legacy MUAs (mail apps) that do know about crypto usually only protect the body of the message and just leave the header fields hanging out there unprotected 😭. that's giving security holes, bestie. a passive middleman can see your Subject line 👀, or someone can swap the Subject and totally change what a signed message means 💀. these aren't just security bugs, they're usability problems too, because regular people can't tell where the header stops and the body starts. the mental model is way more complicated than it needs to be 🙃. useful security only happens when the mental model is simple and the tooling matches it, periodt 💅.
so to avoid all this drama, a conformant MUA MUST implement Header Protection as described in [RFC9788] 🛡️🎀.
quick note 🌸: some header fields like List-, Archived-At, and Resent- are usually added by an intervening MUA (see Section 9.8), not by one of the classic "ends" of an end-to-end email exchange 📬. so a rendering MUA may choose to treat these as markers added during transit on an end-to-end protected message, even if the end-to-end crypto doesn't cover them 🦋.
9.4. Composing an Encrypted Message with Bcc 🙈
okay this one is spicy 🌶️. when you send an encrypted message with at least one recipient in the Bcc header field, the encrypted message itself can leak info about the actual recipients, even if the Bcc field doesn't name them 😱. like, if the message makes it super clear which certificates it's encrypted to, those certificates can basically identify the recipients even though they're not in the header fields 🕵️♀️.
so there are a bunch of interacting factors to think about when you're composing an encrypted message with Bcc'ed people 💖:
- should the Bcc header field be filled in explicitly on the Bcc'ed copies and on the copy in the sender's Sent folder? see Section 3.6.3 of [RFC5322] for the choices 🎀.
- when you make separate copies for Bcc'ed recipients, should each copy _also_ be encrypted to the named recipients, or just to the designated Bcc recipient? 🤔
- when a copy goes in the Sent folder, should that copy also be encrypted to the Bcc'ed recipients? (see also Section 9.1.) 📁
- when a message gets encrypted, and there's a way to include recipients' certificates, whose certificates should get included? 🦢
9.4.1. Simple Encryption with Bcc 🌈
here's a simple approach that keeps the number of message variants low while still giving a coherent view of the message itself 💅:
- no Cryptographic Payload contains any Bcc header field 🙅♀️.
- the main copy is signed and encrypted to all named recipients and the sender. a copy also goes in the sender's Sent folder 📨.
- each Bcc recipient gets their own distinct copy, with an identical Cryptographic Payload (so the cleartext is the same), and it's signed and encrypted to that specific recipient plus all the named recipients. these copies are NOT stored in the sender's Sent folder 🫣.
- any Bcc'ed recipient MUST NOT be taken into consideration when deciding which certificates to include in the message. like, certificates for Bcc'ed recipients MUST NOT included in any message 🚫. (sorry, the original says "MUST NOT included" with no "be", and I'm keeping it exactly like that 🙈)
9.4.1.1. Rationale 🧠
this approach lines up the cryptographic recipients as closely as possible with the named recipients, and it still lets a Bcc'ed person read their own copy and "reply all" if they want 💜.
it should cut down on confusion for the receiver 🥰. a recipient who looks at the User-Facing Header Fields in their own mailbox will get a good sense of what crypto was applied. the composer also sees fields that match what they expect, which makes the whole experience way smoother ✨. plus, it might keep a Bcc'ed person anonymous 🦋. they could hand the signed Cryptographic Payload to someone outside as proof of the original sender's intent without revealing who they are 🕊️.
9.5. Draft Messages 📝
when you're composing, most MUAs save a copy of the unsent message to a "Drafts" folder 💾. if that folder lives somewhere the user doesn't control (like an IMAP mailbox), it would be a huge mistake to store the draft in the clear, because the contents could leak 😬.
this is true even if the message is eventually sent in the clear on purpose 🙃. while you're composing, the MUA has no idea whether the message is going to be sent encrypted or not. like, the user could decide to encrypt it right before sending, and the MUA would have zero way of knowing 🤷♀️.
the MUA SHOULD encrypt all draft messages, unless it has explicit knowledge that the message won't be encrypted when sent, or that the Drafts folder can't be read by an attacker 🔐. for example, if end-to-end confidentiality is the goal, storing a cleartext draft in an IMAP folder where a potentially adversarial server can read it totally defeats the purpose 💀.
also, when you encrypt a draft, the draft MUST only be encrypted to the user's own certificate or to some equivalent secret key that only the user has 🗝️. a draft encrypted this way can be decrypted when the user wants to pick up where they left off, but nobody else can read it, not even a potential intended recipient 🌸. heads up though: a draft encrypted like this can only be resumed by another MUA on 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 probably needed for useful interoperability, but it's out of scope for this document (see Appendix A.4.1) 📚.
a conformant MUA MUST NOT sign a message draft with the user's normal signing key 🚫✍️, because creating a non-repudiable signature means the sender is committing to something. if a signed draft leaked to the user's "Drafts" folder on some untrustworthy server, the server operator could claim the user had committed to something they hadn't decided on yet 😱. if draft signing is meant for cryptographic coordination between multiple MUAs of the same user, it should be negotiated with a different key (but see Appendix A.4.1) 🔄.
the message should only be encrypted to its recipients when it's actually sent 📤. no reasonable user expects the intended recipients to be able to read a message that isn't finished yet 🙈.
9.6. Composing a Message to Heterogeneous Recipients 🌷
so when you're writing a message you want encrypted, it's possible some recipients can't view an encrypted copy 😩. for example, when Carol writes to Alice and Bob, Carol's MUA might find a valid encryption-capable certificate for Alice, but none for Bob 💔.
in this situation there are four possible strategies, and every single one has a downside for the encrypted mail experience 😵💫. Carol's MUA can:
- send encrypted to Alice and Bob, knowing Bob won't be able to read it 🙃.
- send encrypted to Alice only, dropping Bob from the recipient list 👋.
- send the message in the clear to both Alice and Bob 🌐.
- send an encrypted copy to Alice and a cleartext copy to Bob 🦋.
each of these has different drawbacks 💅.
approach 1's problem is that Bob gets unreadable mail 📭. approach 2's problem is that Carol's MUA won't send the message to Bob, even though Carol asked it to 😤. approach 3's problem is that Carol's MUA won't encrypt the message, even though Carol asked it to 🔓.
approach 4 has two problems 💀:
- Carol's MUA releases a cleartext copy of the message, even though Carol asked it to send encrypted 😭.
- if Alice wants to "reply all," she might not be able to find an encryption-capable certificate for Bob either 🫠. that puts Alice in an awkward, confusing spot that most users won't understand. specifically, if Alice's MUA follows the guidance about replies to encrypted messages in Section 5.4, getting an encrypted copy will make Alice's reply buffer act really weird 🌀.
this gets extra messy when the second recipient isn't "Bob" but a public mailing list or some other visible archive, where messages are simply never encrypted 📢.
Carol probably won't understand the subtleties and the negative downstream effects of approaches 1 and 4, so putting those choices in front of her isn't advised 🙅♀️.
the most understandable approach for an MUA with an active user is to ask the user (when they hit "send") to pick between approach 2 and approach 3 🎯. if the user won't choose between 2 and 3, the MUA can send them back to the composition window to make other adjustments ✏️.
see also [CLEARTEXT-COPY] for more discussion of these scenarios 📖.
9.7. Message Transport Protocol Proxy: A Dangerous Implementation Choice ⚠️
an implementer of end-to-end crypto might be tempted by a simple design that piggybacks on a mail protocol, like SMTP Submission [RFC6409], IMAP [RFC9051], or JSON Meta Application Protocol (JMAP) [RFC8621], to handle message assembly and interpretation 🧚. in this setup, a naive MUA talks something like a "standard" protocol (SMTP, IMAP, or JMAP) to a local proxy, and the proxy handles signing and encryption (outbound) and decryption and verification (inbound) internally on the user's behalf 🎀. this "pluggable" design is probably easy to apply to any MUA, but it's a problem for end-to-end goals 😬, especially in an existing cleartext ecosystem like email, where any message might be unsigned or signed, cleartext or encrypted 🌈. in particular:
- the user can't easily and safely tell what protections a message has (including messages still being composed) 🫥, and
- the proxy itself doesn't know the subtle nuances about the message that the MUA actually knows 🙈.
with a trustworthy, well-synchronized side channel or protocol extension between the MUA and the proxy, you could deploy this safely 🔒, but needing that side channel or extension kills the universal deployability advantage of the scheme 💔.
similar concerns apply to any implementation bound by an API that works on message objects alone, without any extra contextual parameters 🧩.
this section tries to document some of the inherent risks of this kind of architecture 📝✨.
9.7.1. Dangers of a Submission Proxy for Message Composition ✨
okay so when you're composing and sending a message, applying crypto protections is seriously subtle 🫠 and the SMTP protocol that Submission uses [RFC6409], or any other simple protocol that just hands off a cleartext message for further processing, literally has no way to express that stuff 💅
For example, the sender can't tell SMTP whether a message _should_ be encrypted (some messages, like ones going to a publicly archived mailing list, are pointless to encrypt 🙄) or pick between multiple certificates for a recipient, if there are any (see Section 8.1.1).
Also, because the proxy only touches the message when it's ready to go out, it can't tell the user during composition whether the message can be encrypted, meaning whether a valid certificate exists for each intended recipient 😬. An author might write a totally different message if they knew it would be protected end-to-end. Without that knowledge, they're stuck either writing stuff they assume will get intercepted or risking leaking sensitive content 😭
Even without encryption, deciding whether to sign (and which certificate to sign with, if there's more than one) is another choice the proxy is ill-equipped to make. The common message-signing techniques either make a message unreadable by any non-cryptographic MUA (i.e., PKCS #7 signed-data) or show up as an attachment that can confuse a naive recipient using a non-cryptographic MUA (i.e., multipart/signed). If the composer knows the recipient won't check signatures, they may prefer to just send a cleartext message with no cryptographic signature at all 🌸
Furthermore, handling encryption properly depends on the context of any given message, and the MUA has no way to express that context to the Submission proxy. For example, decisions about how to handle encryption and quoted or attributed text may depend on the cryptographic status of the message being replied to (see Section 5.4) 🧚
Additionally, such a proxy would need to be capable of managing the user's own key and certificate (see Section 8.2). Like, how will the implementation tell the user when their own certificate is near expiry? And how will any other error conditions be handled when the user needs to be contacted? 🤔
An extension to SMTP might be able to express all the necessary semantics so that a generic MUA could compose messages with standard cryptographic protections via a proxy, but that extension is beyond the scope of this document. Check out [SMIME-SENDER-EXTENSIONS] for an example of how an MUA using a proxy protocol might indicate signing and encryption instructions to its proxy 🦋
9.7.2. Dangers of an IMAP Proxy for Message Rendering 🎀
when it comes to receiving and rendering a message, showing the user the cryptographic status is full of subtleties that are hard to offer through a straightforward IMAP proxy (or a Post Office Protocol (POP) [RFC1939] or JMAP one) 😵💫
One approach such a proxy could take is to strip all the Cryptographic Layers off a well-formed message and package a description of those layers into a special header field that the MUA can read. But this just raises the question: what semantics need to be represented? For example:
- Was the message signed? If so, by whom? When?
- Should the details of the cryptographic algorithms used in any signatures found be indicated as well?
- Was the message encrypted? If so, to whom? What key was used to decrypt it?
- If both signed and encrypted, was the signing outside or inside the encryption?
- How should Errant Cryptographic Layers (see Section 4.5) be dealt with?
- What cryptographic protections do the header fields of the message have? (See [RFC9788].)
- How are any errors or surprises communicated to the user?
If the proxy passes any of this cryptographic status to the client in an added header field, it must also make sure that no such header field is present on the messages it receives before processing them. If it let an unmodified header field through to any client willing to trust its contents, an attacker could spoof the field and make the user believe lies about the cryptographic status of the message 🚨 An MUA can only be confident in such a header field if it has a guarantee from the proxy that any header field the proxy produces will be safe. How does the MUA reliably negotiate that guarantee with the proxy? And if the proxy can no longer offer it, how will the MUA know that things have changed? 💀
If such an inbound proxy handles certificate discovery in inbound messages (see Appendix A.3.1), it will also need to communicate the results of that discovery process to its corresponding outbound proxy for message composition (see Section 9.7.1) 🔁
While an extension to IMAP (or POP or JMAP) might be able to express all the necessary semantics so that a generic MUA could indicate standardized cryptographic message status, that extension is beyond the scope of this document. [RFC9219] describes the transmission of an S/MIME signature verification status over JMAP, which is a subset of the cryptographic status information described here 💜
9.7.3. Who Controls the Proxy? 👑
Finally, the naive proxy deployment approach is risky precisely because it's so opaque to the end user. Such a deployment could be placed anywhere in the stack, including on a machine that isn't ultimately controlled by the end user, which makes it effectively a form of transport protection rather than end-to-end protection 😤
An MUA that's explicitly under the control of the end user, with thoughtful integration, can offer UI/UX and security guarantees that a simple proxy can't provide. See also Appendix A.13 for suggestions of future work that might augment a proxy to make it safer ✨
9.8. Intervening MUAs Do Not Handle End-to-End Cryptographic Protections 🌈
Some MUAs will resend a message in identical form (or very similar form) to the way they received it. For example, consider these use cases:
- a mail expander or mailing list that receives a message and resends it to all subscribers (see also Appendix A.14 for more discussion of mailing lists)
- an individual user who reintroduces a message they received into the mail transport system (see Section 3.6.6 of [RFC5322])
- an automated email intake system that forwards a report to the mailboxes of responsible staffers
These MUAs intervene in message transport by receiving messages and then reinjecting them 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 an 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 it resends. 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 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 the intervening MUA made 🙃 For signed-and-encrypted messages, if the intervening MUA is capable of decrypting the message, it must be careful when retransmitting it. 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 resend the message 🫣
Beyond the act of resending, an intervening MUA should not itself try to apply end-to-end cryptographic protections to a message 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 they won't be interpretable as end-to-end protections because they don't originate with the original sender of the message 🚫💅
9.9. External Subresources in MIME Parts Break Cryptographic Protections ✨
okay so, a MIME part with a content type that can point at external resources (like text/html) can have its own end-to-end cryptographic protections 🔐. BUT, retrieving or rendering those external resources can totally break the stuff users expect from crypto protection 😭
as a baseline, grabbing the external resource at the moment someone reads the message can be used as a "web bug" 🕵️♀️. that leaks the recipient's activity and network location to whoever hosts the resource. this privacy risk exists even for messages with no crypto at all, but it's extra shocking for users who see a security indicator on a message 💀
other problems with external resources are more specifically tied to crypto protections 🎀
for example, a signed email with a text/html part that links to an external image, like <img src="https://example.com/img.png">, can look different if the web server decides to serve different content at that source URL 🙈 that totally wrecks the integrity and authenticity users should be able to count on for signed messages, unless the external subresource has strict integrity guarantees (e.g., via [SRI]) 💅
same vibe for signed-and-encrypted messages: fetching an external subresource breaks the privacy and confidentiality users are relying on 🫶
this is loosely analogous to the security indicator problems web browsers ran into, as described in [MIXED-CONTENT] 🌐 but here's the tea: fetching the subresource over https is enough to dodge a "mixed content" warning in most browsers, and it is NOT enough for an MUA that wants to give users true end-to-end guarantees for email 🙅♀️
a conformant composing MUA that applies signing-only protection to a new email with an external subresource should take one of these 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 (though this does NOT fix the "web bug" privacy risk from above) 🔒
- prompt the composing user to remove the subresource from the message 🗑️
a conformant composing MUA that applies encryption to a new email with an external resource can't lean on Subresource Integrity to protect the privacy and confidentiality of the message 🙃 so it should either pre-fetch the external resource and include it in the message, or prompt the composing user to remove it before sending ✨
a conformant rendering MUA that runs into a message with end-to-end cryptographic protections containing a subresource MUST either refuse to retrieve and render the external subresource, or decline to treat the message as having cryptographic protections 🚫 for example, it could indicate in the Cryptographic Summary that the message is Unprotected 🔓
and lastly, when composing a reply with quoted text from an original message that had an external resource, the composing MUA SHOULD NOT fetch the external resource just to include it in the reply 😱 doing so would trigger the "web bug" at reply composition time. the safest move for quoted text containing an external resource in an end-to-end encrypted reply is to strip any reference to that external resource during initial composition of the reply 🧹
10. IANA Considerations 🌸
This document has no IANA actions. Nothing to register here, bestie 💖
11. Security Considerations 🔐
This entire document addresses security considerations about end-to-end cryptographic protections for email messages. Honestly, the whole thing is a security section in a trench coat 🧥😭 every single part of it is about keeping your encrypted email actually private and actually trustworthy, so read it all, no skipping 🙈💀
12. References 📚
12.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>. - [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001,
<https://www.rfc-editor.org/info/rfc3156>. - [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
<https://www.rfc-editor.org/info/rfc4289>. - [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>. - [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>. - [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>. - [RFC9598] Melnikov, A., Chuang, W., and C. Bonnell, "Internationalized Email Addresses in X.509 Certificates", RFC 9598, DOI 10.17487/RFC9598, May 2024,
<https://www.rfc-editor.org/info/rfc9598>. - [RFC9788] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header Protection for Cryptographically Protected Email", RFC 9788, DOI 10.17487/RFC9788, August 2025,
<https://www.rfc-editor.org/info/rfc9788>. 🦋
12.2. Informative References ✨
okay bestie, these are the "extra reading" references, the ones that help you understand the vibe but aren't strictly required to build the thing 📚💅
[AUTOCRYPT]Autocrypt Team, "Autocrypt - Convenient End-to-End Encryption for E-Mail", <https://autocrypt.org/>.[CERT-BEST-PRACTICE]Woodhouse, D. and N. Mavrogiannopoulos, "Recommendations for applications using X.509 client certificates", Work in Progress, Internet-Draft, draft-woodhouse-cert-best-practice-01, 25 July 2023, <https://datatracker.ietf.org/doc/html/draft-woodhouse-cert-best-practice-01>.[CHROME-INDICATORS]Schechter, E., "Evolving Chrome's security indicators", Chromium Blog, May 2018, <https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html>.[CLEARTEXT-COPY]Gillmor, D. K., "Encrypted E-mail with Cleartext Copies", Work in Progress, Internet-Draft, draft-dkg-mail-cleartext-copy-01, 21 February 2023, <https://datatracker.ietf.org/doc/html/draft-dkg-mail-cleartext-copy-01>.[DROWN]Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N., Dankel, M., Steube, J., Valenta, L., Adrian, D., Halderman, J. A., Dukhovni, V., Käsper, E., Cohney, S., Engels, S., Paar, C., and Y. Shavitt, "DROWN: Breaking TLS using SSLv2", Proceedings of the 25th USENIX Security Symposium (USENIX Security 16), pp. 689-706, August 2016, <https://drownattack.com/drown-attack-paper.pdf>.[EFAIL]Poddebniak, D., Dresen, C., Müller, J., Ising, F., Schinzel, S., Friedberger, S., Somorovsky, J., and J. Schwenk, "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", Proceedings of the 27th USENIX Security Symposium (USENIX Security 18), pp. 549-566, August 2018, <https://www.usenix.org/conference/usenixsecurity18/presentation/poddebniak>.[IKE]Felsch, D., Grothe, M., Schwenk, J., Czubak, A., and M. Szymane, "The Dangers of Key Reuse: Practical Attacks on IPsec IKE", Proceedings of the 27th USENIX Security Symposium, pp. 567-583, August 2018, <https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-felsch.pdf>.[MIXED-CONTENT]Stark, E., Ed., West, M., Ed., and C. Lopez, Ed., "Mixed Content", W3C Candidate Recommendation Draft, February 2023, <https://www.w3.org/TR/2023/CRD-mixed-content-20230223/>. Latest version available at <https://www.w3.org/TR/mixed-content/>.[OPENPGP-FORWARDING]Wussler, A., "Automatic Forwarding for ECDH Curve25519 OpenPGP messages", Work in Progress, Internet-Draft, draft-wussler-openpgp-forwarding-00, 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-wussler-openpgp-forwarding-00>.[ORACLE]Ising, F., Poddebniak, D., Kappert, T., Saatjohann, C., and S. Schinzel, "Content-Type: multipart/oracle - Tapping into Format Oracles in Email End-to-End Encryption", Proceedings of the 32nd USENIX Security Symposium (USENIX Security 23), pp. 4175-4192, August 2023, <https://www.usenix.org/conference/usenixsecurity23/presentation/ising>.[PKCS11]Bong, D., Ed. and T. Cox, Ed., "PKCS #11 Specification Version 3.1", OASIS Standard, July 2023, <https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/os/pkcs11-spec-v3.1-os.html>.[REPLY]Müller, J., Brinkmann, M., Poddebniak, D., Schinzel, S., and J. Schwenk, "Re: What's Up Johnny?: Covert Content Attacks on Email End-to-End Encryption", Applied Cryptography and Network Security (ACNS 2019), Lecture Notes in Computer Science, vol. 11464, pp. 24-42, DOI 10.1007/978-3-030-21568-2_2, April 2019, <https://doi.org/10.1007/978-3-030-21568-2_2>.[RFC1939]Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, <https://www.rfc-editor.org/info/rfc1939>.[RFC2045]Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.[RFC3207]Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <https://www.rfc-editor.org/info/rfc3207>.[RFC3274]Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, DOI 10.17487/RFC3274, June 2002, <https://www.rfc-editor.org/info/rfc3274>.[RFC3370]Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, <https://www.rfc-editor.org/info/rfc3370>.[RFC4511]Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511, June 2006, <https://www.rfc-editor.org/info/rfc4511>.[RFC5322]Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.[RFC6376]Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.[RFC6409]Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <https://www.rfc-editor.org/info/rfc6409>.[RFC6532]Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/info/rfc6532>.[RFC7292]Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, <https://www.rfc-editor.org/info/rfc7292>.[RFC7435]Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.[RFC7929]Wouters, P., "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP", RFC 7929, DOI 10.17487/RFC7929, August 2016, <https://www.rfc-editor.org/info/rfc7929>.[RFC8162]Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", RFC 8162, DOI 10.17487/RFC8162, May 2017, <https://www.rfc-editor.org/info/rfc8162>.[RFC8621]Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, August 2019, <https://www.rfc-editor.org/info/rfc8621>.[RFC8823]Melnikov, A., "Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates", RFC 8823, DOI 10.17487/RFC8823, April 2021, <https://www.rfc-editor.org/info/rfc8823>.[RFC9051]Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, <https://www.rfc-editor.org/info/rfc9051>.[RFC9216]Gillmor, D. K., Ed., "S/MIME Example Keys and Certificates", RFC 9216, DOI 10.17487/RFC9216, April 2022, <https://www.rfc-editor.org/info/rfc9216>.[RFC9219]Melnikov, A., "S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)", RFC 9219, DOI 10.17487/RFC9219, April 2022, <https://www.rfc-editor.org/info/rfc9219>.[RFC9580]Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024, <https://www.rfc-editor.org/info/rfc9580>.[SMIME-SENDER-EXTENSIONS]Melnikov, A., "JMAP extension for S/MIME signing and encryption", Work in Progress, Internet-Draft, draft-ietf-jmap-smime-sender-extensions-04, 3 August 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-sender-extensions-04>.[SPOOFING]Müller, J., Brinkmann, M., Poddebniak, D., Böck, H., Schinzel, S., Somorovsky, J., and J. Schwenk, ""Johnny, you are fired!" - Spoofing OpenPGP and S/MIME Signatures in Emails", Proceedings of the 28th USENIX Security Symposium (USENIX Security 19), pp. 1011-1028, August 2019, <https://www.usenix.org/system/files/sec19-muller.pdf>.[SRI]Akhawe, D., Braun, F., Marier, F., and J. Weinberger, "Subresource Integrity", W3C Candidate Recommendation, June 2016, <https://www.w3.org/TR/2016/REC-SRI-20160623/>. Latest version available at <https://www.w3.org/TR/SRI/>.[WEBKEY-SERVICE]Koch, W., "OpenPGP Web Key Directory", Work in Progress, Internet-Draft, draft-koch-openpgp-webkey-service-20, 2 June 2025, <https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-20>.
Appendix A. Future Work 🌸
okay so this document is packed with useful guidance for MUA implementers, but honestly it can't cover everything 🙈 there are a few topics we're leaving on the table for now, and future revisions might dig into them. these are out of scope for this version, bestie 💜
A.1. Webmail Threat Model
the threat model for end-to-end cryptographic protections in webmail is way more complicated than the classic MUA model 😭 for example, the web server hosting the webmail interface could be a potential adversary. like, if the user treats the web server as a trusted party but the web server betrays that trust, the end-to-end cryptographic protections do not hold. that's a whole plot twist 💀
a future version of this document could include a more detailed discussion of an adversarial threat model for end-to-end cryptographic protections in a webmail context ✨
A.2. 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 [RFC9580] and [RFC9216] 🧚
it may also include example renderings of these messages 🎀
A.3. Further Guidance on Peer Certificates
A.3.1. Certificate Discovery from Incoming Messages
as described in Section 8.2.3, an incoming email message may have one or more certificates embedded in it 📩 this document currently acknowledges that a rendering MUA should assemble a cache of certificates for future use, but giving more detailed guidance on how to assemble and manage that cache is currently out of scope 🫶
existing recommendations like [AUTOCRYPT] give some guidance for handling incoming certificates about peers, but only in certain contexts 🦋 a future version of this document may describe in more detail how these incoming certificates should be handled 🔥
A.3.2. Certificate Directories 📂✨
okay so some MUAs can actually go look up a peer's certs in a directory 🗂️ like through the Lightweight Directory Access Protocol (LDAP) [RFC4511], the Web Key Directory (WKD) [WEBKEY-SERVICE], or DNS, using SMIMEA [RFC8162] or OPENPGPKEY [RFC7929] resource records 🌐
a future version of this doc might get more detailed about which sources an MUA should check when hunting for a peer's certificates, and what to do with the certs it finds by each method 🔮
A.3.3. Checking for Certificate Revocation 🚫
a future version of this document could talk about how and when to check whether a peer's certificate has been revoked, or whether the user's own certificate has 👀
and that conversation should totally address privacy 🙈 like, what information leaks to whom when you check a peer's certificate revocations? 🫣
A.3.4. Further Peer Certificate Selection 🎯
a future version of this doc may give more instructions for deciding whether a peer's certificate is acceptable for encrypting a message 💅 for example, if the SPKI is an Elliptic Curve (EC) public key and the keyUsage extension is absent, what should the encrypting MUA do? 🤔
it might also offer guidance for when multiple certificates are all acceptable for encrypting to the same recipient 💖 like, the composing MUA could pick one in some deterministic way, it could encrypt to all of them, or it could show them to the user so the user can pick any or all of them 🌈
A.3.5. Human-Readable Names in Peer Certificates, Header Fields, and Address Books 🪪💭
okay this one is a whole vibe 😭 in header fields like From that can contain a display-name (see Section 3.4 of [RFC5322]), a sketchy composer or an interfering adversary can fill that display-name with a human-readable name that doesn't match the participant's actual name at all 💀 Section 8.1.1 covers matching peer certificates to email addresses (the addr-spec part of those header fields), but it doesn't go into matching display-names or other user-visible stuff 🙅♀️ Section 6.4 explains how signature validation should confirm the binding between the addr-spec and the certificate itself, but it also doesn't touch display-names or similar user-visible data 😤
depending on how the rendering MUA shows that display-name, the unvalidated field could confuse the user, and that could break the end-to-end assurances we're trying so hard to keep 😱 the plot twist is that both X.509 and OpenPGP certificate formats have ways to include cryptographically certified human-readable names 🎀 (they might not be unique, though) 🙃 and lots of MUAs have an address book or something similar that can make real connections between user-relevant identity labels and email addresses 📇
a human-readable name, like a display-name, doesn't have the global uniqueness that an addr-spec has 🥲 so if you want to reason about those names and show them to the user as part of a system that gives end-to-end cryptographic assurance, you need extra careful analysis 🧐
a future version of this document might offer strategies for linking human-readable names from certificates (and things like address books) to how header fields with a display-name get rendered 🌸 any guidance like that should come with an analysis of the specific usability and security risks of these human-readable fields, plus an explanation of how the recommended guidance reduces those risks 💜
A.4. Further Guidance on Local Certificates and Secret Keys 🔐
A.4.1. Cross-MUA Sharing of Local Certificates and Secret Keys 🔁
lots of people use more than one MUA for the same mailbox 📱💻 (like one MUA on their phone and another on their desktop) 🖥️
a future version of this document might give guidance on how multiple MUAs attached to the same mailbox can share the user's own secret key material and certificates efficiently and securely 🔑 that guidance should include tips on keeping the user's keys maintained (for example, avoiding certificate expiration) and on safe secret key transmission 🛡️
A.4.2. Use of Smart Cards or Other Portable Secret Key Mechanisms 💳
instead of transferring secret key material between clients, some users might prefer portable hardware-backed secret keys, like smart cards, USB tokens, or other similar form factors 🔐✨ these keys sometimes need direct user interaction for every single use, which can make things clunky for any MUA that has to decrypt a huge pile of messages 😩
guidance on this kind of secret key management is out of scope for this document, but future revisions might bring it in 🔮
A.4.3. Active Local Certificate Maintenance 🛠️
Section 8.2.2 describes the conditions where the MUA SHOULD warn the user that something is going wrong with their certificate ⚠️
a future version of this document might explain how an MUA could actively avoid those warning situations 🙌 for example, by automatically updating the certificate or prompting the user to take a specific action 💫
A.5. Certification Authorities 🏛️
a future document could offer guidance on how an MUA should pick and manage root 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.6. Indexing and Search of Encrypted Messages 🔎
searching existing messages by keyword or topic is a huge deal for MUAs 📬 for big mailboxes, the most efficient way to do it is to build an index of message content instead of scanning everything linearly 🏃♀️💨
but when message contents and header fields are encrypted, indexing gets messy 😵💫 if the cleartext isn't indexed, messages can't be found by search at all 🙃 but if the cleartext is indexed, then the index basically contains the sensitive contents of the message and needs its own protection 🔒
detailed guidance on this trade-off, including choices between remote search and local search, is out of scope for this document, but a future version might bring it in 🫶
A.7. Cached Signature Validation 🧾
asymmetric signature validation can be super computationally expensive 🥵 and the results can also change over time (for example, if a signing certificate turns out to be revoked later) 😬 in some cases, the user might care about the signature validation they saw when they first read or received the message, not just the status of the signature check right now 🕰️
so, for both performance and historical perspective, it could be really useful for an MUA to cache signature validation results in a way that they're easy to retrieve and compare 💅 documenting how and when to cache signature validation, plus how to show that to the user, is out of scope for this document, but a future version might cover it 💖
A.8. Aggregate Cryptographic Status 📊
this document only looks at the cryptographic status of single messages 🎯 that's the baseline concept that can be communicated clearly and simply to the user 💁♀️ some users and some MUAs might find higher-level views useful, though, and those aren't considered directly here 👀
for example, a future version might look at how to show a simple cryptographic status for message threads (groups of explicitly related messages), conversations (groups of messages with shared sets of participants), peers, or other perspectives an MUA can offer 🧵✨
A.9. Expectations of Cryptographic Protection 🌡️
as mentioned in Section 2.3, the security indicators shown to the user can vary depending on what the user expects from a given communication 🫧 right now there isn't any widely shared method for an MUA to set up and keep reasonable expectations about whether a specific rendered message should have cryptographic protections 🤔
if a standard like that gets developed, a future version of this document should reference it and encourage clearer, simpler security indicators 🌈
A.10. Secure Deletion 💣
a feature lots of users want from a secure communications medium is the ability to reliably destroy a message so it can't be recovered, even by a determined adversary 😤 in other contexts, a similar property is called "forward secrecy" 🦋 doing this with standard email mechanisms like S/MIME and PGP/MIME is hard because of two intertwined problems:
- A copy of an email message may be retained by any of the mail transport agents that handle it during delivery. 📨
- The secret key used to decrypt an encrypted email message is typically retained indefinitely. 🗝️
so an adversary who wants to recover the cleartext of a deleted message can do it by getting a copy of the encrypted message and the long-term secret key material 😭
some mitigation measures might make it possible to securely delete some encrypted messages, but this document considers that use case out of scope 🙅♀️ a future version might go deeper into secure message deletion 🔮
A.11. Interaction with Opportunistic Encryption 🤝
this document is all about strong, user-comprehensible end-to-end cryptographic protections for email 💜 other approaches are possible, including various forms of opportunistic and transport encryption, but those are out of scope here 🚫
a future version of this document could describe how this guidance interacts with more opportunistic forms of encryption, for example, some of the scenarios considered in [CLEARTEXT-COPY] 🌸
A.12. Split Attachments ✂️
as noted in Section 7.2, the standard form for encrypted email is a single Cryptographic Envelope 📦 now picture multiple user agents drafting one encrypted message over low-bandwidth links 🐢 that can be a rough experience, since each MUA has to retrieve the full message, attachments and all, just to modify the draft 😩 similarly, when someone receives a message with a big attachment, the receiving MUA might only want to render the Main Body Part, but it'll have a significant delay doing that if it has to process the whole message before handling anything 🥱
future work might try to standardize a mechanism that eases this use case, though that could risk leaking additional metadata about the message (for example, the size and number of message parts) 👀 any such work should explicitly try to minimize the risks and concerns described in Section 7.2 🫶
A.13. Proxy Extensions 🧚
as noted in Section 9.7, a proxy-based implementation can be a super tempting approach 😌 but its naive form is likely to be insufficient for providing safe end-to-end encrypted email 🙅♀️
a future version of this document, or a separate but related document, could try to outline the specific additional information, state, and network API surface that would be needed to let an MUA be safely integrated with an encryption provider 🔌 any such work should try to address the potential problems described in Section 9.7 💖
A.14. Mailing Lists
Okay bestie, mailing lists are a whole chaos situation for end-to-end crypto 😭🎀 The thing is, by default there's some kind of MUA sitting in the middle (see Section 9.8) 🫶 And honestly? User expectations are different here, at least if they know they're writing to a mailing list, so it's giving "wait, who else is reading this?" 💀 The big vibe-killer is that a subscriber often has no idea who else is on the list 🙈 And another problem: for some lists, some subscribers might not have a valid, non-expired certificate. Not me being dramatic, this is real 😤
So encryption can behave differently depending on what the list is for 🦋 Sending encrypted mail to a publicly archived mailing list? It's not clear there are any useful reasons for that, ngl 🤷♀️ But an unarchived list might want confidentiality between all the recipients, even if they don't know for sure who everyone else is 🌸 Or a list with private archives might decide that two "hops" of encryption are useful confidentiality measures (between the composer and the list, and between the list and all the subscribers) even though it's not "end-to-end" in the strict sense of composer straight to every recipient ✨ Still iconic, just a different flavor 💅
Signatures are also a mood that changes depending on the list's goals 👑 The list itself might want to check that an incoming message is signed by an authorized sender before it gets redistributed to subscribers 🔥 It might also want to pass along the composer's signature so every subscriber can verify it 💖 Or, the list might want to sign each redistributed message itself and rewrite it so it looks like it came from the list instead of the original composer 🧚
Then there's the spicy option: redistributing shared secret keys to all recipients, or using some kind of proxied re-encryption scheme, similar to [OPENPGP-FORWARDING] 🌈 Bold energy, literally 😭
A future version of this document, or a separate but related document, might walk through some of these trade-offs and give guidance on safely meeting common requirements when combining end-to-end protections with mailing lists 🎀 Stay tuned, babe ✨
Acknowledgements
The set of constructs and recommendations in this document come from discussions with lots of implementers, and I'm literally so grateful 🫶💜 Huge thanks to Bjarni Rúnar Einarsson, Daniel Huigens, David Bremner, Deb Cooley, Eliot Lear, Fabian Ising, Heiko Schaefer, Holger Krekel, Jameson Rollins, John Levine, Jonathan Hammell, juga, Patrick Brunschwig, Paul Kyzivat, Pete Resnick, Roman Danyliw, Santosh Chokhani, Stephen Farrell, Thore Göbel, and Vincent Breitmoser 👑🌸
Authors' Addresses
Daniel Kahn Gillmor (editor) American Civil Liberties Union 125 Broad St. New York, NY 10004 United States of America Email: dkg@fifthhorseman.net
Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom Email: alexey.melnikov@isode.com
Bernie Hoeneisen (editor) pEp Project Oberer Graben 4 CH-8400 Winterthur Switzerland Email: bernie@ietf.hoeneisen.ch URI: https://pep-project.org/
📦 where this page comes from
- ietf: rfc9787 2025-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms