rfc9787.original   rfc9787.txt 
lamps D. K. Gillmor, Ed. Internet Engineering Task Force (IETF) D. K. Gillmor, Ed.
Internet-Draft ACLU Request for Comments: 9787 ACLU
Intended status: Informational B. Hoeneisen, Ed. Category: Informational B. Hoeneisen, Ed.
Expires: 12 July 2025 pEp Project ISSN: 2070-1721 pEp Project
A. Melnikov, Ed. A. Melnikov, Ed.
Isode Ltd Isode Ltd
8 January 2025 May 2025
Guidance on End-to-End E-mail Security Guidance on End-to-End Email Security
draft-ietf-lamps-e2e-mail-guidance-17
Abstract Abstract
End-to-end cryptographic protections for e-mail messages can provide End-to-end cryptographic protections for email messages can provide
useful security. However, the standards for providing cryptographic useful security. However, the standards for providing cryptographic
protection are extremely flexible. That flexibility can trap users protection are extremely flexible. That flexibility can trap users
and cause surprising failures. This document offers guidance for and cause surprising failures. This document offers guidance for
mail user agent implementers to help mitigate those risks, and to mail user agent implementers to help mitigate those risks and to make
make end-to-end e-mail simple and secure for the end user. It end-to-end email simple and secure for the end user. It provides a
provides a useful set of vocabulary as well as recommendations to useful set of vocabulary as well as recommendations to avoid common
avoid common failures. It also identifies a number of currently failures. It also identifies a number of currently unsolved
unsolved usability and interoperability problems. usability and interoperability problems.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://dkg.gitlab.io/e2e-mail-guidance/. Status information for
this document may be found at https://datatracker.ietf.org/doc/draft-
ietf-lamps-e2e-mail-guidance/.
Discussion of this document takes place on the LAMPS Working Group
mailing list (mailto:spasm@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at
https://www.ietf.org/mailman/listinfo/spasm/.
Source for this draft and an issue tracker can be found at
https://gitlab.com/dkg/e2e-mail-guidance.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 12 July 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9787.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology
1.1.1. Structural Header Fields . . . . . . . . . . . . . . 7 1.1.1. Structural Header Fields
1.1.2. User-Facing Header Fields . . . . . . . . . . . . . . 8 1.1.2. User-Facing Header Fields
2. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Usability
2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Simplicity
2.2. E-mail Users Want a Familiar Experience . . . . . . . . . 10 2.2. Email Users Want a Familiar Experience
2.3. Warning About Failure vs. Announcing Success . . . . . . 11 2.3. Warning About Failure vs. Announcing Success
3. Types of Protection . . . . . . . . . . . . . . . . . . . . . 11 3. Types of Protection
3.1. Simplified Mental Model . . . . . . . . . . . . . . . . . 12 3.1. Simplified Mental Model
3.2. One Cryptographic Status Per Message . . . . . . . . . . 13 3.2. One Cryptographic Status per Message
4. Cryptographic MIME Message Structure . . . . . . . . . . . . 14 4. Cryptographic MIME Message Structure
4.1. Cryptographic Layers . . . . . . . . . . . . . . . . . . 14 4.1. Cryptographic Layers
4.1.1. S/MIME Cryptographic Layers . . . . . . . . . . . . . 14 4.1.1. S/MIME Cryptographic Layers
4.1.2. PGP/MIME Cryptographic Layers . . . . . . . . . . . . 15 4.1.2. PGP/MIME Cryptographic Layers
4.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 16 4.2. Cryptographic Envelope
4.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 17 4.3. Cryptographic Payload
4.4. Types of Cryptographic Envelope . . . . . . . . . . . . . 17 4.4. Types of Cryptographic Envelope
4.4.1. Simple Cryptographic Envelopes . . . . . . . . . . . 17 4.4.1. Simple Cryptographic Envelopes
4.4.2. Multilayer Cryptographic Envelopes . . . . . . . . . 17 4.4.2. Multilayer Cryptographic Envelopes
4.5. Errant Cryptographic Layers
4.5. Errant Cryptographic Layers . . . . . . . . . . . . . . . 17 4.5.1. Mailing List Wrapping
4.5.1. Mailing List Wrapping . . . . . . . . . . . . . . . . 18 4.5.2. A Baroque Example
4.5.2. A Baroque Example . . . . . . . . . . . . . . . . . . 18 4.6. Cryptographic Summary
4.6. Cryptographic Summary . . . . . . . . . . . . . . . . . . 19 5. Message Composition
5. Message Composition . . . . . . . . . . . . . . . . . . . . . 19 5.1. Message Composition Algorithm
5.1. Message Composition Algorithm . . . . . . . . . . . . . . 19 5.2. Encryption Outside, Signature Inside
5.2. Encryption Outside, Signature Inside . . . . . . . . . . 20 5.3. Avoid Offering Encrypted-Only Messages
5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 21 5.4. Composing a Reply Message
5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 22 6. Message Interpretation
6. Message Interpretation . . . . . . . . . . . . . . . . . . . 23 6.1. Rendering Well-Formed Messages
6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 23 6.2. Errant Cryptographic Layers
6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 23 6.2.1. Errant Signing Layer
6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 23 6.2.2. Errant Encryption Layer
6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 25 6.2.3. Avoiding Non-MIME Cryptographic Mechanisms
6.2.3. Avoiding Non-MIME Cryptographic Mechanisms . . . . . 26 6.3. Forwarded Messages with Cryptographic Protection
6.3. Forwarded Messages with Cryptographic Protection . . . . 27 6.4. Signature Failures
6.4. Signature failures . . . . . . . . . . . . . . . . . . . 27 6.5. Weak Encryption
6.5. Weak Encryption . . . . . . . . . . . . . . . . . . . . . 29 7. Reasoning about Message Parts
7. Reasoning about Message Parts . . . . . . . . . . . . . . . . 30 7.1. Main Body Part
7.1. Main Body Part . . . . . . . . . . . . . . . . . . . . . 30 7.2. Attachments
7.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 31 7.3. MIME Part Examples
7.3. MIME Part Examples . . . . . . . . . . . . . . . . . . . 32 8. Certificate Management
8. Certificate Management . . . . . . . . . . . . . . . . . . . 33 8.1. Peer Certificates
8.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 33 8.1.1. Peer Certificate Selection
8.1.1. Peer Certificate Selection . . . . . . . . . . . . . 33 8.2. Local Certificates
8.2. Local Certificates . . . . . . . . . . . . . . . . . . . 34 8.2.1. Getting Certificates for the User
8.2.1. Getting Certificates for the User . . . . . . . . . . 34 8.2.2. Local Certificate Maintenance
8.2.2. Local Certificate Maintenance . . . . . . . . . . . . 36 8.2.3. Shipping Certificates in Outbound Messages
8.2.3. Shipping Certificates in Outbound Messages . . . . . 37 9. Common Pitfalls and Guidelines
9. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 38 9.1. Reading Sent Messages
9.1. Reading Sent Messages . . . . . . . . . . . . . . . . . . 39 9.2. Reading Encrypted Messages after Certificate Expiration
9.2. Reading Encrypted Messages after Certificate 9.3. Unprotected Message Header Fields
Expiration . . . . . . . . . . . . . . . . . . . . . . . 40 9.4. Composing an Encrypted Message with Bcc
9.3. Unprotected Message Header Fields . . . . . . . . . . . . 40 9.4.1. Simple Encryption with Bcc
9.4. Composing an Encrypted Message with Bcc . . . . . . . . . 41 9.5. Draft Messages
9.4.1. Simple Encryption with Bcc . . . . . . . . . . . . . 41 9.6. Composing a Message to Heterogeneous Recipients
9.5. Draft Messages . . . . . . . . . . . . . . . . . . . . . 42
9.6. Composing a Message to Heterogeneous Recipients . . . . . 43
9.7. Message Transport Protocol Proxy: A Dangerous 9.7. Message Transport Protocol Proxy: A Dangerous
Implementation Choice . . . . . . . . . . . . . . . . . . 45 Implementation Choice
9.7.1. Dangers of a Submission Proxy for Message 9.7.1. Dangers of a Submission Proxy for Message Composition
Composition . . . . . . . . . . . . . . . . . . . . . 45 9.7.2. Dangers of an IMAP Proxy for Message Rendering
9.7.2. Dangers of an IMAP Proxy for Message Rendering . . . 47 9.7.3. Who Controls the Proxy?
9.7.3. Who Controls the Proxy? . . . . . . . . . . . . . . . 48
9.8. Intervening MUAs Do Not Handle End-to-End Cryptographic 9.8. Intervening MUAs Do Not Handle End-to-End Cryptographic
Protections . . . . . . . . . . . . . . . . . . . . . . . 48 Protections
9.9. External Subresources in MIME Parts Break Cryptographic 9.9. External Subresources in MIME Parts Break Cryptographic
Protections . . . . . . . . . . . . . . . . . . . . . . . 49 Protections
10. IANA Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 11. Security Considerations
11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 12. References
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 12.1. Normative References
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 12.2. Informative References
13.1. Normative References . . . . . . . . . . . . . . . . . . 51 Appendix A. Future Work
13.2. Informative References . . . . . . . . . . . . . . . . . 52 A.1. Webmail Threat Model
Appendix A. Future Work . . . . . . . . . . . . . . . . . . . . 56 A.2. Test Vectors
A.1. Webmail Threat Model . . . . . . . . . . . . . . . . . . 56 A.3. Further Guidance on Peer Certificates
A.2. Test Vectors . . . . . . . . . . . . . . . . . . . . . . 56 A.3.1. Certificate Discovery from Incoming Messages
A.3. Further Guidance on Peer Certificates . . . . . . . . . . 57 A.3.2. Certificate Directories
A.3.1. Certificate Discovery from Incoming Messages . . . . 57 A.3.3. Checking for Certificate Revocation
A.3.2. Certificate Directories . . . . . . . . . . . . . . . 57 A.3.4. Further Peer Certificate Selection
A.3.3. Checking for Certificate Revocation . . . . . . . . . 57 A.3.5. Human-Readable Names in Peer Certificates, Header
A.3.4. Further Peer Certificate Selection . . . . . . . . . 57 Fields, and Address Books
A.3.5. Human-readable Names in Peer Certificates, Header A.4. Further Guidance on Local Certificates and Secret Keys
Fields, and Addressbooks . . . . . . . . . . . . . . 58 A.4.1. Cross-MUA Sharing of Local Certificates and Secret Keys
A.4. Further Guidance on Local Certificates and Secret Keys . 58 A.4.2. Use of Smart Cards or Other Portable Secret Key
A.4.1. Cross-MUA sharing of Local Certificates and Secret Mechanisms
Keys . . . . . . . . . . . . . . . . . . . . . . . . 59 A.4.3. Active Local Certificate Maintenance
A.4.2. Use of Smartcards or Other Portable Secret Key A.5. Certification Authorities
Mechanisms . . . . . . . . . . . . . . . . . . . . . 59 A.6. Indexing and Search of Encrypted Messages
A.4.3. Active Local Certificate Maintenance . . . . . . . . 59 A.7. Cached Signature Validation
A.5. Certification Authorities . . . . . . . . . . . . . . . . 59 A.8. Aggregate Cryptographic Status
A.6. Indexing and Search of Encrypted Messages . . . . . . . . 60 A.9. Expectations of Cryptographic Protection
A.7. Cached Signature Validation . . . . . . . . . . . . . . . 60 A.10. Secure Deletion
A.8. Aggregate Cryptographic Status . . . . . . . . . . . . . 60 A.11. Interaction with Opportunistic Encryption
A.9. Expectations of Cryptographic Protection . . . . . . . . 61 A.12. Split Attachments
A.10. Secure Deletion . . . . . . . . . . . . . . . . . . . . . 61 A.13. Proxy Extensions
A.11. Interaction with Opportunistic Encryption . . . . . . . . 62 A.14. Mailing Lists
A.12. Split Attachments . . . . . . . . . . . . . . . . . . . . 62 Acknowledgements
A.13. Proxy Extensions . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses
A.14. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 63
Appendix B. Document History . . . . . . . . . . . . . . . . . . 64
B.1. Substantive changes from draft-ietf-...-16 to
draft-ietf-...-17 . . . . . . . . . . . . . . . . . . . 64
B.2. Substantive changes from draft-ietf-...-15 to
draft-ietf-...-16 . . . . . . . . . . . . . . . . . . . 64
B.3. Substantive changes from draft-ietf-...-14 to
draft-ietf-...-15 . . . . . . . . . . . . . . . . . . . 64
B.4. Substantive changes from draft-ietf-...-13 to
draft-ietf-...-14 . . . . . . . . . . . . . . . . . . . 64
B.5. Substantive changes from draft-ietf-...-12 to
draft-ietf-...-13 . . . . . . . . . . . . . . . . . . . 65
B.6. Substantive changes from draft-ietf-...-11 to
draft-ietf-...-12 . . . . . . . . . . . . . . . . . . . 65
B.7. Substantive changes from draft-ietf-...-10 to
draft-ietf-...-11 . . . . . . . . . . . . . . . . . . . 65
B.8. Substantive changes from draft-ietf-...-09 to
draft-ietf-...-10 . . . . . . . . . . . . . . . . . . . 65
B.9. Substantive changes from draft-ietf-...-08 to
draft-ietf-...-09 . . . . . . . . . . . . . . . . . . . 65
B.10. Substantive changes from draft-ietf-...-07 to
draft-ietf-...-08 . . . . . . . . . . . . . . . . . . . 65
B.11. Substantive changes from draft-ietf-...-06 to
draft-ietf-...-07 . . . . . . . . . . . . . . . . . . . 66
B.12. Substantive changes from draft-ietf-...-05 to
draft-ietf-...-06 . . . . . . . . . . . . . . . . . . . 66
B.13. Substantive changes from draft-ietf-...-04 to
draft-ietf-...-05 . . . . . . . . . . . . . . . . . . . 66
B.14. Substantive changes from draft-ietf-...-03 to
draft-ietf-...-04 . . . . . . . . . . . . . . . . . . . 66
B.15. Substantive changes from draft-ietf-...-02 to
draft-ietf-...-03 . . . . . . . . . . . . . . . . . . . 67
B.16. Substantive changes from draft-ietf-...-01 to
draft-ietf-...-02 . . . . . . . . . . . . . . . . . . . 67
B.17. Substantive changes from draft-ietf-...-00 to
draft-ietf-...-01 . . . . . . . . . . . . . . . . . . . 67
B.18. Substantive changes from draft-dkg-...-01 to
draft-ietf-...-00 . . . . . . . . . . . . . . . . . . . 67
B.19. Substantive changes from draft-dkg-...-00 to
draft-dkg-...-01 . . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction 1. Introduction
E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME End-to-end email security using S/MIME [RFC8551] and PGP/MIME (Pretty
([RFC3156]) cryptographic standards can provide integrity, Good Privacy with MIME) [RFC3156] cryptographic standards can provide
authentication and confidentiality to MIME ([RFC4289]) e-mail integrity, authentication, and confidentiality to MIME [RFC4289]
messages. email messages.
However, there are many ways that a receiving mail user agent can However, there are many ways that a receiving mail user agent can
misinterpret or accidentally break these security guarantees. For misinterpret or accidentally break these security guarantees. For
example, [EFAIL]'s "Direct Exfiltration" attack leaks cleartext due example, as described in [EFAIL], the "Direct Exfiltration" attack
to an attack that splices existing ciphertext into a new message, leaks cleartext due to an attack that splices existing ciphertext
which is then handled optimistically (and wrongly) by many mail user into a new message, which is then handled optimistically (and
agents. wrongly) by many mail user agents.
A mail user agent that interprets a message with end-to-end A mail user agent that interprets a message with end-to-end
cryptographic protections needs to do so defensively, staying alert cryptographic protections needs to do so defensively, staying alert
to different ways that these protections can be bypassed by mangling to different ways that these protections can be bypassed by mangling
(either malicious or accidental) or a failed user experience. (either malicious or accidental) or a failed user experience.
A mail user agent that generates a message with end-to-end A mail user agent that generates a message with end-to-end
cryptographic protections should be aware of these defensive cryptographic protections should be aware of these defensive
interpretation strategies, and should compose any new outbound interpretation strategies and should compose any new outbound message
message conservatively if they want the protections to remain intact. conservatively if they want the protections to remain intact.
This document offers guidance to the implementer of a mail user agent This document offers guidance to the implementer of a mail user agent
that provides these cryptographic protections, whether for sending or that provides these cryptographic protections, whether for sending or
receiving mail. An implementation that follows this guidance will receiving mail. An implementation that follows this guidance will
provide its users with stronger and easier-to-understand security provide its users with stronger and easier-to-understand security
properties, and will also offer more reliable interoperability for properties and will also offer more reliable interoperability for
messages exchanged with other implementations. messages exchanged with other implementations.
In Appendix A, this document also identifies a number of In Appendix A, this document also identifies a number of
interoperability and usability concerns for end-to-end cryptographic interoperability and usability concerns for end-to-end cryptographic
e-mail which have no current broadly accepted technical standard for email that have no current broadly accepted technical standard for
resolution. One major area not covered in this document is the resolution. One major area not covered in this document is the
acquisition and long-term maintenance of cryptographic identity acquisition and long-term maintenance of cryptographic identity
information and metadata across multiple mail user agents controlled information and metadata across multiple mail user agents controlled
by the same user. by the same user.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.1. Terminology 1.1. Terminology
For the purposes of this document, we define the following concepts: For the purposes of this document, we define the following concepts:
* _MUA_ is short for Mail User Agent; an e-mail client. * _MUA_ is short for Mail User Agent; an email client.
* _Protection_ of message data refers to cryptographic encryption * _Protection_ of message data refers to cryptographic encryption
and/or signatures, providing confidentiality, authenticity, and/or and/or signatures, providing confidentiality, authenticity, and/or
integrity. integrity.
* _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic * _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic
Payload_, _Cryptographic Summary_, and _Errant Cryptographic Payload_, _Cryptographic Summary_, and _Errant Cryptographic
Layer_ are defined in Section 4 Layer_ are defined in Section 4.
* A _well-formed_ e-mail message with cryptographic protection has * A _well-formed_ email message with cryptographic protection has
both a _Cryptographic Envelope_ and a _Cryptographic Payload_. both a _Cryptographic Envelope_ and a _Cryptographic Payload_.
* _Structural Header Fields_ are documented in Section 1.1.1. * _Structural Header Fields_ are documented in Section 1.1.1.
* _User-Facing Header Fields_ are documented in Section 1.1.2. * _User-Facing Header Fields_ are documented in Section 1.1.2.
* _Main Body Part_ is the part (or parts) that are typically * The _Main Body Part_ is the part (or parts) that is typically
rendered to the user as the message itself (not "as an rendered to the user as the message itself (not "as an
attachment"). See Section 7.1. attachment"). See Section 7.1.
This document contains extensive discussion about end-to-end This document contains extensive discussion about end-to-end
cryptographic protections in e-mail, while acknowledging that many cryptographic protections in email while acknowledging that many MUAs
MUAs have no capabilities for end-to-end cryptographic protections at have no capabilities for end-to-end cryptographic protections at all.
all. We divide MUAs into three distinct profiles: We divide MUAs into three distinct profiles:
* A _Non-cryptographic_ MUA has no capabilities for end-to-end * A _non-cryptographic_ MUA has no capabilities for end-to-end
cryptographic protections. cryptographic protections.
* A _Conformant_ MUA follows the guidance in this document when * A _conformant_ MUA follows the guidance in this document when
dealing with end-to-end cryptographic protections. dealing with end-to-end cryptographic protections.
* A _Legacy_ MUA has capabilities for end-to-end cryptographic * A _legacy_ MUA has capabilities for end-to-end cryptographic
protections, but does not adhere to the the guidance in this protections but does not adhere to the guidance in this document.
document.
At the time of the writing of this document, most MUAs with At the time of the writing of this document, most MUAs with
cryptographic protections are legacy MUAs. cryptographic protections are legacy MUAs.
1.1.1. Structural Header Fields 1.1.1. Structural Header Fields
A message header field named MIME-Version, or whose name begins with A message header field named MIME-Version, or whose name begins with
Content- is referred to in this document as a "structural" header Content-, is referred to in this document as a "structural" header
field. This is a less-ambiguous name for what [RFC2045] calls "MIME field. This is a less-ambiguous name for what [RFC2045] calls "MIME
Header Fields". header fields".
These header fields indicate something about the specific MIME part These header fields indicate something about the specific MIME part
they are attached to, and cannot be transferred or copied to other they are attached to and cannot be transferred or copied to other
parts without endangering the readability of the message. parts without endangering the readability of the message.
This includes: This includes:
* MIME-Version * MIME-Version
* Content-Type * Content-Type
* Content-Transfer-Encoding * Content-Transfer-Encoding
* Content-Disposition * Content-Disposition
1.1.2. User-Facing Header Fields 1.1.2. User-Facing Header Fields
Of all the header fields that an e-mail message may contain, only a Of all the header fields that an email message may contain, only a
handful are typically presented directly to the user. This document handful are typically presented directly to the user. This document
refers to them as "user-facing" header fields. Typically, user- refers to them as "user-facing" header fields. Typically, user-
facing header fields are: facing header fields are:
* Subject * Subject
* From * From
* To * To
skipping to change at page 8, line 38 skipping to change at line 297
* Resent-From * Resent-From
* Resent-To * Resent-To
* Resent-Cc * Resent-Cc
* Resent-Date * Resent-Date
* Resent-Sender * Resent-Sender
The above list are the header fields most often presented directly to The above list contains the header fields most often presented
the user who views a message, though an MUA may also decide to treat directly to the user who views a message, though an MUA may also
any other header field as "user-facing". Of course, many of these decide to treat any other header field as "user-facing". Of course,
header fields are entirely absent from any given message, and an many of these header fields are entirely absent from any given
absent header field is not presented to the user at all. message, and an absent header field is not presented to the user at
all.
Note that the resending header fields (those beginning with Resent-) Note that the resending header fields (those beginning with Resent-)
are typically only added by an intervening MUA (see Section 3.6.6 of are typically only added by an intervening MUA (see Section 3.6.6 of
[RFC5322] and Section 9.8 of this document). As such, though they [RFC5322] and Section 9.8 of this document). As such, though they
may in some cases be presented to the user, they will typically not may in some cases be presented to the user, they will typically not
bear any end-to-end cryptographic protection (even if the original bear any end-to-end cryptographic protection (even if the original
header fields of a message are protected, see Section 9.3), because header fields of a message are protected; see Section 9.3), because
they are unknown to the original sender. they are unknown to the original sender.
Other header fields may affect the visible rendering of the message Other header fields may affect the visible rendering of the message
(e.g., References and In-Reply-To may affect the placement of a (e.g., References and In-Reply-To may affect the placement of a
message in a threaded discussion; or the List-* and Archived-At message in a threaded discussion, or the List-* and Archived-At
header fields added by mailing lists may cause additional buttons to header fields added by mailing lists may cause additional buttons to
be displayed during rendering), but they are not directly displayed be displayed during rendering), but they are not directly displayed
to the user and so are not considered "user-facing". to the user and so are not considered "user-facing".
2. Usability 2. Usability
Any MUA that enables its user to transition from unprotected messages Any MUA that enables its user to transition from unprotected messages
to messages with end-to-end cryptographic protection needs to to messages with end-to-end cryptographic protection needs to
consider how the user understands this transition. That said, the consider how the user understands this transition. That said, the
primary goal of the user of an MUA is communication -- so interface primary goal of the user of an MUA is communication -- so interface
elements that interfere with communication should be avoided where elements that interfere with communication should be avoided where
possible. possible.
Furthermore, it is a near certainty that the user will continue to Furthermore, it is a near certainty that the user will continue to
encounter unprotected messages, and may need to send unprotected encounter unprotected messages and may need to send unprotected
messages (for example, if a given recipient cannot handle messages (for example, if a given recipient cannot handle
cryptographic protections). This means that the MUA needs to provide cryptographic protections). This means that the MUA needs to provide
the user with some guidance, so that they understand what protections the user with some guidance so that they understand what protections
any given message or conversation has. But the user should not be any given message or conversation has. But the user should not be
overwhelmed with choices or presented with unactionable information. overwhelmed with choices or presented with unactionable information.
2.1. Simplicity 2.1. Simplicity
The end user (the operator of the MUA) is unlikely to understand The end user (the operator of the MUA) is unlikely to understand
complex end-to-end cryptographic protections on any e-mail message, complex end-to-end cryptographic protections on any email message, so
so keep it simple. keep it simple.
For clarity to the user, any cryptographic protections should apply For clarity to the user, any cryptographic protections should apply
to the message as a whole, not just to some subparts. to the message as a whole, not just to some subparts.
This is true for message composition: the standard message This is true for message composition: The standard message
composition user interface of an MUA should offer minimal controls composition user interface of an MUA should offer minimal controls
which indicate which types of protection to apply to the new message that indicate which types of protection to apply to the new message
as a whole. as a whole.
This is also true for message interpretation: the standard message This is also true for message interpretation: The standard message
rendering user interface of an MUA should offer a minimal, clear rendering user interface of an MUA should offer a minimal, clear
indicator about the end-to-end cryptographic status of the message as indicator about the end-to-end cryptographic status of the message as
a whole. a whole.
See Section 3 for more detail about mental models and cryptographic See Section 3 for more details about mental models and cryptographic
status. status.
(It is of course possible that a message forwarded as a MIME (It is of course possible that a message forwarded as a MIME
attachment could have its own cryptographic status while still being attachment could have its own cryptographic status while still being
a message subpart; but that status should be distinct from the status a message subpart, but that status should be distinct from the status
of the enclosing message.) of the enclosing message.)
2.2. E-mail Users Want a Familiar Experience 2.2. Email Users Want a Familiar Experience
A person communicating over the Internet today often has many options A person communicating over the Internet today often has many options
for reaching their desired correspondent, including web-based for reaching their desired correspondent, including web-based
bulletin boards, contact forms, and instant messaging services. bulletin boards, contact forms, and instant messaging services.
E-mail offers a few distinctions from these other systems, most Email offers a few distinctions from these other systems, most
notably features like: notably features like:
* Ubiquity: Most correspondents will have an e-mail address, while Ubiquity: Most correspondents will have an email address, while not
not everyone is present on the various non-e-mail messaging everyone is present on the various non-email messaging services,
services, particularly those that have reliable end-to-end particularly those that have reliable end-to-end cryptographic
cryptographic protections, protections.
* Federation: interaction between users on distinct domains who have Federation: Interaction between users on distinct domains who have
not agreed on a common communications provider is still possible, not agreed on a common communications provider is still possible.
and
* User Control: the user can interact with the e-mail system using User Control: The user can interact with the email system using an
an MUA of their choosing, including automation and other control MUA of their choosing, including automation and other control over
over their preferred and/or customized workflow. their preferred and/or customized workflow.
Other systems (like some popular instant messaging applications, such Other systems (like some popular instant messaging applications, such
as WhatsApp and Signal Private Messenger) offer built-in end-to-end as WhatsApp and Signal Private Messenger) offer built-in end-to-end
cryptographic protections by default, which are simpler for the user cryptographic protections by default, which are simpler for the user
to understand. ("All the messages I see on Signal are confidential to understand. ("All the messages I see on Signal are confidential
and integrity-protected" is a clean user story) and integrity-protected" is a clean user story.)
A user of e-mail is likely using e-mail instead of other systems A user of email is likely using email instead of other systems
because of the distinctions outlined above. When adding end-to-end because of the distinctions outlined above. When adding end-to-end
cryptographic protection to an e-mail endpoint, care should be taken cryptographic protection to an email endpoint, care should be taken
not to negate any of the distinct features of e-mail as a whole. If not to negate any of the distinct features of email as a whole. If
these features are violated to provide end-to-end crypto, the user these features are violated to provide end-to-end crypto, the user
may just as well choose one of the other systems that don't have the may just as well choose one of the other systems that don't have the
drawbacks that e-mail has. Implementers should try to provide end- drawbacks that email has. Implementers should try to provide end-to-
to-end protections that retain the familiar experience of e-mail end protections that retain the familiar experience of email itself.
itself.
Furthermore, an e-mail user is likely to regularly interact with Furthermore, an email user is likely to regularly interact with other
other e-mail correspondents who _cannot_ handle or produce end-to-end email correspondents who _cannot_ handle or produce end-to-end
cryptographic protections. Care should be taken that enabling cryptographic protections. Care should be taken that enabling
cryptography in an MUA does not inadvertently limit the ability of cryptography in an MUA does not inadvertently limit the ability of
the user to interact with correspondents who use legacy or non- the user to interact with correspondents who use legacy or non-
cryptographic MUAs. cryptographic MUAs.
2.3. Warning About Failure vs. Announcing Success 2.3. Warning About Failure vs. Announcing Success
Moving the web from http to https offers useful historical Moving the Web from http to https offers useful historical
similarities to adding end-to-end encryption to e-mail. similarities to adding end-to-end encryption to email.
In particular, the indicators of what is "secure" vs. "insecure" for In particular, the indicators of what is "secure" vs. "insecure" for
web browsers have changed over time. For example, years ago the web browsers have changed over time. For example, years ago, the
default experience was http, and https sites were flagged with default experience was http, and https sites were flagged with
"secure" indicators like a lock icon. Starting in 2018, some "secure" indicators like a lock icon. Starting in 2018, some
browsers reversed that process by downplaying https, and instead browsers reversed that process by downplaying https and instead
visibly marking http as "not secure" (see [chrome-indicators]). visibly marking http as "not secure" (see [CHROME-INDICATORS]).
By analogy, when the user of an MUA first enables end-to-end By analogy, when the user of an MUA first enables end-to-end
cryptographic protection, it's likely that they will want to see cryptographic protection, it's likely that they will want to see
which messages _have_ protection (that is, the security indicators which messages _have_ protection (that is, the security indicators
amenable to a conformant MUA as of 2024 are most likely to be amenable to a conformant MUA as of 2024 are most likely to be
comparable to those of a pre-2018 web browser). But a user whose comparable to those of a pre-2018 web browser). But a user whose
private e-mail communications with a given correspondent, or within a private email communications with a given correspondent, or within a
given domain are known to be entirely end-to-end protected might given domain, are known to be entirely end-to-end protected might
instead want to know which messages do _not_ have the expected instead want to know which messages do _not_ have the expected
protections. protections.
Note also that some messages may be expected to be confidential, but Note also that some messages may be expected to be confidential, but
other messages are expected to be public -- the types of protection other messages are expected to be public -- the types of protection
(see Section 3) that apply to each particular message will be (see Section 3) that apply to each particular message will be
different. And the types of protection that are _expected_ to be different. And the types of protection that are _expected_ to be
present in any context might differ (for example, by sender, by present in any context might differ (for example, by sender, by
thread, or by date). thread, or by date).
It is out of scope for this document to define expectations about It is out of scope for this document to define expectations about
protections for any given message, but an implementer who cares about protections for any given message, but an implementer who cares about
usable experience should be deliberate and judicious about the usable experience should be deliberate and judicious about the
expectations their interface assumes that the user has in a given expectations their interface assumes that the user has in a given
context. See also Appendix A.9 for future work. context. See Appendix A.9 for future work.
3. Types of Protection 3. Types of Protection
A given message might be: A given message might be:
* signed, * signed,
* encrypted, * encrypted,
* both signed and encrypted, or * both signed and encrypted, or
* none of the above. * none of the above.
Given that many e-mail messages offer no cryptographic protections, Given that many email messages offer no cryptographic protections,
the user needs to be able to detect which protections are present for the user needs to be able to detect which protections are present for
any given message. any given message.
3.1. Simplified Mental Model 3.1. Simplified Mental Model
To the extent that an e-mail message actually does have end-to-end To the extent that an email message actually does have end-to-end
cryptographic protections, those protections need to be visible and cryptographic protections, those protections need to be visible and
comprehensible to the end users: both the sending user and the comprehensible to the end users: both the sending user and the
receiving user. If either user is unaware of the protections, then receiving user. If either user is unaware of the protections, then
they do not effectively extend all the way to the "end". they do not effectively extend all the way to the "end".
However, most users do not have (or want to have) a sophisticated However, most users do not have (or want to have) a sophisticated
mental model of what kinds of protections can be associated with a mental model of what kinds of protections can be associated with a
given message. Even the four states above approach the limits of given message. Even the four states above approach the limits of
complexity for an interface for normal users. complexity for an interface for normal users.
skipping to change at page 12, line 40 skipping to change at line 483
A simple model for the receiving user could be that a message is in A simple model for the receiving user could be that a message is in
one of three normal states, which align with the only reasonable one of three normal states, which align with the only reasonable
choices for message composition: choices for message composition:
* Unprotected * Unprotected
* Verified (has a valid signature from the apparent sender of the * Verified (has a valid signature from the apparent sender of the
message) message)
* Confidential (meaning, encrypted, with a valid signature from the * Confidential (encrypted with a valid signature from the apparent
apparent sender of the message) sender of the message)
However, one error state exists for received mail that does not However, one error state exists for received mail that does not
correspond to a reasonable choice for message composition: correspond to a reasonable choice for message composition:
* Encrypted But Unverified (meaning, encrypted without a valid * Encrypted But Unverified (encrypted without a valid signature from
signature from the apparent sender of the message) the apparent sender of the message)
Note that this last state is not "Confidential" (a secret shared Note that this last state is not "Confidential" (a secret shared
exclusively between the participants in the communication) because exclusively between the participants in the communication) because
the recipient does not know for sure who sent it. the recipient does not know for sure who sent it.
In an ecosystem where encrypted-only messages are never deliberately In an ecosystem where encrypted-only messages are never deliberately
sent (see Section 5.3), representing an Encrypted But Unverified sent (see Section 5.3), representing an Encrypted But Unverified
message as a type of user-visible error is not unreasonable. message as a type of user-visible error is not unreasonable.
However, this is not the state of the global e-mail ecosystem when However, this is not the state of the global email ecosystem when
this document was written, since some legacy MUAs permit sending this document was written, since some legacy MUAs permit sending
encrypted-but-unsigned mail (see Appendix A.9 for possible future encrypted-but-unsigned mail (see Appendix A.9 for possible future
guidance). guidance).
Alternately, an MUA may prefer to represent the state of a Encrypted Alternately, an MUA may prefer to represent the state of an Encrypted
but Unverified message to the user as though it was Unprotected, but Unverified message to the user as though it was Unprotected since
since no verification is possible. However the MUA represents the no verification is possible. However, the MUA represents the message
message to the user, though, it MUST NOT leak cleartext of an to the user, though it MUST NOT leak cleartext of an encrypted
encrypted message (even an Encrypted but Unverified message) in message (even an Encrypted but Unverified message) in subsequent
subsequent replies (see Section 5.4) or similar replications of the replies (see Section 5.4) or similar replications of the message.
message.
Note that a cleartext message with an invalid signature SHOULD NOT be Note that a cleartext message with an invalid signature SHOULD NOT be
represented to the user as anything other than Unprotected (see represented to the user as anything other than Unprotected (see
Section 6.4), unless the MUA is providing the user with debugging Section 6.4) unless the MUA is providing the user with debugging
information. information.
At the time this document was written, the global e-mail ecosystem At the time this document was written, the global email ecosystem
contains a heterogeneous mix of legacy and non-cryptographic MUAs. contains a heterogeneous mix of legacy and non-cryptographic MUAs.
In such an ecosystem, a conformant MUA may prefer instead to In such an ecosystem, a conformant MUA may instead prefer to
represent "Verified" and "Encrypted" as orthogonal states of any represent "Verified" and "Encrypted" as orthogonal states of any
given received message. While this model does not precisely match given received message. While this model does not precisely match
the choice a user makes when composing a message, it may align more the choice a user makes when composing a message, it may align more
with the reality of the range of messages they receive. with the reality of the range of messages they receive.
3.2. One Cryptographic Status Per Message 3.2. One Cryptographic Status per Message
Some MUAs may attempt to generate multiple copies of a given e-mail Some MUAs may attempt to generate multiple copies of a given email
message, with different copies offering different types of protection message, with different copies offering different types of protection
(for example, opportunistically encrypting on a per-recipient basis). (for example, opportunistically encrypting on a per-recipient basis).
A message resulting from this approach will have a cryptographic A message resulting from this approach will have a cryptographic
state that few users will understand. Even if the sender understands state that few users will understand. Even if the sender understands
the different statuses of the different copies, the recipients of the the different statuses of the different copies, the recipients of the
messages may not understand (each recipient might not even know about messages may not understand (each recipient might not even know about
the other copies). See for example the discussion in Section 9.6 for the other copies). See, for example, the discussion in Section 9.6
how this can go wrong. for how this can go wrong.
For comprehensibility, a conformant MUA SHOULD NOT create multiple For comprehensibility, a conformant MUA SHOULD NOT create multiple
copies of a given message that differ in the types of end-to-end copies of a given message that differ in the types of end-to-end
cryptographic protections afforded. cryptographic protections afforded.
For opportunistic cryptographic protections that are not surfaced to For opportunistic cryptographic protections that are not surfaced to
the user (that is, that are not end-to-end), other mechanisms like the user (that is, that are not end-to-end), other mechanisms like
transport encryption ([RFC3207]) or domain-based signing ([RFC6376]) transport encryption [RFC3207] or domain-based signing [RFC6376] may
may be preferable due to ease of implementation and deployment. be preferable due to ease of implementation and deployment. These
These opportunistic transport protections are orthogonal to the end- opportunistic transport protections are orthogonal to the end-to-end
to-end protections described in this document. protections described in this document.
To the extent that opportunistic message protections are made visible To the extent that opportunistic message protections are made visible
to the user for a given copy of a message, a conformant MUA will to the user for a given copy of a message, a conformant MUA will
distinguish that status from the message's end-to-end cryptographic distinguish that status from the message's end-to-end cryptographic
status. But the potential confusion caused by rendering this status. But the potential confusion caused by rendering this
complex, hybrid state may not be worth the value of additional complex, hybrid state may not be worth the value of additional
knowledge gained by the user. The benefits of opportunistic knowledge gained by the user. The benefits of opportunistic
protections accrue (or don't) even without visibility to the user protections accrue (or don't) even without visibility to the user
(see [RFC7435]). (see [RFC7435]).
The user needs a single clear, simple, and correct indication about The user needs a single clear, simple, and correct indication about
the end-to-end cryptographic status of any given message. See the end-to-end cryptographic status of any given message. See
Section 4.6 for more details. Section 4.6 for more details.
4. Cryptographic MIME Message Structure 4. Cryptographic MIME Message Structure
Implementations use the structure of an e-mail message to establish Implementations use the structure of an email message to establish
(when sending) and understand (when receiving) the cryptographic (when sending) and understand (when receiving) the cryptographic
status of the message. This section establishes some conventions status of the message. This section establishes some conventions
about how to think about message structure. about how to think about message structure.
4.1. Cryptographic Layers 4.1. Cryptographic Layers
"Cryptographic Layer" refers to a MIME substructure that supplies "Cryptographic Layer" refers to a MIME substructure that supplies
some cryptographic protections to an internal MIME subtree. The some cryptographic protections to an internal MIME subtree. The
internal subtree is known as the "protected part" though of course it internal subtree is known as the "protected part", though of course
may itself be a multipart object. it may itself be a multipart object.
In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7) In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7)
indicates "decrypts to", and "⇩" (DOWNWARDS WHITE ARROW, U+21E9) indicates "decrypts to" and "⇩" (DOWNWARDS WHITE ARROW, U+21E9)
indicates "unwraps to". indicates "unwraps to".
4.1.1. S/MIME Cryptographic Layers 4.1.1. S/MIME Cryptographic Layers
For S/MIME [RFC8551], there are four forms of Cryptographic Layers: For S/MIME [RFC8551], there are four forms of Cryptographic Layers:
multipart/signed, PKCS #7 signed-data, PKCS #7 enveloped-data, PKCS multipart/signed, PKCS #7 signed-data, PKCS #7 enveloped-data, and
#7 authEnveloped-data. PKCS #7 authEnveloped-data.
4.1.1.1. S/MIME Multipart Signed Cryptographic Layer 4.1.1.1. S/MIME Multipart Signed Cryptographic Layer
└┬╴multipart/signed; protocol="application/pkcs7-signature" └┬╴multipart/signed; protocol="application/pkcs7-signature"
├─╴[protected part] ├─╴[protected part]
└─╴application/pkcs7-signature └─╴application/pkcs7-signature
This MIME layer offers authentication and integrity. This MIME layer offers authentication and integrity.
4.1.1.2. S/MIME PKCS #7 signed-data Cryptographic Layer 4.1.1.2. S/MIME PKCS #7 signed-data Cryptographic Layer
skipping to change at page 15, line 30 skipping to change at line 617
4.1.1.4. S/MIME PKCS #7 authEnveloped-data Cryptographic Layer 4.1.1.4. S/MIME PKCS #7 authEnveloped-data Cryptographic Layer
└─╴application/pkcs7-mime; smime-type="authEnveloped-data" └─╴application/pkcs7-mime; smime-type="authEnveloped-data"
↧ (decrypts to) ↧ (decrypts to)
└─╴[protected part] └─╴[protected part]
This MIME layer offers confidentiality and integrity. This MIME layer offers confidentiality and integrity.
Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data
(Section 4.1.1.4) have identical message structure and very similar (Section 4.1.1.4) have identical message structures and very similar
confidentiality semantics. The only difference between the two is confidentiality semantics. The only difference between the two is
ciphertext malleability. ciphertext malleability.
The examples in this document only include enveloped-data, but the The examples in this document only include enveloped-data, but the
implications for that layer apply to authEnveloped-data as well. implications for that layer apply to authEnveloped-data as well.
4.1.1.5. PKCS #7 Compression is NOT a Cryptographic Layer 4.1.1.5. PKCS #7 Compression is NOT a Cryptographic Layer
The Cryptographic Message Syntax (CMS) provides a MIME compression The Cryptographic Message Syntax (CMS) provides a MIME compression
layer (smime-type="compressed-data"), as defined in [RFC3274]. While layer (smime-type="compressed-data"), as defined in [RFC3274]. While
the compression layer is technically a part of CMS, it is not the compression layer is technically a part of CMS, it is not
considered a Cryptographic Layer for the purposes of this document. considered a Cryptographic Layer for the purposes of this document.
4.1.2. PGP/MIME Cryptographic Layers 4.1.2. PGP/MIME Cryptographic Layers
For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers, For PGP/MIME [RFC3156], there are two forms of Cryptographic Layers:
signing and encryption. signing and encryption.
4.1.2.1. PGP/MIME Signing Cryptographic Layer (multipart/signed) 4.1.2.1. PGP/MIME Signing Cryptographic Layer (multipart/signed)
└┬╴multipart/signed; protocol="application/pgp-signature" └┬╴multipart/signed; protocol="application/pgp-signature"
├─╴[protected part] ├─╴[protected part]
└─╴application/pgp-signature └─╴application/pgp-signature
This MIME layer offers authenticity and integrity. This MIME layer offers authenticity and integrity.
4.1.2.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted) 4.1.2.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted)
└┬╴multipart/encrypted └┬╴multipart/encrypted
├─╴application/pgp-encrypted ├─╴application/pgp-encrypted
└─╴application/octet-stream └─╴application/octet-stream
↧ (decrypts to) ↧ (decrypts to)
└─╴[protected part] └─╴[protected part]
This MIME layer can offer any of: This MIME layer can offer:
* confidentiality (via a Symmetrically Encrypted Data Packet, see * confidentiality (via a Symmetrically Encrypted Data packet, see
Section 5.7 of [RFC9580]; an MUA MUST NOT generate this form due Section 5.7 of [RFC9580]; an MUA MUST NOT generate this form due
to ciphertext malleability) to ciphertext malleability),
* confidentiality and integrity (via a Symmetrically Encrypted * confidentiality and integrity (via a Symmetrically Encrypted and
Integrity Protected Data Packet (SEIPD), see Section 5.13 of Integrity Protected Data Packet (SEIPD); see Section 5.13 of
[RFC9580]), or [RFC9580]), or
* confidentiality, integrity, and authenticity all together (by * confidentiality, integrity, and authenticity all together (by
including an OpenPGP Signature Packet within the SEIPD). including an OpenPGP Signature Packet within the SEIPD).
4.2. Cryptographic Envelope 4.2. Cryptographic Envelope
The Cryptographic Envelope is the largest contiguous set of The Cryptographic Envelope is the largest contiguous set of
Cryptographic Layers of an e-mail message starting with the outermost Cryptographic Layers of an email message starting with the outermost
MIME type (that is, with the Content-Type of the message itself). MIME type (that is, with the Content-Type of the message itself).
If the Content-Type of the message itself is not a Cryptographic If the Content-Type of the message itself is not a Cryptographic
Layer, then the message has no cryptographic envelope. Layer, then the message has no cryptographic envelope.
"Contiguous" in the definition above indicates that if a "Contiguous" in the definition above indicates that if a
Cryptographic Layer is the protected part of another Cryptographic Cryptographic Layer is the protected part of another Cryptographic
Layer, the layers together comprise a single Cryptographic Envelope. Layer, the layers together comprise a single Cryptographic Envelope.
Note that if a non-Cryptographic Layer intervenes, all Cryptographic Note that if a non-Cryptographic Layer intervenes, all Cryptographic
Layers within the non-Cryptographic Layer _are not_ part of the Layers within the non-Cryptographic Layer _are not_ part of the
Cryptographic Envelope. They are Errant Cryptographic Layers (see Cryptographic Envelope. They are Errant Cryptographic Layers (see
Section 4.5). Section 4.5).
Note also that the ordering of the Cryptographic Layers implies Also note that the ordering of the Cryptographic Layers implies
different cryptographic properties. A signed-then-encrypted message different cryptographic properties. A signed-then-encrypted message
is different than an encrypted-then-signed message. See Section 5.2. is different than an encrypted-then-signed message. See Section 5.2.
4.3. Cryptographic Payload 4.3. Cryptographic Payload
The Cryptographic Payload of a message is the first non-Cryptographic The Cryptographic Payload of a message is the first non-Cryptographic
Layer -- the "protected part" -- within the Cryptographic Envelope. Layer -- the "protected part" -- within the Cryptographic Envelope.
4.4. Types of Cryptographic Envelope 4.4. Types of Cryptographic Envelope
4.4.1. Simple Cryptographic Envelopes 4.4.1. Simple Cryptographic Envelopes
As described above, if the "protected part" identified in the section As described above, if the "protected part" identified in the section
above is not itself a Cryptographic Layer, that part _is_ the above is not itself a Cryptographic Layer, that part _is_ the
Cryptographic Payload. Cryptographic Payload.
If the application wants to generate a message that is both encrypted 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 and signed, it MAY use the simple MIME structure from Section 4.1.2.2
by ensuring that the [RFC9580] Encrypted Message within the by ensuring that the Encrypted Message [RFC9580] within the
application/octet-stream part contains an [RFC9580] Signed Message application/octet-stream part contains a Signed Message [RFC9580]
(the final option described in Section 4.1.2.2). (the final option described in Section 4.1.2.2).
4.4.2. Multilayer Cryptographic Envelopes 4.4.2. Multilayer Cryptographic Envelopes
It is possible to construct a Cryptographic Envelope consisting of It is possible to construct a Cryptographic Envelope consisting of
multiple layers with either S/MIME or PGP/MIME , for example using multiple layers with either S/MIME or PGP/MIME, for example, using
the following structure: the following structure:
A └─╴application/pkcs7-mime; smime-type="enveloped-data" A └─╴application/pkcs7-mime; smime-type="enveloped-data"
B ↧ (decrypts to) B ↧ (decrypts to)
C └─╴application/pkcs7-mime; smime-type="signed-data" C └─╴application/pkcs7-mime; smime-type="signed-data"
D ⇩ (unwraps to) D ⇩ (unwraps to)
E └─╴[protected part] E └─╴[protected part]
When handling such a message, the properties of the Cryptographic When handling such a message, the properties of the Cryptographic
Envelope are derived from the series A, C. Envelope are derived from the series A and C.
As noted in Section 4.4.1, PGP/MIME applications also have a simpler As noted in Section 4.4.1, PGP/MIME applications also have a simpler
MIME construction available with the same cryptographic properties. MIME construction available with the same cryptographic properties.
4.5. Errant Cryptographic Layers 4.5. Errant Cryptographic Layers
Due to confusion, malice, or well-intentioned tampering, a message Due to confusion, malice, or well-intentioned tampering, a message
may contain a Cryptographic Layer that is not part of the may contain a Cryptographic Layer that is not part of the
Cryptographic Envelope. Such a layer is an Errant Cryptographic Cryptographic Envelope. Such a layer is an Errant Cryptographic
Layer. Layer.
An Errant Cryptographic Layer MUST NOT contribute to the message's An Errant Cryptographic Layer MUST NOT contribute to the message's
overall cryptographic state. overall cryptographic state.
Guidance for dealing with Errant Cryptographic Layers can be found in Guidance for dealing with Errant Cryptographic Layers can be found in
Section 6.2. Section 6.2.
4.5.1. Mailing List Wrapping 4.5.1. Mailing List Wrapping
Some mailing list software will re-wrap a well-formed signed message Some mailing list software will rewrap a well-formed signed message
before re-sending to add a footer, resulting in the following before resending to add a footer, resulting in the following
structure seen by recipients of the e-mail: structure seen by recipients of the email:
H └┬╴multipart/mixed H └┬╴multipart/mixed
I ├┬╴multipart/signed I ├┬╴multipart/signed
J │├─╴text/plain J │├─╴text/plain
K │└─╴application/pgp-signature K │└─╴application/pgp-signature
L └─╴text/plain L └─╴text/plain
In this message, L is the footer added by the mailing list. I is now In this message, L is the footer added by the mailing list. I is now
an Errant Cryptographic Layer. an Errant Cryptographic Layer.
Note that this message has no Cryptographic Envelope at all. Note that this message has no Cryptographic Envelope at all.
It is NOT RECOMMENDED to produce e-mail messages with this structure, 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 because a legacy MUA may present the data in part L as though it were
part of J, though they have different cryptographic properties. In part of J, though they have different cryptographic properties. In
particular, if the user believes that the entire message is signed, particular, if the user believes that the entire message is signed
but cannot distinguish L from J then the author of L can effectively but cannot distinguish L from J, then the author of L can effectively
tamper with content of the signed message, breaking the user's tamper with content of the signed message, breaking the user's
expectation of integrity and authenticity. expectation of integrity and authenticity.
4.5.2. A Baroque Example 4.5.2. A Baroque Example
Consider a message with the following overcomplicated structure: Consider a message with the following overcomplicated structure:
M └┬╴multipart/encrypted M └┬╴multipart/encrypted
N ├─╴application/pgp-encrypted N ├─╴application/pgp-encrypted
O └─╴application/octet-stream O └─╴application/octet-stream
P ↧ (decrypts to) P ↧ (decrypts to)
Q └┬╴multipart/signed Q └┬╴multipart/signed
R ├┬╴multipart/mixed R ├┬╴multipart/mixed
S │├┬╴multipart/signed S │├┬╴multipart/signed
T ││├─╴text/plain T ││├─╴text/plain
U ││└─╴application/pgp-signature U ││└─╴application/pgp-signature
V │└─╴text/plain V │└─╴text/plain
W └─╴application/pgp-signature W └─╴application/pgp-signature
The 3 Cryptographic Layers in such a message are rooted in parts M,
Q, and S. But the Cryptographic Envelope of the message consists The three Cryptographic Layers in such a message are rooted in parts
only of the properties derived from the series M, Q. The 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 Payload of the message is part R. Part S is an Errant
Cryptographic Layer. Cryptographic Layer.
Note that this message has both a Cryptographic Envelope _and_ an Note that this message has both a Cryptographic Envelope _and_ an
Errant Cryptographic Layer. Errant Cryptographic Layer.
It is NOT RECOMMENDED to generate messages with such complicated It is NOT RECOMMENDED to generate messages with such complicated
structures. Even if a receiving MUA can parse this structure structures. Even if a receiving MUA can parse this structure
properly, it is nearly impossible to render in a way that the user properly, it is nearly impossible to render in a way that the user
can reason about the cryptographic properties of part T compared to can reason about the cryptographic properties of part T compared to
part V. part V.
4.6. Cryptographic Summary 4.6. Cryptographic Summary
The cryptographic status of an e-mail message with end-to-end The cryptographic status of an email message with end-to-end
cryptographic protections is known as the Cryptographic Summary. A cryptographic protections is known as the Cryptographic Summary. A
reasonable, simple Cryptographic Summary is derived from the reasonable, simple Cryptographic Summary is derived from the
aggregate properties of the layers in the Cryptographic Envelope. aggregate properties of the layers in the Cryptographic Envelope.
This is a conceptual tool and a feature that an MUA can use to guide This is a conceptual tool and a feature that an MUA can use to guide
behavior and user experience, but it is not necessarily always behavior and user experience, but it is not necessarily always
directly exposed in any given user interface. See Section 6.1 for directly exposed in any given user interface. See Section 6.1 for
guidance and considerations about rendering the Cryptographic Summary guidance and considerations about rendering the Cryptographic Summary
to the user. to the user.
5. Message Composition 5. Message Composition
This section describes the ideal composition of an e-mail message This section describes the ideal composition of an email message with
with end-to-end cryptographic protection. A message composed with end-to-end cryptographic protection. A message composed with this
this form is most likely to achieve its end-to-end security goals. form is most likely to achieve its end-to-end security goals.
5.1. Message Composition Algorithm 5.1. Message Composition Algorithm
This section describes the steps that an MUA should use to compose a This section describes the steps that an MUA should use to compose a
cryptographically-protected message, such that it has a proper cryptographically protected message, such that it has a proper
Cryptographic Envelope and Payload. Cryptographic Envelope and Payload.
The message composition algorithm takes three parameters: The message composition algorithm takes three parameters:
* origbody: the traditional unprotected message body as a well- origbody: The traditional unprotected message body as a well-formed
formed MIME tree (possibly just a single MIME leaf part). As a MIME tree (possibly just a single MIME leaf part). As a well-
well-formed MIME tree, origbody already has structural header formed MIME tree, origbody already has structural header fields
fields present (see Section 1.1.1). present (see Section 1.1.1).
* origheaders: the intended non-structural header fields for the origheaders: The intended non-structural header fields for the
message, represented here as a list of (h,v) pairs, where h is a message, represented here as a list of (h,v) pairs, where h is a
header field name and v is the associated value. header field name and v is the associated value.
* crypto: The series of cryptographic protections to apply (for crypto: The series of cryptographic protections to apply (for
example, "sign with the secret key corresponding to X.509 example, "sign with the secret key corresponding to X.509
certificate X, then encrypt to X.509 certificates X and Y"). This certificate X, then encrypt to X.509 certificates X and Y"). This
is a routine that accepts a MIME tree as input (the Cryptographic is a routine that accepts a MIME tree as input (the Cryptographic
Payload), wraps the input in the appropriate Cryptographic Payload), wraps the input in the appropriate Cryptographic
Envelope, and returns the resultant MIME tree as output. Envelope, and returns the resultant MIME tree as output.
The algorithm returns a MIME object that is ready to be injected into The algorithm returns a MIME object that is ready to be injected into
the mail system: the mail system:
1. Apply crypto to origbody, yielding MIME tree output 1. Apply crypto to origbody, yielding MIME tree output.
2. For each header name and value (h,v) in origheaders: 2. For each header name and value (h,v) in origheaders:
a. Add header h to output with value v a. Add header h to output with value v.
3. Return output 3. Return output.
This is the traditional algorithm. It only protects the structural This is the traditional algorithm. It only protects the structural
Header Fields of the message body, and leaves non-structural header fields of the message body and leaves non-structural
(including user-facing) Header Fields unprotected. (including user-facing) header fields unprotected.
Therefore, a conformant MUA MUST implement Header Protection as Therefore, a conformant MUA MUST implement Header Protection as
described in [I-D.ietf-lamps-header-protection] (see Section 9.3). described in [RFC9788] (see Section 9.3).
5.2. Encryption Outside, Signature Inside 5.2. Encryption Outside, Signature Inside
An e-mail message that is both signed and encrypted is signed An email message that is both signed and encrypted is signed _inside_
_inside_ the encryption, and not the other way around. For example, the encryption and not the other way around. For example, when
when crafting an encrypted and signed message using a simple crafting an encrypted and signed message using a simple Cryptographic
Cryptographic Envelope of a single layer (Section 4.4.1) with PGP/ Envelope of a single layer (Section 4.4.1) with PGP/MIME, the OpenPGP
MIME, the OpenPGP Encrypted Message object should contain an OpenPGP Encrypted Message object should contain an OpenPGP Signed Message.
Signed Message. Likewise, when using a multilayer Cryptographic Likewise, when using a multilayer Cryptographic Envelope
Envelope (Section 4.4.2), the outer layer should be an encryption (Section 4.4.2), the outer layer should be an encryption layer and
layer and the inner layer should be a signing layer. the inner layer should be a signing layer.
Putting the signature inside the encryption has two advantages: Putting the signature inside the encryption has two advantages:
* The details of the signature remain confidential, visible only to * The details of the signature remain confidential, visible only to
the parties capable of decryption. the parties capable of decryption.
* Any mail transport agent that modifies the message is unlikely to * Any mail transport agent that modifies the message is unlikely to
be able to accidentally break the signature. be able to accidentally break the signature.
A conformant MUA MUST NOT generate an encrypted and signed message A conformant MUA MUST NOT generate an encrypted and signed message
where the only signature is outside the encryption. where the only signature is outside the encryption.
5.3. Avoid Offering Encrypted-only Messages 5.3. Avoid Offering Encrypted-Only Messages
When generating an e-mail, there are four options for applying end- When generating an email, there are four options for applying end-to-
to-end cryptographic protections: end cryptographic protections:
* Unprotected: In some cases, offering any end-to-end cryptographic * Unprotected: In some cases, offering any end-to-end cryptographic
protection is harmful: it may confuse the recipient and offer no protection is harmful: It may confuse the recipient and offer no
benefit. benefit.
* Signed-only: In other cases, signing a message is useful * Signed-only: In other cases, signing a message is useful
(authenticity and integrity are desirable) but encryption is (authenticity and integrity are desirable), but encryption is
either impossible (for example, if the sender does not know how to either impossible (for example, if the sender does not know how to
encrypt to all recipients) or meaningless (for example, an e-mail encrypt to all recipients) or meaningless (for example, an email
message to a mailing list that is intended to be published to a message to a mailing list that is intended to be published to a
public archive). public archive).
* Signed-and-Encryped: In other cases, full end-to-end * Signed-and-Encrypted: In other cases, full end-to-end
confidentiality, authenticity, and integrity are desirable. confidentiality, authenticity, and integrity are desirable.
* Encrypted-only: There is no common use case for generating an * Encrypted-only: There is no common use case for generating an
e-mail message with end-to-end confidentiality but without email message with end-to-end confidentiality but without
authenticity or integrity. authenticity or integrity.
- Additionally, some encryption schemes are malleable. This - Additionally, some encryption schemes are malleable. This
allows an attacker to tamper with the plaintext by modifying allows an attacker to tamper with the plaintext by modifying
the ciphertext (i.e., without decrypting it). One way to the ciphertext (i.e., without decrypting it). One way to
prevent this is to authenticate the ciphertext, e.g., using prevent this is to authenticate the ciphertext, e.g., using
signatures, MACs, or AEAD schemes. See the CBC/CFB gadget signatures, Message Authentication Codes (MACs), or
attack in [EFAIL]. 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 A conformant MUA should keep its message composition interface
simple. When presenting the user with a choice of cryptographic simple. When presenting the user with a choice of cryptographic
protection, it MUST offer no more than three choices: protection, it MUST offer no more than three choices:
* No end-to-end cryptographic protection 1. No end-to-end cryptographic protection
* Verified (signed only) 2. Verified (signed only)
* Confidential (signed and encrypted) 3. Confidential (signed and encrypted)
Note that these choices correspond to the simplified mental model in Note that these choices correspond to the simplified mental model in
Section 3.1. Section 3.1.
A common anti-pattern among legacy MUAs is offering two boolean A common anti-pattern among legacy MUAs is offering two boolean
choices: one to toggle signing, another to toggle encryption. This choices: one to toggle signing and another to toggle encryption.
creates usability hurdles: This creates usability hurdles:
* A user who wants to send a signed and encrypted message will have * A user who wants to send a signed-and-encrypted message will have
to click two buttons instead of one. to click two buttons instead of one.
* A user who clicks "Encrypt" but neglects to click "Signed" may not * A user who clicks "Encrypt" but neglects to click "Signed" may not
understand that they are creating a message which cannot be understand that they are creating a message that cannot be
authenticated by the receiver. authenticated by the receiver.
5.4. Composing a Reply Message 5.4. Composing a Reply Message
When replying to a message, most MUAs compose an initial draft of the When replying to a message, most MUAs compose an initial draft of the
reply that contains quoted text from the original message. A reply that contains quoted text from the original message. A
responsible MUA will take precautions to avoid leaking the cleartext responsible MUA will take precautions to avoid leaking the cleartext
of an encrypted message in such a reply. of an encrypted message in such a reply.
If the original message was end-to-end encrypted, the replying MUA If the original message was end-to-end encrypted, the replying MUA
MUST either: MUST either:
* compose the reply with end-to-end encryption, or * compose the reply with end-to-end encryption or
* avoid including quoted text from the original message. * avoid including quoted text from the original message.
In general, MUAs SHOULD prefer the first option: to compose an In general, MUAs SHOULD prefer the first option: to compose an
encrypted reply. This is what users expect. encrypted reply. This is what users expect.
However, in some circumstances, the replying MUA cannot compose an However, in some circumstances, the replying MUA cannot compose an
encrypted reply. For example, the MUA might not have a valid, encrypted reply. For example, the MUA might not have a valid,
unexpired, encryption-capable certificate for all recipients. This unexpired, and encryption-capable certificate for all recipients.
can also happen during composition when a user adds a new recipient This can also happen during composition when a user adds a new
into the reply, or manually toggles the cryptographic protections to recipient into the reply or manually toggles the cryptographic
remove encryption. protections to remove encryption.
In this circumstance, the composing MUA SHOULD strip the quoted text In this circumstance, the composing MUA SHOULD strip the quoted text
from the original message, unless the user indicates that they are from the original message, unless the user indicates that they are
deliberately including previously confidential content in a non- deliberately including previously confidential content in a non-
confidential message. confidential message.
Note additional nuance about replies to malformed messages that Note additional nuance about replies to malformed messages that
contain encryption in Section 6.2.2.1. contain encryption in Section 6.2.2.1.
6. Message Interpretation 6. Message Interpretation
Despite the best efforts of well-intentioned senders to create e-mail Despite the best efforts of well-intentioned senders to create email
messages with well-formed end-to-end cryptographic protection, messages with well-formed, end-to-end cryptographic protection,
receiving MUAs will inevitably encounter some messages with malformed receiving MUAs will inevitably encounter some messages with malformed
end-to-end cryptographic protection. end-to-end cryptographic protection.
This section offers guidance on dealing with both well-formed and This section offers guidance on dealing with both well-formed and
malformed messages containing Cryptographic Layers. malformed messages containing Cryptographic Layers.
6.1. Rendering Well-formed Messages 6.1. Rendering Well-Formed Messages
A message is well-formed when it has a Cryptographic Envelope, a A message is well-formed when it has a Cryptographic Envelope, a
Cryptographic Payload, and no Errant Cryptographic Layers. Rendering Cryptographic Payload, and no Errant Cryptographic Layers. Rendering
a well-formed message is straightforward. a well-formed message is straightforward.
The receiving MUA evaluates and assembles the cryptographic The receiving MUA evaluates and assembles the cryptographic
properties of the Cryptographic Envelope into a Cryptographic Summary properties of the Cryptographic Envelope into a Cryptographic Summary
and displays that status to the user in a secure, strictly-controlled and displays that status to the user in a secure and strictly
part of the UI. In particular, the part of the UI used to render the controlled part of the UI. In particular, the part of the UI used to
Cryptographic Summary of the message MUST NOT be spoofable, render the Cryptographic Summary of the message MUST NOT be
modifiable, or otherwise controllable by the received message itself. spoofable, modifiable, or otherwise controllable by the received
By analogy, consider the "lock" icon in the address bar of the web message itself. By analogy, consider the "lock" icon in the address
browser: regardless of the content of the webpage, the lock icon will bar of the web browser: Regardless of the content of the webpage, the
only be displayed when the transport to the web server is adequately lock icon will only be displayed when the transport to the web server
secured. is adequately secured.
Aside from this Cryptographic Summary, the message itself MUST be Aside from this Cryptographic Summary, the message itself MUST be
rendered as though the Cryptographic Payload is the body of the rendered as though the Cryptographic Payload is the body of the
message. The Cryptographic Layers themselves SHOULD NOT be rendered message. The Cryptographic Layers themselves SHOULD NOT be rendered
as distinct objects unless the MUA is providing the user with as distinct objects unless the MUA is providing the user with
debugging information. debugging information.
6.2. Errant Cryptographic Layers 6.2. Errant Cryptographic Layers
If an incoming message has any Errant Cryptographic Layers, a If an incoming message has any Errant Cryptographic Layers, a
conformant interpreting MUA MUST ignore those layers when rendering conformant-interpreting MUA MUST ignore those layers when rendering
the Cryptographic Summary of the message to the user. the Cryptographic Summary of the message to the user.
6.2.1. Errant Signing Layer 6.2.1. Errant Signing Layer
When rendering a message with an Errant Cryptographic Layer that When rendering a message with an Errant Cryptographic Layer that
provides authenticity and integrity (via signatures), the message provides authenticity and integrity (via signatures), the message
should be rendered by replacing the Cryptographic layer with the part should be rendered by replacing the Cryptographic Layer with the part
it encloses. it encloses.
For example, a message with this structure: For example, a message with this structure:
A └┬╴multipart/mixed A └┬╴multipart/mixed
B ├╴text/plain B ├╴text/plain
C ├┬╴multipart/signed C ├┬╴multipart/signed
D │├─╴image/jpeg D │├─╴image/jpeg
E │└─╴application/pgp-signature E │└─╴application/pgp-signature
F └─╴text/plain F └─╴text/plain
Should be rendered identically to this: should be rendered identically to this:
A └┬╴multipart/mixed A └┬╴multipart/mixed
B ├─╴text/plain B ├─╴text/plain
D ├─╴image/jpeg D ├─╴image/jpeg
F └─╴text/plain F └─╴text/plain
In such a situation, a conformant MUA MUST NOT indicate in the In such a situation, a conformant MUA MUST NOT indicate in the
Cryptographic Summary that the message is signed. It MUST indicate Cryptographic Summary that the message is signed. It MUST indicate
that the message is Unprotected. that the message is Unprotected.
6.2.1.1. Exception: Mailing List Footers 6.2.1.1. Exception: Mailing List Footers
The use case described in Section 4.5.1 is common enough in some 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 contexts that a conformant MUA MAY decide to handle it as a special
exception. exception.
If the MUA determines that the message comes from a mailing list (for If the MUA determines that the message comes from a mailing list (for
example, it has a List-ID header), and it has a structure that example, it has a List-ID header) and it has a structure that appends
appends a footer to a signing-only Cryptographic Layer with a valid a footer to a signing-only Cryptographic Layer with a valid
signature, such as: signature, such as:
H └┬╴multipart/mixed H └┬╴multipart/mixed
I ├┬╴multipart/signed I ├┬╴multipart/signed
J │├─╴[protected part, may be arbitrary MIME subtree] J │├─╴[protected part, may be arbitrary MIME subtree]
K │└─╴application/{pgp,pkcs7}-signature K │└─╴application/{pgp,pkcs7}-signature
L └─╴[footer, typically text/plain] L └─╴[footer, typically text/plain]
or: or:
H └┬╴multipart/mixed H └┬╴multipart/mixed
I ├─╴application/pkcs7-mime; smime-type="signed-data" I ├─╴application/pkcs7-mime; smime-type="signed-data"
│⇩ (unwraps to) │⇩ (unwraps to)
J │└─╴[protected part, may be an arbitrary MIME subtree] J │└─╴[protected part, may be an arbitrary MIME subtree]
L └─╴[footer, typically text/plain] L └─╴[footer, typically text/plain]
Then, the MUA MAY indicate to the user that this is a Verified then the MUA MAY indicate to the user that this is a Verified message
message that has been wrapped by the mailing list. that has been wrapped by the mailing list.
In this case, the MUA MUST distinguish the footer (part L) from the In this case, the MUA MUST distinguish the footer (part L) from the
protected part (part J) when rendering any information about the protected part (part J) when rendering any information about the
signature. signature.
One way to do this is to offer the user two different views of the One way to do this is to offer the user two different views of the
message: the "mailing list" view, which hides any positive message: the "mailing list" view, which hides any positive
Cryptographic Summary but shows the footer: Cryptographic Summary but shows the footer:
Cryptographic Protections: Unprotected Cryptographic Protections: Unprotected
H └┬╴multipart/mixed H └┬╴multipart/mixed
J ├─╴[protected part, may be arbitrary MIME subtree] J ├─╴[protected part, may be arbitrary MIME subtree]
L └─╴[footer, typically text/plain] L └─╴[footer, typically text/plain]
or the "sender's view", which shows the Cryptographic Summary as or the "sender's view", which shows the Cryptographic Summary as
Verified, but hides the footer: Verified but hides the footer:
Cryptographic Protections: Verified [details from part I] Cryptographic Protections: Verified [details from part I]
J └─╴[protected part, may be arbitrary MIME subtree] J └─╴[protected part, may be arbitrary MIME subtree]
6.2.2. Errant Encryption Layer 6.2.2. Errant Encryption Layer
An MUA may encounter a message with an Errant Cryptographic Layer An MUA may encounter a message with an Errant Cryptographic Layer
that offers confidentiality (encryption), and the MUA is capable of that offers confidentiality (encryption), and the MUA is capable of
decrypting it. decrypting it.
The user wants to be able to see the contents of any message that The user wants to be able to see the contents of any message that
they receive, so a conformant MUA in this situation SHOULD decrypt they receive, so a conformant MUA in this situation SHOULD decrypt
the part. the part.
In this case, though, a conformant MUA MUST NOT indicate in the Although, in this case, a conformant MUA MUST NOT indicate in the
message's Cryptographic Summary that the message itself was message's Cryptographic Summary that the message itself was
encrypted. Such an indication could be taken to mean that other encrypted. Such an indication could be taken to mean that other
(non-encrypted) parts of the message arrived with cryptographic (non-encrypted) parts of the message arrived with cryptographic
confidentiality. confidentiality.
Furthermore, when decrypting an Errant Cryptographic Layer, the MUA Furthermore, when decrypting an Errant Cryptographic Layer, the MUA
MUST treat the decrypted cleartext as a distinct MIME subtree, and MUST treat the decrypted cleartext as a distinct MIME subtree and not
not attempt to merge or splice it together with any other part of the attempt to merge or splice it together with any other part of the
message. This offers protection against the direct exfiltration message. This offers protection against the direct exfiltration
(also known as EFAIL-DE) attacks described in [EFAIL] and so-called (also known as EFAIL-DE) attacks described in [EFAIL] and so-called
multipart/oracle attacks described in [ORACLE]. multipart/oracle attacks described in [ORACLE].
6.2.2.1. Replying to a Message with an Errant Encryption Layer 6.2.2.1. Replying to a Message with an Errant Encryption Layer
Note that there is an asymmetry here between rendering and replying Note that there is an asymmetry here between rendering and replying
to a message with an Errant Encryption Layer. to a message with an Errant Encryption Layer.
When rendering, the MUA does not indicate that the message was When rendering, the MUA does not indicate that the message was
skipping to change at page 26, line 17 skipping to change at line 1116
When composing a reply to a message that has any encryption layer, When composing a reply to a message that has any encryption layer,
even an errant one, the reply message SHOULD be marked for even an errant one, the reply message SHOULD be marked for
encryption, unless quoted and attributed text is not included in the encryption, unless quoted and attributed text is not included in the
reply, as noted in Section 5.4. reply, as noted in Section 5.4.
When composing a reply to a message with an errant cryptographic When composing a reply to a message with an errant cryptographic
layer, a conformant MUA MUST NOT decrypt any errant cryptographic layer, a conformant MUA MUST NOT decrypt any errant cryptographic
layers when generating quoted or attributed text. This will layers when generating quoted or attributed text. This will
typically mean either leaving the ciphertext itself in the generated typically mean either leaving the ciphertext itself in the generated
reply message, or simply not generating any quoted or attributed text reply message or simply not generating any quoted or attributed text
at all. This offers protection against the reply-based attacks at all. This offers protection against the reply-based attacks
described in [REPLY]. described in [REPLY].
In all circumstances, if the reply message cannot be encrypted (or if In all circumstances, if the reply message cannot be encrypted (or if
the user elects to not encrypt the reply), the composed reply MUST the user elects to not encrypt the reply), the composed reply MUST
NOT include any material from the decrypted subpart. NOT include any material from the decrypted subpart.
6.2.3. Avoiding Non-MIME Cryptographic Mechanisms 6.2.3. Avoiding Non-MIME Cryptographic Mechanisms
In some cases, there may be a cryptographic signature or encryption In some cases, there may be a cryptographic signature or encryption
that does not coincide with a MIME boundary. For example so-called that does not coincide with a MIME boundary. For example, so-called
"PGP Inline" messages typically contain base64-encoded ("ASCII- "PGP Inline" messages typically contain base64-encoded ("ASCII-
armored", see Section 6 of [RFC9580]) ciphertext, or within the armored", see Section 6 of [RFC9580]) ciphertext, or within the
content of a MIME part. content of a MIME part.
6.2.3.1. Do Not Validate Non-MIME Signatures 6.2.3.1. Do Not Validate Non-MIME Signatures
When encountering cryptographic signatures in these positions, a When encountering cryptographic signatures in these positions, a
conformant MUA MUST NOT attempt to validate any signature. It is conformant MUA MUST NOT attempt to validate any signature. It is
challenging to communicate to the user exactly which part of such a challenging to communicate to the user exactly which part of such a
message is covered by the signature, so it is better to leave the message is covered by the signature, so it is better to leave the
message marked as Unprotected. See [SPOOFING] for examples of message marked as Unprotected. See [SPOOFING] for examples of
spoofed message signatures that rely on permissive legacy clients spoofed message signatures that rely on permissive legacy clients
that are willing to validate signatures in poorly-structured that are willing to validate signatures in poorly structured
messages. messages.
6.2.3.2. Skip or Isolate Non-MIME Decryption When Rendering 6.2.3.2. Skip or Isolate Non-MIME Decryption When Rendering
When encountering what appears to be encrypted data not at a MIME When encountering what appears to be encrypted data not at a MIME
boundary, a conformant MUA MAY decline to decrypt the data at all. boundary, a conformant MUA MAY decline to decrypt the data at all.
During message rendering, if a conformant MUA attempts decryption of During message rendering, if a conformant MUA attempts decryption of
such a non-MIME encrypted section of an e-mail, it MUST synthesize a such a non-MIME encrypted section of an email, it MUST synthesize a
separate MIME part to contain only the decrypted data, and not separate MIME part to contain only the decrypted data and not attempt
attempt to merge or splice that part together with any other part of to merge or splice that part together with any other part of the
the message. Keeping such a section distinct and isolated from any message. Keeping such a section distinct and isolated from any other
other part of the message offers protection against the direct part of the message offers protection against the direct exfiltration
exfiltration attacks (also known as EFAIL-DE) described in [EFAIL]. attacks (also known as EFAIL-DE) described in [EFAIL].
6.2.3.3. Do Not Decrypt Non-MIME Decryption when Replying 6.2.3.3. Do Not Decrypt Non-MIME Decryption When Replying
When composing a reply to a message with such a non-MIME encrypted When composing a reply to a message with such a non-MIME encrypted
section, a conformant MUA MUST NOT decrypt any non-MIME encrypted section, a conformant MUA MUST NOT decrypt any non-MIME encrypted
section when generating quoted or attributed text, similar to the section when generating quoted or attributed text, similar to the
guidance in Section 6.2.2.1. guidance in Section 6.2.2.1.
This offers protection against the reply-based attacks described in This offers protection against the reply-based attacks described in
[REPLY]. [REPLY].
6.3. Forwarded Messages with Cryptographic Protection 6.3. Forwarded Messages with Cryptographic Protection
An incoming e-mail message may include an attached forwarded message, An incoming email message may include an attached forwarded message,
typically as a MIME subpart with Content-Type: message/rfc822 typically as a MIME subpart with Content-Type: message/rfc822
([RFC5322]) or Content-Type: message/global ([RFC5355]). [RFC5322] or Content-Type: message/global [RFC5355].
Regardless of the cryptographic protections and structure of the Regardless of the cryptographic protections and structure of the
incoming message, the internal forwarded message may have its own incoming message, the internal forwarded message may have its own
Cryptographic Envelope. Cryptographic Envelope.
The Cryptographic Layers that are part of the Cryptographic Envelope The Cryptographic Layers that are part of the Cryptographic Envelope
of the forwarded message are not Errant Cryptographic Layers of the of the forwarded message are not Errant Cryptographic Layers of the
surrounding message -- they are simply layers that apply to the surrounding message -- they are simply layers that apply to the
forwarded message itself. forwarded message itself.
A conformant rendering MUA MUST NOT conflate the cryptographic A conformant-rendering MUA MUST NOT conflate the cryptographic
protections of the forwarded message with the cryptographic protections of the forwarded message with the cryptographic
protections of the incoming message. protections of the incoming message.
A conformant rendering MUA MAY render a Cryptographic Summary of the A conformant-rendering MUA MAY render a Cryptographic Summary of the
protections afforded to the forwarded message by its own protections afforded to the forwarded message by its own
Cryptographic Envelope, as long as that rendering is unambiguously Cryptographic Envelope, as long as that rendering is unambiguously
tied to the forwarded message itself, and cannot be spoofed either by tied to the forwarded message itself and cannot be spoofed by either
the enclosing message or by the forwarded message. the enclosing message or the forwarded message.
6.4. Signature failures 6.4. Signature Failures
A cryptographic signature may fail in multiple ways. A conformant A cryptographic signature may fail in multiple ways. A conformant-
receiving MUA that discovers a failed signature treats the message as receiving MUA that discovers a failed signature treats the message as
though the signature did not exist. This is similar to the standard though the signature did not exist. This is similar to the standard
guidance for about failed DKIM signatures (see Section 6.1 of guidance for failed DomainKeys Identified Mail (DKIM) signatures (see
[RFC6376]). Section 6.1 of [RFC6376]).
A conformant MUA MUST NOT render a message with a failed signature as A conformant MUA MUST NOT render a message with a failed signature as
more dangerous or more dubious than a comparable message without any more dangerous or more dubious than a comparable message without any
signature at all. In both cases, the Cryptographic Summary should be signature at all. In both cases, the Cryptographic Summary should be
Unprotected. Unprotected.
A conformant MUA that encounters an encrypted-and-signed message A conformant MUA that encounters an encrypted-and-signed message
where the signature is invalid SHOULD treat the message the same way where the signature is invalid SHOULD treat the message the same way
that it would treat a message that is encryption-only, unless the MUA that it would treat a message that is encryption-only, unless the MUA
is providing the user with debugging information. is providing the user with debugging information.
Some different ways that a signature may be invalid on a given These are some different ways that a signature may be invalid on a
message: given message:
* the signature is not cryptographically valid (the math fails). * The signature is not cryptographically valid (the math fails).
* the signature relies on suspect cryptographic primitives (e.g., * The signature relies on suspect cryptographic primitives (e.g.,
over a deprecated digest algorithm, or was made by a weak key, 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 e.g., 1024-bit RSA); note that this requires the rendering MUA to
have an explicit policy about what cryptographic primitives are have an explicit policy about what cryptographic primitives are
acceptable. acceptable.
* the signature is made by a certificate which the receiving MUA * The signature is made by a certificate that the receiving MUA does
does not have access to. not have access to.
* the certificate used to verify the signature was revoked. * The certificate used to verify the signature was revoked.
* the certificate used to verify the signature was expired at the * The certificate used to verify the signature was expired at the
time that the signature was made. time that the signature was made.
* the certificate used to verify the signature does not correspond * The certificate used to verify the signature does not correspond
to the author of the message. (for X.509, there is no to the author of the message. (For X.509, there is no
subjectAltName of type rfc822Name whose value matches an e-mail subjectAltName of type rfc822Name whose value matches an email
address found in From: or Sender:) address found in the From or Sender header field.)
* the certificate used to verify the signature was not issued by an * The certificate used to verify the signature was not issued by an
authority that the MUA user is willing to rely on for certifying authority that the MUA user is willing to rely on for certifying
the sender's e-mail address, and the user has no other reasonable the sender's email address, and the user has no other reasonable
indication that the certificate belongs to the sender's e-mail indication that the certificate belongs to the sender's email
address. address.
* the signature indicates that it was made at a time much before or * The signature indicates that it was made at a time much before or
much after from the date of the message itself. much after the date of the message itself.
* The signature covers a message that depends on an external * The signature covers a message that depends on an external
subresource that might change (see Section 9.9). subresource that might change (see Section 9.9).
A valid signature must pass all these tests, but of course invalid A valid signature must pass all these tests, but of course, invalid
signatures may be invalid in more than one of the ways listed above. signatures may be invalid in more than one of the ways listed above.
6.5. Weak Encryption 6.5. Weak Encryption
Sometimes, an MUA might encounter a message with a well-formed Sometimes, an MUA might encounter a message with a well-formed
Cryptographic Envelope that uses a form of encryption with Cryptographic Envelope that uses a form of encryption with
substantial known flaws. For example, a PGP/MIME message might use a substantial known flaws. For example, a PGP/MIME message might use a
Symmetrically Encrypted Data packet, which is known to have malleable Symmetrically Encrypted Data packet, which is known to have malleable
ciphertext (see Section 5.7 of [RFC9580]). ِAs another example, an S/ ciphertext (see Section 5.7 of [RFC9580]). As another example, an S/
MIME message may use an enveloped-data MIME part with a MIME message may use an enveloped-data MIME part with a
contentEncryptionAlgorithm of rc2-cbc with rc2ParameterVersion of contentEncryptionAlgorithm of rc2-cbc with rc2ParameterVersion of
160, meaning a 40-bit key (see Section 5.2 of [RFC3370]), which is 160, meaning a 40-bit key (see Section 5.2 of [RFC3370]), which is
widely considered breakable via brute force with moderate hardware widely considered breakable via brute force with moderate hardware
investment in 2024. As cryptanalysis and hardware capacities investment in 2024. As cryptanalysis and hardware capacities
advance, an implementation may widen the scope of what encryption advance, an implementation may widen the scope of what encryption
mechanisms are considered weak. mechanisms are considered weak.
A receiving MUA MUST warn the user that such a message has a known A receiving MUA MUST warn the user that such a message has a known
weakness. The receiving MUA MAY decline to decrypt such a message at weakness. The receiving MUA MAY decline to decrypt such a message at
skipping to change at page 29, line 34 skipping to change at line 1277
that the message was encrypted, as the confidentiality of the message that the message was encrypted, as the confidentiality of the message
is suspect. This is similar to the approach taken in Section 6.2.2 is suspect. This is similar to the approach taken in Section 6.2.2
for messages with an Errant Encryption Layer. for messages with an Errant Encryption Layer.
Like the Errant Encryption Layer situation, there is an asymmetry Like the Errant Encryption Layer situation, there is an asymmetry
between rendering and replying to a message with weak encryption. 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 The guidance in Section 6.2.2.1 should be followed when replying to a
message with weak encryption as well. message with weak encryption as well.
A receiving MUA MAY also treat historically archived messages with A receiving MUA MAY also treat historically archived messages with
weak encryption differently from modern messages. For example, if an weak encryption differently than modern messages. For example, if an
encryption algorithm was known to be weak in 2005, then a message encryption algorithm was known to be weak in 2005, then a message
that appears to have been encrypted with that algorithm in 1995 might that appears to have been encrypted with that algorithm in 1995 might
decrypted with a warning, as an archival service. But a message that be decrypted with a warning, as an archival service. But a message
appears to have been encrypted with that same weak algorithm in 2015 that appears to have been encrypted with that same weak algorithm in
might be quarantined as a likely attack. 2015 might be quarantined as a likely attack.
There are several possible ways to distinguish a historical message There are several possible ways to distinguish a historical message
from a modern one, including: from a modern one, including:
* The message timestamp (e.g., the Date header field) * the message timestamp (e.g., the Date header field)
* The time the message was first observed on the network (e.g., * the time the message was first observed on the network (e.g.,
delivery of a new message via IMAP from a mailbox that had delivery of a new message via IMAP from a mailbox that had
recently checked) recently checked)
* The timestamp in any signature observed in the message * 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 weak * the message structure (a message composed using protocol elements
is likely to be an attack than a legitimate archival message) 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 7. Reasoning about Message Parts
When generating or rendering messages, it is useful to know what When generating or rendering messages, it is useful to know what
parts of the message are likely to be displayed, and how. This parts of the message are likely to be displayed and how. This
section introduces some common terms that can be applied to parts section introduces some common terms that can be applied to parts
within the Cryptographic Payload. within the Cryptographic Payload.
7.1. Main Body Part 7.1. Main Body Part
When an e-mail message is composed or rendered to the user there is When an email message is composed or rendered to the user, there is
typically one main view that presents a (mostly textual) part of the typically one main view that presents a (mostly textual) part of the
message. message.
While the message itself may be constructed of several distinct MIME While the message itself may be constructed of several distinct MIME
parts in a tree, the part that is rendered to the user is the "Main parts in a tree, the part that is rendered to the user is the "Main
Body Part". Body Part".
When rendering a message, one of the primary jobs of the receiving When rendering a message, one of the primary jobs of the receiving
MUA is identifying which part (or parts) is the Main Body Part. MUA is identifying which part (or parts) is the Main Body Part.
Typically, this is found by traversing the MIME tree of the message Typically, this is found by traversing the MIME tree of the message
looking for a leaf node that has a primary content type of text looking for a leaf node that has text (e.g., text/plain or text/html)
(e.g., text/plain or text/html) and is not Content-Disposition: as a primary content type and is not Content-Disposition: attachment.
attachment.
MIME tree traversal follows the first child of every multipart node, MIME tree traversal follows the first child of every multipart node,
with the exception of multipart/alternative. When traversing a with the exception of multipart/alternative. When traversing a
multipart/alternative node, all children should be scanned, with multipart/alternative node, all children should be scanned, with
preference given to the last child node with a MIME type that the MUA preference given to the last child node with a MIME type that the MUA
is capable of rendering directly. is capable of rendering directly.
An MUA MAY offer the user a mechanism to prefer a particular MIME An MUA MAY offer the user a mechanism to prefer a particular MIME
type within multipart/alternative instead of the last renderable type within multipart/alternative instead of the last renderable
child. For example, a user may explicitly prefer a text/plain child. For example, a user may explicitly prefer a text/plain
alternative part over text/html. Note that due to uncertainty about alternative part over text/html. Note that due to uncertainty about
the capabilities and configuration of the receiving MUA, a conformant the capabilities and configuration of the receiving MUA, a
composing MUA should consider that multiple parts might be rendered conformant-composing MUA should consider that multiple parts might be
as the Main Body Part when the message is ultimately viewed. In rendered as the Main Body Part when the message is ultimately viewed.
particular, the composing MUA should ensure that any part likely to In particular, the composing MUA should ensure that any part likely
be viewed as the Main Body Part has the same semantic content as any to be viewed as the Main Body Part has the same semantic content as
other such part. any other such part.
When composing a message, an originating MUA operating on behalf of When composing a message, an originating MUA operating on behalf of
an active user can identify which part (or parts) are the "main" an active user can identify which part (or parts) are the "main"
parts: these are the parts the MUA generates from the user's editor. parts: These are the parts the MUA generates from the user's editor.
Tooling that automatically generates email messages should also have
Tooling that automatically generates e-mail messages should also have
a reasonable estimate of which part (or parts) are the "main" parts, a reasonable estimate of which part (or parts) are the "main" parts,
as they can be programmatically identified by the message author. as they can be programmatically identified by the message author.
For a filtering program that attempts to transform an outbound For a filtering program that attempts to transform an outbound
message without any special knowledge about which parts are Main Body message without any special knowledge about which parts are the Main
Parts, it can identify the likely parts by following the same routine Body Parts, it can identify the likely parts by following the same
as a receiving MUA. routine as a receiving MUA.
7.2. Attachments 7.2. Attachments
A message may contain one or more separated MIME parts that are A message may contain one or more separated MIME parts that are
intended for download or extraction. Such a part is commonly called intended for download or extraction. Such a part is commonly called
an "attachment", and is commonly identified by having Content- an "attachment" and is commonly identified by having Content-
Disposition: attachment. Disposition: attachment.
An MUA MAY identify a subpart as an attachment, or permit extraction An MUA MAY identify a subpart as an attachment or permit extraction
of a subpart even when the subpart does not have Content-Disposition: of a subpart even when the subpart does not have Content-Disposition:
attachment. attachment.
When generating a message with end-to-end cryptographic protection, When generating a message with end-to-end cryptographic protection,
any attachment MUST be included within the Cryptographic Payload. If any attachment MUST be included within the Cryptographic Payload. If
an attachment is found outside the Cryptographic Payload, then the an attachment is found outside the Cryptographic Payload, then the
message is not well-formed (see Section 6.1), and will not be handled message is not well-formed (see Section 6.1) and will not be handled
by other MUAs as intended. by other MUAs as intended.
Some MUAs have tried to compose messages where each attachment is Some MUAs have tried to compose messages where each attachment is
placed in its own cryptographic envelope. Such a message is placed in its own cryptographic envelope. Such a message is
problematic for several reasons: problematic for several reasons:
* The attachments can be stripped, replaced, or reordered without * The attachments can be stripped, replaced, or reordered without
breaking any cryptographic integrity mechanism. breaking any cryptographic integrity mechanism.
* The resulting message may have a mix of cryptographic statuses * The resulting message may have a mix of cryptographic statuses
(e.g., if a signature on one part fails but another succeeds, or (e.g., if a signature on one part fails but another succeeds or if
if one part is encrypted and another is not). This mix of one part is encrypted and another is not). This mix of statuses
statuses is difficult to represent to the user in a comprehensible is difficult to represent to the user in a comprehensible way.
way.
* The divisions between the different attachments are visible to * The divisions between the different attachments are visible to
operators of any mail transport agent (MTA) that handles the operators of any mail transport agent (MTA) that handles the
message, potentially resulting in a metadata leak. For example, message, potentially resulting in a metadata leak. For example,
the MTA operator may learn the number of attachments, and the size the MTA operator may learn the number of attachments and the size
of each attachment. of each attachment.
These messages are unlikely to be usefully interoperable without These messages are unlikely to be usefully interoperable without
additional standardization work (see Appendix A.12). additional standardization work (see Appendix A.12).
7.3. MIME Part Examples 7.3. MIME Part Examples
Consider a common message with the following MIME structure: Consider a common message with the following MIME structure:
M └─╴application/pkcs7-mime M └─╴application/pkcs7-mime
skipping to change at page 33, line 7 skipping to change at line 1440
Parts P and R (the first two leaf nodes within each subtree of part Parts P and R (the first two leaf nodes within each subtree of part
O) are the Main Body Parts. O) are the Main Body Parts.
Part S is more likely not to be an attachment, as the subtree layout Part S is more likely not to be an attachment, as the subtree layout
suggests that it is only relevant for the HTML version of the suggests that it is only relevant for the HTML version of the
message. For example, it might be rendered as an image within the message. For example, it might be rendered as an image within the
HTML alternative. HTML alternative.
8. Certificate Management 8. Certificate Management
A cryptographically-capable MUA typically maintains knowledge about A cryptographically capable MUA typically maintains knowledge about
certificates for the user's own account(s), as well as certificates certificates for the user's own account(s), as well as certificates
for the peers that it communicates with. for the peers that it communicates with.
8.1. Peer Certificates 8.1. Peer Certificates
Most certificates that a cryptographically-capable MUA will use will Most certificates that a cryptographically capable MUA will use will
be certificates belonging to the parties that the user communicates be certificates belonging to the parties that the user communicates
with through the MUA. This section discusses how to manage the with through the MUA. This section discusses how to manage the
certificates that belong to such a peer. certificates that belong to such a peer.
The MUA will need to be able to discover X.509 certificates for each The MUA will need to be able to discover X.509 certificates for each
peer, cache them, and select among them when composing an encrypted peer, cache them, and select among them when composing an encrypted
message. message.
Detailed guidance about how to do this is beyond the scope of this Detailed guidance about how to do this is beyond the scope of this
document, but future revisions may bring it into scope (see document, but future revisions may bring it into scope (see
Appendix A.3). Appendix A.3).
8.1.1. Peer Certificate Selection 8.1.1. Peer Certificate Selection
When composing an encrypted message, the MUA needs to select an When composing an encrypted message, the MUA needs to select an
encryption-capable certificate for each recipient. encryption-capable certificate for each recipient.
To select such a certificate for a given destination e-mail address, To select such a certificate for a given destination email address,
the MUA should look through all of its known certificates and verify the MUA should look through all of its known certificates and verify
that _all_ of the conditions below are met: that _all_ of the conditions below are met:
* The certificate must be valid, not expired or revoked. * The certificate must be valid, not expired or revoked.
* It must have a subjectAltName of type rfc822Name whose contents * It must have a subjectAltName of type rfc822Name whose contents
match the destination e-mail address. In particular, the local- match the destination email address. In particular, the local
part of the two addresses should be an exact bytewise match, and part of the two addresses should be an exact bytewise match, and
the domain parts of the two addresses should be matched by the domain parts of the two addresses should be matched by
ensuring label equivalence across the full domain name, as ensuring label equivalence across the full domain name, as
described in Section 2.3.2.4 of [RFC5890]. described in Section 2.3.2.4 of [RFC5890].
* The algorithm OID in the certificate's SPKI is known to the MUA * The algorithm OID in the certificate's SPKI is known to the MUA
and capable of encryption. Examples include: and capable of encryption. Examples include:
- rsaEncryption (OID 1.2.840.113549.1.1.1), with keyUsage (OID - rsaEncryption (OID 1.2.840.113549.1.1.1), with the keyUsage
2.5.29.15) extension present and the "key encipherment" bit (OID 2.5.29.15) extension present and the "key encipherment"
(value 32) set. bit (value 32) set.
- curveX25519 (OID 1.3.101.110) with keyUsage extension present - curveX25519 (OID 1.3.101.110), with the keyUsage extension
and the "key agreement" bit (value 8) set. present and the "key agreement" bit (value 8) set.
* If extendedKeyUsage (OID 2.5.29.37) is present, it contains at * If extendedKeyUsage (OID 2.5.29.37) is present, it contains at
least one of the following OIDs: e-mail protection (OID least one of the following OIDs: email protection (OID
1.3.6.1.5.5.7.3.4), anyExtendedKeyUsage (OID 2.5.29.37.0). 1.3.6.1.5.5.7.3.4), anyExtendedKeyUsage (OID 2.5.29.37.0).
A conformant MUA may include more considerations when selecting a A conformant MUA may include more considerations when selecting a
peer certificate as well, see Appendix A.3.4 for examples. peer certificate as well; see Appendix A.3.4 for examples.
8.2. Local Certificates 8.2. Local Certificates
The MUA also needs to know about one or more certificates associated The MUA also needs to know about one or more certificates associated
with the user's e-mail account. It is typically expected to have with the user's email account. It is typically expected to have
access to the secret key material associated with the public keys in access to the secret key material associated with the public keys in
those certificates. those certificates.
While some basic guidance is offered here, it is beyond the scope of While some basic guidance is offered here, it is beyond the scope of
this document to describe all possible relevant guidance for local this document to describe all possible relevant guidance for local
certificate and key material handling. See Appendix A.4 for certificate and key material handling. See Appendix A.4 for
suggestions of guidance that a future version might bring into scope. suggestions of guidance that a future version might bring into scope.
8.2.1. Getting Certificates for the User 8.2.1. Getting Certificates for the User
If a conformant MUA does not have any certificate or secret key for If a conformant MUA does not have a certificate or secret key for the
the user, it should help the user to generate, acquire, or import user, it should help the user to generate, acquire, or import them
them with a minimum of difficulty. with minimum difficulty.
8.2.1.1. User Certificates for S/MIME 8.2.1.1. User Certificates for S/MIME
For S/MIME, the user SHOULD have both a signing-capable certificate For S/MIME, the user SHOULD have both a signing-capable certificate
and an encryption-capable certificate (and the corresponding secret and an encryption-capable certificate (and the corresponding secret
keys). Using the same cryptographic key material for multiple keys). Using the same cryptographic key material for multiple
algorithms (i.e., for both encryption and signing) has been the algorithms (i.e., for both encryption and signing) has been the
source of vulnerabilities in other (non-e-mail) contexts (e.g., source of vulnerabilities in other (non-email) contexts (e.g.,
[DROWN] and [IKE]). The simplest way to avoid any comparable risk is [DROWN] and [IKE]). The simplest way to avoid any comparable risk is
to use distinct key material for each cryptographic algorithm. A to use distinct key material for each cryptographic algorithm. A
conformant MUA that generates S/MIME certificates for the user MUST conformant MUA that generates S/MIME certificates for the user MUST
generate distinct S/MIME certificates: one for encryption and another generate distinct S/MIME certificates: one for encryption and another
for signing, to avoid possible cross-protocol key misuse. for signing, to avoid possible cross-protocol key misuse.
The simplest option for an S/MIME-capable MUA is for the MUA to The simplest option for an S/MIME-capable MUA is for the MUA to
permit the user to import a PKCS #12 ([RFC7292]) object that is permit the user to import a PKCS #12 [RFC7292] object that is
expected to contain secret key material, end entity certificates for expected to contain secret key material, end entity certificates for
the user, and intermediate certification authority certificates that the user, and intermediate certification authority certificates that
permit chaining from the end entity certs to widely-accepted trust permit chaining from the end entity certs to widely accepted trust
anchors. A conformant MUA that imports such a PKCS #12 bundle SHOULD anchors. A conformant MUA that imports such a PKCS #12 bundle SHOULD
warn the user if the bundle contains an S/MIME certificate and warn the user if the bundle contains an S/MIME certificate and
corresponding secret key where the same secret key is used for both corresponding secret key where the same secret key is used for both
encryption and signing. encryption and signing.
An S/MIME-capable MUA that has access to user certificates and their An S/MIME-capable MUA that has access to user certificates and their
corresponding secret key material should also offer the ability to corresponding secret key material should also offer the ability to
export those objects into a well-formed PKCS #12 object that could be export those objects into a well-formed PKCS #12 object that could be
imported into another MUA operated by the same user. imported into another MUA operated by the same user.
Manual handling of PKCS #12 objects is challenging for most users. Manual handling of PKCS #12 objects is challenging for most users.
Producing the initial PKCS #12 object typically can only be done with Producing the initial PKCS #12 object typically can only be done with
the aid of a certification authority via non-standardized, labor- the aid of a certification authority via non-standardized, labor-
intensive, and error-prone procedures that most users do not intensive, and error-prone procedures that most users do not
understand. Furthermore, manual export and import incurs ongoing understand. Furthermore, manual export and import incurs ongoing
labor (for example, before certificate expiration) by the user which labor (for example, before certificate expiration) by the user, which
most users are unprepared to do (see Section 8.2.2). most users are unprepared to do (see Section 8.2.2).
A better approach is for the MUA to integrate some form of automated A better approach is for the MUA to integrate some form of automated
certificate issuance procedure, for example, by using the ACME certificate issuance procedure, for example, by using the Automatic
protocol for end user S/MIME certificates ([RFC8823]). Certificate Management Environment (ACME) protocol for end user S/
MIME certificates [RFC8823].
Another possible approach is integration with a cryptographic Another possible approach is integration with a cryptographic
hardware token or smartcard that can provide certificates and permit hardware token or smart card that can provide certificates and permit
the use of isolated secret key material, for example [PKCS11], though the use of isolated secret key material, for example, see [PKCS11],
this approach delegates the complexity of acquiring and managing though this approach delegates the complexity of acquiring and
certificates to management of the hardware token itself (see managing certificates to management of the hardware token itself (see
Appendix A.4.2). Appendix A.4.2).
See also [I-D.woodhouse-cert-best-practice] for more recommendations See also [CERT-BEST-PRACTICE] for more recommendations about managing
about managing user certificates. user certificates.
8.2.1.2. User Certificates for PGP/MIME 8.2.1.2. User Certificates for PGP/MIME
As distinct from S/MIME, OpenPGP ([RFC9580]) has a different set of As distinct from S/MIME, OpenPGP [RFC9580] has a different set of
common practices. For one thing, a single OpenPGP certificate can common practices. For one thing, a single OpenPGP certificate can
contain both a signing-capable key and a distinct encryption-capable contain both a signing-capable key and a distinct encryption-capable
key, so only one certificate is needed for an e-mail user of OpenPGP, key, so only one certificate is needed for an email user of OpenPGP
as long as the certificate has distinct key material for the as long as the certificate has distinct key material for the
different purposes. different purposes.
Furthermore, a single OpenPGP certificate MAY be only self-signed, so Furthermore, a single OpenPGP certificate MAY only be self-signed, so
the MUA can generate such a certificate entirely on its own. the MUA can generate such a certificate entirely on its own.
An OpenPGP-capable MUA should have the ability to import and export An OpenPGP-capable MUA should have the ability to import and export
OpenPGP Tranferable Secret Keys (see Section 10.2 of [RFC9580]), to OpenPGP Transferable Secret Keys (see Section 10.2 of [RFC9580]) to
enable manual transfer of user certificates and secret key material enable manual transfer of user certificates and secret key material
between multiple MUAs controlled by the user. between multiple MUAs controlled by the user.
Since an OpenPGP certificate MAY be certified by third parties Since an OpenPGP certificate MAY be certified by third parties
(whether formal certification authorities or merely other well- (whether formal certification authorities or merely other well-
connected peers) the MUA SHOULD offer affordances to help the user connected peers), the MUA SHOULD offer affordances to help the user
acquire and merge third party certifications on their certificate. acquire and merge third-party certifications on their certificate.
When doing this, the MUA should prioritize third-party certifications When doing this, the MUA should prioritize third-party certifications
from entities that the user's peers are likely to know about and be from entities that the user's peers are likely to know about and be
willing to rely on. willing to rely on.
Since an OpenPGP certificate can grow arbitrarily large with third- Since an OpenPGP certificate can grow arbitrarily large with third-
party certifications, the MUA should assist the user in pruning it to party certifications, the MUA should assist the user in pruning it to
ensure that it remains a reasonable size when transmitting it to ensure that it remains a reasonable size when transmitting it to
other parties. other parties.
8.2.1.3. Generate Secret Key Material Locally 8.2.1.3. Generate Secret Key Material Locally
Regardless of protocol used (S/MIME or PGP), when producing Regardless of the protocol used (S/MIME or PGP), when producing
certificates for the end user, the MUA SHOULD ensure that it has certificates for the end user, the MUA SHOULD ensure that it has
generated secret key material locally, and MUST NOT accept secret key generated secret key material locally and MUST NOT accept secret key
material from an untrusted external party as the basis for the user's material from an untrusted external party as the basis for the user's
certificate. For example, a user who trusts their system certificate. For example, a user who trusts their system
administrator not to compromise their MUA may accept secret key administrator not to compromise their MUA may accept secret key
material generated by the sysadmin, but probably should not accept material generated by the sysadmin but probably should not accept
secret key material generated by an unaffiliated online web service. secret key material generated by an unaffiliated online web service.
An MUA that accepts secret key material from a third party cannot An MUA that accepts secret key material from a third party cannot
prevent that third party from retaining this material. A third party prevent that third party from retaining this material. A third party
with this level of access could decrypt messages intended to be with this level of access could decrypt messages intended to be
confidential for the user, or could forge messages that would appear confidential for the user or could forge messages that would appear
to come from the user. to come from the user.
8.2.2. Local Certificate Maintenance 8.2.2. Local Certificate Maintenance
In the context of a single e-mail account managed by an MUA, where In the context of a single email account managed by an MUA, where
that e-mail account is expected to be able to use end-to-end that email account is expected to be able to use end-to-end
cryptographic protections, the MUA SHOULD warn the user (or cryptographic protections, the MUA SHOULD warn the user (or
proactively fix the problem) when/if: proactively fix the problem) when/if:
* For S/MIME, the user's own certificate set for the account does * For S/MIME, the user's own certificate set for the account does
not include a valid, unexpired encryption-capable X.509 not include a valid, unexpired encryption-capable X.509
certificate, and a valid, unexpired signature-capable X.509 certificate and a valid, unexpired signature-capable X.509
certificate. certificate.
* For PGP/MIME, the user's own certificate does not include a valid, * For PGP/MIME, the user's own certificate does not include a valid,
unexpired signing-capable key/subkey and a valid, unexpired unexpired signing-capable key/subkey and a valid, unexpired
encryption-capable key/subkey. encryption-capable key/subkey.
* Any of the user's own certificates for the account: * Any of the user's own certificates for the account:
- is due to expire in the next month (or at some other reasonable - are due to expire in the next month (or at some other
cadence). reasonable cadence).
- not match the e-mail address associated with the account in - do not match the email address associated with the account in
question. question.
* Any of the user's own S/MIME certificates for the account: * Any of the user's own S/MIME certificates for the account:
- does not have a keyUsage extension. - do not have a keyUsage extension.
- does not contain an extendedKeyUsage extension. - do not contain an extendedKeyUsage extension.
- would be considered invalid by the MUA for any other reason if - would be considered invalid by the MUA for any other reason if
it were a peer certificate. it were a peer certificate.
An MUA that takes active steps to fix any of these problems before An MUA that takes active steps to fix any of these problems before
they arise is even more usable than just warning, but guidance on how they arise is even more usable than just warning, but guidance on how
to do active certificate maintenance is beyond scope for this current to do active certificate maintenance is beyond the scope of this
document (see Appendix A.4.3). document (see Appendix A.4.3).
If the MUA does find any of these issues and chooses to warn the If the MUA does find any of these issues and chooses to warn the
user, it should use one aggregate warning with simple language that user, it should use one aggregate warning with simple language that
the certificates might not be acceptable for other people, and the certificates might not be acceptable for other people and
recommend a course of action that the user can take to remedy the recommend a course of action that the user can take to remedy the
problem. problem.
8.2.3. Shipping Certificates in Outbound Messages 8.2.3. Shipping Certificates in Outbound Messages
When sending mail, a conformant MUA SHOULD include copies of the When sending mail, a conformant MUA SHOULD include copies of the
user's own certificates (and potentially other certificates) in each user's own certificates (and potentially other certificates) in each
message to facilitate future communication, unless it has specific message to facilitate future communication, unless it has specific
knowledge that the other parties involved already know the relevant knowledge that the other parties involved already know the relevant
keys (for example, if it is mail between members within a domain that keys (for example, if it is mail between members within a domain that
has a synchronized and up-to-date certificate directory). has a synchronized and up-to-date certificate directory).
The mechanism for including these certificates, and which The mechanism for including these certificates, and which
certificates to include in the message, are protocol specific. certificates to include in the message, are protocol specific.
8.2.3.1. Shipping Certificates in S/MIME Messages 8.2.3.1. Shipping Certificates in S/MIME Messages
In any S/MIME SignedData object, certificates can be shipped in the In any S/MIME SignedData object, certificates can be shipped in the
"certificates" member. In S/MIME EnvelopedData object, certificates "certificates" member. In any S/MIME EnvelopedData object,
can be shipped in the "originatorInfo.certs" member. certificates can be shipped in the "originatorInfo.certs" member.
When a single S/MIME-protected e-mail message is encrypted and When a single S/MIME-protected email message is encrypted and signed,
signed, it is usually sufficient to ship all the relevant it is usually sufficient to ship all the relevant certificates in the
certificates in the inner SignedData object's "certificates" member. inner SignedData object's "certificates" member.
The S/MIME certificates shipped in such a message SHOULD include: The S/MIME certificates shipped in such a message SHOULD include:
* The user's own S/MIME signing certificate, so that signature on * the user's own S/MIME signing certificate, so that signature on
the current message can be validated. the current message can be validated.
* The user's own S/MIME encryption-capable certificate, so that the * the user's own S/MIME encryption-capable certificate, so that the
recipient can reply in encrypted form. recipient can reply in encrypted form.
* On an encrypted message to multiple recipients, the encryption- * on an encrypted message to multiple recipients, the encryption-
capable peer certificates of the other recipients, so that any capable peer certificates of the other recipients, so that any
recipient can easily "reply all" without needing to search for recipient can easily "reply all" without needing to search for
certificates. certificates.
* Any intermediate CA certificates needed to chain all of the above * any intermediate certification authority (CA) certificates needed
to a widely-trusted set of root authorities. to chain all of the above to a widely trusted set of root
authorities.
8.2.3.2. Shipping Certificates in PGP/MIME Messages 8.2.3.2. Shipping Certificates in PGP/MIME Messages
PGP/MIME does not have a single specific standard location for PGP/MIME does not have a single specific standard location for
shipping certificates. shipping certificates.
Some MUAs ship relevant OpenPGP certificates in a single MIME leaf of Some MUAs ship relevant OpenPGP certificates in a single MIME leaf of
Content-Type "application/pgp-keys". When such a message has Content-Type "application/pgp-keys". When such a message has
cryptographic protections, to ensure that the message is well-formed, cryptographic protections, to ensure that the message is well-formed,
this kind of MIME part SHOULD be a leaf of the Cryptographic Payload, this kind of MIME part SHOULD be a leaf of the Cryptographic Payload
and not outside of it. One problem with this approach is that it and not outside of it. One problem with this approach is that it
appears to recipients with non-cryptographic MUAs as an "attachment", appears to recipients with non-cryptographic MUAs as an "attachment",
which can lead to confusion if the user does not know how to use it. which can lead to confusion if the user does not know how to use it.
Other implementations ship relevant OpenPGP certificates in Other implementations ship relevant OpenPGP certificates in
"Autocrypt" or "Autocrypt-Gossip" message header fields (see "Autocrypt" or "Autocrypt-Gossip" message header fields (see
[AUTOCRYPT]). To ensure that those header fields receive the same [AUTOCRYPT]). To ensure that those header fields receive the same
cryptographic authenticity as the rest of the message, these header cryptographic authenticity as the rest of the message, these header
fields SHOULD be protected as described in fields SHOULD be protected as described in [RFC9788].
[I-D.ietf-lamps-header-protection].
The OpenPGP certificates shipped in such a message SHOULD include: The OpenPGP certificates shipped in such a message SHOULD include:
* The user's own OpenPGP certificate, capable of both signing and * the user's own OpenPGP certificate, capable of both signing and
encryption, so that the user can validate the message's signature encryption, so that the user can validate the message's signature
and can encrypt future messages and can encrypt future messages.
* On an encrypted message to multiple recipients, the OpenPGP * on an encrypted message to multiple recipients, the OpenPGP
certificates of the other recipients, so that any recipient can certificates of the other recipients, so that any recipient can
easily "reply all" without needing to search for certificates. easily "reply all" without needing to search for certificates.
9. Common Pitfalls and Guidelines 9. Common Pitfalls and Guidelines
This section highlights a few "pitfalls" and guidelines based on This section highlights a few "pitfalls" and guidelines based on
these discussions and lessons learned. these discussions and lessons learned.
9.1. Reading Sent Messages 9.1. Reading Sent Messages
When sending a message, a typical MUA will store a copy of the When sending a message, a typical MUA will store a copy of the
message sent in sender's Sent mail folder so that the sender can read message sent in sender's Sent mail folder so that the sender can read
it later. If the message is an encrypted message, storing it it later. If the message is an encrypted message, storing it
encrypted requires some forethought to ensure that the sender can encrypted requires some forethought to ensure that the sender can
read it in the future. read it in the future.
It is a common and simple practice to encrypt the message not only to It is a common and simple practice to encrypt the message not only to
the recipients of the message, but also to the sender. One advantage the recipients of the message but also to the sender. One advantage
of doing this is that the message that is sent on the wire can be of doing this is that the message that is sent on the wire can be
identical to the message stored in the sender's Sent mail folder. identical to the message stored in the sender's Sent mail folder.
This allows the sender to review and re-read the message even though This allows the sender to review and reread the message even though
it was encrypted. it was encrypted.
There are at least three other approaches that are possible to ensure There are at least three other approaches that are possible to ensure
future readability by the sender of the message, but with different future readability by the sender of the message but with different
tradeoffs: trade-offs:
* Encrypt two versions of the message: one to the recipients (this * 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 sent on the wire) and one to the sender only (this
version is stored in the sender's Sent folder). This approach version is stored in the sender's Sent folder). This approach
means that the message stored in the Sent folder is not byte-for- means that the message stored in the Sent folder is not byte-for-
byte identical to the message sent to the recipients. In the byte identical to the message sent to the recipients. In the
event that message delivery has a transient failure, the MUA event that message delivery has a transient failure, the MUA
cannot simply re-submit the stored message into the SMTP system cannot simply resubmit the stored message into the SMTP system and
and expect it to be readable by the recipient. expect it to be readable by the recipient.
* Store a cleartext version of the message in the Sent folder. This * Store a cleartext version of the message in the Sent folder. This
presents a risk of information leakage: anyone with access to the presents a risk of information leakage: Anyone with access to the
Sent folder can read the contents of the message. Furthermore, Sent folder can read the contents of the message. Furthermore,
any attempt to re-send the message needs to also re-apply the any attempt to resend the message needs to also reapply the
cryptographic transformation before sending, or else the message cryptographic transformation before sending, or else the message
contents will leak upon re-send. A conformant MUA SHOULD NOT contents will leak upon resend. A conformant MUA SHOULD NOT store
store a cleartext copy in the Sent folder unless it knows that the a cleartext copy in the Sent folder unless it knows that the Sent
Sent folder cannot be read by an attacker. For example, if end- folder cannot be read by an attacker. For example, if end-to-end
to-end confidentiality is desired, then storing the cleartext in confidentiality is desired, then storing the cleartext in an IMAP
an IMAP folder where a potentially adversarial server can read it folder where a potentially adversarial server can read it defeats
defeats the purpose. the purpose.
* A final option is that the MUA can store a copy of the message's * A final option is that the MUA can store a copy of the message's
encryption session key. Standard e-mail encryption mechanisms encryption session key. Standard email encryption mechanisms
(e.g., S/MIME and PGP/MIME) are hybrid mechanisms: the asymmetric (e.g., S/MIME and PGP/MIME) are hybrid mechanisms: The asymmetric
encryption steps simply encrypt a symmetric "session key", which encryption steps simply encrypt a symmetric "session key", which
is used to encrypt the message itself. If the MUA stores the is used to encrypt the message itself. If the MUA stores the
session key itself, it can use the session key to decrypt the Sent session key itself, it can use the session key to decrypt the Sent
message without needing the Sent message to be decryptable by the message without needing the Sent message to be decryptable by the
user's own asymmetric key. An MUA doing this must take care to user's own asymmetric key. An MUA doing this must take care to
store (and backup) its stash of session keys, because if it loses store (and backup) its stash of session keys, because if it loses
them it will not be able to read the sent messages; and if someone them, it will not be able to read the sent messages; and if
else gains access to them, they can decrypt the sent messages. someone else gains access to them, they can decrypt the sent
This has the additional consequence that any other MUA accessing messages. This has the additional consequence that any other MUA
the same Sent folder cannot decrypt the message unless it also has accessing the same Sent folder cannot decrypt the message unless
access to the stashed session key. it also has access to the stashed session key.
9.2. Reading Encrypted Messages after Certificate Expiration 9.2. Reading Encrypted Messages after Certificate Expiration
When encrypting a message, the sending MUA should decline to encrypt When encrypting a message, the sending MUA should decline to encrypt
to an expired certificate (see Section 8.1.1). But when decrypting a 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 message, as long as the viewing MUA has access to the appropriate
secret key material, it should permit decryption of the message, even secret key material, it should permit decryption of the message, even
if the associated certificate is expired. That is, the viewing MUA if the associated certificate is expired. That is, the viewing MUA
should not prevent the user from reading a message that they have should not prevent the user from reading a message that they have
already received. already received.
The viewing MUA may warn the user when decrypting a message that The viewing MUA may warn the user when decrypting a message that
appears to have been encrypted to an encryption-capable certificate appears to have been encrypted to an encryption-capable certificate
that was expired at the time of encryption (e.g., based on the Date: 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 header field of the message or the timestamp in the cryptographic
signature), but otherwise should not complain. signature) but otherwise should not complain.
The primary goal of certificate expiration is to facilitate rotation The primary goal of certificate expiration is to facilitate rotation
of secret key material, so that secret key material does not need to of secret key material, so that secret key material does not need to
be retained indefinitely. Certificate expiration permits the user to be retained indefinitely. Certificate expiration permits the user to
destroy an older secret key if access to the messages received under destroy an older secret key if access to the messages received under
it is no longer necessary (see also Appendix A.10). it is no longer necessary (see also Appendix A.10).
9.3. Unprotected Message Header Fields 9.3. Unprotected Message Header Fields
Many legacy cryptographically-aware MUAs only apply cryptographic Many legacy cryptographically aware MUAs only apply cryptographic
protections to the body of the message, but leave the header fields protections to the body of the message but leave the header fields
unprotected. This gives rise to vulnerabilities like information unprotected. This gives rise to vulnerabilities like information
leakage (e.g., the Subject line is visible to a passive intermediary) leakage (e.g., the Subject line is visible to a passive intermediary)
or message tampering (e.g., the Subject line is replaced, effectively or message tampering (e.g., the Subject line is replaced, effectively
changing the semantics of a signed message). These are not only changing the semantics of a signed message). These are not only
security vulnerabilities, but usability problems, because the security vulnerabilities but also usability problems, because the
distinction between what is a header and what is the body of a distinction between what is a header and what is the body of a
message is unclear to many end users, and requires a more complex message is unclear to many end users and requires a more complex
mental model than is necessary. Useful security comes from alignment mental model than is necessary. Useful security comes from alignment
between simple mental models and tooling. between simple mental models and tooling.
To avoid these concerns, a conformant MUA MUST implement header To avoid these concerns, a conformant MUA MUST implement Header
protection as described in [I-D.ietf-lamps-header-protection]. Protection as described in [RFC9788].
Note that some message header fields, like List-*, Archived-At, and Note that some message header fields, such as List-*, Archived-At,
Resent-* are typically added by an intervening MUA (see Section 9.8), and Resent-*, are typically added by an intervening MUA (see
not by one of the traditional "ends" of an end-to-end e-mail Section 9.8), not by one of the traditional "ends" of an end-to-end
exchange. A receiving MUA may choose to consider the contents of email exchange. A receiving MUA may choose to consider the contents
these header fields on an end-to-end protected message as markers of these header fields on an end-to-end protected message as markers
added during message transit, even if they are not covered by the added during message transit, even if they are not covered by the
end-to-end cryptographic protection. end-to-end cryptographic protection.
9.4. Composing an Encrypted Message with Bcc 9.4. Composing an Encrypted Message with Bcc
When composing an encrypted message containing at least one recipient When composing an encrypted message containing at least one recipient
address in the Bcc header field, there is a risk that the encrypted address in the Bcc header field, there is a risk that the encrypted
message itself could leak information about the actual recipients, message itself could leak information about the actual recipients,
even if the Bcc header field does not mention the recipient. For even if the Bcc header field does not mention the recipient. For
example, if the message clearly indicates which certificates it is example, if the message clearly indicates which certificates it is
encrypted to, the set of certificates can identify the recipients encrypted to, the set of certificates can identify the recipients
even if they are not named in the message header fields. even if they are not named in the message header fields.
Because of these complexities, there are several interacting factors Because of these complexities, there are several interacting factors
that need to be taken into account when composing an encrypted that need to be taken into account when composing an encrypted
message with Bcc'ed recipients. message with Bcc'ed recipients.
* Section 3.6.3 of [RFC5322] describes a set of choices about * Section 3.6.3 of [RFC5322] describes a set of choices about
whether (and how) to populate the Bcc field explicitly on Bcc'ed whether (and how) to populate the Bcc field explicitly on Bcc'ed
copies of the message, and in the copy stored in the sender's Sent copies of the message and in the copy stored in the sender's Sent
folder. folder.
* When separate copies are made for Bcced recipients, should each * When separate copies are made for Bcc'ed recipients, should each
separate copy _also_ be encrypted to the named recipients, or just separate copy _also_ be encrypted to the named recipients or just
to the designated Bcc recipient? to the designated Bcc recipient?
* When a copy is stored in the Sent folder, should that copy also be * When a copy is stored in the Sent folder, should that copy also be
encrypted to Bcced recipients? (see also Section 9.1) encrypted to Bcc'ed recipients? (See also Section 9.1.)
* When a message is encrypted, if there is a mechanism to include * When a message is encrypted, if there is a mechanism to include
the certificates of the recipients, whose certificates should be the certificates of the recipients, whose certificates should be
included? included?
9.4.1. Simple Encryption with Bcc 9.4.1. Simple Encryption with Bcc
Here is a simple approach that tries to minimize the total number of Here is a simple approach that tries to minimize the total number of
variants of the message created while leaving a coherent view of the variants of the message created while leaving a coherent view of the
message itself: message itself:
skipping to change at page 42, line 23 skipping to change at line 1885
* Any Bcc'ed recipient MUST NOT be taken into consideration when * Any Bcc'ed recipient MUST NOT be taken into consideration when
determining which certificates to include in the message. In determining which certificates to include in the message. In
particular, certificates for Bcc'ed recipients MUST NOT included particular, certificates for Bcc'ed recipients MUST NOT included
in any message. in any message.
9.4.1.1. Rationale 9.4.1.1. Rationale
The approach described in Section 9.4.1 aligns the list of The approach described in Section 9.4.1 aligns the list of
cryptographic recipients as closely as possible with the set of named cryptographic recipients as closely as possible with the set of named
recipients, while still allowing a Bcced recipient to read their own recipients while still allowing a Bcc'ed recipient to read their own
copy, and to "Reply All" should they want to. copy and to "reply all", should they want to.
This should reduce user confusion on the receiving side: a recipient This should reduce user confusion on the receiving side: A recipient
of such a message who naively looks at the user-facing header fields of such a message who naively looks at the user-facing header fields
from their own mailbox will have a good sense of what cryptographic from their own mailbox will have a good sense of what cryptographic
treatments have been applied to the message. It also simplifies treatments have been applied to the message. It also simplifies
message composition and user experience: the message composer sees message composition and user experience: The message composer sees
fields that match their expectations about what will happen to the fields that match their expectations about what will happen to the
message. Additionally, it may preserve the ability for a Bcc'ed message. Additionally, it may preserve the ability for a Bcc'ed
recipient to retain their anonymity, should they need to offer the recipient to retain their anonymity, should they need to offer the
signed cryptographic payload to an outside party as proof of the signed cryptographic payload to an outside party as proof of the
original sender's intent without revealing their own identity. original sender's intent without revealing their own identity.
9.5. Draft Messages 9.5. Draft Messages
When composing a message, most MUAs will save a copy of the as-yet- When composing a message, most MUAs will save a copy of the as-yet-
unsent message to a "Drafts" folder. If that folder is itself stored unsent message to a "Drafts" folder. If that folder is itself stored
skipping to change at page 43, line 6 skipping to change at line 1914
would be a mistake to store the draft message in the clear, because would be a mistake to store the draft message in the clear, because
its contents could leak. its contents could leak.
This is the case even if the message is ultimately sent deliberately This is the case even if the message is ultimately sent deliberately
in the clear. During message composition, the MUA does not know in the clear. During message composition, the MUA does not know
whether the message is intended to be sent encrypted or not. For whether the message is intended to be sent encrypted or not. For
example, just before sending, the sender could decide to encrypt the example, just before sending, the sender could decide to encrypt the
message, and the MUA would have had no way of knowing. message, and the MUA would have had no way of knowing.
The MUA SHOULD encrypt all draft messages, unless it has explicit The MUA SHOULD encrypt all draft messages, unless it has explicit
knowledge that the message will not be encrypted when sent, or that knowledge that the message will not be encrypted when sent or that
the Drafts folder cannot be read by an attacker. For example, if the Drafts folder cannot be read by an attacker. For example, if
end-to-end confidentiality is desired, then storing a cleartext draft end-to-end confidentiality is desired, then storing a cleartext draft
in an IMAP folder where a potentially adversarial server can read it in an IMAP folder where a potentially adversarial server can read it
defeats the purpose. defeats the purpose.
Furthermore, when encrypting a draft message, the message draft MUST Furthermore, when encrypting a draft message, the message draft MUST
only be encrypted to the user's own certificate, or to some only be encrypted to the user's own certificate or to some equivalent
equivalent secret key that only the user possesses. A draft message secret key that only the user possesses. A draft message encrypted
encrypted in this way can be decrypted when the user wants to resume in this way can be decrypted when the user wants to resume composing
composing the message, but cannot be read by anyone else, including a the message but cannot be read by anyone else, including a potential
potential intended recipient. Note that a draft message encrypted in intended recipient. Note that a draft message encrypted in this way
this way will only be resumable by another MUA attached to the same will only be resumable by another MUA attached to the same mailbox if
mailbox if that other MUA has access to the user's decryption-capable that other MUA has access to the user's decryption-capable secret
secret key. This shared access to key material is also likely key. This shared access to key material is also likely necessary for
necessary for useful interoperability, but is beyond the scope of useful interoperability but is beyond the scope of this document (see
this document (see Appendix A.4.1). Appendix A.4.1).
A conformant MUA MUST NOT sign a message draft with the user's normal A conformant MUA MUST NOT sign a message draft with the user's normal
signing key. If draft signing is intended for cryptographic signing key. If draft signing is intended for cryptographic
coordination between multiple MUAs of the same user, it should be coordination between multiple MUAs of the same user, it should be
negotiated with a different key (but see Appendix A.4.1). negotiated with a different key (but see Appendix A.4.1).
The message should only be encrypted to its recipients upon actually The message should only be encrypted to its recipients upon actually
sending the message. No reasonable user expects their message's sending the message. No reasonable user expects their message's
intended recipients to be able to read a message that is not yet intended recipients to be able to read a message that is not yet
complete. complete.
skipping to change at page 44, line 5 skipping to change at line 1962
Carol's MUA can: Carol's MUA can:
1. send encrypted to Alice and Bob, knowing that Bob will be unable 1. send encrypted to Alice and Bob, knowing that Bob will be unable
to read the message. to read the message.
2. send encrypted to Alice only, dropping Bob from the message 2. send encrypted to Alice only, dropping Bob from the message
recipient list. recipient list.
3. send the message in the clear to both Alice and Bob. 3. send the message in the clear to both Alice and Bob.
4. send an encrypted copy of the message to Alice, and a cleartext 4. send an encrypted copy of the message to Alice and a cleartext
copy to Bob. copy to Bob.
Each of these strategies has different drawbacks. Each of these strategies has different drawbacks.
The problem with approach 1 is that Bob will receive unreadable mail. The problem with approach 1 is that Bob will receive unreadable mail.
The problem with approach 2 is that Carol's MUA will not send the The problem with approach 2 is that Carol's MUA will not send the
message to Bob, despite Carol asking it to. message to Bob, despite Carol asking it to.
The problem with approach 3 is that Carol's MUA will not encrypt the The problem with approach 3 is that Carol's MUA will not encrypt the
message, despite Carol asking it to. message, despite Carol asking it to.
Approach 4 has two problems: Approach 4 has two problems:
* Carol's MUA will release a cleartext copy of the message, despite 1. Carol's MUA will release a cleartext copy of the message, despite
Carol asking it to send the message encrypted. Carol asking it to send the message encrypted.
* If Alice wants to "reply all" to the message, she may not be able 2. If Alice wants to "reply all" to the message, she may not be able
to find an encryption-capable certificate for Bob either. This to find an encryption-capable certificate for Bob either. This
puts Alice in an awkward and confusing position, one that users puts Alice in an awkward and confusing position, one that users
are unlikely to understand. In particular, if Alice's MUA is are unlikely to understand. In particular, if Alice's MUA is
following the guidance about replies to encrypted messages in following the guidance about replies to encrypted messages in
Section 5.4, having received an encrypted copy will make Alice's Section 5.4, having received an encrypted copy will make Alice's
Reply buffer behave in an unusual fashion. reply buffer behave in an unusual fashion.
This is particularly problematic when the second recipient is not This is particularly problematic when the second recipient is not
"Bob" but in fact a public mailing list or other visible archive, "Bob" but in fact a public mailing list or other visible archive,
where messages are simply never encrypted. where messages are simply never encrypted.
Carol is unlikely to understand the subtleties and negative Carol is unlikely to understand the subtleties and negative
downstream interactions involved with approaches 1 and 4, so downstream interactions involved with approaches 1 and 4, so
presenting the user with those choices is not advised. presenting the user with those choices is not advised.
The most understandable approach for an MUA with an active user is to The most understandable approach for an MUA with an active user is to
ask the user (when they hit "send") to choose between approach 2 and ask the user (when they hit "send") to choose between approach 2 and
approach 3. If the user declines to choose between 2 and 3, the MUA approach 3. If the user declines to choose between 2 and 3, the MUA
can drop them back to their message composition window and let them can drop them back to their message composition window and let them
make alternate adjustments. make alternate adjustments.
See also further discussion of these scenarios in See also further discussion of these scenarios in [CLEARTEXT-COPY].
[I-D.dkg-mail-cleartext-copy].
9.7. Message Transport Protocol Proxy: A Dangerous Implementation 9.7. Message Transport Protocol Proxy: A Dangerous Implementation
Choice Choice
An implementer of end-to-end cryptographic protections may be tempted An implementer of end-to-end cryptographic protections may be tempted
by a simple software design that piggybacks off of a mail protocol by a simple software design that piggybacks off of a mail protocol,
like SMTP Submission ([RFC6409]), IMAP ([RFC9051]), or JMAP like SMTP Submission [RFC6409], IMAP [RFC9051], or JSON Meta
([RFC8621]) to handle message assembly and interpretation. In such Application Protocol (JMAP) [RFC8621], to handle message assembly and
an architecture, a naive MUA speaks something like a "standard" interpretation. In such an architecture, a naive MUA speaks
protocol like SMTP, IMAP, or JMAP to a local proxy, and the proxy something like a "standard" protocol, like SMTP, IMAP, or JMAP, to a
handles signing and encryption (outbound), and decryption and local proxy, and the proxy handles signing and encryption (outbound)
verification (inbound) internally on behalf of the user. While such and decryption and verification (inbound) internally on behalf of the
a "pluggable" architecture has the advantage that it is likely to be user. While such a "pluggable" architecture has the advantage of
easy to apply to any mail user agent, it is problematic for the goals likely being easy to apply to any mail user agent, it is problematic
of end-to-end communication, especially in an existing cleartext for the goals of end-to-end communication, especially in an existing
ecosystem like e-mail, where any given message might be unsigned or cleartext ecosystem like email, where any given message might be
signed, cleartext or encrypted. In particular: unsigned or signed, cleartext or encrypted. In particular:
* the user cannot easily and safely identify what protections any * the user cannot easily and safely identify what protections any
particular message has (including messages currently being particular message has (including messages currently being
composed), and composed) and
* the proxy itself is unaware of subtle nuances about the message * the proxy itself is unaware of subtle nuances about the message
that the MUA actually knows. that the MUA actually knows.
With a trustworthy and well-synchronized sidechannel or protocol With a trustworthy and well-synchronized side channel or protocol
extension between the MUA and the proxy, it is possible to deploy extension between the MUA and the proxy, it is possible to deploy
such an implementation safely, but the requirement for the such an implementation safely, but the requirement for the side
sidechannel or extension eliminates the universal-deployability channel or extension eliminates the universal deployability advantage
advantage of the scheme. of the scheme.
Similar concerns apply to any implementation bound by an API which Similar concerns apply to any implementation bound by an API that
operates on message objects alone, without any additional contextual operates on message objects alone, without any additional contextual
parameters. parameters.
This section attempts to document some of the inherent risks involved This section attempts to document some of the inherent risks involved
with such an architecture. with such an architecture.
9.7.1. Dangers of a Submission Proxy for Message Composition 9.7.1. Dangers of a Submission Proxy for Message Composition
When composing and sending a message, the act of applying When composing and sending a message, the act of applying
cryptographic protections has subtleties that cannot be directly cryptographic protections has subtleties that cannot be directly
expressed in the SMTP protocol used by Submission [RFC6409], or in expressed in the SMTP protocol used by Submission [RFC6409] or in any
any other simple protocol that hands off a cleartext message for other simple protocol that hands off a cleartext message for further
further processing. processing.
For example, the sender cannot indicate via SMTP whether or not a For example, the sender cannot indicate via SMTP whether or not a
given message _should_ be encrypted (some messages, like those sent given message _should_ be encrypted (some messages, such as those
to a publicly archived mailing list, are pointless to encrypt), or sent to a publicly archived mailing list, are pointless to encrypt)
select among multiple certificates for a recipient, if they exist or selected among multiple certificates for a recipient, if they
(see Section 8.1.1). exist (see Section 8.1.1).
Likewise, because such a proxy only interacts with the message when Likewise, because such a proxy only interacts with the message when
it is ready to be sent, it cannot indicate back to the user _during it is ready to be sent, it cannot indicate back to the user _during
message composition_ whether or not the message is able to be message composition_ whether or not the message is able to be
encrypted (that is, whether a valid certificate is available for each encrypted (that is, whether a valid certificate is available for each
intended recipient). A message author may write an entirely intended recipient). A message author may write an entirely
different message if they know that it will be protected end-to-end; different message if they know that it will be protected end-to-end;
but without this knowledge, the author is obliged either to write however, without this knowledge, the author is obliged to either
text that they presume will be intercepted, or to risk revealing write text that they presume will be intercepted or risk revealing
sensitive content. sensitive content.
Even without encryption, deciding whether to sign or not (and which Even without encryption, deciding whether to sign or not (and which
certificate to sign with, if more than one exists) is another choice certificate to sign with, if more than one exists) is another choice
that the proxy is ill-equipped to make. The common message-signing that the proxy is ill-equipped to make. The common message-signing
techniques either render a message unreadable by any non- techniques either render a message unreadable by any non-
cryptographic MUA (i.e., PKCS7 signed-data), or appear as an cryptographic MUA (i.e., PKCS #7 signed-data) or appear as an
attachment that can cause confusion to a naive recipient using a non- attachment that can cause confusion to a naive recipient using a non-
cryptographic MUA (i.e., multipart/signed). If the sender knows that cryptographic MUA (i.e., multipart/signed). If the sender knows that
the recipient will not check signatures, they may prefer to leave a the recipient will not check signatures, they may prefer to leave a
cleartext message without a cryptographic signature at all. cleartext message without a cryptographic signature at all.
Furthermore, handling encryption properly depends on the context of Furthermore, handling encryption properly depends on the context of
any given message, which cannot be expressed by the MUA to the any given message, which cannot be expressed by the MUA to the
Submission proxy. For example, decisions about how to handle Submission proxy. For example, decisions about how to handle
encryption and quoted or attributed text may depend on the encryption and quoted or attributed text may depend on the
cryptographic status of the message that is being replied to (see cryptographic status of the message that is being replied to (see
Section 5.4). Section 5.4).
Additionally, such a proxy would need to be capable of managing the Additionally, such a proxy would need to be capable of managing the
user's own key and certificate (see Section 8.2). How will the user's own key and certificate (see Section 8.2). For example, how
implementation indicate to the user when their own certificate is will the implementation indicate to the user when their own
near expiry, for example? How will any other error conditions be certificate is near expiry? How will any other error conditions be
handled when communication with the user is needed? handled when communication with the user is needed?
While an extension to SMTP might be able to express all the necessary While an extension to SMTP might be able to express all the necessary
semantics that would allow a generic MUA to compose messages with semantics that would allow a generic MUA to compose messages with
standard cryptographic protections via a proxy, such an extension is standard cryptographic protections via a proxy, such an extension is
beyond the scope of this document. See beyond the scope of this document. See [SMIME-SENDER-EXTENSIONS] for
[I-D.ietf-jmap-smime-sender-extensions] for an example of how an MUA an example of how an MUA using a proxy protocol might indicate
using a proxy protocol might indicate signing and encryption signing and encryption instructions to its proxy.
instructions to its proxy.
9.7.2. Dangers of an IMAP Proxy for Message Rendering 9.7.2. Dangers of an IMAP Proxy for Message Rendering
When receiving and rendering a message, the process of indicating to When receiving and rendering a message, the process of indicating the
the user the cryptographic status of a message requires subtleties cryptographic status of a message to the user requires subtleties
that are difficult to offer from a straightforwad IMAP (or POP that are difficult to offer from a straightforward IMAP (or Post
[RFC1939], or JMAP) proxy. Office Protocol (POP) [RFC1939] or JMAP) proxy.
One approach such a proxy could take is to remove all the One approach such a proxy could take is to remove all the
Cryptographic Layers from a well-formed message, and to package a Cryptographic Layers from a well-formed message and to package a
description of those layers into a special header field that the MUA description of those layers into a special header field that the MUA
can read. But this merely raises the question: what semantics need can read. But this merely raises the question: What semantics need
to be represented? For example: to be represented? For example:
* Was the message signed? If so, by whom? When? * Was the message signed? If so, by whom? When?
* Should the details of the cryptographic algorithms used in any * Should the details of the cryptographic algorithms used in any
signatures found be indicated as well? signatures found be indicated as well?
* Was the message encrypted? if so, to whom? What key was used to * Was the message encrypted? If so, by whom? What key was used to
decrypt it? decrypt it?
* If both signed and encrypted, was the signing outside the * If both signed and encrypted, was the signing outside or inside
encryption or inside? the encryption?
* How should errant Cryptographic Layers (see Section 4.5) be dealt * How should errant Cryptographic Layers (see Section 4.5) be dealt
with? with?
* What cryptographic protections do the header fields of the message * What cryptographic protections do the header fields of the message
have? (see [I-D.ietf-lamps-header-protection]) have? (See [RFC9788].)
* How are any errors or surprises communicated to the user? * How are any errors or surprises communicated to the user?
If the proxy passes any of this cryptographic status to the client in If the proxy passes any of this cryptographic status to the client in
an added header field, it must also ensure that no such header field an added header field, it must also ensure that no such header field
is present on the messages it receives before processing it. If it is present on the messages it receives before processing it. If it
were to allow such a header field through unmodified to any client were to allow such an unmodified header field through to any client
that is willing to trust its contents, an attacker could spoof the that is willing to trust its contents, an attacker could spoof the
field to make the user believe lies about the cryptographic status of field to make the user believe lies about the cryptographic status of
the message. In order for an MUA to be confident in such a header the message. In order for an MUA to be confident in such a header
field, then, it needs a guarantee from the proxy that any header it field, it needs a guarantee from the proxy that any header it
produces will be safe. How does the MUA reliably negotiate this produces will be safe. How does the MUA reliably negotiate this
guarantee with the proxy? If the proxy can no longer offer this guarantee with the proxy? If the proxy can no longer offer this
guarantee, how will the MUA know that things have changed? guarantee, how will the MUA know that things have changed?
If such an inbound proxy handles certificate discovery in inbound If such an inbound proxy handles certificate discovery in inbound
messages (see Appendix A.3.1), it will also need to communicate the messages (see Appendix A.3.1), it will also need to communicate the
results of that discovery process to its corresponding outbound proxy results of that discovery process to its corresponding outbound proxy
for message composition (see Section 9.7.1). for message composition (see Section 9.7.1).
While an extension to IMAP (or POP, or JMAP) might be able to express While an extension to IMAP (or POP or JMAP) might be able to express
all the necessary semantics that would allow a generic MUA to all the necessary semantics that would allow a generic MUA to
indicate standardized cryptographic message status, such an extension indicate standardized cryptographic message status, such an extension
is beyond the scope of this document. [RFC9219] describes S/MIME is beyond the scope of this document. [RFC9219] describes the S/MIME
signature verification status over JMAP, which is a subset of the signature verification status over JMAP, which is a subset of the
cryptographic status information described here. cryptographic status information described here.
9.7.3. Who Controls the Proxy? 9.7.3. Who Controls the Proxy?
Finally, consider that the naive proxy deployment approach is risky Finally, consider that the naive proxy deployment approach is risky
precisely because of its opacity to the end user. Such a deployment precisely because of its opacity to the end user. Such a deployment
could be placed anywhere in the stack, including on a machine that is could be placed anywhere in the stack, including on a machine that is
not ultimately controlled by the end user, making it effectively a not ultimately controlled by the end user, making it effectively a
form of transport protection, rather than end-to-end protection. form of transport protection rather than end-to-end protection.
An MUA explicitly under the control of the end user with thoughtful An MUA explicitly under the control of the end user with thoughtful
integration can offer UI/UX and security guarantees that a simple integration can offer UI/UX and security guarantees that a simple
proxy cannot provide. See also Appendix A.13 for suggestions of proxy cannot provide. See also Appendix A.13 for suggestions of
future work that might augment a proxy to make it safer. future work that might augment a proxy to make it safer.
9.8. Intervening MUAs Do Not Handle End-to-End Cryptographic 9.8. Intervening MUAs Do Not Handle End-to-End Cryptographic
Protections Protections
Some Mail User Agents (MUAs) will resend a message in identical form Some Mail User Agents (MUAs) will resend a message in identical form
(or very similar form) to the way that they received it. For (or very similar form) to the way that they received it. For
example, consider the following use cases: example, consider the following use cases:
* A mail expander or mailing list that receives a message and re- * a mail expander or mailing list that receives a message and
sends it to all subscribers (see also Appendix A.14 for more resends it to all subscribers (see also Appendix A.14 for more
discussion of mailing lists). discussion of mailing lists)
* An individual user who reintroduces a message they received into * an individual user who reintroduces a message they received into
the mail transport system (see Section 3.6.6 of [RFC5322]). the mail transport system (see Section 3.6.6 of [RFC5322])
* An automated e-mail intake system that forwards a report to the * an automated email intake system that forwards a report to the
mailboxes of responsible staffers. mailboxes of responsible staffers
These MUAs intervene in message transport by receiving and then re- These MUAs intervene in message transport by receiving and then
injecting messages into the mail transport system. In some cases, reinjecting messages into the mail transport system. In some cases,
the original sender or final recipient of a message that has passed the original sender or final recipient of a message that has passed
through such an MUA may be unaware of the intervention. (Note that through such an MUA may be unaware of the intervention. (Note that
an MUA that forwards a received message as a attachment (MIME an MUA that forwards a received message as a attachment (MIME
subpart) of type message/rfc822 or message/global or "inline" in the 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 body of a message is _not_ acting as an intervening MUA in this
sense, because the forwarded message is encapsulated within a visible sense, because the forwarded message is encapsulated within a visible
outer message that is clearly from the MUA itself.) outer message that is clearly from the MUA itself.)
An intervening MUA should be aware of end-to-end cryptographic An intervening MUA should be aware of end-to-end cryptographic
protections that might already exist on messages that they re-send. protections that might already exist on messages that they resend.
In particular, it is unclear what the "end-to-end" properties are of 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- a message that has been handled by an intervening MUA. For signed-
only messages, if the intervening MUA makes any substantive only messages, if the intervening MUA makes any substantive
modifications to the message as it passes it along, it may break the modifications to the message as it passes it along, it may break the
signature from the original sender. In many cases, breaking the signature from the original sender. In many cases, breaking the
original signature is the appropriate result, since the original original signature is the appropriate result, since the original
message has been modified, and the original sender has no control message has been modified, and the original sender has no control
over the modifications made by the intervening MUA. For encrypted- over the modifications made by the intervening MUA. For encrypted-
and-signed messages, if the intervening MUA is capable of decrypting and-signed messages, if the intervening MUA is capable of decrypting
the message, it must be careful when re-transmitting the message. the message, it must be careful when retransmitting the message.
Will the new recipient be able to decrypt it? If not, will the 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 message be useful to the recipient? If not, it may not make sense to
re-send the message. resend the message.
Beyond the act of re-sending, an intervening MUA should not itself Beyond the act of resending, an intervening MUA should not itself try
try to apply end-to-end cryptographic protections on a message that to apply end-to-end cryptographic protections on a message that it is
it is resending unless directed otherwise by some future resending unless directed otherwise by some future specification.
specification. Additional layers of cryptographic protection added Additional layers of cryptographic protection added in an ad hoc way
in an ad-hoc way by an intervening MUA are more likely to confuse the by an intervening MUA are more likely to confuse the recipient and
recipient and will not be interpretable as end-to-end protections as will not be interpretable as end-to-end protections as they do not
they do not originate with the original sender of the message. originate with the original sender of the message.
9.9. External Subresources in MIME Parts Break Cryptographic 9.9. External Subresources in MIME Parts Break Cryptographic
Protections Protections
A MIME part with a content type that can refer to external resources A MIME part with a content type that can refer to external resources
(like text/html) may itself have some sort of end-to-end (like text/html) may itself have some sort of end-to-end
cryptographic protections. However, retrieving or rendering these cryptographic protections. However, retrieving or rendering these
external resources may violate the properties that users expect from external resources may violate the properties that users expect from
cryptographic protection. cryptographic protection.
As a baseline, retrieving the external resource at the time a message As a baseline, retrieving the external resource at the time a message
is read can be used as a "web bug", leaking the activity and network is read can be used as a "web bug", leaking the activity and network
location of the receiving user to the server hosting the external location of the receiving user to the server hosting the external
resource. This privacy risk is present, of course, even for messages resource. This privacy risk is present, of course, even for messages
with no cryptographic protections, but may be even more surprising to with no cryptographic protections but may be even more surprising to
users who are shown some level of security indicator about a given users who are shown some level of security indicator about a given
message. message.
Other problems with external resources are more specifically bound to Other problems with external resources are more specifically bound to
cryptographic protections. cryptographic protections.
For example, an signed e-mail message with at text/html part that For example, a signed email message with a text/html part that refers
refers to an external image (i.e., via <img src="https://example.com/ to an external image (i.e., via <img src="https://example.com/
img.png">) may render differently if the hosting webserver decides to img.png">) may render differently if the hosting web server decides
serve different content at the source URL for the image. This to serve different content at the source URL for the image. This
effectively breaks the goals of integrity and authenticity that the effectively breaks the goals of integrity and authenticity that the
user should be able to rely on for signed messages, unless the user should be able to rely on for signed messages, unless the
external subresource has strict integrity guarantees (e.g., via external subresource has strict integrity guarantees (e.g., via
[SRI]). [SRI]).
Likewise, fetching an external subresource for an encrypted-and- Likewise, fetching an external subresource for an encrypted-and-
signed message effectively breaks goals of privacy and signed message effectively breaks goals of privacy and
confidentiality for the user. confidentiality for the user.
This is loosely analogous to security indicator problems that arose This is loosely analogous to security indicator problems that arose
for web browsers as described in [mixed-content]. However, while for web browsers as described in [MIXED-CONTENT]. However, while
fetching the external subresource over https is sufficient to avoid a fetching the external subresource over https is sufficient to avoid a
"mixed content" warning from most browsers, it is insufficicent for "mixed content" warning from most browsers, it is insufficient for an
an MUA that wants to offer its users true end-to-end guarantees for MUA that wants to offer its users true end-to-end guarantees for
e-mail messages. email messages.
A conformant sending MUA that applies signing-only cryptographic A conformant-sending MUA that applies signing-only cryptographic
protection to a new e-mail message with an external subresource protection to a new email message with an external subresource should
should take one of the following options: take one of the following options:
* pre-fetch the external subresource and include it in the message * pre-fetch the external subresource and include it in the message
itself, itself,
* use a strong integrity mechanism like Subresource Integrity * use a strong integrity mechanism like Subresource Integrity [SRI]
([SRI]) to guarantee the content of the subresource (though this to guarantee the content of the subresource (though this does not
does not fix the "web bug" privacy risk described above), or fix the "web bug" privacy risk described above), or
* prompt the composing user to remove the subresource from the * prompt the composing user to remove the subresource from the
message. message.
A conformant sending MUA that applies encryption to a new e-mail A conformant-sending MUA that applies encryption to a new email
message with an external resource cannot depend on subresource message with an external resource cannot depend on Subresource
integrity to protect the privacy and confidentiality of the message, Integrity to protect the privacy and confidentiality of the message,
so it should either pre-fetch the external resource to include it in so it should either pre-fetch the external resource to include it in
the message, or prompt the composing user to remove it before the message or prompt the composing user to remove it before sending.
sending.
A conformant receiving MUA that encounters a message with end-to-end A conformant-receiving MUA that encounters a message with end-to-end
cryptographic protections that contain a subresource MUST either cryptographic protections that contain a subresource MUST either
refuse to retrieve and render the external subresource, or it should refuse to retrieve and render the external subresource or decline to
decline to treat the message as having cryptographic protections. treat the message as having cryptographic protections. For example,
For example, it could indicate in the Cryptographic Summary that the it could indicate in the Cryptographic Summary that the message is
message is Unprotected. Unprotected.
Note that when composing a message reply with quoted text from the Note that when composing a message reply with quoted text from the
original message, if the original message did contain an external original message, if the original message did contain an external
resource, the composing MUA SHOULD NOT fetch the external resource resource, the composing MUA SHOULD NOT fetch the external resource
solely to include it in the reply message, as doing so would trigger solely to include it in the reply message, as doing so would trigger
the "web bug" at reply composition time. Instead, the safest way to the "web bug" at reply composition time. Instead, the safest way to
deal with quoted text that contains an external resource in an end- deal with quoted text that contains an external resource in an end-
to-end encrypted reply is to strip any reference to the external to-end encrypted reply is to strip any reference to the external
resource during initial composition of the reply. resource during initial composition of the reply.
10. IANA Considerations 10. IANA Considerations
This document does not require anything from IANA. This document has no IANA actions.
11. Security Considerations 11. Security Considerations
This entire document addresses security considerations about end-to- This entire document addresses security considerations about end-to-
end cryptographic protections for e-mail messages. end cryptographic protections for email messages.
12. Acknowledgements
The set of constructs and recommendations in this document are
derived from discussions with many different implementers, including
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.
13. References
13.1. Normative References 12. References
[I-D.ietf-lamps-header-protection] 12.1. Normative References
Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header
Protection for Cryptographically Protected E-mail", Work
in Progress, Internet-Draft, draft-ietf-lamps-header-
protection-25, 6 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
header-protection-25>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, "MIME Security with OpenPGP", RFC 3156,
DOI 10.17487/RFC3156, August 2001, DOI 10.17487/RFC3156, August 2001,
<https://www.rfc-editor.org/rfc/rfc3156>. <https://www.rfc-editor.org/info/rfc3156>.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005, BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
<https://www.rfc-editor.org/rfc/rfc4289>. <https://www.rfc-editor.org/info/rfc4289>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/rfc/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551, Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/rfc/rfc8551>. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
13.2. Informative References [RFC9788] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header
Protection for Cryptographically Protected Email",
RFC 9788, DOI 10.17487/RFC9788, May 2025,
<https://www.rfc-editor.org/info/rfc9788>.
12.2. Informative References
[AUTOCRYPT] [AUTOCRYPT]
Breitmoser, V., Krekel, H., and D. K. Gillmor, "Autocrypt Autocrypt Team, "Autocrypt - Convenient End-to-End
- Convenient End-to-End Encryption for E-Mail", July 2018, Encryption for E-Mail", <https://autocrypt.org/>.
<https://autocrypt.org/>.
[chrome-indicators] [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", Schechter, E., "Evolving Chrome's security indicators",
May 2018, <https://blog.chromium.org/2018/05/evolving- Chromium Blog, May 2018,
chromes-security-indicators.html>. <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., [DROWN] Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N.,
Dankel, M., Steube, J., Valenta, L., Adrian, D., Dankel, M., Steube, J., Valenta, L., Adrian, D.,
Halderman, J. A., Dukhovni, V., Käsper, E., Cohney, S., Halderman, J. A., Dukhovni, V., Käsper, E., Cohney, S.,
Engels, S., Paar, C., and Y. Shavitt, "DROWN: Breaking TLS Engels, S., Paar, C., and Y. Shavitt, "DROWN: Breaking TLS
using SSLv2", March 2016, <https://drownattack.com/>. 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., [EFAIL] Poddebniak, D., Dresen, C., Müller, J., Ising, F.,
Schinzel, S., Friedberger, S., Somorovsky, J., and J. Schinzel, S., Friedberger, S., Somorovsky, J., and J.
Schwenk, "Efail: breaking S/MIME and OpenPGP email Schwenk, "Efail: Breaking S/MIME and OpenPGP Email
encryption using exfiltration channels", August 2018, Encryption using Exfiltration Channels", Proceedings of
<https://efail.de>. the 27th USENIX Security Symposium (USENIX Security 18),
pp. 549-566, August 2018,
[I-D.dkg-mail-cleartext-copy] <https://www.usenix.org/conference/usenixsecurity18/
Gillmor, D. K., "Encrypted E-mail with Cleartext Copies", presentation/poddebniak>.
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>.
[I-D.ietf-jmap-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>.
[I-D.koch-openpgp-webkey-service] [IKE] Felsch, D., Grothe, M., Schwenk, J., Czubak, A., and M.
Koch, W., "OpenPGP Web Key Directory", Work in Progress, Szymane, "The Dangers of Key Reuse: Practical Attacks on
Internet-Draft, draft-koch-openpgp-webkey-service-19, 5 IPsec IKE", Proceedings of the 27th USENIX Security
December 2024, <https://datatracker.ietf.org/doc/html/ Symposium, pp. 567-583, August 2018,
draft-koch-openpgp-webkey-service-19>. <https://www.usenix.org/system/files/conference/
usenixsecurity18/sec18-felsch.pdf>.
[I-D.woodhouse-cert-best-practice] [MIXED-CONTENT]
Woodhouse, D. and N. Mavrogiannopoulos, "Recommendations Stark, E., Ed., West, M., Ed., and C. Lopez, Ed., "Mixed
for applications using X.509 client certificates", Work in Content", W3C Candidate Recommendation Draft, February
Progress, Internet-Draft, draft-woodhouse-cert-best- 2023,
practice-01, 25 July 2023, <https://www.w3.org/TR/2023/CRD-mixed-content-20230223/>.
<https://datatracker.ietf.org/doc/html/draft-woodhouse- Latest version available at
cert-best-practice-01>. <https://www.w3.org/TR/mixed-content/>.
[I-D.wussler-openpgp-forwarding] [OPENPGP-FORWARDING]
Wussler, A., "Automatic Forwarding for ECDH Curve25519 Wussler, A., "Automatic Forwarding for ECDH Curve25519
OpenPGP messages", Work in Progress, Internet-Draft, OpenPGP messages", Work in Progress, Internet-Draft,
draft-wussler-openpgp-forwarding-00, 10 July 2023, draft-wussler-openpgp-forwarding-00, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-wussler- <https://datatracker.ietf.org/doc/html/draft-wussler-
openpgp-forwarding-00>. openpgp-forwarding-00>.
[IKE] Felsch, D., Grothe, M., Schwenk, J., Czubak, A., and M.
Szymane, "The Dangers of Key Reuse: Practical Attacks on
IPsec IKE", August 2018,
<https://www.usenix.org/system/files/conference/
usenixsecurity18/sec18-felsch.pdf>.
[mixed-content]
"Mixed Content", February 2023,
<https://www.w3.org/TR/mixed-content/>.
[ORACLE] Ising, F., Poddebniak, D., Kappert, T., Saatjohann, C., [ORACLE] Ising, F., Poddebniak, D., Kappert, T., Saatjohann, C.,
and S. Schinzel, "Content-Type: multipart/oracle Tapping and S. Schinzel, "Content-Type: multipart/oracle - Tapping
into Format Oracles in Email End-to-End Encryption", into Format Oracles in Email End-to-End Encryption",
August 2023, Proceedings of the 32nd USENIX Security Symposium (USENIX
Security 23), pp. 4175-4192, August 2023,
<https://www.usenix.org/conference/usenixsecurity23/ <https://www.usenix.org/conference/usenixsecurity23/
presentation/ising>. presentation/ising>.
[PKCS11] Bong, D. and T. Cox, "PKCS", 23 July 2023, [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/ <https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/os/
pkcs11-spec-v3.1-os.html>. pkcs11-spec-v3.1-os.html>.
[REPLY] Müller, J., Brinkmann, M., Poddebniak, D., Schinzel, S., [REPLY] Müller, J., Brinkmann, M., Poddebniak, D., Schinzel, S.,
and J. Schwenk, "Re: What’s Up Johnny?: Covert Content and J. Schwenk, "Re: What's Up Johnny?: Covert Content
Attacks on Email End-to-End Encryption", Springer Attacks on Email End-to-End Encryption", Applied
International Publishing, Lecture Notes in Computer Cryptography and Network Security (ACNS 2019), Lecture
Science pp. 24-42, DOI 10.1007/978-3-030-21568-2_2, Notes in Computer Science, vol. 11464, pp. 24-42,
ISBN ["9783030215675", "9783030215682"], 2019, DOI 10.1007/978-3-030-21568-2_2, April 2019,
<https://doi.org/10.1007/978-3-030-21568-2_2>. <https://doi.org/10.1007/978-3-030-21568-2_2>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<https://www.rfc-editor.org/rfc/rfc1939>. <https://www.rfc-editor.org/info/rfc1939>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/rfc/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <https://www.rfc-editor.org/rfc/rfc3207>. February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3274] Gutmann, P., "Compressed Data Content Type for [RFC3274] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, Cryptographic Message Syntax (CMS)", RFC 3274,
DOI 10.17487/RFC3274, June 2002, DOI 10.17487/RFC3274, June 2002,
<https://www.rfc-editor.org/rfc/rfc3274>. <https://www.rfc-editor.org/info/rfc3274>.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
<https://www.rfc-editor.org/rfc/rfc3370>. <https://www.rfc-editor.org/info/rfc3370>.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, Protocol (LDAP): The Protocol", RFC 4511,
DOI 10.17487/RFC4511, June 2006, DOI 10.17487/RFC4511, June 2006,
<https://www.rfc-editor.org/rfc/rfc4511>. <https://www.rfc-editor.org/info/rfc4511>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/rfc/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S., [RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S.,
and M. Holdrege, "Threats Introduced by Reliable Server and M. Holdrege, "Threats Introduced by Reliable Server
Pooling (RSerPool) and Requirements for Security in Pooling (RSerPool) and Requirements for Security in
Response to Threats", RFC 5355, DOI 10.17487/RFC5355, Response to Threats", RFC 5355, DOI 10.17487/RFC5355,
September 2008, <https://www.rfc-editor.org/rfc/rfc5355>. September 2008, <https://www.rfc-editor.org/info/rfc5355>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/rfc/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/rfc/rfc6409>. <https://www.rfc-editor.org/info/rfc6409>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
and M. Scott, "PKCS #12: Personal Information Exchange and M. Scott, "PKCS #12: Personal Information Exchange
Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
<https://www.rfc-editor.org/rfc/rfc7292>. <https://www.rfc-editor.org/info/rfc7292>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/rfc/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities
(DANE) Bindings for OpenPGP", RFC 7929, (DANE) Bindings for OpenPGP", RFC 7929,
DOI 10.17487/RFC7929, August 2016, DOI 10.17487/RFC7929, August 2016,
<https://www.rfc-editor.org/rfc/rfc7929>. <https://www.rfc-editor.org/info/rfc7929>.
[RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to [RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to
Associate Certificates with Domain Names for S/MIME", Associate Certificates with Domain Names for S/MIME",
RFC 8162, DOI 10.17487/RFC8162, May 2017, RFC 8162, DOI 10.17487/RFC8162, May 2017,
<https://www.rfc-editor.org/rfc/rfc8162>. <https://www.rfc-editor.org/info/rfc8162>.
[RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application [RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application
Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621,
August 2019, <https://www.rfc-editor.org/rfc/rfc8621>. August 2019, <https://www.rfc-editor.org/info/rfc8621>.
[RFC8823] Melnikov, A., "Extensions to Automatic Certificate [RFC8823] Melnikov, A., "Extensions to Automatic Certificate
Management Environment for End-User S/MIME Certificates", Management Environment for End-User S/MIME Certificates",
RFC 8823, DOI 10.17487/RFC8823, April 2021, RFC 8823, DOI 10.17487/RFC8823, April 2021,
<https://www.rfc-editor.org/rfc/rfc8823>. <https://www.rfc-editor.org/info/rfc8823>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051, Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021, DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/rfc/rfc9051>. <https://www.rfc-editor.org/info/rfc9051>.
[RFC9216] Gillmor, D. K., Ed., "S/MIME Example Keys and [RFC9216] Gillmor, D. K., Ed., "S/MIME Example Keys and
Certificates", RFC 9216, DOI 10.17487/RFC9216, April 2022, Certificates", RFC 9216, DOI 10.17487/RFC9216, April 2022,
<https://www.rfc-editor.org/rfc/rfc9216>. <https://www.rfc-editor.org/info/rfc9216>.
[RFC9219] Melnikov, A., "S/MIME Signature Verification Extension to [RFC9219] Melnikov, A., "S/MIME Signature Verification Extension to
the JSON Meta Application Protocol (JMAP)", RFC 9219, the JSON Meta Application Protocol (JMAP)", RFC 9219,
DOI 10.17487/RFC9219, April 2022, DOI 10.17487/RFC9219, April 2022,
<https://www.rfc-editor.org/rfc/rfc9219>. <https://www.rfc-editor.org/info/rfc9219>.
[RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, [RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe,
"OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024,
<https://www.rfc-editor.org/rfc/rfc9580>. <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., [SPOOFING] Müller, J., Brinkmann, M., Poddebniak, D., Böck, H.,
Schinzel, S., Somorovsky, J., and J. Schwenk, "“Johnny, Schinzel, S., Somorovsky, J., and J. Schwenk, ""Johnny,
you are fired!” – Spoofing OpenPGP and S/MIME Signatures you are fired!" - Spoofing OpenPGP and S/MIME Signatures
in Emails", August 2019, 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>. <https://www.usenix.org/system/files/sec19-muller.pdf>.
[SRI] "Subresource Integrity", June 2016, [SRI] Akhawe, D., Braun, F., Marier, F., and J. Weinberger,
<https://www.w3.org/TR/SRI/>. "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-19, 5
December 2024, <https://datatracker.ietf.org/doc/html/
draft-koch-openpgp-webkey-service-19>.
Appendix A. Future Work Appendix A. Future Work
This document contains useful guidance for MUA implementers, but it This document contains useful guidance for MUA implementers, but it
cannot contain all possible guidance. Future revisions to this cannot contain all possible guidance. Future revisions of this
document may want to further explore the following topics, which are document may want to further explore the following topics, which are
out of scope for this version. out of scope for this version.
A.1. Webmail Threat Model A.1. Webmail Threat Model
The webmail threat model for end-to-end cryptographic protections is The webmail threat model for end-to-end cryptographic protections is
significantly more complex than the traditional MUA model. For significantly more complex than the traditional MUA model. For
example, the web server hosting the webmail interface could be a example, the web server hosting the webmail interface could be a
potential adversary. If the user treats the web server as a trusted potential adversary. If the user treats the web server as a trusted
party, but the web server violates that trust, the end-to-end party, but the web server violates that trust, the end-to-end
skipping to change at page 57, line 11 skipping to change at line 2576
contain examples of well-formed and malformed messages using contain examples of well-formed and malformed messages using
cryptographic key material and certificates from [RFC9580] and cryptographic key material and certificates from [RFC9580] and
[RFC9216]. [RFC9216].
It may also include example renderings of these messages. It may also include example renderings of these messages.
A.3. Further Guidance on Peer Certificates A.3. Further Guidance on Peer Certificates
A.3.1. Certificate Discovery from Incoming Messages A.3.1. Certificate Discovery from Incoming Messages
As described in Section 8.2.3, an incoming e-mail message may have As described in Section 8.2.3, an incoming email message may have one
one or more certificates embedded in it. This document currently or more certificates embedded in it. This document currently
acknowledges that receiving MUA should assemble a cache of acknowledges that a receiving MUA should assemble a cache of
certificates for future use, but providing more detailed guidance for certificates for future use, but providing more detailed guidance for
how to assemble and manage that cache is currently out of scope. how to assemble and manage that cache is currently out of scope.
Existing recommendations like [AUTOCRYPT] provide some guidance for Existing recommendations like [AUTOCRYPT] provide some guidance for
handling incoming certificates about peers, but only in certain handling incoming certificates about peers but only in certain
contexts. A future version of this document may describe in more contexts. A future version of this document may describe in more
detail how these incoming certs should be handled. detail how these incoming certs should be handled.
A.3.2. Certificate Directories A.3.2. Certificate Directories
Some MUAs may have the capability to look up peer certificates in a Some MUAs may have the capability to look up peer certificates in a
directory, for example via LDAP [RFC4511], WKD directory, for example, via the Lightweight Directory Access Protocol
[I-D.koch-openpgp-webkey-service], or the DNS (e.g., SMIMEA [RFC8162] (LDAP) [RFC4511], Web Key Directory (WKD) [WEBKEY-SERVICE], or DNS
or OPENPGPKEY [RFC7929] resource records). (e.g., SMIMEA [RFC8162] or OPENPGPKEY [RFC7929] resource records).
A future version of this document may describe in more detail what A future version of this document may describe in more detail what
sources an MUA should consider when searching for a peer's sources an MUA should consider when searching for a peer's
certificates, and what to do with the certificates found by various certificates and what to do with the certificates found by various
methods. methods.
A.3.3. Checking for Certificate Revocation A.3.3. Checking for Certificate Revocation
A future version of this document could discuss how/when to check for A future version of this document could discuss how/when to check for
revocation of peer certificates, or of the user's own certificate. revocation of peer certificates or of the user's own certificate.
Such discussion should address privacy concerns: what information Such discussion should address privacy concerns: What information
leaks to whom when checking peer cert revocations? leaks to whom when checking peer cert revocations?
A.3.4. Further Peer Certificate Selection A.3.4. Further Peer Certificate Selection
A future version of this document may describe more prescriptions for A future version of this document may describe more prescriptions for
deciding whether a peer certificate is acceptable for encrypting a deciding whether a peer certificate is acceptable for encrypting a
message. For example, if the SPKI is an EC Public Key and the message. For example, if the SPKI is an Elliptic Curve (EC) Public
keyUsage extension is absent, what should the encrypting MUA do? Key and the keyUsage extension is absent, what should the encrypting
MUA do?
A future version of this document might also provide guidance on what A future version of this document might also provide guidance on what
to do if multiple certificates are all acceptable for encrypting to a to do if multiple certificates are all acceptable for encrypting to a
given recipient. For example, the sender could select among them in given recipient. For example, the sender could select among them in
some deterministic way; it could encrypt to all of them; or it could some deterministic way; it could encrypt to all of them; or it could
present them to the user to let the user select any or all of them. present them to the user to let the user select any or all of them.
A.3.5. Human-readable Names in Peer Certificates, Header Fields, and A.3.5. Human-Readable Names in Peer Certificates, Header Fields, and
Addressbooks Address Books
In header fields like From: that may contain a display-name as In header fields such as From that may contain a display-name as
described in Section 3.4 of [RFC5322], a malicious sender (or described in Section 3.4 of [RFC5322], a malicious sender (or
interfering adversary) may populate the display-name part with a interfering adversary) may populate the display-name part with a
human-readable name that does not at all match the actual name of the human-readable name that does not at all match the actual name of the
participant. Section 8.1.1 describes some matching rules relating participant. Section 8.1.1 describes some matching rules relating
peer certificates to e-mail addresses (the addr-spec part of these peer certificates to email addresses (the addr-spec part of these
e-mail header fields), but does not contemplate matching display- email header fields) but does not contemplate matching display-names
names or other or similar user-visible data elements. Section 6.4 or other similar user-visible data elements. Section 6.4 describes
describes how signature validation should confirm a binding between how signature validation should confirm a binding between the addr-
the addr-spec and the certificate itself, but also does not spec and the certificate itself, but it also does not contemplate
contemplate matching display-names or other similar user-visible data matching display-names or other similar user-visible data elements.
elements. Depending on how the receiving MUA renders the display- Depending on how the receiving MUA renders the display-name in a
name in a message's header field, that unvalidated field may present message's header field, that unvalidated field may present a risk of
a risk of user confusion which could break the intended end-to-end user confusion, which could break the intended end-to-end assurances.
assurances. Yet both X.509 and OpenPGP certificate formats offer Yet both X.509 and OpenPGP certificate formats offer ways to provide
ways to provide cryptographically certified (though possibly not cryptographically certified (though possibly not unique) comparable
unique) comparable human-readable names. Additionally, many MUAs human-readable names. Additionally, many MUAs also include an
also include an addressbook or comparable feature which can make address book or comparable feature that can make substantive
substantive connections between user-relevant identity labels and connections between user-relevant identity labels and email
e-mail addresses. addresses.
A human-readable name like a display-name does not have the property A human-readable name like a display-name does not have the property
of global uniqueness that an addr-spec does, so reasoning about of global uniqueness that an addr-spec does, so reasoning about
human-readable names and rendering them to the user as an element in human-readable names and rendering them to the user as an element in
a system providing end-to-end cryptographic assurance requires a system providing end-to-end cryptographic assurance requires
additional deliberate analysis. additional deliberate analysis.
A future version of this document might offer strategies for A future version of this document might offer strategies for
associating human-readable names from certificates (and features like associating human-readable names from certificates (and features like
addressbooks) to the rendering of header fields that include display- address books) to the rendering of header fields that include
name. Such guidance should be paired with an analysis of specific display-name. Such guidance should be paired with an analysis of
usability and security risks associated with these human-readable specific usability and security risks associated with these human-
fields, as well as a description of how the recommended guidance readable fields, as well as a description of how the recommended
mitigates those risks. guidance mitigates those risks.
A.4. Further Guidance on Local Certificates and Secret Keys A.4. Further Guidance on Local Certificates and Secret Keys
A.4.1. Cross-MUA sharing of Local Certificates and Secret Keys
A.4.1. Cross-MUA Sharing of Local Certificates and Secret Keys
Many users today use more than one MUA to access the same mailbox Many users today use more than one MUA to access the same mailbox
(for example, one MUA on a mobile device, and another MUA on a (for example, one MUA on a mobile device and another MUA on a desktop
desktop computer). computer).
A future version of this document might offer guidance on how A future version of this document might offer guidance on how
multiple MUAs attached to the same mailbox can efficiently and multiple MUAs attached to the same mailbox can efficiently and
securely share the user's own secret key material and certificates securely share the user's own secret key material and certificates
between each other. This guidance should include suggestions on how between each other. This guidance should include suggestions on how
to maintain the user's keys (e.g., avoiding certificate expiration) to maintain the user's keys (e.g., avoiding certificate expiration)
and safe secret key transmission. and safe secret key transmission.
A.4.2. Use of Smartcards or Other Portable Secret Key Mechanisms A.4.2. Use of Smart Cards or Other Portable Secret Key Mechanisms
Rather than having to transfer secret key material between clients, Rather than having to transfer secret key material between clients,
some users may prefer to rely on portable hardware-backed secret keys some users may prefer to rely on portable hardware-backed secret keys
in the form of smartcards, USB tokens or other comparable form in the form of smart cards, USB tokens, or other comparable form
factors. These secret keys sometimes require direct user interaction factors. These secret keys sometimes require direct user interaction
for each use, which can complicate the usability of any MUA that uses for each use, which can complicate the usability of any MUA that uses
them to decrypt a large number of messages. them to decrypt a large number of messages.
Guidance on the use of this kind of secret key management are beyond Guidance on the use of this kind of secret key management is beyond
the scope of this document, but future revisions may bring them into the scope of this document, but future revisions may bring them into
scope. scope.
A.4.3. Active Local Certificate Maintenance A.4.3. Active Local Certificate Maintenance
Section 8.2.2 describes conditions where the MUA SHOULD warn the user Section 8.2.2 describes conditions where the MUA SHOULD warn the user
that something is going wrong with their certificate. that something is going wrong with their certificate.
A future version of this document might outline how an MUA could A future version of this document might outline how an MUA could
actively avoid these warning situations, for example, by actively avoid these warning situations, for example, by
skipping to change at page 60, line 6 skipping to change at line 2710
and manage root certification authorities (CAs). and manage root certification authorities (CAs).
For example: For example:
* Should the MUA cache intermediate CAs? * Should the MUA cache intermediate CAs?
* Should the MUA share such a cache with other PKI clients (e.g., * Should the MUA share such a cache with other PKI clients (e.g.,
web browsers)? web browsers)?
* What distinctions are there between a CA for S/MIME and a CA for * What distinctions are there between a CA for S/MIME and a CA for
the web? the Web?
A.6. Indexing and Search of Encrypted Messages A.6. Indexing and Search of Encrypted Messages
A common use case for MUAs is search of existing messages by keyword A common use case for MUAs is the search of existing messages by
or topic. This is done most efficiently for large mailboxes by keyword or topic. This is done most efficiently for large mailboxes
assembling an index of message content, rather than by a linear scan by assembling an index of message content rather than by a linear
of all message content. scan of all message content.
When message contents and header fields are encrypted, search by When message contents and header fields are encrypted, search by
index is complicated. If the cleartext is not indexed, then messages index is complicated. If the cleartext is not indexed, then messages
cannot be found by search. On the other hand, if the cleartext is cannot be found by search. On the other hand, if the cleartext is
indexed, then the index effectively contains the sensitive contents indexed, then the index effectively contains the sensitive contents
of the message, and needs to be protected. of the message and needs to be protected.
Detailed guidance on the tradeoff here, including choices about Detailed guidance on the trade-off here, including choices about
remote search vs local search, are beyond the scope of this document, remote search vs. local search, are beyond the scope of this
but a future version of the document may bring them into scope. document, but a future version of the document may bring them into
scope.
A.7. Cached Signature Validation A.7. Cached Signature Validation
Asymmetric signature validation can be computationally expensive, and Asymmetric signature validation can be computationally expensive, and
the results can also potentially vary over time (e.g., if a signing the results can also potentially vary over time (e.g., if a signing
certificate is discovered to be revoked). In some cases, the user certificate is discovered to be revoked). In some cases, the user
may care about the signature validation that they saw when they first may care about the signature validation that they saw when they first
read or received the message, not only about the status of the read or received the message, not only about the status of the
signature verification at the current time. signature verification at the current time.
skipping to change at page 60, line 47 skipping to change at line 2752
when to cache signature validation, as well as how to indicate it to when to cache signature validation, as well as how to indicate it to
the user, is beyond the scope of this document, but a future version the user, is beyond the scope of this document, but a future version
of the document may bring these topics into scope. of the document may bring these topics into scope.
A.8. Aggregate Cryptographic Status A.8. Aggregate Cryptographic Status
This document limits itself to consideration of the cryptographic This document limits itself to consideration of the cryptographic
status of single messages as a baseline concept that can be clearly status of single messages as a baseline concept that can be clearly
and simply communicated to the user. However, some users and some and simply communicated to the user. However, some users and some
MUAs may find it useful to contemplate even higher-level views of MUAs may find it useful to contemplate even higher-level views of
cryptographic status which are not considered directly here. cryptographic status, which are not considered directly here.
For example, a future version of the document may also consider how For example, a future version of the document may also consider how
to indicate a simple cryptographic status of message threads (groups to indicate a simple cryptographic status of message threads (groups
of explicitly related messages), conversations (groups of messages of explicitly related messages), conversations (groups of messages
with shared sets of participants), peers, or other perspectives that with shared sets of participants), peers, or other perspectives that
an MUA can provide. an MUA can provide.
A.9. Expectations of Cryptographic Protection A.9. Expectations of Cryptographic Protection
As mentioned in Section 2.3, the types of security indicators As mentioned in Section 2.3, the types of security indicators
displayed to the user may well vary based on the expectations of the displayed to the user may vary based on the expectations of the user
user for a given communication. At present, there is no widely for a given communication. At present, there is no widely shared
shared method for the MUA to establish and maintain reasonable method for the MUA to establish and maintain reasonable expectations
expectations about whether a specific received message should have about whether a specific received message should have cryptographic
cryptographic protections. protections.
If such a standard is developed, a future version of this document If such a standard is developed, a future version of this document
should reference it and encourage the deployment of clearer and should reference it and encourage the deployment of clearer and
simpler security indicators. simpler security indicators.
A.10. Secure Deletion A.10. Secure Deletion
One feature many users desire from a secure communications medium is One feature many users desire from a secure communications medium is
the ability to reliably destroy a message such that it cannot be the ability to reliably destroy a message such that it cannot be
recovered even by a determined adversary. In other contexts, a recovered even by a determined adversary. In other contexts, a
similar desired property is called "forward secrecy". Doing this similar desired property is called "forward secrecy". Doing this
with standard e-mail mechanisms like S/MIME and PGP/MIME is with standard email mechanisms such as S/MIME and PGP/MIME is
challenging because of two interrelated factors: challenging because of two interrelated factors:
* A copy of of an e-mail message may be retained by any of the mail * A copy of an email message may be retained by any of the mail
transport agents that handle it during delivery, and transport agents that handle it during delivery.
* The secret key used to decrypt an encrypted e-mail message is * The secret key used to decrypt an encrypted email message is
typically retained indefinitely. typically retained indefinitely.
This means that an adversary aiming to recover the cleartext contents This means that an adversary aiming to recover the cleartext contents
of a deleted message can do so by getting access to a copy of the of a deleted message can do so by getting access to a copy of the
encrypted message and the long-term secret key material. encrypted message and the long-term secret key material.
Some mitigation measures may be available to make it possible to Some mitigation measures may be available to make it possible to
delete some encrypted messages securely, but this document considers delete some encrypted messages securely, but this document considers
this use case out of scope. A future version of the document may this use case out of scope. A future version of the document may
elaborate on secure message deleton in more detail. elaborate on secure message deletion in more detail.
A.11. Interaction with Opportunistic Encryption A.11. Interaction with Opportunistic Encryption
This document focuses on guidance for strong, user-comprehensible This document focuses on guidance for strong, user-comprehensible
end-to-end cryptographic protections for e-mail. Other approaches end-to-end cryptographic protections for email. Other approaches are
are possible, including various forms of opportunistic and transport possible, including various forms of opportunistic and transport
encryption, which are out of scope for this document. encryption, which are out of scope for this document.
A future version of this document could describe the interaction A future version of this document could describe the interaction
between this guidance and more opportunistic forms of encryption, for between this guidance and more opportunistic forms of encryption, for
example some of the scenarios contemplated in example, some of the scenarios contemplated in [CLEARTEXT-COPY].
[I-D.dkg-mail-cleartext-copy].
A.12. Split Attachments A.12. Split Attachments
As noted in Section 7.2, the standard form for encrypted e-mail As noted in Section 7.2, the standard form for encrypted email
messages is a single cryptographic envelope. In a scenario where messages is a single cryptographic envelope. In a scenario where
multiple user agents are drafting a single encrypted message over multiple user agents are drafting a single encrypted message over
low-bandwidth links, this can create a poor user experience, as each low-bandwidth links, this can create a poor user experience, as each
MUA has to retrieve the full message, including attachments, to MUA has to retrieve the full message, including attachments, to
modify the draft. Similarly, when retrieving a message with a large modify the draft. Similarly, when retrieving a message with a large
attachment, the receiving MUA might want to only render the main body attachment, the receiving MUA might want to only render the Main Body
part, and will have a significant delay in doing so if required to Part and will have a significant delay in doing so if required to
process the full message before handling. process the full message before handling.
Future work might include an attempt to standardize a mechanism that Future work might include an attempt to standardize a mechanism that
eases this use case, potentially at the risk of additional metadata eases this use case, potentially at the risk of additional metadata
leakage about the message (e.g., the size and number of message leakage about the message (e.g., the size and number of message
parts). Any such work should explicitly try to minimize the risks parts). Any such work should explicitly try to minimize the risks
and concerns described in Section 7.2. and concerns described in Section 7.2.
A.13. Proxy Extensions A.13. Proxy Extensions
As noted in Section 9.7, a proxy-based implementation can be a As noted in Section 9.7, a proxy-based implementation can be a
tempting approach. But its naive form is likely to be insufficient tempting approach. But its naive form is likely to be insufficient
to provide safe end-to-end encrypted e-mail. to provide safe end-to-end encrypted email.
A future version of this document, or a separate but related A future version of this document, or a separate but related
document, could try to outline the specific additional information, document, could try to outline the specific additional information,
state, and network API surface that would be needed to allow an MUA state, and network API surface that would be needed to allow an MUA
to be safely integrated with an encryption provider. Any such work to be safely integrated with an encryption provider. Any such work
should try to address the potential problems described in should try to address the potential problems described in
Section 9.7. Section 9.7.
A.14. Mailing Lists A.14. Mailing Lists
Mailing lists offer challenging complications to any notion of end- Mailing lists offer challenging complications to any notion of end-
to-end cryptographic protections. By default, there is some sort of to-end cryptographic protections. By default, there is some sort of
intervening MUA (see Section 9.8), but more than that, user intervening MUA (see Section 9.8), but more than that, user
expectations about cryptographic protections might differ from normal expectations about cryptographic protections might differ from normal
messages, at least insofar as they understand they are writing to a messages, at least insofar as they understand they are writing to a
mailing list. A particular challenge to the notion of end-to-end mailing list. A particular challenge to the notion of end-to-end
cryptographic security with mailing lists is that a subscriber to a cryptographic security with mailing lists is that a subscriber to a
mailing list often does not know who else is subscribed to the mailing list often does not know who else is subscribed to the
mailing list. Another challenge is that for some mailing lists, some mailing list. Another challenge is that, for some mailing lists,
subscribers might not have a valid, non-expired certificate. some subscribers might not have a valid, non-expired certificate.
Encryption can interact with mailing lists in different ways, Encryption can interact with mailing lists in different ways,
depending on the use case of the list. It's not clear that there are depending on the use case of the list. It's not clear that there are
any useful motivations for sending encrypted mail to a publicly any useful motivations for sending encrypted mail to a publicly
archived mailing list. But an unarchived mailing list might want to archived mailing list. But an unarchived mailing list might want to
provide confidentiality between all recipients, even if the provide confidentiality between all recipients, even if the
recipients don't know for certain who all the other participants are. recipients don't know for certain who all the other participants are.
Or, a mailing list with private archives might well decide that two Or a mailing list with private archives might well decide that two
"hops" of encryption (between the sender and the mailing list, and "hops" of encryption (between the sender and the mailing list, and
the mailing list and all the subscribers) are a useful the mailing list and all the subscribers) are useful confidentiality
confidentiality measure even though they are not "end-to-end" in the measures even though they are not "end-to-end" in the sense of the
sense of the sender directly to all recipients. sender directly to all recipients.
Similarly, cryptographic signatures may play different roles in a Similarly, cryptographic signatures may play different roles in a
mailing list, depending on the list's communication goals. The mailing list, depending on the list's communication goals. The
mailing list itself might want to verify that an incoming message is mailing list itself might want to verify that an incoming message is
cryptographically signed by an authorized sender before cryptographically signed by an authorized sender before
redistribution to the list subscribers. It might also want to pass redistribution to the list subscribers. It might also want to pass
along the sender's signature in a way that the subscribers can all along the sender's signature in a way that the subscribers can all
verify it. Alternately, the mailing list might want to sign each verify it. Alternately, the mailing list might want to sign each
redistributed message itself, and change the message so it appears to redistributed message itself and change the message so it appears to
come from the list rather than the original sender. come from the list rather than the original sender.
Yet another design for a mailing list with end-to-end cryptographic Yet another design for a mailing list with end-to-end cryptographic
protections might involve redistributing shared secret keys to all protections might involve redistributing shared secret keys to all
recipients, or using some sort of proxied re-encryption scheme, recipients or using some sort of proxied re-encryption scheme,
similar to [I-D.wussler-openpgp-forwarding]. similar to [OPENPGP-FORWARDING].
A future version of this document or a separate but related document
might describe some of these tradeoffs and provide guidance for
safely meeting common requirements or use cases when combining end-
to-end cryptographic protections with mailing lists.
Appendix B. Document History
B.1. Substantive changes from draft-ietf-...-16 to draft-ietf-...-17
* Update OpenPGP references to RFC 9580
* Clarify ciphertext malleability concerns
B.2. Substantive changes from draft-ietf-...-15 to draft-ietf-...-16
* Address feedback from Last Call and IESG review:
* Add "Weak Encryption" section
* Add Future Work subsection on mailing lists
* Add Future Work subsection on human-readable names
* Mention possible user control over stripping quoted text in
cleartext reply to encrypted message
* Simplify Bcc guidance about certificate inclusion
B.3. Substantive changes from draft-ietf-...-14 to draft-ietf-...-15
* update IMAP reference to RFC 9051
* add webmail concerns as part of Future Work
B.4. Substantive changes from draft-ietf-...-13 to draft-ietf-...-14
* Responded to SEC AD Review, including:
* clarify "conformant" vs "legacy" vs "non-cryptographic" MUA
categories
* tighten up MUSTs for conformant MUAs
* explicitly recommend encrypting drafts
* clarify debugging as a use case for showing invalid signatures
* clarify "Headers" to "Header Fields"
* 3 states for sending, 4 for receiving
B.5. Substantive changes from draft-ietf-...-12 to draft-ietf-...-13
* clarify RFC 2119 guidance about not rendering cryptographic layers
other than message cryptographic status
B.6. Substantive changes from draft-ietf-...-11 to draft-ietf-...-12
* More nuance (and future work) around split attachments
* More nuance (and future work) around proxy-style design
* Clearer caveats about external resources in text/html parts
B.7. Substantive changes from draft-ietf-...-10 to draft-ietf-...-11
* Mention List-* and Archived-At message header fields
* Add additional references to papers that describe flaws in e2e
e-mail
B.8. Substantive changes from draft-ietf-...-09 to draft-ietf-...-10
* Introduction: describe one major theme of Future Work
B.9. Substantive changes from draft-ietf-...-08 to draft-ietf-...-09
* Clarify goals of document
* Identify cross-protocol attacks in more detail to justify
prescription against key reuse
* Add informative references to Opportunistic Encryption RFC and
Certificate Best Practice draft
* Add "Reading Encrypted Messages after Certificate Expiration"
section to Common Pitfalls and Guidelines
* Clean up nits identified by Stephen Farrell and Eliot Lear
B.10. Substantive changes from draft-ietf-...-07 to draft-ietf-...-08
* Add guidance about importing and exporting secret key material
* More explanation about "encryption outside, signature inside"
* Guidance about Intervening (resending) MUAs
* Include Sender and Resent-* as user-facing header fields
* Guidance about external subresources for cryptographically
protected messages
* Relax "user-facing" definition to be more advisory
B.11. Substantive changes from draft-ietf-...-06 to draft-ietf-...-07
* Add Bernie Hoeneisen and Alexey Melnikov as editors
* Explicitly avoid requiring anything from IANA
* Simplify description of "attachments"
* Add concrete detail on how to compare e-mail addresses
* Explicitly define "Cryptographic Summary"
B.12. Substantive changes from draft-ietf-...-05 to draft-ietf-...-06
* Expand proxy implementation warning to comparable APIs
* Move many marked TODO and FIXME items to "Future Work"
* More detailed guidance on local certificates
* Provide guidance on encrypting draft messages
* More detailed guidanc eon shipping certificates in outbound
messages
* Recommend implementing header protection
* Added "Future Work" subsection about interactions with
opportunistic approaches
B.13. Substantive changes from draft-ietf-...-04 to draft-ietf-...-05
* Adopt and update text about Bcc from draft-ietf-lamps-header-
protection
* Add section about the dangers of an implementation based on a
network protocol proxy
B.14. Substantive changes from draft-ietf-...-03 to draft-ietf-...-04
* Added reference to multipart/oracle attacks
* Clarified that "Structural Header fields" are the same as
RFC2045's "MIME Headers"
B.15. Substantive changes from draft-ietf-...-02 to draft-ietf-...-03
* Added section about mixed recipients
* Noted SMIMEA and OPENPGPKEY DNS RR cert discovery mechanisms
* Added more notes about simplified mental models
* More clarification on one-status-per-message
* Added guidance to defend against EFAIL
B.16. Substantive changes from draft-ietf-...-01 to draft-ietf-...-02
* Added definition of "user-facing" header fields
B.17. Substantive changes from draft-ietf-...-00 to draft-ietf-...-01
* Added section about distinguishing Main Body Parts and Attachments
* Updated document considerations section, including reference to
auto-built editor's copy
B.18. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00
* WG adopted draft
* moved Document History and Document Considerations sections to end
of appendix, to avoid section renumbering when removed
B.19. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01
* consideration of success/failure indicators for usability
* clarify extendedKeyUsage and keyUsage algorithm-specific details A future version of this document, or a separate but related
document, might describe some of these trade-offs and provide
guidance for safely meeting common requirements or use cases when
combining end-to-end cryptographic protections with mailing lists.
* initial section on certificate management Acknowledgements
* added more TODO items The set of constructs and recommendations in this document are
derived from discussions with many different implementers, including
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 Authors' Addresses
Daniel Kahn Gillmor (editor) Daniel Kahn Gillmor (editor)
American Civil Liberties Union American Civil Liberties Union
125 Broad St. 125 Broad St.
New York, NY, 10004 New York, NY 10004
United States of America United States of America
Email: dkg@fifthhorseman.net Email: dkg@fifthhorseman.net
Bernie Hoeneisen (editor) Bernie Hoeneisen (editor)
pEp Project pEp Project
Oberer Graben 4 Oberer Graben 4
CH- 8400 Winterthur CH-8400 Winterthur
Switzerland Switzerland
Email: bernie@ietf.hoeneisen.ch Email: bernie@ietf.hoeneisen.ch
URI: https://pep-project.org/ URI: https://pep-project.org/
Alexey Melnikov (editor) Alexey Melnikov (editor)
Isode Ltd Isode Ltd
14 Castle Mews 14 Castle Mews
Hampton, Middlesex Hampton, Middlesex
TW12 2NP TW12 2NP
United Kingdom United Kingdom
 End of changes. 374 change blocks. 
1060 lines changed or deleted 830 lines changed or added

This html diff was produced by rfcdiff 1.48.