rfc9787v6.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 A. Melnikov, Ed. Category: Informational A. Melnikov, Ed.
ISSN: 2070-1721 Isode Ltd ISSN: 2070-1721 Isode Ltd
B. Hoeneisen, Ed. B. Hoeneisen, Ed.
pEp Project pEp Project
July 2025 August 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 (MUA) implementers to help mitigate those risks and Mail User Agent (MUA) implementers to help mitigate those risks and
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 MUA can misinterpret or However, there are many ways that an MUA handling such a message can
accidentally break these security guarantees. For example, as misinterpret or accidentally break these security guarantees. For
described in [EFAIL], the "Direct Exfiltration" attack leaks example, as described in [EFAIL], the "Direct Exfiltration" attack
cleartext due to an attack that splices existing ciphertext into a leaks cleartext due to an attack that splices existing ciphertext
new message, which is then handled optimistically (and wrongly) by into a new message, which is then handled optimistically (and
many MUAs. wrongly) by many MUAs.
A MUA that interprets a message with end-to-end cryptographic A MUA that interprets a message with end-to-end cryptographic
protections needs to do so defensively, staying alert to different protections needs to do so defensively, staying alert to different
ways that these protections can be bypassed by mangling (either ways that these protections can be bypassed by mangling (either
malicious or accidental) or a failed user experience. malicious or accidental) or a failed user experience.
A MUA that generates a message with end-to-end cryptographic A MUA that generates a message with end-to-end cryptographic
protections should be aware of these defensive interpretation protections should be aware of these defensive interpretation
strategies and should compose any new outbound message conservatively strategies and should compose any new outbound message 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 MUA that This document offers guidance to the implementer of a MUA that
provides these cryptographic protections, whether for sending or provides these cryptographic protections, whether for composing,
receiving mail. An implementation that follows this guidance will interpreting, rendering, or replying to a message. An implementation
provide its users with stronger and easier-to-understand security that follows this guidance will provide its users with stronger and
properties and will also offer more reliable interoperability for easier-to-understand security properties and will also offer more
messages exchanged with other implementations. reliable interoperability for 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 MUAs controlled by the same information and metadata across multiple MUAs controlled by the same
user. user.
1.1. Terminology 1.1. Terminology
skipping to change at line 465 skipping to change at line 466
* none of the above. * none of the above.
Given that many email messages offer no cryptographic protections, Given that many email messages offer no cryptographic protections,
the user needs to be able to detect which protections are present for the user needs to be able to detect which protections are present for
any given message. any given message.
3.1. Simplified Mental Model 3.1. Simplified Mental Model
To the extent that an email message actually does have end-to-end To the extent that an email message actually does have end-to-end
cryptographic protections, those protections need to be visible and cryptographic protections, those protections need to be visible and
comprehensible to the end users: both the sending user and the comprehensible to the end users: both the composing user and the
receiving user. If either user is unaware of the protections, then recipient who views the rendered message. If either user is unaware
they do not effectively extend all the way to the "end". of the protections, then they do not effectively extend all the way
to the "end".
However, most users do not have (or want to have) a sophisticated However, most users do not have (or want to have) a sophisticated
mental model of what kinds of protections can be associated with a mental model of what kinds of protections can be associated with a
given message. Even the four states above approach the limits of given message. Even the four states above approach the limits of
complexity for an interface for normal users. complexity for an interface for normal users.
While Section 5.3 recommends avoiding deliberate creation of While Section 5.3 recommends avoiding deliberate creation of
encrypted-only messages, some messages may end up in the encrypted- encrypted-only messages, some messages may end up in the encrypted-
only state due to signature failure or certificate revocation. only state due to signature failure or certificate revocation.
A simple model for the receiving user could be that a message is in A simple model for the recipient could be that a message is in one of
one of three normal states, which align with the only reasonable three normal states, which align with the only reasonable choices for
choices for message composition: message composition:
* Unprotected * Unprotected
* Verified (has a valid signature from the apparent sender of the * Verified (has a valid signature from the apparent sender of the
message) message)
* Confidential (encrypted with a valid signature from the apparent * Confidential (encrypted with a valid signature from the apparent
sender of the message) sender of the message)
However, one error state exists for received mail that does not However, one error state exists for rendered mail that does not
correspond to a reasonable choice for message composition: correspond to a reasonable choice for message composition:
* Encrypted But Unverified (encrypted without a valid signature from * Encrypted But Unverified (encrypted without a valid signature from
the apparent sender of the message) the apparent sender of the message)
Note that this last state is not "Confidential" (a secret shared Note that this last state is not "Confidential" (a secret shared
exclusively between the participants in the communication) because exclusively between the participants in the communication) because
the recipient does not know for sure who sent it. the recipient does not know for sure who sent it.
In an ecosystem where encrypted-only messages are never deliberately In an ecosystem where encrypted-only messages are never deliberately
sent (see Section 5.3), representing an Encrypted But Unverified sent (see Section 5.3), representing an Encrypted But Unverified
message as a type of user-visible error is not unreasonable. message as a type of user-visible error is not unreasonable.
However, this is not the state of the global 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 composing
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, it MUST NOT leak cleartext of an encrypted message (even to the user, it MUST NOT leak cleartext of an encrypted message (even
an Encrypted But Unverified message) in subsequent replies (see an Encrypted But Unverified message) in subsequent 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
given received message. While this model does not precisely match given rendered message. While this model does not precisely match
the choice a user makes when composing a message, it may align more the choice a user makes when composing a message, it may align more
with the reality of the range of messages they receive. with the reality of the range of messages they encounter as a
recipient.
3.2. One Cryptographic Status per Message 3.2. One Cryptographic Status per Message
Some MUAs may attempt to generate multiple copies of a given email Some MUAs may attempt to generate multiple copies of a given email
message, with different copies offering different types of protection message, with different copies offering different types of protection
(for example, opportunistically encrypting on a per-recipient basis). (for example, opportunistically encrypting on a per-recipient basis).
A message resulting from this approach will have a cryptographic A message resulting from this approach will have a cryptographic
state that few users will understand. Even if the sender understands state that few users will understand. Even if the composer
the different statuses of the different copies, the recipients of the understands the different statuses of the different copies, the
messages may not understand (each recipient might not even know about recipients of the messages may not understand (each recipient might
the other copies). See, for example, the discussion in Section 9.6 not even know about the other copies). See, for example, the
for how this can go wrong. discussion in Section 9.6 for how this can go wrong.
For comprehensibility, a conformant MUA SHOULD NOT create multiple For comprehensibility, a conformant MUA SHOULD NOT create multiple
copies of a given message that differ in the types of end-to-end copies of a given message that differ in the types of end-to-end
cryptographic protections afforded. cryptographic protections afforded.
For opportunistic cryptographic protections that are not surfaced to For opportunistic cryptographic protections that are not surfaced to
the user (that is, that are not end-to-end), other mechanisms like the user (that is, that are not end-to-end), other mechanisms like
transport encryption [RFC3207] or domain-based signing [RFC6376] may transport encryption [RFC3207] or domain-based signing [RFC6376] may
be preferable due to ease of implementation and deployment. These be preferable due to ease of implementation and deployment. These
opportunistic transport protections are orthogonal to the end-to-end opportunistic transport protections are orthogonal to the end-to-end
skipping to change at line 567 skipping to change at line 570
protections accrue (or don't) even without visibility to the user protections accrue (or don't) even without visibility to the user
(see [RFC7435]). (see [RFC7435]).
The user needs a single clear, simple, and correct indication about The user needs a single clear, simple, and correct indication about
the end-to-end cryptographic status of any given message. See the end-to-end cryptographic status of any given message. See
Section 4.6 for more details. Section 4.6 for more details.
4. Cryptographic MIME Message Structure 4. Cryptographic MIME Message Structure
Implementations use the structure of an email message to establish Implementations use the structure of an email message to establish
(when sending) and understand (when receiving) the cryptographic (when composing) and understand (when rendering) the cryptographic
status of the message. This section establishes some conventions status of the message. This section establishes some conventions
about how to think about message structure. about how to think about message structure.
4.1. Cryptographic Layers 4.1. Cryptographic Layers
"Cryptographic Layer" refers to a MIME substructure that supplies "Cryptographic Layer" refers to a MIME substructure that supplies
some cryptographic protections to an internal MIME subtree. The some cryptographic protections to an internal MIME subtree. The
internal subtree is known as the "protected part", though of course 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.
skipping to change at line 767 skipping to change at line 770
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 See also Section 6.2.1.1 for guidance on how a rendering MUA might
deal with this common pattern. 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)
skipping to change at line 894 skipping to change at line 897
When generating an email, there are four options for applying end-to- When generating an email, there are four options for applying end-to-
end cryptographic protections: end cryptographic protections:
* Unprotected: In some cases, offering any end-to-end cryptographic * Unprotected: In some cases, offering any end-to-end cryptographic
protection is harmful: It may confuse the recipient and offer no protection is harmful: It may confuse the recipient and offer no
benefit. benefit.
* Signed-only: In other cases, signing a message is useful * Signed-only: In other cases, signing a message is useful
(authenticity and integrity are desirable), but encryption is (authenticity and integrity are desirable), but encryption is
either impossible (for example, if the sender does not know how to either impossible (for example, if the composer does not know how
encrypt to all recipients) or meaningless (for example, an email to encrypt to all recipients) or meaningless (for example, an
message to a mailing list that is intended to be published to a email message to a mailing list that is intended to be published
public archive). to a 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
skipping to change at line 932 skipping to change at line 935
3. Confidential (signed and encrypted) 3. Confidential (signed and encrypted)
Note that these choices correspond to the simplified mental model in Note that these choices correspond to the simplified mental model in
Section 3.1. Section 3.1.
A common anti-pattern among legacy MUAs is offering two boolean A common anti-pattern among legacy MUAs is offering two boolean
choices: one to toggle signing and another to toggle encryption. choices: one to toggle signing and another to toggle encryption.
This creates usability hurdles: This creates usability hurdles:
* A user who wants to send a signed-and-encrypted message will have * A user who wants to compose a signed-and-encrypted message will
to click two buttons instead of one. have to click two buttons instead of one.
* A user who clicks "Encrypt" but neglects to click "Signed" may not * A user who clicks "Encrypt" but neglects to click "Signed" may not
understand that they are creating a message that cannot be understand that they are creating a message that cannot be
authenticated by the receiver. authenticated by the recipient.
5.4. Composing a Reply Message 5.4. Composing a Reply Message
When replying to a message, most MUAs compose an initial draft of the When replying to a message, most MUAs compose an initial draft of the
reply that contains quoted text from the original message. A reply that contains quoted text from the original message. A
responsible MUA will take precautions to avoid leaking the cleartext responsible MUA will take precautions to avoid leaking the cleartext
of an encrypted message in such a reply. of an encrypted message in such a reply.
If the original message was end-to-end encrypted, the replying MUA If the original message was end-to-end encrypted, the replying MUA
MUST either: MUST either:
skipping to change at line 973 skipping to change at line 976
In this circumstance, the composing MUA SHOULD strip the quoted text In this circumstance, the composing MUA SHOULD strip the quoted text
from the original message, unless the user indicates that they are from the original message, unless the user indicates that they are
deliberately including previously confidential content in a non- deliberately including previously confidential content in a non-
confidential message. confidential message.
Note additional nuance about replies to malformed messages that Note additional nuance about replies to malformed messages that
contain encryption in Section 6.2.2.1. contain encryption in Section 6.2.2.1.
6. Message Interpretation 6. Message Interpretation
Despite the best efforts of well-intentioned senders to create email Despite the best efforts of well-intentioned composers to create
messages with well-formed, end-to-end cryptographic protection, email messages with well-formed, end-to-end cryptographic protection,
receiving MUAs will inevitably encounter some messages with malformed rendering MUAs will inevitably encounter some messages with malformed
end-to-end cryptographic protection. end-to-end cryptographic protection.
This section offers guidance on dealing with both well-formed and This section offers guidance on dealing with both well-formed and
malformed messages containing Cryptographic Layers. malformed messages containing Cryptographic Layers.
6.1. Rendering Well-Formed Messages 6.1. Rendering Well-Formed Messages
A message is well-formed when it has a Cryptographic Envelope, a A message is well-formed when it has a Cryptographic Envelope, a
Cryptographic Payload, and no Errant Cryptographic Layers. Rendering Cryptographic Payload, and no Errant Cryptographic Layers. Rendering
a well-formed message is straightforward. a well-formed message is straightforward.
The receiving MUA evaluates and assembles the cryptographic The rendering MUA evaluates and assembles the cryptographic
properties of the Cryptographic Envelope into a Cryptographic Summary properties of the Cryptographic Envelope into a Cryptographic Summary
and displays that status to the user in a secure and strictly and displays that status to the user in a secure and strictly
controlled part of the UI. In particular, the part of the UI used to controlled part of the UI. In particular, the part of the UI used to
render the Cryptographic Summary of the message MUST NOT be render the Cryptographic Summary of the message MUST NOT be
spoofable, modifiable, or otherwise controllable by the received spoofable, modifiable, or otherwise controllable by the rendered
message itself. By analogy, consider the "lock" icon in the address message itself. By analogy, consider the "lock" icon in the address
bar of the web browser: Regardless of the content of the webpage, the bar of the web browser: Regardless of the content of the webpage, the
lock icon will only be displayed when the transport to the web server lock icon will only be displayed when the transport to the web server
is adequately secured. is adequately secured.
Aside from this Cryptographic Summary, the message itself MUST be Aside from this Cryptographic Summary, the message itself MUST be
rendered as though the Cryptographic Payload is the body of the rendered as though the Cryptographic Payload is the body of the
message. The Cryptographic Layers themselves SHOULD NOT be rendered message. The Cryptographic Layers themselves SHOULD NOT be rendered
as distinct objects unless the MUA is providing the user with as distinct objects unless the MUA is providing the user with
debugging information. debugging information.
skipping to change at line 1091 skipping to change at line 1094
Cryptographic Protections: Verified [details from part I] Cryptographic Protections: Verified [details from part I]
J └─╴[protected part, may be arbitrary MIME subtree] J └─╴[protected part, may be arbitrary MIME subtree]
6.2.2. Errant Encryption Layer 6.2.2. Errant Encryption Layer
An MUA may encounter a message with an Errant Cryptographic Layer An MUA may encounter a message with an Errant Cryptographic Layer
that offers confidentiality (encryption), and the MUA is capable of that offers confidentiality (encryption), and the MUA is capable of
decrypting it. decrypting it.
The user wants to be able to see the contents of any message that The user wants to be able to see the contents of any message that
they receive, so a conformant MUA in this situation SHOULD decrypt they have access to, so a conformant MUA in this situation SHOULD
the part. decrypt the part.
However, 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 it MUST treat the decrypted cleartext as a distinct MIME subtree and it
MUST NOT attempt to merge or splice it together with any other part MUST NOT attempt to merge or splice it together with any other part
skipping to change at line 1202 skipping to change at line 1205
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 rendering 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 a signed-and-encrypted message where A conformant MUA that encounters a signed-and-encrypted message where
skipping to change at line 1228 skipping to change at line 1231
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
acceptable. acceptable.
* The signature is made by a certificate that the receiving MUA does * The signature is made by a certificate that the rendering MUA does
not have access to. not have access to.
* The certificate used to verify the signature was revoked. * The certificate used to verify the signature was revoked.
* The certificate used to verify the signature was expired at the * The certificate used to verify the signature was expired at the
time that the signature was made. time that the signature was made.
* The certificate used to verify the signature does not correspond * The certificate used to verify the signature does not correspond
to the author of the message. (For X.509, there is no to the author of the message. (For X.509, there is no
subjectAltName of type rfc822Name whose value matches an email subjectAltName of type rfc822Name whose value matches an email
skipping to change at line 1271 skipping to change at line 1274
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 rendering MUA MUST warn the user that such a message has a known
weakness. The receiving MUA MAY fully decline to decrypt such a weakness. The rendering MUA MAY fully decline to decrypt such a
message. 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.
A receiving MUA MAY also treat historically archived messages with A rendering MUA MAY also treat historically archived messages with
weak encryption differently than modern messages. For example, if an weak encryption differently than modern messages. For example, if an
encryption algorithm was known to be weak in 2005, then a message encryption algorithm was known to be weak in 2005, then a message
that appears to have been encrypted with that algorithm in 1995 might that appears to have been encrypted with that algorithm in 1995 might
be decrypted with a warning, as an archival service. But a message be decrypted with a warning, as an archival service. But a message
that appears to have been encrypted with that same weak algorithm in that appears to have been encrypted with that same weak algorithm in
2015 might be quarantined as a likely attack. 2015 might be quarantined as a likely attack.
There are several possible ways to distinguish a historical message There are several possible ways to distinguish a historical message
from a modern one, including: from a modern one, including:
skipping to change at line 1325 skipping to change at line 1328
7.1. Main Body Part 7.1. Main Body Part
When an email message is composed or rendered to the user, there is When an email message is composed or rendered to the user, there is
typically one main view that presents a (mostly textual) part of the typically one main view that presents a (mostly textual) part of the
message. message.
While the message itself may be constructed of several distinct MIME While the message itself may be constructed of several distinct MIME
parts in a tree, the part that is rendered to the user is the "Main parts in a tree, the part that is rendered to the user is the "Main
Body Part". Body Part".
When rendering a message, one of the primary jobs of the receiving When rendering a message, one of the primary jobs of the rendering
MUA is identifying which part (or parts) is the Main Body Part. MUA is identifying which part (or parts) is the Main Body Part.
Typically, this is found by traversing the MIME tree of the message Typically, this is found by traversing the MIME tree of the message
looking for a leaf node that has 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 let the user select a preferred MIME type for rendering An MUA MAY let the user select a preferred MIME type for rendering
within multipart/alternative instead of the last renderable child. within multipart/alternative instead of the last renderable child.
For example, a user may explicitly prefer a text/plain alternative For example, a user may explicitly prefer a text/plain alternative
part over text/html. Note that due to uncertainty about the part over text/html. Note that due to uncertainty about the
capabilities and configuration of the receiving MUA, a conformant capabilities and configuration of the rendering MUA, a conformant
composing MUA should consider that multiple parts might be rendered composing MUA should consider that multiple parts might be rendered
as the Main Body Part when the message is ultimately viewed. In as the Main Body Part when the message is ultimately viewed. In
particular, the composing MUA should ensure that any part likely to particular, the composing MUA should ensure that any part likely to
be viewed as the Main Body Part has the same semantic content as any be viewed as the Main Body Part has the same semantic content as 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
Body Parts, it can identify the likely parts by following the same Body Parts, it can identify the likely parts by following the same
routine as a receiving MUA. routine as a rendering MUA.
7.2. Attachments 7.2. Attachments
A message may contain one or more separated MIME parts that are A message may contain one or more separated MIME parts that are
intended for download or extraction. Such a part is commonly called intended for download or extraction. Such a part is commonly called
an "attachment" and is commonly identified by having Content- an "attachment" and is commonly identified by having Content-
Disposition: attachment. Disposition: attachment.
An MUA MAY identify a subpart as an attachment or permit extraction An MUA MAY identify a subpart as an attachment or permit extraction
of a subpart even when the subpart does not have Content-Disposition: of a subpart even when the subpart does not have Content-Disposition:
skipping to change at line 1419 skipping to change at line 1422
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 field, 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 composer prefers a specific behavior, it should explicitly set the
Content-Disposition header field on part S to either inline or Content-Disposition header field on part S to either inline or
attachment as guidance to the receiving MUA. attachment as guidance to the rendering 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
skipping to change at line 1665 skipping to change at line 1668
the scope of this 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
describes how the certificates might not be acceptable for other describes how the certificates might not be acceptable for other
people and recommend a course of action that the user can take to people and recommend a course of action that the user can take to
remedy the 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 composing 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
skipping to change at line 1792 skipping to change at line 1795
user's own asymmetric key. An MUA doing this must take care to user's own asymmetric key. An MUA doing this must take care to
store (and backup) its stash of session keys, because if it loses store (and backup) its stash of session keys, because if it loses
them, it will not be able to read the sent messages; and if them, it will not be able to read the sent messages; and if
someone else gains access to them, they can decrypt the sent someone else gains access to them, they can decrypt the sent
messages. This has the additional consequence that any other MUA messages. This has the additional consequence that any other MUA
accessing the same Sent folder cannot decrypt the message unless accessing the same Sent folder cannot decrypt the message unless
it also has access to the stashed session key. it also has access to the stashed session key.
9.2. Reading Encrypted Messages after Certificate Expiration 9.2. Reading Encrypted Messages after Certificate Expiration
When encrypting a message, the sending MUA should decline to encrypt When encrypting a message, the composing MUA should decline to
to an expired certificate (see Section 8.1.1). But when decrypting a encrypt to an expired certificate (see Section 8.1.1). But when
message, as long as the viewing MUA has access to the appropriate decrypting a message, as long as the viewing MUA has access to the
secret key material, it should permit decryption of the message, even appropriate secret key material, it should permit decryption of the
if the associated certificate is expired. That is, the viewing MUA message, even if the associated certificate is expired. That is, the
should not prevent the user from reading a message that they have rendering MUA should not prevent the user from reading a message that
already received. they have access to merely due to an expired encryption certificate.
The viewing MUA may warn the user when decrypting a message that The rendering MUA may warn the user when decrypting a message that
appears to have been encrypted to an encryption-capable certificate appears to have been encrypted to an encryption-capable certificate
that was expired at the time of encryption (e.g., based on the Date that was expired at the time of encryption (e.g., based on the Date
header field of the message or the timestamp in the cryptographic header field of the message or the timestamp in the cryptographic
signature) but otherwise should not complain. signature) but otherwise should not complain.
The primary goal of certificate expiration is to facilitate rotation The primary goal of certificate expiration is to facilitate rotation
of secret key material, so that secret key material does not need to of secret key material, so that secret key material does not need to
be retained indefinitely. Certificate expiration permits the user to be retained indefinitely. Certificate expiration permits the user to
destroy an older secret key if access to the messages received under destroy an older secret key if access to the messages encrypted to it
it is no longer necessary (see also Appendix A.10). is no longer necessary (see also Appendix A.10).
9.3. Unprotected Message Header Fields 9.3. Unprotected Message Header Fields
Many legacy cryptographically aware MUAs only apply cryptographic Many legacy cryptographically aware MUAs only apply cryptographic
protections to the body of the message but leave the header fields protections to the body of the message but leave the header fields
unprotected. This gives rise to vulnerabilities like information unprotected. This gives rise to vulnerabilities like information
leakage (e.g., the Subject line is visible to a passive intermediary) leakage (e.g., the Subject line is visible to a passive intermediary)
or message tampering (e.g., the Subject line is replaced, effectively or message tampering (e.g., the Subject line is replaced, effectively
changing the semantics of a signed message). These are not only changing the semantics of a signed message). These are not only
security vulnerabilities but also usability problems, because the security vulnerabilities but also usability problems, because the
skipping to change at line 1833 skipping to change at line 1836
requires a more complex mental model than is necessary. Useful requires a more complex mental model than is necessary. Useful
security comes from alignment between simple mental models and security comes from alignment between simple mental models and
tooling. 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 classic "ends" of an end-to-end email Section 9.8), not by one of the classic "ends" of an end-to-end email
exchange. A receiving MUA may choose to consider the contents of exchange. A rendering MUA may choose to consider the contents 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
skipping to change at line 1919 skipping to change at line 1922
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.
This is the case even if the message is ultimately sent deliberately This is the case even if the message is ultimately sent deliberately
in the clear. During message composition, the MUA does not know in the clear. During message composition, the MUA does not know
whether the message is intended to be sent encrypted or not. For whether the message is intended to be sent encrypted or not. For
example, just before sending, the sender could decide to encrypt the example, just before sending, the user could decide to encrypt the
message, and the MUA would have had no way of knowing. message, and the MUA would have had no way of knowing.
The MUA SHOULD encrypt all draft messages, unless it has explicit The MUA SHOULD encrypt all draft messages, unless it has explicit
knowledge that the message will not be encrypted when sent or that knowledge that the message will not be encrypted when sent or that
the Drafts folder cannot be read by an attacker. For example, if the Drafts folder cannot be read by an attacker. For example, if
end-to-end confidentiality is desired, then storing a cleartext draft end-to-end confidentiality is desired, then storing a cleartext draft
in an IMAP folder where a potentially adversarial server can read it in an IMAP folder where a potentially adversarial server can read it
defeats the purpose. defeats the purpose.
Furthermore, when encrypting a draft message, the message draft MUST Furthermore, when encrypting a draft message, the message draft MUST
skipping to change at line 1958 skipping to change at line 1961
same user, it should be negotiated with a different key (but see same user, it should be negotiated with a different key (but see
Appendix A.4.1). 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 composing 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 view an encrypted
copy. For example, when Carol composes a message to Alice and Bob, copy. For example, when Carol composes a message to Alice and Bob,
Carol's MUA may be able to find a valid encryption-capable Carol's MUA may be able to find a valid encryption-capable
certificate for Alice, but none for Bob. certificate for Alice, but none for Bob.
In this situation, there are four possible strategies, each of which In this situation, there are four possible strategies, each of which
has a negative impact on the experience of using encrypted mail. has a negative impact on the experience of using encrypted mail.
Carol's MUA can: Carol's MUA can:
1. send encrypted to Alice and Bob, knowing that Bob will be unable 1. send encrypted to Alice and Bob, knowing that Bob will be unable
to read the message. to read the message.
skipping to change at line 2085 skipping to change at line 2088
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.
Even without encryption, deciding whether to sign or not (and which Even without encryption, deciding whether to sign or not (and which
certificate to sign with, if more than one exists) is another choice certificate to sign with, if more than one exists) is another choice
that the proxy is ill-equipped to make. The common message-signing that the proxy is ill-equipped to make. The common message-signing
techniques either render a message unreadable by any non- techniques either render a message unreadable by any non-
cryptographic MUA (i.e., PKCS #7 signed-data) or appear as an cryptographic MUA (i.e., PKCS #7 signed-data) or appear as an
attachment that can cause confusion to a naive recipient using a non- attachment that can cause confusion to a naive recipient using a non-
cryptographic MUA (i.e., multipart/signed). If the sender knows that cryptographic MUA (i.e., multipart/signed). If the composer knows
the recipient will not check signatures, they may prefer to leave a that the recipient will not check signatures, they may prefer to
cleartext message without a cryptographic signature at all. leave a cleartext message without a cryptographic signature at all.
Furthermore, handling encryption properly depends on the context of Furthermore, handling encryption properly depends on the context of
any given message, which cannot be expressed by the MUA to the any given message, which cannot be expressed by the MUA to the
Submission proxy. For example, decisions about how to handle Submission proxy. For example, decisions about how to handle
encryption and quoted or attributed text may depend on the encryption and quoted or attributed text may depend on the
cryptographic status of the message that is being replied to (see cryptographic status of the message that is being replied to (see
Section 5.4). Section 5.4).
Additionally, such a proxy would need to be capable of managing the Additionally, such a proxy would need to be capable of managing the
user's own key and certificate (see Section 8.2). For example, how user's own key and certificate (see Section 8.2). For example, how
skipping to change at line 2241 skipping to change at line 2244
Protections Protections
A MIME part with a content type that can refer to external resources A MIME part with a content type that can refer to external resources
(like text/html) may itself have some sort of end-to-end (like text/html) may itself have some sort of end-to-end
cryptographic protections. However, retrieving or rendering these cryptographic protections. However, retrieving or rendering these
external resources may violate the properties that users expect from external resources may violate the properties that users expect from
cryptographic protection. cryptographic protection.
As a baseline, retrieving the external resource at the time a message As a baseline, retrieving the external resource at the time a message
is read can be used as a "web bug", leaking the activity and network is read can be used as a "web bug", leaking the activity and network
location of the receiving user to the server hosting the external location of the recipient to the server hosting the external
resource. This privacy risk is present, of course, even for messages resource. This privacy risk is present, of course, even for messages
with no cryptographic protections but may be even more surprising to with no cryptographic protections but may be even more surprising to
users who are shown some level of security indicator about a given users who are shown some level of security indicator about a given
message. message.
Other problems with external resources are more specifically bound to Other problems with external resources are more specifically bound to
cryptographic protections. cryptographic protections.
For example, 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/
skipping to change at line 2270 skipping to change at line 2273
message effectively breaks goals of privacy and confidentiality for message effectively breaks goals of privacy and 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 composing 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 composing 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 rendering 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 2355 skipping to change at line 2358
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, [RFC9598] Melnikov, A., Chuang, W., and C. Bonnell,
"Internationalized Email Addresses in X.509 Certificates", "Internationalized Email Addresses in X.509 Certificates",
RFC 9598, DOI 10.17487/RFC9598, May 2024, RFC 9598, DOI 10.17487/RFC9598, May 2024,
<https://www.rfc-editor.org/info/rfc9598>. <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, June 2025, RFC 9788, DOI 10.17487/RFC9788, August 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 2596 skipping to change at line 2599
[RFC9216]. [RFC9216].
It may also include example renderings of these messages. It may also include example renderings of these messages.
A.3. Further Guidance on Peer Certificates A.3. Further Guidance on Peer Certificates
A.3.1. Certificate Discovery from Incoming Messages A.3.1. Certificate Discovery from Incoming Messages
As described in Section 8.2.3, an incoming 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 rendering 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 certificates should be handled. detail how these incoming certificates should be handled.
A.3.2. Certificate Directories A.3.2. Certificate Directories
skipping to change at line 2635 skipping to change at line 2638
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 composing MUA could select among
some deterministic way; it could encrypt to all of them; or it could them in some deterministic way; it could encrypt to all of them; or
present them to the user to let the user select any or all of them. it could 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
In header fields such as From that may contain a display-name as In header fields such as From that may contain a display-name as
described in Section 3.4 of [RFC5322], a malicious sender (or described in Section 3.4 of [RFC5322], a malicious composer (or
interfering adversary) may populate the display-name part with a interfering adversary) may populate the display-name part with a
human-readable name that does not at all match the actual name of the human-readable name that does not at all match the actual name of the
participant. Section 8.1.1 describes some matching rules relating participant. Section 8.1.1 describes some matching rules relating
peer certificates to email addresses (the addr-spec part of these peer certificates to email addresses (the addr-spec part of these
email header fields) but does not contemplate matching display-names email header fields) but does not contemplate matching display-names
or other similar user-visible data elements. Section 6.4 describes or other similar user-visible data elements. Section 6.4 describes
how signature validation should confirm a binding between the addr- how signature validation should confirm a binding between the addr-
spec and the certificate itself, but it also does not contemplate spec and the certificate itself, but it also does not contemplate
matching display-names or other similar user-visible data elements. matching display-names or other similar user-visible data elements.
Depending on how the receiving MUA renders the display-name in a Depending on how the rendering MUA renders the display-name in a
message's header field, that unvalidated field may present a risk of message's header field, that unvalidated field may present a risk of
user confusion, which could break the intended end-to-end assurances. user confusion, which could break the intended end-to-end assurances.
Yet both X.509 and OpenPGP certificate formats offer ways to provide Yet both X.509 and OpenPGP certificate formats offer ways to provide
cryptographically certified (though possibly not unique) comparable cryptographically certified (though possibly not unique) comparable
human-readable names. Additionally, many MUAs also include an human-readable names. Additionally, many MUAs also include an
address book or comparable feature that can make substantive address book or comparable feature that can make substantive
connections between user-relevant identity labels and email connections between user-relevant identity labels and email
addresses. addresses.
A human-readable name like a display-name does not have the property A human-readable name like a display-name does not have the property
skipping to change at line 2784 skipping to change at line 2788
of explicitly related messages), conversations (groups of messages of explicitly related messages), conversations (groups of messages
with shared sets of participants), peers, or other perspectives that with shared sets of participants), peers, or other perspectives that
an MUA can provide. an MUA can provide.
A.9. Expectations of Cryptographic Protection A.9. Expectations of Cryptographic Protection
As mentioned in Section 2.3, the types of security indicators As mentioned in Section 2.3, the types of security indicators
displayed to the user may vary based on the expectations of the user displayed to the user may vary based on the expectations of the user
for a given communication. At present, there is no widely shared for a given communication. At present, there is no widely shared
method for the MUA to establish and maintain reasonable expectations method for the MUA to establish and maintain reasonable expectations
about whether a specific received message should have cryptographic about whether a specific rendered message should have cryptographic
protections. protections.
If such a standard is developed, a future version of this document If such a standard is developed, a future version of this document
should reference it and encourage the deployment of clearer and should reference it and encourage the deployment of clearer and
simpler security indicators. simpler security indicators.
A.10. Secure Deletion A.10. Secure Deletion
One feature many users desire from a secure communications medium is One feature many users desire from a secure communications medium is
the ability to reliably destroy a message such that it cannot be the ability to reliably destroy a message such that it cannot be
skipping to change at line 2877 skipping to change at line 2881
mailing list. Another challenge is that, for some mailing lists, mailing list. Another challenge is that, for some mailing lists,
some subscribers might not have a valid, non-expired certificate. some subscribers might not have a valid, non-expired certificate.
Encryption can interact with mailing lists in different ways, Encryption can interact with mailing lists in different ways,
depending on the use case of the list. It's not clear that there are depending on the use case of the list. It's not clear that there are
any useful motivations for sending encrypted mail to a publicly any useful motivations for sending encrypted mail to a publicly
archived mailing list. But an unarchived mailing list might want to archived mailing list. But an unarchived mailing list might want to
provide confidentiality between all recipients, even if the provide confidentiality between all recipients, even if the
recipients don't know for certain who all the other participants are. recipients don't know for certain who all the other participants are.
Or a mailing list with private archives might well decide that two Or a mailing list with private archives might well decide that two
"hops" of encryption (between the sender and the mailing list, and "hops" of encryption (between the composer and the mailing list, and
the mailing list and all the subscribers) are useful confidentiality the mailing list and all the subscribers) are useful confidentiality
measures even though they are not "end-to-end" in the sense of the measures even though they are not "end-to-end" in the sense of the
sender directly to all recipients. composer directly to all recipients.
Similarly, cryptographic signatures may play different roles in a Similarly, cryptographic signatures may play different roles in a
mailing list, depending on the list's communication goals. The mailing list, depending on the list's communication goals. The
mailing list itself might want to verify that an incoming message is mailing list itself might want to verify that an incoming message is
cryptographically signed by an authorized sender before cryptographically signed by an authorized sender before
redistribution to the list subscribers. It might also want to pass redistribution to the list subscribers. It might also want to pass
along the sender's signature in a way that the subscribers can all along the composer's signature in a way that the subscribers can all
verify it. Alternately, the mailing list might want to sign each verify it. Alternately, the mailing list might want to sign each
redistributed message itself and change the message so it appears to redistributed message itself and change the message so it appears to
come from the list rather than the original sender. come from the list rather than the original composer.
Yet another design for a mailing list with end-to-end cryptographic Yet another design for a mailing list with end-to-end cryptographic
protections might involve redistributing shared secret keys to all protections might involve redistributing shared secret keys to all
recipients or using some sort of proxied re-encryption scheme, recipients or using some sort of proxied re-encryption scheme,
similar to [OPENPGP-FORWARDING]. similar to [OPENPGP-FORWARDING].
A future version of this document, or a separate but related A future version of this document, or a separate but related
document, might describe some of these trade-offs and provide document, might describe some of these trade-offs and provide
guidance for safely meeting common requirements or use cases when guidance for safely meeting common requirements or use cases when
combining end-to-end cryptographic protections with mailing lists. combining end-to-end cryptographic protections with mailing lists.
 End of changes. 50 change blocks. 
87 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.48.