rfc9788v4.txt   rfc9788.txt 
skipping to change at line 143 skipping to change at line 143
Content-Types Content-Types
6. Replying and Forwarding Guidance 6. Replying and Forwarding Guidance
6.1. Avoid Leaking Encrypted Header Fields in Replies and 6.1. Avoid Leaking Encrypted Header Fields in Replies and
Forwards Forwards
6.1.1. ReferenceHCP 6.1.1. ReferenceHCP
6.2. Avoid Misdirected Replies 6.2. Avoid Misdirected Replies
7. Unprotected Header Fields Added in Transit 7. Unprotected Header Fields Added in Transit
7.1. Mailing List Header Fields: List-* and Archived-At 7.1. Mailing List Header Fields: List-* and Archived-At
8. Email Ecosystem Evolution 8. Email Ecosystem Evolution
8.1. Dropping Legacy Display Elements 8.1. Dropping Legacy Display Elements
8.2. More Ambitious Default Header Confidentiality Policy 8.2. More Ambitious Default HCP
8.3. Deprecation of Messages Without Header Protection 8.3. Deprecation of Messages Without Header Protection
9. Usability Considerations 9. Usability Considerations
9.1. Mixed Protections Within a Message Are Hard to Understand 9.1. Mixed Protections Within a Message Are Hard to Understand
9.2. Users Should Not Have to Choose a Header Confidentiality 9.2. Users Should Not Have to Choose a Header Confidentiality
Policy Policy
10. Security Considerations 10. Security Considerations
10.1. From Address Spoofing 10.1. From Address Spoofing
10.1.1. From Rendering Reasoning 10.1.1. From Rendering Reasoning
10.2. Avoid Cryptographic Summary Confusion from the hp 10.2. Avoid Cryptographic Summary Confusion from the hp
Parameter Parameter
skipping to change at line 318 skipping to change at line 318
considered in [RFC8551]. considered in [RFC8551].
1.1.1. Problems with RFC 8551 Header Protection 1.1.1. Problems with RFC 8551 Header Protection
Several Legacy MUAs have difficulty rendering a message that uses Several Legacy MUAs have difficulty rendering a message that uses
RFC8551HP. These problems can appear on signed-only messages, as RFC8551HP. These problems can appear on signed-only messages, as
well as signed-and-encrypted messages. well as signed-and-encrypted messages.
In some cases, some MUAs cannot render message/rfc822 message In some cases, some MUAs cannot render message/rfc822 message
subparts at all, which is in violation of baseline MIME requirements subparts at all, which is in violation of baseline MIME requirements
as defined in Section 2 of [RFC2049]. A message using RFC8551HP is as defined in requirement 6 of Section 2 of [RFC2049]. A message
unreadable by any recipient using such an MUA. using RFC8551HP is unreadable by any recipient using such an MUA.
In other cases, the user sees an attachment suggesting a forwarded In other cases, the user sees an attachment suggesting a forwarded
email message that -- in fact -- contains the protected email message email message that -- in fact -- contains the protected email message
that should be rendered directly. In most of these cases, the user that should be rendered directly. In most of these cases, the user
can click on the attachment to view the protected message. can click on the attachment to view the protected message.
However, viewing the protected message as an attachment in isolation However, viewing the protected message as an attachment in isolation
may strip it of any security indications, leaving the user unable to may strip it of any security indications, leaving the user unable to
assess the cryptographic properties of the message. Worse, for assess the cryptographic properties of the message. Worse, for
encrypted messages, interacting with the protected message in encrypted messages, interacting with the protected message in
skipping to change at line 960 skipping to change at line 960
delivery systems, some of which may reject, drop, or delay messages delivery systems, some of which may reject, drop, or delay messages
where all Header Fields are removed from the top-level MIME object. where all Header Fields are removed from the top-level MIME object.
Note that no representation of the HCP itself ever appears "on the Note that no representation of the HCP itself ever appears "on the
wire". However, the consumer of the encrypted message can see the wire". However, the consumer of the encrypted message can see the
decisions that were made by the sender's HCP via the HP-Outer Header decisions that were made by the sender's HCP via the HP-Outer Header
Fields (see Section 2.2). Fields (see Section 2.2).
3.1. HCP Definition 3.1. HCP Definition
In this document, we represent that Header Confidentiality Policy as In this document, we represent that HCP as a function hcp:
a function hcp:
* hcp(name, val_in) -> val_out: This function takes a Non-Structural * hcp(name, val_in) -> val_out: This function takes a Non-Structural
Header Field identified by name with the initial value val_in as Header Field identified by name with the initial value val_in as
arguments and returns a replacement Header Field value val_out. arguments and returns a replacement Header Field value val_out.
If val_out is the special value null, it means that the Header If val_out is the special value null, it means that the Header
Field in question should be removed from the set of Header Fields Field in question should be removed from the set of Header Fields
visible outside the Cryptographic Envelope. visible outside the Cryptographic Envelope.
In the pseudocode descriptions of various choices of HCP in this In the pseudocode descriptions of various choices of HCP in this
document, any comparison with the name input is done case- document, any comparison with the name input is done case-
skipping to change at line 1038 skipping to change at line 1037
The purpose of the registry of HCPs is to facilitate HCP evolution The purpose of the registry of HCPs is to facilitate HCP evolution
and interoperability discussion among MUA developers and MTA and interoperability discussion among MUA developers and MTA
operators. operators.
(The example hypothetical HCP, hcp_example_hide_cc, described in (The example hypothetical HCP, hcp_example_hide_cc, described in
Section 3.1 above is deliberately not formally registered, as it has Section 3.1 above is deliberately not formally registered, as it has
not been evaluated in practice.) not been evaluated in practice.)
3.2.1. Baseline Header Confidentiality Policy 3.2.1. Baseline Header Confidentiality Policy
The most conservative recommended Header Confidentiality Policy only The most conservative recommended HCP only provides confidentiality
provides confidentiality for Informational Fields, as defined in for Informational Fields, as defined in Section 3.6.5 of [RFC5322].
Section 3.6.5 of [RFC5322]. These fields are "only human-readable These fields are "only human-readable content" and thus their content
content" and thus their content should not be relevant to transport should not be relevant to transport agents. Since most Internet
agents. Since most Internet messages today do have a Subject Header messages today do have a Subject Header Field, and some filtering
Field, and some filtering engines might object to a message without a engines might object to a message without a Subject, this policy is
Subject, this policy is conservative and merely obscures that Header conservative and merely obscures that Header Field by replacing it
Field by replacing it with a fixed string [...]. By contrast, with a fixed string [...]. By contrast, Comments and Keywords Header
Comments and Keywords Header Fields are comparatively rare, so these Fields are comparatively rare, so these fields are removed entirely
fields are removed entirely from the Outer Header Section. from the Outer Header Section.
hcp_baseline(name, val_in) → val_out: hcp_baseline(name, val_in) → val_out:
if lower(name) is 'subject': if lower(name) is 'subject':
return '[...]' return '[...]'
else if lower(name) is in ['comments', 'keywords']: else if lower(name) is in ['comments', 'keywords']:
return null return null
else: else:
return val_in return val_in
hcp_baseline is the recommended default HCP for a new implementation, hcp_baseline is the recommended default HCP for a new implementation,
as it provides meaningful confidentiality protections and is unlikely as it provides meaningful confidentiality protections and is unlikely
to cause deliverability or usability problems. to cause deliverability or usability problems.
3.2.2. Shy Header Confidentiality Policy 3.2.2. Shy Header Confidentiality Policy
Alternately, a slightly more ambitious (and therefore more privacy- Alternately, a slightly more ambitious (and therefore more privacy-
preserving) Header Confidentiality Policy might avoid leaking human- preserving) HCP might avoid leaking human-interpretable data that
interpretable data that MTAs generally don't care about. The MTAs generally don't care about. The additional protected data isn't
additional protected data isn't related to message routing or related to message routing or transport but might reveal sensitive
transport but might reveal sensitive information about the sender or information about the sender or their relationship to the recipients.
their relationship to the recipients. This "shy" HCP builds on This "shy" HCP builds on hcp_baseline but also:
hcp_baseline but also:
* avoids revealing the display-name of each identified email address * avoids revealing the display-name of each identified email address
and and
* avoids leaking the sender's locally configured time zone in the * avoids leaking the sender's locally configured time zone in the
Date Header Field. Date Header Field.
hcp_shy(name, val_in) → val_out: hcp_shy(name, val_in) → val_out:
if lower(name) is 'from': if lower(name) is 'from':
if val_in is an RFC 5322 mailbox: if val_in is an RFC 5322 mailbox:
skipping to change at line 1114 skipping to change at line 1112
to any Header Field: to any Header Field:
hcp_no_confidentiality(name, val_in) → val_out: hcp_no_confidentiality(name, val_in) → val_out:
return val_in return val_in
A conformant MUA that is not modified by local policy or A conformant MUA that is not modified by local policy or
configuration MUST NOT use hcp_no_confidentiality by default. configuration MUST NOT use hcp_no_confidentiality by default.
3.3. Default Header Confidentiality Policy 3.3. Default Header Confidentiality Policy
An MUA MUST have a default Header Confidentiality Policy that offers An MUA MUST have a default HCP that offers confidentiality for the
confidentiality for the Subject Header Field at least. Local policy Subject Header Field at least. Local policy and configuration may
and configuration may alter this default, but the MUA SHOULD NOT alter this default, but the MUA SHOULD NOT require the user to select
require the user to select an HCP. an HCP.
hcp_baseline provides confidentiality for the Subject Header Field by hcp_baseline provides confidentiality for the Subject Header Field by
replacing it with the literal string "[...]". It also provides replacing it with the literal string "[...]". It also provides
confidentiality for the other less common Informational Header Fields confidentiality for the other less common Informational Header Fields
(Comments and Keywords) by removing them entirely from the Outer (Comments and Keywords) by removing them entirely from the Outer
Header Section. This is a sensible default because most users treat Header Section. This is a sensible default because most users treat
the Informational Fields of a message (particularly the Subject) the the Informational Fields of a message (particularly the Subject) the
same way that they treat the Body, and they are surprised to find same way that they treat the Body, and they are surprised to find
that the Subject of an encrypted message is visible. that the Subject of an encrypted message is visible.
3.4. HCP Evolution 3.4. HCP Evolution
This document does not mandate any particular Header Confidentiality This document does not mandate any particular HCP, though it offers
Policy, though it offers guidance for MUA implementers in selecting guidance for MUA implementers in selecting one in Section 3.3.
one in Section 3.3. Future documents may recommend or mandate such a Future documents may recommend or mandate such a policy for an MUA
policy for an MUA with specific needs. Such a recommendation might with specific needs. Such a recommendation might be motivated by
be motivated by descriptions of metadata-derived attacks, stem from descriptions of metadata-derived attacks, stem from research about
research about message deliverability, or describe new signaling message deliverability, or describe new signaling mechanisms, but
mechanisms, but these topics are out of scope for this document. these topics are out of scope for this document.
3.4.1. Offering More Ambitious Header Confidentiality 3.4.1. Offering More Ambitious Header Confidentiality
An MUA MAY offer even more ambitious confidentiality for Header An MUA MAY offer even more ambitious confidentiality for Header
Fields of an encrypted message than defined in Section 3.2.2. For Fields of an encrypted message than defined in Section 3.2.2. For
example, it might implement an HCP that removes the To and Cc Header example, it might implement an HCP that removes the To and Cc Header
Fields entirely, relying on the SMTP envelope to ensure proper Fields entirely, relying on the SMTP envelope to ensure proper
routing. Or it might remove References and In-Reply-To so that routing. Or it might remove References and In-Reply-To so that
message threading is not visible to any MTA. Any more ambitious message threading is not visible to any MTA. Any more ambitious
choice might result in deliverability, rendering, or usability issues choice might result in deliverability, rendering, or usability issues
for the relevant messages, so testing and documentation will be for the relevant messages, so testing and documentation will be
valuable to get this right. valuable to get this right.
The authors of this document hope that implementers with deployment The authors of this document hope that implementers with deployment
experience will document their chosen Header Confidentiality Policy experience will document their chosen HCP and the rationale behind
and the rationale behind their choice. their choice.
3.4.2. Expert Guidance for Registering Header Confidentiality Policies 3.4.2. Expert Guidance for Registering Header Confidentiality Policies
There is no formal syntax specified for the Header Confidentiality There is no formal syntax specified for the HCP, but any attempt to
Policy, but any attempt to specify an HCP for inclusion in the specify an HCP for inclusion in the registry needs to provide:
registry needs to provide:
* a stable reference document clearly indicating the distinct name * a stable reference document clearly indicating the distinct name
for the proposed HCP, for the proposed HCP,
* pseudocode that other implementers can clearly and unambiguously * pseudocode that other implementers can clearly and unambiguously
interpret, interpret,
* a clear explanation of why this HCP is different from all other * a clear explanation of why this HCP is different from all other
registered HCPs, and registered HCPs, and
skipping to change at line 1230 skipping to change at line 1227
* The MUA SHOULD include information in the message's Cryptographic * The MUA SHOULD include information in the message's Cryptographic
Summary to indicate the types of protection that applied to each Summary to indicate the types of protection that applied to each
rendered Header Field (if any). rendered Header Field (if any).
* If any Legacy Display Elements are present in the Body of the * If any Legacy Display Elements are present in the Body of the
message, it does not render them. message, it does not render them.
* When replying to a message with confidential Header Fields, the * When replying to a message with confidential Header Fields, the
replying MUA avoids leaking any Header Fields that were replying MUA avoids leaking any Header Fields that were
confidential in the original into the cleartext of the reply. It confidential in the original into the cleartext of the reply. It
does this even if its own Header Confidentiality Policy would not does this even if its own HCP would not have treated those Header
have treated those Header Fields as confidential. See Section 6 Fields as confidential. See Section 6 for more details.
for more details.
Note that an MUA that handles a message with Header Protection does Note that an MUA that handles a message with Header Protection does
_not_ need to render any new Header Fields that it did not render _not_ need to render any new Header Fields that it did not render
before. before.
4.1. Identifying That a Message Has Header Protection 4.1. Identifying That a Message Has Header Protection
An incoming message can be identified as having Header Protection An incoming message can be identified as having Header Protection
using the following test: using the following test:
skipping to change at line 2011 skipping to change at line 2007
3. Return output. 3. Return output.
5.2. Composing a Message with Header Protection 5.2. Composing a Message with Header Protection
To compose a message using Header Protection, the composing MUA uses To compose a message using Header Protection, the composing MUA uses
the following inputs: the following inputs:
* all the inputs described in Section 5.1 * all the inputs described in Section 5.1
* hcp: a Header Confidentiality Policy, as defined in Section 3 * hcp: an HCP, as defined in Section 3
* respond: if the new message is a response to another message * respond: if the new message is a response to another message
(e.g., "Reply", "Reply All", "Forward", etc.), the MUA function (e.g., "Reply", "Reply All", "Forward", etc.), the MUA function
corresponding to the user's action (see Section 6.1), otherwise corresponding to the user's action (see Section 6.1), otherwise
null null
* refmsg: if the new message is a response to another message, the * refmsg: if the new message is a response to another message, the
message being responded to, otherwise null message being responded to, otherwise null
* legacy: a boolean value, indicating whether any recipient of the * legacy: a boolean value, indicating whether any recipient of the
skipping to change at line 2331 skipping to change at line 2327
composing MUA SHOULD make use of the HP-Outer Header Fields from composing MUA SHOULD make use of the HP-Outer Header Fields from
within the Cryptographic Envelope of the reference message to ensure within the Cryptographic Envelope of the reference message to ensure
that Header Fields derived from the reference message do not leak in that Header Fields derived from the reference message do not leak in
the reply. the reply.
On a high level, this can be achieved as follows: Consider a Header On a high level, this can be achieved as follows: Consider a Header
Field in a reply message that is generated by derivation from a Field in a reply message that is generated by derivation from a
Header Field in the reference message. For example, the To Header Header Field in the reference message. For example, the To Header
Field is typically derived from the reference message's Reply-To or Field is typically derived from the reference message's Reply-To or
From Header Fields. When generating the outer copy of the Header From Header Fields. When generating the outer copy of the Header
Field, the composing MUA first applies its own Header Confidentiality Field, the composing MUA first applies its own HCP. If the Header
Policy. If the Header Field's value is changed by the HCP, then it Field's value is changed by the HCP, then it is applied to the Outer
is applied to the Outer Header Section. If the Header Field's value Header Section. If the Header Field's value is unchanged, the
is unchanged, the composing MUA re-generates the Header Field using composing MUA re-generates the Header Field using the Header Fields
the Header Fields that had been on the outside of the original that had been on the outside of the original message at sending time.
message at sending time. These can be inferred from the HP-Outer These can be inferred from the HP-Outer Header Fields located within
Header Fields located within the Cryptographic Payload of the the Cryptographic Payload of the referenced message. If that value
referenced message. If that value is itself different than the is itself different than the protected value, then it is applied to
protected value, then it is applied to the Outer Header Section. If the Outer Header Section. If the value is the same as the protected
the value is the same as the protected value, then it is simply value, then it is simply copied to the Outer Header Section directly.
copied to the Outer Header Section directly. Whether it was changed Whether it was changed or not, it is noted in the protected Header
or not, it is noted in the protected Header Section using HP-Outer, Section using HP-Outer, as described in Section 2.2.1.
as described in Section 2.2.1.
See Appendix D.2 for a simple worked example of this process. See Appendix D.2 for a simple worked example of this process.
Below we describe a supporting algorithm to handle this. It produces Below we describe a supporting algorithm to handle this. It produces
a list of Header Fields that should be obscured or removed in the new a list of Header Fields that should be obscured or removed in the new
message even if the sender's choice of Header Confidentiality Policy message even if the sender's choice of HCP wouldn't normally remove
wouldn't normally remove or obscure the Header Field in question. or obscure the Header Field in question. This is effectively a
This is effectively a single-use HCP. The normal sending guidance in single-use HCP. The normal sending guidance in Section 5.2 applies
Section 5.2 applies this single-use HCP to implement the high-level this single-use HCP to implement the high-level guidance above.
guidance above.
6.1.1. ReferenceHCP 6.1.1. ReferenceHCP
The algorithm takes two inputs: The algorithm takes two inputs:
* A single referenced message refmsg * A single referenced message refmsg
* A built-in MUA respond function associated with the user's action. * A built-in MUA respond function associated with the user's action.
The respond function takes a list of Header Fields from a The respond function takes a list of Header Fields from a
referenced message as input and generates a list of initial referenced message as input and generates a list of initial
candidate message Header Field names and values that are used to candidate message Header Field names and values that are used to
populate the message composition interface. Something like this populate the message composition interface. Something like this
function already exists in most MUAs, though it may differ across function already exists in most MUAs, though it may differ across
responsive actions. For example, the respond function that responsive actions. For example, the respond function that
implements "Reply All" is likely to be a different from the implements "Reply All" is likely to be a different from the
respond that implements "Reply". respond that implements "Reply".
As an output, it produces an ephemeral single-use Header As an output, it produces an ephemeral single-use HCP, specific to
Confidentiality Policy, specific to this kind of response to this this kind of response to this specific message.
specific message.
Method signature: Method signature:
ReferenceHCP(refmsg, respond) -> ephemeral_hcp ReferenceHCP(refmsg, respond) -> ephemeral_hcp
Procedure: Procedure:
1. If refmsg is not encrypted with Header Protection: 1. If refmsg is not encrypted with Header Protection:
i. Return hcp_no_confidentiality (there is no header i. Return hcp_no_confidentiality (there is no header
skipping to change at line 2569 skipping to change at line 2562
Until that point, an end user might want to signal that their Until that point, an end user might want to signal that their
receiving MUAs are conformant to this document so that a peer receiving MUAs are conformant to this document so that a peer
composing a message to them can set legacy to false. A signal composing a message to them can set legacy to false. A signal
indicating capability of handling messages with Header Protection indicating capability of handling messages with Header Protection
might be placed in the user's cryptographic certificate or in might be placed in the user's cryptographic certificate or in
outbound messages. outbound messages.
This document does not attempt to define the syntax or semantics of This document does not attempt to define the syntax or semantics of
such a signal. such a signal.
8.2. More Ambitious Default Header Confidentiality Policy 8.2. More Ambitious Default HCP
This document defines a few different forms of Header Confidentiality This document defines a few different forms of HCP. An MUA
Policy. An MUA implementing an HCP for the first time SHOULD deploy implementing an HCP for the first time SHOULD deploy hcp_baseline as
hcp_baseline as recommended in Section 3.3. This HCP offers the most recommended in Section 3.3. This HCP offers the most commonly
commonly expected protection (obscuring the Subject Header Field) expected protection (obscuring the Subject Header Field) without
without risking deliverability or rendering issues. risking deliverability or rendering issues.
The HCPs proposed in this document are relatively conservative and The HCPs proposed in this document are relatively conservative and
still leak a significant amount of metadata for encrypted messages. still leak a significant amount of metadata for encrypted messages.
This is largely done to ensure deliverability (see Section 1.3.2) and This is largely done to ensure deliverability (see Section 1.3.2) and
usability, as messages without some critical Header Fields are more usability, as messages without some critical Header Fields are more
likely to not reach their intended recipient. likely to not reach their intended recipient.
In the future, some mail transport systems may accept and deliver In the future, some mail transport systems may accept and deliver
messages with even less publicly visible metadata. Many MTA messages with even less publicly visible metadata. Many MTA
operators today would ask for additional guarantees about such a operators today would ask for additional guarantees about such a
skipping to change at line 2697 skipping to change at line 2690
* When rendering a message with a signed-and-encrypted or encrypted- * When rendering a message with a signed-and-encrypted or encrypted-
only cryptographic status with Header Protection but where the only cryptographic status with Header Protection but where the
Subject Header Field has not been removed or obscured, place a Subject Header Field has not been removed or obscured, place a
warning sign on the Subject line. warning sign on the Subject line.
Other simple rendering strategies could also be reasonable. Other simple rendering strategies could also be reasonable.
9.2. Users Should Not Have to Choose a Header Confidentiality Policy 9.2. Users Should Not Have to Choose a Header Confidentiality Policy
This document defines the abstraction of a Header Confidentiality This document defines the abstraction of an HCP object for the sake
Policy object for the sake of communication between implementers and of communication between implementers and deployments.
deployments.
Most email users are unlikely to understand the trade-offs between Most email users are unlikely to understand the trade-offs between
different policies. In particular, the potential negative side different policies. In particular, the potential negative side
effects (e.g., poor deliverability) may not be easily attributable by effects (e.g., poor deliverability) may not be easily attributable by
a normal user to a particular HCP. a normal user to a particular HCP.
Therefore, MUA implementers should be conservative in their choice of Therefore, MUA implementers should be conservative in their choice of
default HCP and should not require the Ordinary User to make an default HCP and should not require the Ordinary User to make an
incomprehensible choice that could cause unfixable, undiagnosable incomprehensible choice that could cause unfixable, undiagnosable
problems. The safest option is for the MUA developer to select a problems. The safest option is for the MUA developer to select a
skipping to change at line 3067 skipping to change at line 3059
for more details about risks related to Bcc). for more details about risks related to Bcc).
Clearly, no end-to-end cryptographic protection of any Header Field Clearly, no end-to-end cryptographic protection of any Header Field
as defined in this document will hide such a sensitive field from the as defined in this document will hide such a sensitive field from the
intended recipient. Instead, the composing MUA MUST populate the intended recipient. Instead, the composing MUA MUST populate the
origheaders list for any outbound message with only information the origheaders list for any outbound message with only information the
recipient should have access to. This is true for messages without recipient should have access to. This is true for messages without
any cryptographic protection as well, of course, and it is even worse any cryptographic protection as well, of course, and it is even worse
there: Such a leak is exposed to the transport agents as well as the there: Such a leak is exposed to the transport agents as well as the
recipient. An encrypted message with Header Protection and a more recipient. An encrypted message with Header Protection and a more
ambitious Header Confidentiality Policy avoids these leaks that ambitious HCP avoids these leaks that expose information to the
expose information to the transport agents, but it cannot defend transport agents, but it cannot defend against such a leak to the
against such a leak to the recipient. recipient.
11.2.2. Encrypted Header Fields Can Be Inferred from External or 11.2.2. Encrypted Header Fields Can Be Inferred from External or
Internal Metadata Internal Metadata
For example, if the To and Cc Header Fields are removed from the For example, if the To and Cc Header Fields are removed from the
unprotected Header Section, the values in those fields might still be unprotected Header Section, the values in those fields might still be
inferred with high probability by an adversary who looks at the inferred with high probability by an adversary who looks at the
message either in transit or at rest. If the message is found in a message either in transit or at rest. If the message is found in a
mailbox, or being delivered to a mailbox, for example, mailbox, or being delivered to a mailbox, for example,
bob@example.org, it's likely that Bob was in either To or Cc. bob@example.org, it's likely that Bob was in either To or Cc.
skipping to change at line 4802 skipping to change at line 4794
iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA
MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ
sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli
vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg==
--508-- --508--
C.2. Signed-Only Messages C.2. Signed-Only Messages
These messages are signed-only, using different schemes of Header These messages are signed-only, using different schemes of Header
Protection and different S/MIME structures. They use no Header Protection and different S/MIME structures. They use no HCP because
Confidentiality Policy because the HCP is only relevant when a the HCP is only relevant when a message is encrypted.
message is encrypted.
C.2.1. S/MIME Signed-Only signedData over a Simple Message, Header C.2.1. S/MIME Signed-Only signedData over a Simple Message, Header
Protection Protection
This is a signed-only S/MIME message via PKCS#7 signedData. The This is a signed-only S/MIME message via PKCS#7 signedData. The
payload is a text/plain message. It uses the Header Protection payload is a text/plain message. It uses the Header Protection
scheme from the draft. scheme from the draft.
It has the following structure: It has the following structure:
skipping to change at line 5717 skipping to change at line 5708
These messages are signed and encrypted. They use PKCS#7 signedData These messages are signed and encrypted. They use PKCS#7 signedData
inside envelopedData, with different Header Protection schemes and inside envelopedData, with different Header Protection schemes and
different Header Confidentiality Policies. different Header Confidentiality Policies.
C.3.1. S/MIME Signed and Encrypted over a Simple Message, Header C.3.1. S/MIME Signed and Encrypted over a Simple Message, Header
Protection with hcp_baseline Protection with hcp_baseline
This is a signed-and-encrypted S/MIME message using PKCS#7 This is a signed-and-encrypted S/MIME message using PKCS#7
envelopedData around signedData. The payload is a text/plain envelopedData around signedData. The payload is a text/plain
message. It uses the Header Protection scheme from the draft with message. It uses the Header Protection scheme from the draft with
the hcp_baseline Header Confidentiality Policy. the hcp_baseline HCP.
It has the following structure: It has the following structure:
└─╴application/pkcs7-mime [smime.p7m] 7825 bytes └─╴application/pkcs7-mime [smime.p7m] 7825 bytes
↧ (decrypts to) ↧ (decrypts to)
└─╴application/pkcs7-mime [smime.p7m] 4786 bytes └─╴application/pkcs7-mime [smime.p7m] 4786 bytes
⇩ (unwraps to) ⇩ (unwraps to)
└─╴text/plain 329 bytes └─╴text/plain 329 bytes
Its contents are: Its contents are:
skipping to change at line 12144 skipping to change at line 12135
C H R C H R
C C
Compose Table 5 Compose Table 5
ComposeNoHeaderProtection Table 5 ComposeNoHeaderProtection Table 5
H H
HCP Section 1.7; Section 1.7; Section 3, Paragraph 2; HCP Section 1.7; Section 1.7; Section 3, Paragraph 2;
Section 3, Paragraph 5; Section 3.1, Paragraph 3; Section 3, Paragraph 5; Section 3.1, Paragraph 1;
Section 3.1, Paragraph 9; Section 3.1.1, Paragraph 1; Section 3.1, Paragraph 3; Section 3.1, Paragraph 9;
Section 3.2, Paragraph 2; Section 3.2, Paragraph 3; Section 3.1.1, Paragraph 1; Section 3.2, Paragraph 2;
Section 3.2, Paragraph 3; Section 3.2.1, Paragraph 1;
Section 3.2.1, Paragraph 3; Section 3.2.2, Paragraph 1; Section 3.2.1, Paragraph 3; Section 3.2.2, Paragraph 1;
Section 3.2.2, Paragraph 4; Section 3.3, Paragraph 1; Section 3.2.2, Paragraph 4; Section 3.3, Paragraph 1;
Section 3.4.1, Paragraph 1; Section 3.4.2, Paragraph 1; Section 3.4, Paragraph 1; Section 3.4.1, Paragraph 1;
Section 3.4.1, Paragraph 2; Section 3.4.2, Paragraph 1;
Section 3.4.2, Paragraph 2.1.1; Section 3.4.2, Paragraph Section 3.4.2, Paragraph 2.1.1; Section 3.4.2, Paragraph
2.3.1; Section 3.4.2, Paragraph 2.4.1; Section 3.4.2, 2.3.1; Section 3.4.2, Paragraph 2.4.1; Section 3.4.2,
Paragraph 3; Section 4.8.2, Paragraph 3; Section 5.2.1, Paragraph 3; Section 4, Paragraph 5.4.1; Section 4.8.2,
Paragraph 3; Section 5.2, Paragraph 2.2.1; Section 5.2.1,
Paragraph 4.5.2.2.2.1.1; Section 6.1, Paragraph 5; Paragraph 4.5.2.2.2.1.1; Section 6.1, Paragraph 5;
Section 6.1, Paragraph 7; Section 6.1.1, Paragraph 7.8.1; Section 6.1, Paragraph 7; Section 6.1.1, Paragraph 3;
Section 6.1.1, Paragraph 8; Section 8.2, Paragraph 1; Section 6.1.1, Paragraph 7.8.1; Section 6.1.1, Paragraph 8;
Section 8.2, Paragraph 4; Section 8.2, Paragraph 5; Section 8.2, Paragraph 1; Section 8.2, Paragraph 4;
Section 8.2, Paragraph 6; Section 9.2, Paragraph 2; Section 8.2, Paragraph 5; Section 8.2, Paragraph 6;
Section 9.2, Paragraph 1; Section 9.2, Paragraph 2;
Section 9.2, Paragraph 3; Section 11.2, Paragraph 1; Section 9.2, Paragraph 3; Section 11.2, Paragraph 1;
Section 11.2.1, Paragraph 1; Section 11.2.3, Paragraph 1; Section 11.2.1, Paragraph 1; Section 11.2.1, Paragraph 3;
Section 11.2.3, Paragraph 2; Section 11.3, Paragraph 2; Section 11.2.3, Paragraph 1; Section 11.2.3, Paragraph 2;
Section 11.4, Paragraph 2; Section 12, Paragraph 1; Table 5; Section 11.3, Paragraph 2; Section 11.4, Paragraph 2;
Appendix D.1.2, Paragraph 1; Appendix D.2.2, Paragraph 3; Section 12, Paragraph 1; Table 5; Appendix C.2, Paragraph 1;
Appendix D.2.2, Paragraph 6 Appendix C.3.1, Paragraph 1; Appendix D.1.2, Paragraph 1;
Appendix D.2.2, Paragraph 3; Appendix D.2.2, Paragraph 6
Header Confidentiality Policy Section 1.2, Paragraph 4; Header Confidentiality Policy Section 1.2, Paragraph 4;
Section 1.7; Section 3, Paragraph 2; Section 3.1, Paragraph Section 1.7; Section 3, Paragraph 2; Section 12.3;
1; Section 3.2.1, Paragraph 1; Section 3.2.2, Paragraph 1; Appendix C.3.2, Paragraph 1; Appendix C.3.3, Paragraph 1;
Section 3.3, Paragraph 1; Section 3.4, Paragraph 1; Appendix C.3.4, Paragraph 1; Appendix C.3.5, Paragraph 1;
Section 3.4.1, Paragraph 2; Section 3.4.2, Paragraph 1; Appendix C.3.6, Paragraph 1; Appendix C.3.7, Paragraph 1;
Section 4, Paragraph 5.4.1; Section 5.2, Paragraph 2.2.1; Appendix C.3.8, Paragraph 1; Appendix C.3.9, Paragraph 1;
Section 6.1, Paragraph 5; Section 6.1, Paragraph 7; Appendix C.3.10, Paragraph 1; Appendix C.3.11, Paragraph 1;
Section 6.1.1, Paragraph 3; Section 8.2, Paragraph 1; Appendix C.3.12, Paragraph 1; Appendix C.3.13, Paragraph 1;
Section 9.2, Paragraph 1; Section 11.2.1, Paragraph 3; Appendix C.3.14, Paragraph 1; Appendix C.3.15, Paragraph 1;
Section 12.3; Appendix C.2, Paragraph 1; Appendix C.3.1, Appendix C.3.16, Paragraph 1; Appendix C.3.17, Paragraph 1
Paragraph 1; Appendix C.3.2, Paragraph 1; Appendix C.3.3,
Paragraph 1; Appendix C.3.4, Paragraph 1; Appendix C.3.5,
Paragraph 1; Appendix C.3.6, Paragraph 1; Appendix C.3.7,
Paragraph 1; Appendix C.3.8, Paragraph 1; Appendix C.3.9,
Paragraph 1; Appendix C.3.10, Paragraph 1; Appendix C.3.11,
Paragraph 1; Appendix C.3.12, Paragraph 1; Appendix C.3.13,
Paragraph 1; Appendix C.3.14, Paragraph 1; Appendix C.3.15,
Paragraph 1; Appendix C.3.16, Paragraph 1; Appendix C.3.17,
Paragraph 1
HeaderFieldProtection Section 4.10.2, Paragraph 2.2.1; Table 5 HeaderFieldProtection Section 4.10.2, Paragraph 2.2.1; Table 5
HeaderSetsFromMessage Section 4.3.1, Paragraph 4.2.1; HeaderSetsFromMessage Section 4.3.1, Paragraph 4.2.1;
Section 4.10.2, Paragraph 2.2.1; Section 4.10.2, Paragraph Section 4.10.2, Paragraph 2.2.1; Section 4.10.2, Paragraph
2.4.1; Table 5 2.4.1; Table 5
R R
ReferenceHCP Table 5 ReferenceHCP Table 5
RFC8551HP Section 1.1, Paragraph 1; Section 1.1, Paragraph 2; RFC8551HP Section 1.1, Paragraph 1; Section 1.1, Paragraph 2;
Section 1.1.1, Paragraph 1; Section 1.1.1, Paragraph 2; Section 1.1.1, Paragraph 1; Section 1.1.1, Paragraph 2;
 End of changes. 26 change blocks. 
110 lines changed or deleted 97 lines changed or added

This html diff was produced by rfcdiff 1.48.