rfc9787v1.txt   rfc9787.txt 
Internet Engineering Task Force (IETF) D. K. Gillmor, Ed. Internet Engineering Task Force (IETF) D. K. Gillmor, Ed.
Request for Comments: 9787 ACLU Request for Comments: 9787 ACLU
Category: Informational B. Hoeneisen, Ed. Category: Informational A. Melnikov, Ed.
ISSN: 2070-1721 pEp Project ISSN: 2070-1721 Isode Ltd
A. Melnikov, Ed. B. Hoeneisen, Ed.
Isode Ltd pEp Project
May 2025 July 2025
Guidance on End-to-End Email Security Guidance on End-to-End Email Security
Abstract Abstract
End-to-end cryptographic protections for email 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 make Mail User Agent (MUA) implementers to help mitigate those risks and
end-to-end email simple and secure for the end user. It provides a to make end-to-end email simple and secure for the end user. It
useful set of vocabulary as well as recommendations to avoid common provides a useful set of vocabulary as well as recommendations to
failures. It also identifies a number of currently unsolved avoid common failures. It also identifies a number of currently
usability and interoperability problems. unsolved usability and interoperability problems.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents Internet Engineering Steering Group (IESG). Not all documents
skipping to change at line 163 skipping to change at line 163
Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
End-to-end email security using S/MIME [RFC8551] and PGP/MIME (Pretty End-to-end email security using S/MIME [RFC8551] and PGP/MIME (Pretty
Good Privacy with MIME) [RFC3156] cryptographic standards can provide Good Privacy with MIME) [RFC3156] cryptographic standards can provide
integrity, authentication, and confidentiality to MIME [RFC4289] integrity, authentication, and confidentiality to MIME [RFC4289]
email messages. email messages.
However, there are many ways that a receiving mail user agent can However, there are many ways that a receiving MUA can misinterpret or
misinterpret or accidentally break these security guarantees. For accidentally break these security guarantees. For example, as
example, as described in [EFAIL], the "Direct Exfiltration" attack described in [EFAIL], the "Direct Exfiltration" attack leaks
leaks cleartext due to an attack that splices existing ciphertext cleartext due to an attack that splices existing ciphertext into a
into a new message, which is then handled optimistically (and new message, which is then handled optimistically (and wrongly) by
wrongly) by many mail user agents. many MUAs.
A mail user agent that interprets a message with end-to-end A MUA that interprets a message with end-to-end cryptographic
cryptographic protections needs to do so defensively, staying alert protections needs to do so defensively, staying alert to different
to different ways that these protections can be bypassed by mangling ways that these protections can be bypassed by mangling (either
(either malicious or accidental) or a failed user experience. malicious or accidental) or a failed user experience.
A mail user agent that generates a message with end-to-end A MUA that generates a message with end-to-end cryptographic
cryptographic protections should be aware of these defensive protections should be aware of these defensive interpretation
interpretation strategies and should compose any new outbound message strategies and should compose any new outbound message conservatively
conservatively if they want the protections to remain intact. 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 MUA that
that provides these cryptographic protections, whether for sending or 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
email that 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 MUAs controlled by the same
by the same user. user.
1.1. Terminology
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 BCP "OPTIONAL" in this document are to be interpreted as described in 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
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 email client. * The _Mail User Agent (MUA)_ is 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_ email 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.
* _Non-Structural Header Fields_ are header fields that are not
Structural Header Fields.
* _User-Facing Header Fields_ are documented in Section 1.1.2. * _User-Facing Header Fields_ are documented in Section 1.1.2.
* The _Main Body Part_ is the part (or parts) that is typically * A _Main Body Part_ is any part of a message 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 email while acknowledging that many MUAs cryptographic protections in email while acknowledging that many MUAs
have no capabilities for end-to-end cryptographic protections at all. have no capabilities for end-to-end cryptographic protections at 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.
skipping to change at line 267 skipping to change at line 270
* 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 email 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 small subset are typically presented directly to the user. This
refers to them as "user-facing" header fields. Typically, user- document refers to them as User-Facing Header Fields. Typically,
facing header fields are: User-Facing Header Fields are:
* Subject * Subject
* From * From
* To * To
* Cc * Cc
* Date * Date
skipping to change at line 299 skipping to change at line 302
* Resent-To * Resent-To
* Resent-Cc * Resent-Cc
* Resent-Date * Resent-Date
* Resent-Sender * Resent-Sender
The above list contains the header fields most often presented The above list contains the header fields most often presented
directly to the user who views a message, though an MUA may also directly to the user who views a message, though an MUA may also
decide to treat any other header field as "user-facing". Of course, decide to treat any other header field as "User-Facing". Of course,
many of these header fields are entirely absent from any given many of these header fields are entirely absent from any given
message, and an absent header field is not presented to the user at message, and an absent header field is not presented to the user at
all. 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.
skipping to change at line 358 skipping to change at line 361
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 details 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
a message subpart, but that status should be distinct from the status | being a message subpart, but that status should be distinct
of the enclosing message.) | from the status of the enclosing message.)
2.2. Email 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.
Email 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:
skipping to change at line 394 skipping to change at line 397
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 email is likely using email 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 email endpoint, care should be taken cryptographic protection to an email endpoint, care should be taken
not to negate any of the distinct features of email 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 cryptographic
may just as well choose one of the other systems that don't have the protection, the user may just as well choose one of the other systems
drawbacks that email has. Implementers should try to provide end-to- that don't have the drawbacks that email has. Implementers should
end protections that retain the familiar experience of email itself. try to provide end-to-end protections that retain the familiar
experience of email itself.
Furthermore, an email user is likely to regularly interact with other Furthermore, an email user is likely to regularly interact with other
email 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 when enabling
cryptography in an MUA does not inadvertently limit the ability of cryptography in an MUA so that the MUA does not inadvertently limit
the user to interact with correspondents who use legacy or non- the ability of the user to interact with correspondents who use
cryptographic MUAs. legacy or non-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 email. 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 2025 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 email 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 offering a simple user experience should be deliberate and judicious
expectations their interface assumes that the user has in a given about the expectations their interface assumes that the user has in a
context. See Appendix A.9 for future work. given 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
skipping to change at line 505 skipping to change at line 509
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 email 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 an Encrypted Alternately, an MUA may prefer to represent the state of an Encrypted
but Unverified message to the user as though it was Unprotected since But Unverified message to the user as though it was Unprotected since
no verification is possible. However, the MUA represents the message no verification is possible. However the MUA represents the message
to the user, though it MUST NOT leak cleartext of an encrypted to the user, it MUST NOT leak cleartext of an encrypted message (even
message (even an Encrypted but Unverified message) in subsequent an Encrypted But Unverified message) in subsequent replies (see
replies (see Section 5.4) or similar replications of the message. Section 5.4) or similar replications of the 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 email 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 instead prefer 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
skipping to change at line 574 skipping to change at line 578
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 internal subtree is known as the "protected part", though of course
it 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, "╧" (BOX DRAWINGS UP SINGLE AND HORIZONTAL
indicates "decrypts to" and "⇩" (DOWNWARDS WHITE ARROW, U+21E9) DOUBLE, U+2567) indicates "decrypts to" and "┴" (BOX DRAWINGS LIGHT
indicates "unwraps to". UP AND HORIZONTAL, U+2534) 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, and multipart/signed, PKCS #7 signed-data, PKCS #7 enveloped-data, and
PKCS #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
└─╴application/pkcs7-mime; smime-type="signed-data" └┬╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to) ┴ (unwraps to)
└─╴[protected part] └─╴[protected part]
This MIME layer offers authentication and integrity. This MIME layer offers authentication and integrity.
4.1.1.3. S/MIME PKCS #7 enveloped-data Cryptographic Layer 4.1.1.3. S/MIME PKCS #7 enveloped-data Cryptographic Layer
└─╴application/pkcs7-mime; smime-type="enveloped-data" └┬╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to) ╧ (decrypts to)
└─╴[protected part] └─╴[protected part]
This MIME layer offers confidentiality. This MIME layer offers confidentiality.
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 structures 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
skipping to change at line 648 skipping to change at line 652
└┬╴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: 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 and * 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, see Section 5.2 of
[RFC9580], 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 email 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).
skipping to change at line 702 skipping to change at line 707
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 Encrypted Message [RFC9580] within the by ensuring that the [RFC9580] Encrypted Message within the
application/octet-stream part contains a Signed Message [RFC9580] application/octet-stream part contains a [RFC9580] Signed Message
(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 and 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, message forwarding, or well-intentioned
may contain a Cryptographic Layer that is not part of the tampering, a message may contain a Cryptographic Layer that is not
Cryptographic Envelope. Such a layer is an Errant Cryptographic part of the Cryptographic Envelope. Such a layer is an Errant
Layer. Cryptographic 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 rewrap a well-formed signed message Some mailing list software will rewrap a well-formed signed message
skipping to change at line 762 skipping to change at line 767
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 email 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.
See also Section 6.2.1.1 for guidance on how a receiving MUA might
deal with this common pattern.
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 three Cryptographic Layers in such a message are rooted in parts The three Cryptographic Layers in such a message are rooted in parts
M, Q, and S. But the Cryptographic Envelope of the message consists M, Q, and S. But the Cryptographic Envelope of the message consists
skipping to change at line 817 skipping to change at line 825
This section describes the ideal composition of an email message with This section describes the ideal composition of an email message with
end-to-end cryptographic protection. A message composed with this end-to-end cryptographic protection. A message composed with 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 inputs to the algorithm are:
origbody: The traditional unprotected message body as a well-formed origbody: The unprotected message body as a well-formed MIME tree
MIME tree (possibly just a single MIME leaf part). As a well- (possibly just a single MIME leaf part). As a well-formed MIME
formed MIME tree, origbody already has structural header fields tree, origbody already has Structural Header Fields present (see
present (see Section 1.1.1). 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 MIME part origbody, producing MIME tree output.
2. For each header name and value (h,v) in origheaders: 2. For each header field name and value (h,v) in origheaders:
a. Add header h to output with value v. a. Add header field 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 classic 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 [RFC9788] (see Section 9.3). described in [RFC9788] (see Section 9.3).
5.2. Encryption Outside, Signature Inside 5.2. Encryption Outside, Signature Inside
An email message that is both signed and encrypted is signed _inside_ An email message that is both signed and encrypted is signed _inside_
the encryption and not the other way around. For example, when the encryption and not the other way around. For example, when
crafting an encrypted and signed message using a simple Cryptographic crafting a signed-and-encrypted message using a simple Cryptographic
Envelope of a single layer (Section 4.4.1) with PGP/MIME, the OpenPGP Envelope of a single layer (Section 4.4.1) with PGP/MIME, the OpenPGP
Encrypted Message object should contain an OpenPGP Signed Message. Encrypted Message object should contain an OpenPGP Signed Message.
Likewise, when using a multilayer Cryptographic Envelope Likewise, when using a multilayer Cryptographic Envelope
(Section 4.4.2), the outer layer should be an encryption layer and (Section 4.4.2), the outer layer should be an encryption 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.
skipping to change at line 891 skipping to change at line 899
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 email 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-Encrypted: 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
email 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
skipping to change at line 999 skipping to change at line 1007
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:
skipping to change at line 1036 skipping to change at line 1044
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 appends example, it has a List-ID header field) and it has a structure that
a footer to a signing-only Cryptographic Layer with a valid appends 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 message then the MUA MAY indicate to the user that this is a Verified 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.
skipping to change at line 1086 skipping to change at line 1094
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.
Although, in this case, a conformant MUA MUST NOT indicate in the However, 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 not MUST treat the decrypted cleartext as a distinct MIME subtree and it
attempt to merge or splice it together with any other part of the MUST NOT attempt to merge or splice it together with any other part
message. This offers protection against the direct exfiltration of the message. This offers protection against the direct
(also known as EFAIL-DE) attacks described in [EFAIL] and so-called exfiltration (also known as EFAIL-DE) attacks described in [EFAIL]
multipart/oracle attacks described in [ORACLE]. and so-called 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
encrypted, even if some subpart of it was decrypted for rendering. encrypted, even if some subpart of it was decrypted for rendering.
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 quote or attribute text derived from
layers when generating quoted or attributed text. This will the decryption of any Errant Cryptographic Layer. 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 within the content
content of a MIME part. 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 fully decline to decrypt the data.
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 email, 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 attempt separate MIME part to contain only the decrypted data and it MUST NOT
to merge or splice that part together with any other part of the attempt to merge or splice that part together with any other part of
message. Keeping such a section distinct and isolated from any other the message. Keeping such a section distinct and isolated from any
part of the message offers protection against the direct exfiltration other part of the message offers protection against the direct
attacks (also known as EFAIL-DE) described in [EFAIL]. exfiltration 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 email 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 [RFC6532].
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 Errant Cryptographic Layers with respect
surrounding message -- they are simply layers that apply to the to the surrounding message -- they are layers that only 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 by either tied to the forwarded message itself and cannot be spoofed by either
the enclosing message or 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 failed DomainKeys Identified Mail (DKIM) signatures (see guidance for failed DomainKeys Identified Mail (DKIM) signatures (see
Section 6.1 of [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 a signed-and-encrypted message where
where the signature is invalid SHOULD treat the message the same way the signature is invalid SHOULD treat the message the same way that
that it would treat a message that is encryption-only, unless the MUA it would treat a message that is encryption-only, unless the MUA is
is providing the user with debugging information. providing the user with debugging information.
These are some different ways that a signature may be invalid on a These are some different ways that a signature may be invalid on a
given 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
skipping to change at line 1253 skipping to change at line 1261
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 fully decline to decrypt such a
all. If it decides to decrypt a message with a weak encryption message. If it decides to decrypt a message with a weak encryption
layer, it MUST NOT indicate in the message's Cryptographic Summary layer, it MUST NOT indicate in the message's Cryptographic Summary
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.
skipping to change at line 1329 skipping to change at line 1337
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 text (e.g., text/plain or text/html) looking for a leaf node that has text (e.g., text/plain or text/html)
as a primary content type and is not Content-Disposition: attachment. as a primary content type and is not Content-Disposition: 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 let the user select a preferred MIME type for rendering
type within multipart/alternative instead of the last renderable within multipart/alternative instead of the last renderable child.
child. For example, a user may explicitly prefer a text/plain For example, a user may explicitly prefer a text/plain alternative
alternative part over text/html. Note that due to uncertainty about part over text/html. Note that due to uncertainty about the
the capabilities and configuration of the receiving MUA, a capabilities and configuration of the receiving MUA, a conformant
conformant-composing MUA should consider that multiple parts might be composing MUA should consider that multiple parts might be rendered
rendered as the Main Body Part when the message is ultimately viewed. as the Main Body Part when the message is ultimately viewed. In
In particular, the composing MUA should ensure that any part likely particular, the composing MUA should ensure that any part likely to
to be viewed as the Main Body Part has the same semantic content as be viewed as the Main Body Part has the same semantic content as any
any other such part. 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 email 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 the Main message without any special knowledge about which parts are the Main
skipping to change at line 1370 skipping to change at line 1378
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 if (e.g., if a signature on one part fails but another succeeds or if
one part is encrypted and another is not). This mix of statuses one part is encrypted and another is not). This mix of statuses
is difficult to represent to the user in a comprehensible way. is difficult to represent to the user in a comprehensible way.
skipping to change at line 1394 skipping to change at line 1402
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
↧ (decrypts to) ╧ (decrypts to)
N └─╴application/pkcs7-mime N └┬╴application/pkcs7-mime
⇩ (unwraps to) ┴ (unwraps to)
O └┬╴multipart/mixed O └┬╴multipart/mixed
P ├┬╴multipart/alternative P ├┬╴multipart/alternative
Q │├─╴text/plain Q │├─╴text/plain
R │└─╴text/html R │└─╴text/html
S └─╴image/png S └─╴image/png
Parts M and N comprise the Cryptographic Envelope. Parts M and N comprise the Cryptographic Envelope.
Parts Q and R are both Main Body Parts. Parts Q and R are both Main Body Parts.
If part S is Content-Disposition: attachment, then it is an If part S is Content-Disposition: attachment, then it is an
attachment. If part S has no Content-Disposition header, it is attachment. If part S has no Content-Disposition header field, it is
potentially ambiguous whether it is an attachment or not. If the potentially ambiguous whether it is an attachment or not. If the
sender prefers a specific behavior, it should explicitly set the sender prefers a specific behavior, it should explicitly set the
Content-Disposition header on part S to either inline or attachment Content-Disposition header field on part S to either inline or
as guidance to the receiving MUA. attachment as guidance to the receiving MUA.
Consider also this alternate structure: Consider also this alternate structure:
M └─╴application/pkcs7-mime M └┬╴application/pkcs7-mime
↧ (decrypts to) ╧ (decrypts to)
N └─╴application/pkcs7-mime N └┬╴application/pkcs7-mime
⇩ (unwraps to) ┴ (unwraps to)
O └┬╴multipart/alternative O └┬╴multipart/alternative
P ├─╴text/plain P ├─╴text/plain
Q └┬╴multipart/related Q └┬╴multipart/related
R ├─╴text/html R ├─╴text/html
S └─╴image/png S └─╴image/png
In this case, parts M and N still comprise the Cryptographic In this case, parts M and N still comprise the Cryptographic
Envelope. Envelope.
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
skipping to change at line 1453 skipping to change at line 1461
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 document, but future revisions may bring it into scope (see
Detailed guidance about how to do this is beyond the scope of this
document, but future revisions may bring it into scope (see
Appendix A.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 email 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 (for all ASCII
match the destination email address. In particular, the local email addresses) or SmtpUTF8Mailbox (for Internationalized Email
part of the two addresses should be an exact bytewise match, and Addresses) whose contents match the destination email address. In
the domain parts of the two addresses should be matched by particular, for rfc822Name, the local-part of the two addresses
ensuring label equivalence across the full domain name, as should be an exact bytewise match, and the domain parts of the two
described in Section 2.3.2.4 of [RFC5890]. addresses should be matched by ensuring label equivalence across
the full domain name, as described in Section 2.3.2.4 of
[RFC5890]. Comparison with SmtpUTF8Mailbox is specified in
Section 5 of [RFC9598].
* The algorithm OID in the certificate's SPKI is known to the MUA * The algorithm OID in the certificate's SubjectPublicKeyInfo (SPKI)
and capable of encryption. Examples include: is known to the MUA and capable of encryption. Examples include:
- rsaEncryption (OID 1.2.840.113549.1.1.1), with the keyUsage - rsaEncryption (OID 1.2.840.113549.1.1.1), with the keyUsage
(OID 2.5.29.15) extension present and the "key encipherment" (OID 2.5.29.15) extension present and the "key encipherment"
bit (value 32) set. bit (value 32) set.
- curveX25519 (OID 1.3.101.110), with the keyUsage extension - curveX25519 (OID 1.3.101.110), with the keyUsage extension
present 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: email protection (OID least one of the following OIDs: email protection (OID
skipping to change at line 1522 skipping to change at line 1531
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-email) 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 to avoid possible cross-
for signing, to avoid possible cross-protocol key misuse. protocol key misuse: one for encryption and another for signing.
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 (CA) certificates
permit chaining from the end entity certs to widely accepted trust that permit chaining from the end entity certificates to widely
anchors. A conformant MUA that imports such a PKCS #12 bundle SHOULD accepted trust anchors. A conformant MUA that imports such a PKCS
warn the user if the bundle contains an S/MIME certificate and #12 bundle SHOULD warn the user if the bundle contains an S/MIME
corresponding secret key where the same secret key is used for both certificate and corresponding secret key where the same secret key is
encryption and signing. used for both 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 CA via non-standardized, labor-intensive, and error-
intensive, and error-prone procedures that most users do not prone procedures that most users do not understand. Furthermore,
understand. Furthermore, manual export and import incurs ongoing manual export and import incurs ongoing labor (for example, before
labor (for example, before certificate expiration) by the user, which certificate expiration) by the user, which most users are unprepared
most users are unprepared to do (see Section 8.2.2). 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 Automatic certificate issuance procedure, for example, by using the Automatic
Certificate Management Environment (ACME) protocol for end user S/ Certificate Management Environment (ACME) protocol for end user S/
MIME certificates [RFC8823]. MIME certificates [RFC8823].
Another possible approach is integration with a cryptographic Another possible approach is integration with a cryptographic
hardware token or smart card 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, see [PKCS11], the use of isolated secret key material, for example, see [PKCS11],
though this approach delegates the complexity of acquiring and though this approach delegates the complexity of acquiring and
skipping to change at line 1581 skipping to change at line 1590
Furthermore, a single OpenPGP certificate MAY only be 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 Transferable 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 CAs or merely other well-connected peers), the MUA
connected peers), the MUA SHOULD offer affordances to help the user SHOULD offer affordances to help the user acquire and merge third-
acquire and merge third-party certifications on their certificate. party certifications on their certificate. When doing this, the MUA
When doing this, the MUA should prioritize third-party certifications should prioritize third-party certifications from entities that the
from entities that the user's peers are likely to know about and be 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 the 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 system administrator but probably should
secret key material generated by an unaffiliated online web service. not accept 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 email account managed by an MUA, where In the context of a single email account managed by an MUA, where
skipping to change at line 1644 skipping to change at line 1653
* Any of the user's own S/MIME certificates for the account: * Any of the user's own S/MIME certificates for the account:
- do not have a keyUsage extension. - do not have a keyUsage extension.
- do 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 one that just issues warnings,
to do active certificate maintenance is beyond the scope of this but guidance on how to do active certificate maintenance is beyond
document (see Appendix A.4.3). the scope of this 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 describes how the certificates might not be acceptable for other
recommend a course of action that the user can take to remedy the people and recommend a course of action that the user can take to
problem. remedy the 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 any S/MIME EnvelopedData object, "certificates" member. In any S/MIME EnvelopedData object,
certificates can be shipped in the "originatorInfo.certs" member. certificates can be shipped in the "originatorInfo.certs" member.
When a single S/MIME-protected email message is encrypted and signed, When a single S/MIME-protected email message is signed-and-encrypted,
it is usually sufficient to ship all the relevant certificates in the it is usually sufficient to ship all the relevant 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 certification authority (CA) certificates needed * any intermediate CA certificates needed to chain all of the above
to chain all of the above to a widely trusted set of root to a widely trusted set of root authorities.
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
skipping to change at line 1757 skipping to change at line 1765
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 resubmit the stored message into the SMTP system and cannot simply resubmit the stored message into the SMTP system 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, in
any attempt to resend the message needs to also reapply the any attempt to resend the message, the cryptographic
cryptographic transformation before sending, or else the message transformation needs to be reapplied before sending or else the
contents will leak upon resend. A conformant MUA SHOULD NOT store message contents will leak upon resend. A conformant MUA SHOULD
a cleartext copy in the Sent folder unless it knows that the Sent NOT store a cleartext copy in the Sent folder unless it knows that
folder cannot be read by an attacker. For example, if end-to-end the Sent folder cannot be read by an attacker. For example, if
confidentiality is desired, then storing the cleartext in an IMAP end-to-end confidentiality is desired, then storing the cleartext
folder where a potentially adversarial server can read it defeats in an IMAP folder where a potentially adversarial server can read
the purpose. it defeats 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 email 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
skipping to change at line 1813 skipping to change at line 1821
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 also 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 part of the header section and what is
message is unclear to many end users and requires a more complex part of the body of a message is unclear to many end users and
mental model than is necessary. Useful security comes from alignment requires a more complex mental model than is necessary. Useful
between simple mental models and tooling. security comes from alignment 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 [RFC9788]. Protection as described in [RFC9788].
Note that some message header fields, such as List-*, Archived-At, Note that some message header fields, such as List-*, Archived-At,
and Resent-*, are typically added by an intervening MUA (see and Resent-*, are typically added by an intervening MUA (see
Section 9.8), not by one of the traditional "ends" of an end-to-end Section 9.8), not by one of the classic "ends" of an end-to-end email
email exchange. A receiving MUA may choose to consider the contents exchange. A receiving MUA may choose to consider the contents of
of these header fields on an end-to-end protected message as markers 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 * Should the Bcc header field be populated 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? See Section 3.6.3 of [RFC5322] for a set of choices.
* When separate copies are made for Bcc'ed 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 Bcc'ed 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:
* No cryptographic payload contains any Bcc header field. * No Cryptographic Payload contains any Bcc header field.
* The main copy of the message is signed and encrypted to all named * The main copy of the message is signed and encrypted to all named
recipients and to the sender. A copy of this message is also recipients and to the sender. A copy of this message is also
stored in the sender's Sent folder. stored in the sender's Sent folder.
* Each Bcc recipient receives a distinct copy of the message, with * Each Bcc recipient receives a distinct copy of the message, with
an identical cryptographic payload, and the message is signed and an identical Cryptographic Payload (that is, the cleartext is
encrypted to that specific recipient and all the named recipients. identical), and the message is signed and encrypted to that
These copies are not stored in the sender's Sent folder. specific recipient and all the named recipients. These copies are
not stored in the sender's Sent folder.
* Any Bcc'ed recipient MUST NOT be taken into consideration when * 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 Bcc'ed 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
somewhere not under the user's control (e.g., an IMAP mailbox), it somewhere not under the user's control (e.g., an IMAP mailbox), it
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.
skipping to change at line 1933 skipping to change at line 1942
in this way can be decrypted when the user wants to resume composing in this way can be decrypted when the user wants to resume composing
the message but cannot be read by anyone else, including a potential the message but cannot be read by anyone else, including a potential
intended recipient. Note that a draft message encrypted in this way intended recipient. Note that a draft message encrypted in this way
will only be resumable by another MUA attached to the same mailbox if will only be resumable by another MUA attached to the same mailbox if
that other MUA has access to the user's decryption-capable secret that other MUA has access to the user's decryption-capable secret
key. This shared access to key material is also likely necessary for key. This shared access to key material is also likely necessary for
useful interoperability but is beyond the scope of this document (see useful interoperability but is beyond the scope of 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, because creating a non-repudiable signature implies a
coordination between multiple MUAs of the same user, it should be commitment from the sender. If a signed draft message were to leak
negotiated with a different key (but see Appendix A.4.1). to the user's "Drafts" folder on some untrustworthy server, the
server operator could claim that the user had committed to something
that they had not yet decided to commit to. If draft signing is
intended for cryptographic coordination between multiple MUAs of the
same user, it should be negotiated with a different key (but see
Appendix A.4.1).
The message should only be encrypted to its recipients 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.
9.6. Composing a Message to Heterogeneous Recipients 9.6. Composing a Message to Heterogeneous Recipients
When sending a message that the user intends to be encrypted, it's When sending a message that the user intends to be encrypted, it's
possible that some recipients will be unable to receive an encrypted possible that some recipients will be unable to receive an encrypted
skipping to change at line 2016 skipping to change at line 2030
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 JSON Meta like SMTP Submission [RFC6409], IMAP [RFC9051], or JSON Meta
Application Protocol (JMAP) [RFC8621], to handle message assembly and Application Protocol (JMAP) [RFC8621], to handle message assembly and
interpretation. In such an architecture, a naive MUA speaks interpretation. In such an architecture, a naive MUA speaks
something like a "standard" protocol, like SMTP, IMAP, or JMAP, to a something like a "standard" protocol, like SMTP, IMAP, or JMAP, to a
local proxy, and the proxy handles signing and encryption (outbound) local proxy, and the proxy handles signing and encryption (outbound)
and decryption and verification (inbound) internally on behalf of the and decryption and verification (inbound) internally on behalf of the
user. While such a "pluggable" architecture has the advantage of user. While such a "pluggable" architecture has the advantage of
likely being easy to apply to any mail user agent, it is problematic likely being easy to apply to any MUA, it is problematic for the
for the goals of end-to-end communication, especially in an existing goals of end-to-end communication, especially in an existing
cleartext ecosystem like email, where any given message might be cleartext ecosystem like email, where any given message might be
unsigned or 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.
skipping to change at line 2052 skipping to change at line 2066
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 any expressed in the SMTP protocol used by Submission [RFC6409] or in any
other simple protocol that hands off a cleartext message for further other simple protocol that hands off a cleartext message for 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, such as those given message _should_ be encrypted (some messages, such as those
sent to a publicly archived mailing list, are pointless to encrypt) sent to a publicly archived mailing list, are pointless to encrypt)
or selected among multiple certificates for a recipient, if they or select among multiple certificates for a recipient, if they exist
exist (see Section 8.1.1). (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;
however, without this knowledge, the author is obliged to either however, without this knowledge, the author is obliged to either
write text that they presume will be intercepted or risk revealing write text that they presume will be intercepted or risk revealing
sensitive content. sensitive content.
skipping to change at line 2113 skipping to change at line 2127
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, by whom? What key was used to * Was the message encrypted? If so, to whom? What key was used to
decrypt it? decrypt it?
* If both signed and encrypted, was the signing outside or inside * If both signed and encrypted, was the signing outside or inside
the encryption? 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 [RFC9788].) 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 an unmodified header field through 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, it needs a guarantee from the proxy that any header it field, it needs a guarantee from the proxy that any header field 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 the S/MIME is beyond the scope of this document. [RFC9219] describes the
signature verification status over JMAP, which is a subset of the transmission of an S/MIME signature verification status over JMAP,
cryptographic status information described here. which is a subset of the 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 MUAs will resend a message in identical form (or very similar
(or very similar form) to the way that they received it. For form) to the way that they received it. For example, consider the
example, consider the following use cases: following use cases:
* a mail expander or mailing list that receives a message and * a mail expander or mailing list that receives a message and
resends 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 email 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
skipping to change at line 2200 skipping to change at line 2215
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 resend. 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 signed-and-
and-signed messages, if the intervening MUA is capable of decrypting encrypted messages, if the intervening MUA is capable of decrypting
the message, it must be careful when retransmitting 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
resend the message. resend the message.
Beyond the act of resending, an intervening MUA should not itself try Beyond the act of resending, an intervening MUA should not itself try
to apply end-to-end cryptographic protections on a message that it is to apply end-to-end cryptographic protections on a message that it is
resending unless directed otherwise by some future specification. resending unless directed otherwise by some future specification.
Additional layers of cryptographic protection added in an ad hoc way Additional layers of cryptographic protection added in an ad hoc way
by an intervening MUA are more likely to confuse the recipient and by an intervening MUA are more likely to confuse the recipient and
skipping to change at line 2244 skipping to change at line 2259
For example, a signed email message with a text/html part that refers For example, a signed email message with a text/html part that 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 web server decides img.png">) may render differently if the hosting web server decides
to 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 a signed-and-encrypted
signed message effectively breaks goals of privacy and message effectively breaks goals of privacy and confidentiality for
confidentiality for the user. 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 insufficient for an "mixed content" warning from most browsers, it is insufficient for 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
email 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 email message with an external subresource should protection to a new email message with an external subresource 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 [SRI] * use a strong integrity mechanism like Subresource Integrity [SRI]
to guarantee the content of the subresource (though this does not to guarantee the content of the subresource (though this 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 email 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 sending. the message or prompt the composing user to remove it before 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 decline to refuse to retrieve and render the external subresource or decline to
treat the message as having cryptographic protections. For example, treat the message as having cryptographic protections. For example,
it could indicate in the Cryptographic Summary that the message is it could indicate in the Cryptographic Summary that the 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
skipping to change at line 2333 skipping to change at line 2348
[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/info/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/info/rfc8551>. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC9598] Melnikov, A., Chuang, W., and C. Bonnell,
"Internationalized Email Addresses in X.509 Certificates",
RFC 9598, DOI 10.17487/RFC9598, May 2024,
<https://www.rfc-editor.org/info/rfc9598>.
[RFC9788] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header [RFC9788] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header
Protection for Cryptographically Protected Email", Protection for Cryptographically Protected Email",
RFC 9788, DOI 10.17487/RFC9788, May 2025, RFC 9788, DOI 10.17487/RFC9788, June 2025,
<https://www.rfc-editor.org/info/rfc9788>. <https://www.rfc-editor.org/info/rfc9788>.
12.2. Informative References 12.2. Informative References
[AUTOCRYPT] [AUTOCRYPT]
Autocrypt Team, "Autocrypt - Convenient End-to-End Autocrypt Team, "Autocrypt - Convenient End-to-End
Encryption for E-Mail", <https://autocrypt.org/>. Encryption for E-Mail", <https://autocrypt.org/>.
[CERT-BEST-PRACTICE] [CERT-BEST-PRACTICE]
Woodhouse, D. and N. Mavrogiannopoulos, "Recommendations Woodhouse, D. and N. Mavrogiannopoulos, "Recommendations
skipping to change at line 2456 skipping to change at line 2476
[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/info/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/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S.,
and M. Holdrege, "Threats Introduced by Reliable Server
Pooling (RSerPool) and Requirements for Security in
Response to Threats", RFC 5355, DOI 10.17487/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/info/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/info/rfc6409>. <https://www.rfc-editor.org/info/rfc6409>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., [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/info/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/info/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
skipping to change at line 2539 skipping to change at line 2557
2019, 2019,
<https://www.usenix.org/system/files/sec19-muller.pdf>. <https://www.usenix.org/system/files/sec19-muller.pdf>.
[SRI] Akhawe, D., Braun, F., Marier, F., and J. Weinberger, [SRI] Akhawe, D., Braun, F., Marier, F., and J. Weinberger,
"Subresource Integrity", W3C Candidate Recommendation, "Subresource Integrity", W3C Candidate Recommendation,
June 2016, <https://www.w3.org/TR/2016/REC-SRI-20160623/>. June 2016, <https://www.w3.org/TR/2016/REC-SRI-20160623/>.
Latest version available at <https://www.w3.org/TR/SRI/>. Latest version available at <https://www.w3.org/TR/SRI/>.
[WEBKEY-SERVICE] [WEBKEY-SERVICE]
Koch, W., "OpenPGP Web Key Directory", Work in Progress, Koch, W., "OpenPGP Web Key Directory", Work in Progress,
Internet-Draft, draft-koch-openpgp-webkey-service-19, 5 Internet-Draft, draft-koch-openpgp-webkey-service-20, 2
December 2024, <https://datatracker.ietf.org/doc/html/ June 2025, <https://datatracker.ietf.org/doc/html/draft-
draft-koch-openpgp-webkey-service-19>. koch-openpgp-webkey-service-20>.
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 of 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 classic MUA model. For example,
example, the web server hosting the webmail interface could be a the web server hosting the webmail interface could be a potential
potential adversary. If the user treats the web server as a trusted adversary. If the user treats the web server as a trusted party, but
party, but the web server violates that trust, the end-to-end the web server violates that trust, the end-to-end cryptographic
cryptographic protections do not hold. protections do not hold.
A future version of this document could include more detailed A future version of this document could include more detailed
discussion of an adversarial threat model for end-to-end discussion of an adversarial threat model for end-to-end
cryptographic protections in a webmail context. cryptographic protections in a webmail context.
A.2. Test Vectors A.2. Test Vectors
A future version of this document (or a companion document) could A future version of this document (or a companion document) could
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
skipping to change at line 2585 skipping to change at line 2603
As described in Section 8.2.3, an incoming email message may have one As described in Section 8.2.3, an incoming email message may have one
or more certificates embedded in it. This document currently or more certificates embedded in it. This document currently
acknowledges that a 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 certificates 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 the Lightweight Directory Access Protocol directory, for example, via the Lightweight Directory Access Protocol
(LDAP) [RFC4511], Web Key Directory (WKD) [WEBKEY-SERVICE], or DNS (LDAP) [RFC4511], Web Key Directory (WKD) [WEBKEY-SERVICE], or DNS
(e.g., SMIMEA [RFC8162] 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 certificate 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 Elliptic Curve (EC) Public message. For example, if the SPKI is an Elliptic Curve (EC) public
Key and the keyUsage extension is absent, what should the encrypting key and the keyUsage extension is absent, what should the encrypting
MUA do? 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
Address Books Address Books
skipping to change at line 2700 skipping to change at line 2718
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
automatically updating the certificate or prompting the user to take automatically updating the certificate or prompting the user to take
specific action. specific action.
A.5. Certification Authorities A.5. Certification Authorities
A future document could offer guidance on how an MUA should select A future document could offer guidance on how an MUA should select
and manage root certification authorities (CAs). and manage root 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?
skipping to change at line 2811 skipping to change at line 2829
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 [CLEARTEXT-COPY]. example, some of the scenarios contemplated in [CLEARTEXT-COPY].
A.12. Split Attachments A.12. Split Attachments
As noted in Section 7.2, the standard form for encrypted email 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
skipping to change at line 2903 skipping to change at line 2921
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)
pEp Project
Oberer Graben 4
CH-8400 Winterthur
Switzerland
Email: bernie@ietf.hoeneisen.ch
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
Email: alexey.melnikov@isode.com Email: alexey.melnikov@isode.com
Bernie Hoeneisen (editor)
pEp Project
Oberer Graben 4
CH-8400 Winterthur
Switzerland
Email: bernie@ietf.hoeneisen.ch
URI: https://pep-project.org/
 End of changes. 112 change blocks. 
276 lines changed or deleted 286 lines changed or added

This html diff was produced by rfcdiff 1.48.