rfc9787v4.txt   rfc9787.txt 
skipping to change at line 225 skipping to change at line 225
* 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 * _Non-Structural Header Fields_ are header fields that are not
Structural Header Fields. 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 510 skipping to change at line 510
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 658 skipping to change at line 658
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 within the SEIPD).
skipping to change at line 706 skipping to change at line 706
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)
skipping to change at line 1003 skipping to change at line 1003
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 1090 skipping to change at line 1090
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 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
of the message. This offers protection against the direct of the message. This offers protection against the direct
exfiltration (also known as EFAIL-DE) attacks described in [EFAIL] exfiltration (also known as EFAIL-DE) attacks described in [EFAIL]
skipping to change at line 1185 skipping to change at line 1185
Regardless of the cryptographic protections and structure of the Regardless of the cryptographic protections and structure of the
incoming message, the internal forwarded message may have its own incoming message, the internal forwarded message may have its own
Cryptographic Envelope. Cryptographic Envelope.
The Cryptographic Layers that are part of the Cryptographic Envelope The Cryptographic Layers that are part of the Cryptographic Envelope
of the forwarded message are not Errant Cryptographic Layers of the of the forwarded message are not Errant Cryptographic Layers of the
surrounding message -- they are simply layers that apply to the surrounding message -- they are simply layers that apply to the
forwarded message itself. forwarded message itself.
A conformant-rendering MUA MUST NOT conflate the cryptographic A conformant rendering MUA MUST NOT conflate the cryptographic
protections of the forwarded message with the cryptographic protections of the forwarded message with the cryptographic
protections of the incoming message. protections of the incoming message.
A conformant-rendering MUA MAY render a Cryptographic Summary of the A conformant rendering MUA MAY render a Cryptographic Summary of the
protections afforded to the forwarded message by its own protections afforded to the forwarded message by its own
Cryptographic Envelope, as long as that rendering is unambiguously Cryptographic Envelope, as long as that rendering is unambiguously
tied to the forwarded message itself and cannot be spoofed 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.
skipping to change at line 1257 skipping to change at line 1257
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
skipping to change at line 1337 skipping to change at line 1337
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 receiving 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
skipping to change at line 1475 skipping to change at line 1475
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 whose contents
match the destination email address. In particular, the local match the destination email address. In particular, the local-
part of the two addresses should be an exact bytewise match, and part of the two addresses should be an exact bytewise match, and
the domain parts of the two addresses should be matched by the domain parts of the two addresses should be matched by
ensuring label equivalence across the full domain name, as ensuring label equivalence across the full domain name, as
described in Section 2.3.2.4 of [RFC5890]. described in Section 2.3.2.4 of [RFC5890].
* The algorithm OID in the certificate's SubjectPublicKeyInfo (SPKI) * The algorithm OID in the certificate's SubjectPublicKeyInfo (SPKI)
is known to the MUA 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"
skipping to change at line 1526 skipping to change at line 1526
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
also generate distinct S/MIME certificates to avoid possible cross- generate distinct S/MIME certificates to avoid possible cross-
protocol key misuse: one for encryption and another for signing. 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 (CA) certificates the user, and intermediate certification authority (CA) certificates
that permit chaining from the end entity certificates to widely that permit chaining from the end entity certificates to widely
accepted trust anchors. A conformant MUA that imports such a PKCS accepted trust anchors. A conformant MUA that imports such a PKCS
#12 bundle SHOULD warn the user if the bundle contains an S/MIME #12 bundle SHOULD warn the user if the bundle contains an S/MIME
certificate and corresponding secret key where the same secret key is certificate and corresponding secret key where the same secret key is
skipping to change at line 2054 skipping to change at line 2054
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 2115 skipping to change at line 2115
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].)
skipping to change at line 2149 skipping to change at line 2149
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
skipping to change at line 2257 skipping to change at line 2258
signed message effectively breaks goals of privacy and signed message effectively breaks goals of privacy and
confidentiality for the user. confidentiality for the user.
This is loosely analogous to security indicator problems that arose This is loosely analogous to security indicator problems that arose
for web browsers as described in [MIXED-CONTENT]. However, while for web browsers as described in [MIXED-CONTENT]. However, while
fetching the external subresource over https is sufficient to avoid a fetching the external subresource over https is sufficient to avoid a
"mixed content" warning from most browsers, it is 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 2337 skipping to change at line 2338
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>.
[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 2539 skipping to change at line 2540
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-20, 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-20>. 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
 End of changes. 21 change blocks. 
30 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.48.