Header Protection for Cryptographically Protected Email
updates
- rfc-8551 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
Extracted elements (33)
The HCP abstraction was introduced because the choice of which Header Fields to make confidential in encrypted messages is a policy decision with real deliverability tradeoffs. Existing mail infrastructure may reject or delay messages with all Header Fields removed; hcp_baseline was chosen as default because it hides the Subject (the most sensitive field) while preserving routing-relevant fields.
The HCP is deliberately not represented on the wire; instead, the rendering MUA infers the sender's confidentiality choices by comparing protected Inner Header Fields against HP-Outer fields. This avoids adding a new negotiation round-trip while still giving the receiver cryptographically verifiable information about which fields the composer intended to hide.
The new Header Protection scheme avoids using an intervening message/rfc822 wrapper (as RFC8551HP did) because that structure caused pervasive Legacy MUA failures. Instead, protected Header Fields are copied directly into the Cryptographic Payload's Header Section, which Legacy MUAs can ignore without breaking message rendering.
An RFC8551HP message is identified by its MIME structure: a Cryptographic Envelope whose Cryptographic Payload is a single message/rfc822 object, with no hp= parameter on the Cryptographic Payload or its immediate child. When identified, a conformant MUA may render it by treating the Payload's immediate child as the Cryptographic Payload.
RFC 8551 Header Protection (RFC8551HP), which wraps a message/rfc822 MIME object in the Cryptographic Payload, causes widespread rendering failures in Legacy MUAs: some cannot render message/rfc822 at all, others show the protected message as a forwarded attachment stripped of security indicators. This specification supersedes RFC8551HP.
The Header Protection scheme defined in this document is applicable to PGP/MIME (RFC 3156) as well as S/MIME. Any divergence needed for PGP/MIME is explicitly out of scope; implementations SHOULD apply the same mechanisms to both.
A composing implementation MUST NOT produce a Cryptographic Payload with hp='cipher' for an unencrypted message. Conversely, if composing an encrypted message with Header Protection, it MUST emit an hp='cipher' parameter regardless of which Header Fields were made confidential.
A rendering implementation MUST NOT mistake the presence of an hp='cipher' parameter in the Cryptographic Payload for the actual presence of a Cryptographic Layer that provides encryption, since encryption may have been added in transit.
An automated system using email as a control channel that depends on a message's cryptographic signature MUST rely on Header Fields from within the Cryptographic Payload and MUST NOT rely on any Header Field found outside it.
An implementation that composes encrypted email MUST include a copy of all Non-Structural Header Fields deliberately exposed outside the Cryptographic Envelope as HP-Outer Header Fields within the Cryptographic Payload. HP-Outer fields appearing elsewhere MUST be ignored for Header Protection evaluation.
An MUA MUST have a default HCP that offers confidentiality for the Subject Header Field at least. A conformant MUA not altered by local policy MUST NOT use hcp_no_confidentiality by default.
An MUA MUST NOT generate an RFC8551HP message (the legacy scheme from RFC 8551 that wraps a message/rfc822 object). However, for backward compatibility, an MUA MAY attempt to render or respond to such a message as though it has standard Header Protection.
An MUA SHOULD warn the user when both a From Header Field Mismatch exists (inner and outer addr-spec differ) and there is no valid, correctly bound signature. The warning should be comparable to a spam/phishing warning and SHOULD show both non-matching From values.
An MUA that depends on any implicitly rendered Header Field (e.g., Message-Id, References, In-Reply-To, Reply-To) in a message with Header Protection MUST use the value from the protected Header Field and SHOULD NOT use any value found outside the cryptographic protection.
The rendering MUA MUST completely avoid rendering Legacy Display Elements to the user. If a text/html or text/plain part is identified as containing Legacy Display Elements, those elements MUST be hidden when rendering and MUST be dropped when generating a draft reply or inline forwarded message.
When composing a message with end-to-end cryptographic protections, an MUA SHOULD apply Header Protection. The hp parameter MUST be added only to the Content-Type at the root of the Cryptographic Payload, and its value MUST reflect whether the envelope contains an encrypting layer.
When rendering a message with Header Protection, an MUA SHOULD render the protected Header Field value from the Cryptographic Payload and ignore unprotected counterparts, with a special exception for the From Header Field when a mismatch with no valid signature is detected.
When responding to a message with Header Protection, an MUA MUST only use the protected Header Fields when populating recipients of the new message. This prevents a MITM attacker from causing a misdirected reply by modifying the unprotected outer From address of an encrypted message.
Encrypted Header Fields are not fully private: (1) they may reveal information to the recipient that the sender didn't intend; (2) they can be inferred from external metadata (e.g., message size, timing); (3) HCP may not fully mask them. Additionally, a naive recipient may overestimate the confidentiality status of a Header Field that is signed-only despite the message body being encrypted.
When replying to or forwarding a message with confidential Header Fields, MUAs must prevent leaking those fields in cleartext. The HP-Outer mechanism provides a cryptographically protected record of which fields were exposed, enabling safe replies without inadvertently revealing the original message's Subject or recipients.
A Header Confidentiality Policy (HCP) is a function hcp(name, val_in) -> val_out that, for each Non-Structural Header Field, returns either the original value (expose), a modified value (obscure), or null (remove from the Outer Header Section). HCPs are only relevant for encrypted messages.
hcp_baseline is the recommended default HCP: it replaces the Subject with '[...]' and removes Comments and Keywords from the Outer Header Section, while leaving all other Non-Structural Header Fields unchanged. It balances meaningful confidentiality with deliverability.
hcp_shy is a more privacy-preserving HCP that builds on hcp_baseline and additionally strips display names from From/To/Cc addresses (leaving only addr-spec) and normalizes the Date Header Field to UTC, reducing metadata leakage without affecting routing.
The hp Content-Type parameter is placed on the root of the Cryptographic Payload to signal the composer's intent for Header Protection. Its value is either 'clear' (signed with integrity/authenticity but no confidentiality) or 'cipher' (signed, with Header Protection, and encrypted to recipients).
The hp-legacy-display Content-Type parameter (value '1') marks a text/plain or text/html leaf MIME node as containing a Legacy Display Element — a decorative backward-compatible copy of removed or obscured User-Facing Header Fields intended for Legacy MUAs. Conformant MUAs suppress rendering of this element.
The HP-Outer Header Field appears only within the Header Section of an encrypted message's Cryptographic Payload. It embeds a protected copy of every Non-Structural Header Field that the composer exposed outside the Cryptographic Envelope, enabling the renderer to determine which Header Fields were made confidential.
This document creates the 'Mail Header Confidentiality Policies' IANA registry with 'Specification Required' policy. Initial entries are hcp_baseline (Recommended), hcp_shy, and hcp_no_confidentiality. Entries must include a stable reference, pseudocode, differentiation from existing policies, and deployment considerations.
This document registers the HP-Outer Header Field in the 'Provisional Message Header Field Names' registry (per RFC 3864). The field is used only in the Inner Header Section of encrypted messages with Header Protection and MUST be ignored elsewhere.
Encryption may be added to a message in transit after signing. A rendering MUA MUST NOT infer that the composer intended confidentiality merely because an encrypting layer is present; it must also confirm the hp='cipher' parameter was set by the composer in the Cryptographic Payload.
Legacy Display Elements in composing MUAs can expose confidential Header Fields: a Legacy MUA handling the message will display the Legacy Display Element in the message body, revealing the same fields that were removed or obscured from the Outer Header Section. Composers must understand this tradeoff.
When a rendering MUA depends on its MTA to authenticate the outer From address but renders the inner (protected) From address that differs from the outer one without a valid bound signature, an attacker can substitute the sender identity. MUAs SHOULD warn users and render the outer From address under these conditions.
Each Header Field in a message with Header Protection has exactly one of four protection states: unprotected, signed-only (in signature but visible in transit), encrypted-only (only in Cryptographic Payload; external value removed or obscured), or signed-and-encrypted (encrypted-only and under a validated signature). The state is computed by the HeaderFieldProtection algorithm using the hp parameter and HP-Outer fields.
The HP-Outer Header Field syntax is: 'HP-Outer:' [FWS] field-name ': ' hp-outer-value CRLF, where hp-outer-value matches the unstructured production from RFC 5322 §3.2.5 but without the obsolete obs-unstruct option. Each instance encodes a single Non-Structural Header Field name and its Outer Header Section value.