rfc9787v3.txt   rfc9787.txt 
skipping to change at line 823 skipping to change at line 823
form is most likely to achieve its end-to-end security goals. form is most likely to achieve its end-to-end security goals.
5.1. Message Composition Algorithm 5.1. Message Composition Algorithm
This section describes the steps that an MUA should use to compose a This section describes the steps that an MUA should use to compose a
cryptographically protected message, such that it has a proper cryptographically protected message, such that it has a proper
Cryptographic Envelope and Payload. Cryptographic Envelope and Payload.
The message composition algorithm takes three parameters: The message composition algorithm takes three parameters:
origbody: The traditional unprotected message body as a well-formed origbody: The unprotected message body as a well-formed MIME tree
MIME tree (possibly just a single MIME leaf part). As a well- (possibly just a single MIME leaf part). As a well-formed MIME
formed MIME tree, origbody already has Structural Header Fields tree, origbody already has Structural Header Fields present (see
present (see Section 1.1.1). Section 1.1.1).
origheaders: The intended Non-Structural Header Fields for the origheaders: The intended Non-Structural Header Fields for the
message, represented here as a list of (h,v) pairs, where h is a message, represented here as a list of (h,v) pairs, where h is a
header field name and v is the associated value. header field name and v is the associated value.
crypto: The series of cryptographic protections to apply (for crypto: The series of cryptographic protections to apply (for
example, "sign with the secret key corresponding to X.509 example, "sign with the secret key corresponding to X.509
certificate X, then encrypt to X.509 certificates X and Y"). This certificate X, then encrypt to X.509 certificates X and Y"). This
is a routine that accepts a MIME tree as input (the Cryptographic is a routine that accepts a MIME tree as input (the Cryptographic
Payload), wraps the input in the appropriate Cryptographic Payload), wraps the input in the appropriate Cryptographic
skipping to change at line 850 skipping to change at line 850
the mail system: the mail system:
1. Apply crypto to origbody, yielding MIME tree output. 1. Apply crypto to origbody, yielding MIME tree output.
2. For each header name and value (h,v) in origheaders: 2. For each header name and value (h,v) in origheaders:
a. Add header h to output with value v. a. Add header h to output with value v.
3. Return output. 3. Return output.
This is the traditional algorithm. It only protects the Structural This is the classic algorithm. It only protects the Structural
Header Fields of the message body and leaves Non-Structural Header Fields of the message body and leaves Non-Structural
(including User-Facing) Header Fields unprotected. (including User-Facing) Header Fields unprotected.
Therefore, a conformant MUA MUST implement Header Protection as Therefore, a conformant MUA MUST implement Header Protection as
described in [RFC9788] (see Section 9.3). described in [RFC9788] (see Section 9.3).
5.2. Encryption Outside, Signature Inside 5.2. Encryption Outside, Signature Inside
An email message that is both signed and encrypted is signed _inside_ An email message that is both signed and encrypted is signed _inside_
the encryption and not the other way around. For example, when the encryption and not the other way around. For example, when
skipping to change at line 1826 skipping to change at line 1826
distinction between what is a header and what is the body of a distinction between what is a header and what is the body of a
message is unclear to many end users and requires a more complex message is unclear to many end users and requires a more complex
mental model than is necessary. Useful security comes from alignment mental model than is necessary. Useful security comes from alignment
between simple mental models and tooling. between simple mental models and tooling.
To avoid these concerns, a conformant MUA MUST implement Header To avoid these concerns, a conformant MUA MUST implement Header
Protection as described in [RFC9788]. Protection as described in [RFC9788].
Note that some message header fields, such as List-*, Archived-At, Note that some message header fields, such as List-*, Archived-At,
and Resent-*, are typically added by an intervening MUA (see and Resent-*, are typically added by an intervening MUA (see
Section 9.8), not by one of the traditional "ends" of an end-to-end Section 9.8), not by one of the classic "ends" of an end-to-end email
email exchange. A receiving MUA may choose to consider the contents exchange. A receiving MUA may choose to consider the contents of
of these header fields on an end-to-end protected message as markers these header fields on an end-to-end protected message as markers
added during message transit, even if they are not covered by the added during message transit, even if they are not covered by the
end-to-end cryptographic protection. end-to-end cryptographic protection.
9.4. Composing an Encrypted Message with Bcc 9.4. Composing an Encrypted Message with Bcc
When composing an encrypted message containing at least one recipient When composing an encrypted message containing at least one recipient
address in the Bcc header field, there is a risk that the encrypted address in the Bcc header field, there is a risk that the encrypted
message itself could leak information about the actual recipients, message itself could leak information about the actual recipients,
even if the Bcc header field does not mention the recipient. For even if the Bcc header field does not mention the recipient. For
example, if the message clearly indicates which certificates it is example, if the message clearly indicates which certificates it is
skipping to change at line 2553 skipping to change at line 2553
Appendix A. Future Work Appendix A. Future Work
This document contains useful guidance for MUA implementers, but it This document contains useful guidance for MUA implementers, but it
cannot contain all possible guidance. Future revisions of this cannot contain all possible guidance. Future revisions of this
document may want to further explore the following topics, which are document may want to further explore the following topics, which are
out of scope for this version. out of scope for this version.
A.1. Webmail Threat Model A.1. Webmail Threat Model
The webmail threat model for end-to-end cryptographic protections is The webmail threat model for end-to-end cryptographic protections is
significantly more complex than the traditional MUA model. For significantly more complex than the classic MUA model. For example,
example, the web server hosting the webmail interface could be a the web server hosting the webmail interface could be a potential
potential adversary. If the user treats the web server as a trusted adversary. If the user treats the web server as a trusted party, but
party, but the web server violates that trust, the end-to-end the web server violates that trust, the end-to-end cryptographic
cryptographic protections do not hold. protections do not hold.
A future version of this document could include more detailed A future version of this document could include more detailed
discussion of an adversarial threat model for end-to-end discussion of an adversarial threat model for end-to-end
cryptographic protections in a webmail context. cryptographic protections in a webmail context.
A.2. Test Vectors A.2. Test Vectors
A future version of this document (or a companion document) could A future version of this document (or a companion document) could
contain examples of well-formed and malformed messages using contain examples of well-formed and malformed messages using
cryptographic key material and certificates from [RFC9580] and cryptographic key material and certificates from [RFC9580] and
 End of changes. 4 change blocks. 
13 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.48.