Summary

  • RFC 9787 gives a message one clear cryptographic summary, but only the contiguous signing and encryption layers surrounding its Crypto Payload contribute to it.
  • A valid nested signature, an errant encrypted fragment, a forwarded message or a detached attachment can have its own cryptographic result without inheriting—or upgrading—the status of the enclosing message.
  • Replies, archival decryption and certificate expiry are new decisions with new evidence. A mail user agent must preserve those boundaries instead of extending yesterday's badge by implication.

A green light needs a jurisdiction

Consider a message that arrives with a familiar encrypted indicator. Inside it sits a forwarded message. Inside that forward is a signed document. Beside it is an attachment added after the signing operation. Which object did the indicator describe?

The answer cannot be “the screen”. A screen is a composition assembled after transport, parsing, decryption and rendering. RFC 9787 instead defines a cryptographic envelope: the contiguous series of signing and encryption layers surrounding one Crypto Payload. The mail user agent aggregates the results of those layers into one summary. A cryptographic layer elsewhere in the MIME tree is errant relative to that envelope and must not contribute.

That rule is deliberately narrow. RFC 3156 and RFC 8551 supply the OpenPGP/MIME and S/MIME formats; RFC 2045 supplies the MIME substrate. None turns visual proximity into cryptographic coverage. RFC 9787 gives the interface a common answer while refusing to let one successfully processed object lend authority to its neighbors.

The distinction matters most when all the cryptography works. A nested signed part may validate. An encrypted fragment may decrypt. Those are genuine local results. They still do not prove that the enclosing message, its added introduction, its footer or an adjacent attachment shared the same protection. The summary is not a mood. It is a statement about membership in a particular structure.

The mailing-list footer changes the received object

RFC 9787 uses mailing-list wrapping to expose the problem. An author signs a message. A list service encloses that signed entity and adds a footer. The original signature may remain perfectly valid for the inner content, but it is now an errant layer relative to the message the subscriber received. The subscriber's message has no cryptographic envelope and its summary is unprotected.

The user agent may still explain the inner result, provided it does so separately and in non-spoofable interface chrome. It must not merge “this enclosed part validates” into “this received message is signed”. In some list workflows the sender's sent copy and the subscriber's received copy can therefore carry different legitimate summaries. That is not inconsistency; they are different message objects.

The same reasoning covers baroque nesting. If signing or encryption occurs inside the Crypto Payload rather than as part of the contiguous outer envelope, it is errant for the top-level summary. The renderer can expose its local state, but it cannot promote that state upward.

Decryption is not permission to splice

An errant encrypted part creates a tempting shortcut: decrypt the fragment and insert its cleartext into the surrounding HTML. RFC 9787 rejects that move. A client may let the user inspect the decrypted material, but it must render it as a separate MIME subtree and must not claim that the whole message was encrypted.

The separation responds to a concrete class of risks explored by the EFAIL research and later multipart-oracle work. Attacker-controlled neighboring content can turn decryption plus rendering into an exfiltration mechanism. Successful decryption is evidence about ciphertext and a key; it is not authority to combine that plaintext with arbitrary surrounding markup.

Inline non-MIME OpenPGP material receives the same disciplined treatment. RFC 9580 describes the modern OpenPGP format, but an inline block outside the MIME protection model cannot supply a validating signature to the message summary. A client may decrypt it into a separate part. It must not silently quote the resulting plaintext in a reply.

Forwarding creates a second evidence scope

A forwarded message/rfc822 or internationalized message/global object can carry its own envelope under RFC 5322 and RFC 6532. RFC 9787 says its cryptographic layers are errant relative to the enclosing message. The forward can have a distinct summary; the outer message can have another. A trustworthy interface shows both without making either badge look inherited.

A reply is not a passive view. It is a new message and therefore a new disclosure decision. When the received message's overall summary is encrypted, RFC 9787 requires an encrypted reply or omission of quoted original text. If the client lacks an unexpired encryption-capable certificate for every recipient, it removes the quotation unless the user explicitly decides otherwise. The reply-attack research supplies context for treating quotation as an active security boundary.

Errant encrypted content is more asymmetric. The client may decrypt it for display, while the enclosing message remains unencrypted. A reply should still be encrypted to the relevant recipients, but the decrypted errant content must not enter the quotation. “I was allowed to see it” is not the same receipt as “I am authorized to redistribute it in this new message”.

Attachments belong inside the one payload

RFC 9787 places attachments inside the Crypto Payload. That supplies one integrity boundary for the message and its attachments. Giving each attachment a separate envelope looks flexible but creates a composition problem: parts can be removed, replaced or reordered without global integrity, and a single badge cannot honestly describe mixed attachment states.

This is an architectural choice, not a claim that every attachment displayed by a client is protected. An operator must recover the parsed MIME tree and prove membership. The visible paperclip, filename or download panel is not evidence. A detached object can sit one pixel from an encrypted body and remain outside its envelope.

Expiry changes lifecycle evidence, not old ciphertext

Certificate expiry is another place where interfaces collapse distinct facts. RFC 9787 says a client should allow decryption when the user possesses the required secret key even if the associated certificate has expired. Expiry supports rotation and planned key destruction. It does not retroactively make the ciphertext unreadable. A warning belongs when the certificate was already expired at encryption time; later expiry is a different event.

Long-term access therefore depends on custody choices. A sender can encrypt an exact wire copy to itself; keep distinct recipient and sender versions; retain cleartext; or preserve session keys. Each option changes byte fidelity, exposure, backup requirements and portability across clients. No badge answers those governance questions.

RFC 9788 addresses adjacent header-protection mechanics; they are outside this article's scope. The RFC Editor record, Datatracker and errata search establish the publication record and the time-bounded fact that no matching errata were listed when checked. They do not prove implementation or deployment.