Browse Source

Updated MIME relevant section after call with Alexey

master
Bernie Hoeneisen 2 years ago
parent
commit
222ff077e9
2 changed files with 478 additions and 311 deletions
  1. +178
    -123
      ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200626.html
  2. +300
    -188
      ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200626.txt

+ 178
- 123
ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200626.html View File

@ -391,8 +391,9 @@
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Main Use Case">
<link href="#rfc.section.4.1.1" rel="Chapter" title="4.1.1 MIME Format">
<link href="#rfc.section.4.1.2" rel="Chapter" title="4.1.2 Inner Message Header Fields">
<link href="#rfc.section.4.1.3" rel="Chapter" title="4.1.3 Outer Message Header Fields">
<link href="#rfc.section.4.1.4" rel="Chapter" title="4.1.4 Message Processing">
<link href="#rfc.section.4.1.3" rel="Chapter" title="4.1.3 Wrapper">
<link href="#rfc.section.4.1.4" rel="Chapter" title="4.1.4 Outer Message Header Fields">
<link href="#rfc.section.4.1.5" rel="Chapter" title="4.1.5 Message Processing">
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Backward Compatibility Use Case">
<link href="#rfc.section.5" rel="Chapter" title="5 Security Considerations">
<link href="#rfc.section.6" rel="Chapter" title="6 Privacy Considerations">
@ -503,9 +504,11 @@
</li>
<li>4.1.2. <a href="#rfc.section.4.1.2">Inner Message Header Fields</a>
</li>
<li>4.1.3. <a href="#rfc.section.4.1.3">Outer Message Header Fields</a>
<li>4.1.3. <a href="#rfc.section.4.1.3">Wrapper</a>
</li>
<li>4.1.4. <a href="#rfc.section.4.1.4">Message Processing</a>
<li>4.1.4. <a href="#rfc.section.4.1.4">Outer Message Header Fields</a>
</li>
<li>4.1.5. <a href="#rfc.section.4.1.5">Message Processing</a>
</li>
</ul><li>4.2. <a href="#rfc.section.4.2">Backward Compatibility Use Case</a>
</li>
@ -571,7 +574,8 @@
<li>Header Field (HF): cf. <a href="#RFC5322" class="xref">[RFC5322]</a> Header Fields are lines beginning with a field name, followed by a colon (&#8220;:&#8221;), followed by a field body (value), and terminated by CRLF; cf. <a href="#RFC5322" class="xref">[RFC5322]</a>. <br><br> Note: To avoid ambiguity, this document does not use the terms &#8220;Header&#8221; or &#8220;Headers&#8221; in isolation, but instead always uses &#8220;Header Field&#8221; to refer to the individual field and &#8220;Header Section&#8221; to refer to the entire collection; cf. <a href="#RFC5322" class="xref">[RFC5322]</a>.</li>
<li>Header Section (HS): The Header Section is a sequence of lines of characters with special syntax as defined in <a href="#RFC5322" class="xref">[RFC5322]</a>. It is the (top) section of a message containing the Header Fields.</li>
<li>Body: The Body is simply a sequence of characters that follows the Header Section and is separated from the Header Section by an empty line (i.e., a line with nothing preceding the CRLF); cf <a href="#RFC5322" class="xref">[RFC5322]</a>. It is the (bottom) section of Message containing the payload of a Message. Typically, the Body consists of a (multipart) MIME <a href="#RFC2045" class="xref">[RFC2045]</a> construct.</li>
<li>MIME Header Section (part): The collection of MIME Header Fields describing the following MIME structure as defined in <a href="#RFC2045" class="xref">[RFC2045]</a>.</li>
<li>MIME Header Fields: Header Fields describing the MIME structure of its body as defined in <a href="#RFC2045" class="xref">[RFC2045]</a>.</li>
<li>MIME Header Section (part): The collection of MIME Header Fields. &#8220;MIME Header Section&#8221; refers to a Header Sections that contains only MIME Header Fields, whereas &#8220;MIME Header Section part&#8221; refers to the MIME Header Fields of a Header Section that - in addition to MIME Header Fields - also contains non-MIME Header Fields.</li>
<li>Header Protection (HP): cryptographic protection of email Header Sections (or parts of it) for signatures and/or encryption</li>
<li>Protection Levels (PL): One of &#8216;signature and encryption&#8217;, &#8216;signature only&#8217; or &#8216;encryption only&#8217; (cf. <a href="#protection-levels" class="xref">Section 3.2</a>)</li>
</ul>
@ -579,10 +583,10 @@
<ul>
<li>Original Message (OrigM): The message to be protected before any protection related processing has been applied on the sending side.</li>
<li>Inner Message (InnerM): The message to be protected, shortly before protection measures are applied to on the sending side or the message shortly after decryption and/or unwrapping the signed part on the receiving side. Typically the Inner Message is in clear text. The Inner Message is rather similar as the Original Message. The Inner Message MUST be the same on the sending and the receiving side.</li>
<li>Inner Message (InnerM): The message to be protected, shortly before wrapping and protection measures are applied to on the sending side or the message shortly after decryption and unwrapping has been applied to on the receiving side respectively. Typically, the Inner Message is in clear text. The Inner Message is a subset of (or the same as) the Original Message. The Inner Message must be the same on the sending and the receiving side.</li>
<li>Outer Message (OuterM): The Message as handed over to the Transport or received from the Transport respectively. The Outer Message normally differs on the sending and the receiving side (e.g. new Header Fields are added by intermediary nodes).</li>
<li>Receiving User Facing Message (RUFM): The message used for rendering at the receiving side after the Outer Message Header Section has been merged with the Inner Message Header Section.</li>
<li>Essential Header Fields (EHF): The Header Fields an Outer Message Header Section SHOULD contain at least; cf. <a href="#outer-msg-hf" class="xref">Section 4.1.3</a>.</li>
<li>Essential Header Fields (EHF): The Header Fields an Outer Message Header Section SHOULD contain at least; cf. <a href="#outer-msg-hf" class="xref">Section 4.1.4</a>.</li>
<li>Protected: Protected refers to the parts of a message where protection measures of any Protection Levels have been applied to.</li>
<li>Protected Message: A message that protection measures of any Protection Levels have been applied to.</li>
<li>Unprotected: Unprotected refers to the parts of a message where no protection measures of any Protection Levels have been applied to.</li>
@ -674,22 +678,32 @@ signature.
<h1 id="rfc.section.4.1.1">
<a href="#rfc.section.4.1.1">4.1.1.</a> <a href="#mime-format" id="mime-format">MIME Format</a>
</h1>
<p id="rfc.section.4.1.1.p.1">As per S&#8203;/&#8203;MIME version 3.1 and later (cf. <a href="#RFC8551" class="xref">[RFC8551]</a>), the sending client MAY wrap a full MIME message in a message/RFC822 wrapper in order to apply S&#8203;/&#8203;MIME security services to these header fields.</p>
<p id="rfc.section.4.1.1.p.2">To help the receiving side to distinguish between forwarded and wrapped message, a Content-Type header field parameter &#8220;forwarded&#8221; is added as defined in <a href="#I-D.melnikov-iana-reg-forwarded" class="xref">[I-D.melnikov-iana-reg-forwarded]</a>. Certain mailing applications might display the Inner Message as attachment otherwise.</p>
<p id="rfc.section.4.1.1.p.3">In the simplest case, a message looks as follows:</p>
<p id="rfc.section.4.1.1.p.1">Currently there are two options in discussion:</p>
<p></p>
<ol>
<li>The option according to the current S&#8203;/&#8203;MIME specification (cf. <a href="#RFC8551" class="xref">[RFC8551]</a>)</li>
<li>An alternative option that is based on the former &#8220;memory hole&#8221; approach (cf. <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a>)</li>
</ol>
<h1 id="rfc.section.4.1.1.1">
<a href="#rfc.section.4.1.1.1">4.1.1.1.</a> <a href="#option-smime-spec" id="option-smime-spec">S/MIME Specification</a>
</h1>
<p id="rfc.section.4.1.1.1.p.1">As per S&#8203;/&#8203;MIME version 3.1 and later (cf. <a href="#RFC8551" class="xref">[RFC8551]</a>), the sending client MAY wrap a full MIME message in a message/RFC822 wrapper in order to apply S&#8203;/&#8203;MIME security services to these header fields.</p>
<p id="rfc.section.4.1.1.1.p.2">To help the receiving side to distinguish between forwarded and wrapped message, a Content-Type header field parameter &#8220;forwarded&#8221; is added as defined in <a href="#I-D.melnikov-iana-reg-forwarded" class="xref">[I-D.melnikov-iana-reg-forwarded]</a>. Certain mailing applications might display the Inner Message as attachment otherwise.</p>
<p id="rfc.section.4.1.1.1.p.3">The MIME structure of an Email message looks as follows:</p>
<pre>
&lt;Outer Message Header Section (unprotected)&gt;
&lt;Outer Message Body (protected)&gt;
&lt;MIME Header Section&gt;
&lt;MIME Header Section (wrapper)&gt;
&lt;Inner Message Header Section&gt;
&lt;Inner Message Header Section&gt;
&lt;Inner Message Body&gt;
&lt;Inner Message Body&gt;
</pre>
<p id="rfc.section.4.1.1.p.4">The following example demonstrates how header section and payload of a protect body part might look like. For example, this will be the first body part of a multipart/signed message or the signed and/or encrypted payload of the application/pkcs7-mime body part. Lines prepended by &#8220;O: &#8220; are the Outer Message Header Section. Lines prepended by &#8220;I: &#8220; are the Inner Message Header Section. Lines prepended by &#8220;W: &#8220; are the wrapper (MIME Header Section):</p>
<p id="rfc.section.4.1.1.1.p.4">The following example demonstrates how header section and payload of a protect body part might look like. For example, this will be the first body part of a multipart/signed message or the signed and/or encrypted payload of the application/pkcs7-mime body part. Lines prepended by &#8220;O: &#8220; are the Outer Message Header Section. Lines prepended by &#8220;I: &#8220; are the Inner Message Header Section. Lines prepended by &#8220;W: &#8220; are the wrapper (MIME Header Section):</p>
<pre>
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
@ -727,24 +741,70 @@ signature.
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
</pre>
<p id="rfc.section.4.1.1.p.5">The Outer Message Header Section is unprotected, while the remainder (Outer Message Body) is protected. The Outer Message Body consists of the Inner Message (Header Section and Body).</p>
<p id="rfc.section.4.1.1.p.6">The Inner Message Header Section is the same as (or a subset of) the Original Message Header Section preceded by a MIME Header Section with media type &#8220;message/RFC822&#8221; containing a Content-Type header field parameter &#8220;forwarded=no&#8221; (cf. <a href="#inner-msg-hf" class="xref">Section 4.1.2</a>).</p>
<p id="rfc.section.4.1.1.p.7">The Inner Message Body is the same as the Original Message Body.</p>
<p id="rfc.section.4.1.1.p.8">The Original Message itself may contain any defined MIME structure.</p>
<p id="rfc.section.4.1.1.p.9">There may also be an additional MIME layer with Media-Type &#8220;multipart/mixed&#8221; in the Outer Message Body to contain the Inner Message (as &#8220;message/RFC822&#8221;) along with other MIME part(s).</p>
<h1 id="rfc.section.4.1.1.1">
<a href="#rfc.section.4.1.1.1">4.1.1.1.</a> <a href="#ex-memory-hole" id="ex-memory-hole">Alternative Option Autocrypt &#8220;Protected Headers&#8221; (Ex-&#8220;Memory Hole&#8221;)</a>
<p id="rfc.section.4.1.1.1.p.5">The Outer Message Header Section is unprotected, while the remainder (Outer Message Body) is protected. The Outer Message Body consists of the wrapper (MIME Header Section) and the Inner Message (Header Section and Body).</p>
<p id="rfc.section.4.1.1.1.p.6">The wrapper is a simple MIME Header Section with media type &#8220;message/RFC822&#8221; containing a Content-Type header field parameter &#8220;forwarded=no&#8221; followed by an empty line.</p>
<p id="rfc.section.4.1.1.1.p.7">The Inner Message Header Section is the same as (or a subset of) the Original Message Header Section (cf. <a href="#inner-msg-hf" class="xref">Section 4.1.2</a>).</p>
<p id="rfc.section.4.1.1.1.p.8">The Inner Message Body is the same as the Original Message Body.</p>
<p id="rfc.section.4.1.1.1.p.9">The Original Message itself may contain any MIME structure.</p>
<p id="rfc.section.4.1.1.1.p.10">There may also be an additional MIME layer with media type &#8220;multipart/mixed&#8221; in the Outer Message Body to contain the Inner Message (wrapped in a &#8220;message/RFC822&#8221;) along with other MIME part(s).</p>
<h1 id="rfc.section.4.1.1.2">
<a href="#rfc.section.4.1.1.2">4.1.1.2.</a> <a href="#alternative-option-autocrypt-protected-headers-ex-memory" id="alternative-option-autocrypt-protected-headers-ex-memory">Alternative Option Autocrypt &#8220;Protected Headers&#8221; (Ex-&#8220;Memory</a>
</h1>
<p id="rfc.section.4.1.1.1.p.1">An alternative Option (based on the former autocrypt &#8220;Memory Hole&#8221; approach) to be considered, is described in <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a>.</p>
<p id="rfc.section.4.1.1.1.p.2">That option emphasizes backward compatibility challenges to existing Mail User Agents (MUAs) that do encryption, but are unaware of Header Protection as specified herein (see also <a href="#backward-compatibility-use-case" class="xref">Section 4.2</a>).</p>
<p id="rfc.section.4.1.1.1.p.3">That option suggests to use the media type &#8220;text/plain&#8221; to contain the Inner Message (as opposed to &#8220;message/RFC822&#8221;, cf. <a href="#mime-format" class="xref">Section 4.1.1</a>). For MUA implementers rendering those messages, that approach might become problematic implementation-wise once the Content of &#8220;text/plain&#8221; needs to be parsed (as media type &#8220;text/plain&#8221; is defined as unstructured text).</p>
<p id="rfc.section.4.1.1.1.p.4">Regarding MIME type &#8220;message/RFC822&#8221; <a href="#RFC2046" class="xref">[RFC2046]</a> specifies:</p>
<p></p>
<pre>
Hole") {#option-ex-memory-hole}
</pre>
<p id="rfc.section.4.1.1.2.p.1">An alternative Option (based on the former autocrypt &#8220;Memory Hole&#8221; approach) to be considered, is described in <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a>.</p>
<p id="rfc.section.4.1.1.2.p.2">Unlike the option described in <a href="#option-smime-spec" class="xref">Section 4.1.1.1</a>, this option does not use a &#8220;message/RFC822&#8221; wrapper to unambigously delimit the Inner Message.</p>
<p id="rfc.section.4.1.1.2.p.3">The MIME structure of an Email message looks as follows:</p>
<pre>
&lt;Outer Message Header Section (unprotected)&gt;
&lt;Outer Message Body (protected)&gt;
&lt;Inner Message Header Section&gt;
&lt;Inner Message Body&gt;
</pre>
<p id="rfc.section.4.1.1.2.p.4">The following example demonstrates how header section and payload of a protect body part might look like. For example, this will be the first body part of a multipart/signed message or the signed and/or encrypted payload of the application/pkcs7-mime body part. Lines prepended by &#8220;O: &#8220; are the outer header section. Lines prepended by &#8220;I: &#8220; are the inner header section.</p>
<pre>
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: &lt;e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net&gt;
O: Subject: Meeting at my place
O: From: "Alexey Melnikov" &lt;alexey.melnikov@example.net&gt;
O: MIME-Version: 1.0
O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
O: protocol="application/pkcs7-signature";
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
This is a multipart message in MIME format.
--.cbe16d2a-e1a3-4220-b821-38348fc97237
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
I: From: "Alexey Melnikov" &lt;alexey.melnikov@example.net&gt;
I: Message-ID: &lt;e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net&gt;
I: MIME-Version: 1.0
I: MMHS-Primary-Precedence: 3
I: Subject: Meeting at my place
I: To: somebody@example.net
I: X-Mailer: Isode Harrier Web Server
I: Content-Type: text/plain; charset=us-ascii
This is an important message that I don't want to be modified.
--.cbe16d2a-e1a3-4220-b821-38348fc97237
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature
<ul class="empty"><li>Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks&#8221;</li></ul>
<p id="rfc.section.4.1.1.1.p.6">Existing MIME parsers and libraries and/or MUAs implemented according to <a href="#RFC2046" class="xref">[RFC2046]</a> will need to be changed to implement the option described in <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a>, as that option differs from the current MIME Standard (cf. <a href="#RFC2046" class="xref">[RFC2046]</a>).</p>
<p id="rfc.section.4.1.1.1.p.7">The impact of using &#8220;text/plain&#8221;, while in fact containing a (subset of a) &#8220;message/RFC822&#8221; media type to be parsed, is for further study concerning MIME standards and real world deployments.</p>
<p id="rfc.section.4.1.1.1.p.8">For further information, the reader is encouraged to consult <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a>.</p>
[[base-64 encoded signature]]
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
</pre>
<p id="rfc.section.4.1.1.2.p.5">The Outer Message Header Section is unprotected, while the remainder (Outer Message Body) is protected. The Outer Message Body consists of the Inner Message (Header Section and Body).</p>
<p id="rfc.section.4.1.1.2.p.6">The Inner Message Header Section is the same as (or a subset of) the Original Message Header Section (cf. <a href="#inner-msg-hf" class="xref">Section 4.1.2</a>).</p>
<p id="rfc.section.4.1.1.2.p.7">The Inner Message Body is the same as the Original Message Body.</p>
<p id="rfc.section.4.1.1.2.p.8">The Original Message itself may contain any MIME structure.</p>
<p id="rfc.section.4.1.1.2.p.9">There may also be an additional MIME layer with media type &#8220;multipart/mixed&#8221; in the Outer Message Body to contain the Inner Message along with other MIME part(s).</p>
<h1 id="rfc.section.4.1.2">
<a href="#rfc.section.4.1.2">4.1.2.</a> <a href="#inner-msg-hf" id="inner-msg-hf">Inner Message Header Fields</a>
</h1>
@ -753,28 +813,30 @@ signature.
<ul><li>Bcc</li></ul>
<p id="rfc.section.4.1.2.p.3">[[ TODO: Bcc handling needs to be further specified (see also <a href="#bcc-handling" class="xref">Appendix A.1</a>). Certain MUAs cannot properly decrypt messages with Bcc recipients. ]]</p>
<p id="rfc.section.4.1.2.p.4">In additon, the Inner Message Header Section MUST be preceded by a MIME Header Section with media type &#8220;message/RFC822&#8221; that SHOULD contain the Content-Type header field parameter &#8220;forwarded=no&#8221; as defined in <a href="#I-D.melnikov-iana-reg-forwarded" class="xref">[I-D.melnikov-iana-reg-forwarded]</a>.</p>
<h1 id="rfc.section.4.1.3">
<a href="#rfc.section.4.1.3">4.1.3.</a> <a href="#outer-msg-hf" id="outer-msg-hf">Outer Message Header Fields</a>
<a href="#rfc.section.4.1.3">4.1.3.</a> <a href="#wrapper" id="wrapper">Wrapper</a>
</h1>
<p id="rfc.section.4.1.3.p.1">The wrapper is a simple MIME Header Section followed by an empty line preceding the Inner Message (inside the Outer Message Body). The media type of the wrapper MUST be &#8220;message/RFC822&#8221; and SHOULD contain the Content-Type header field parameter &#8220;forwarded=no&#8221; as defined in <a href="#I-D.melnikov-iana-reg-forwarded" class="xref">[I-D.melnikov-iana-reg-forwarded]</a>. The wrapper delimits unambigously the Inner Message from the rest of the message.</p>
<h1 id="rfc.section.4.1.4">
<a href="#rfc.section.4.1.4">4.1.4.</a> <a href="#outer-msg-hf" id="outer-msg-hf">Outer Message Header Fields</a>
</h1>
<p id="rfc.section.4.1.3.p.1">To maximize Privacy, it is strongly RECOMMENDED to follow the principle of Data Minimization (cf. <a href="#privacy" class="xref">Section 2.1</a>).</p>
<p id="rfc.section.4.1.3.p.2">However, the Outer Message Header Section SHOULD contain the Essential Header Fields and, in addition, MUST contain the Header Fields of the MIME Header Section part to describe the encryption or signature as per <a href="#RFC8551" class="xref">[RFC8551]</a>.</p>
<p id="rfc.section.4.1.3.p.3">The following Header Fields are defined as the Essential Header Fields:</p>
<p id="rfc.section.4.1.4.p.1">To maximize Privacy, it is strongly RECOMMENDED to follow the principle of Data Minimization (cf. <a href="#privacy" class="xref">Section 2.1</a>).</p>
<p id="rfc.section.4.1.4.p.2">However, the Outer Message Header Section SHOULD contain the Essential Header Fields and, in addition, MUST contain the Header Fields of the MIME Header Section part to describe the encryption or signature as per <a href="#RFC8551" class="xref">[RFC8551]</a>.</p>
<p id="rfc.section.4.1.4.p.3">The following Header Fields are defined as the Essential Header Fields:</p>
<p></p>
<ul>
<li>From</li>
<li>To (if present in the OrigM)</li>
<li>Cc (if present in the OrigM)</li>
<li>Bcc (if present in the OrigM, see also <a href="#outer-msg-hf" class="xref">Section 4.1.3</a> and <a href="#bcc-handling" class="xref">Appendix A.1</a>)</li>
<li>Bcc (if present in the OrigM, see also <a href="#inner-msg-hf" class="xref">Section 4.1.2</a> and <a href="#bcc-handling" class="xref">Appendix A.1</a>)</li>
<li>Date</li>
<li>Message-ID</li>
<li>Subject</li>
</ul>
<p id="rfc.section.4.1.3.p.5">Some of these Header Fields are needed by the Transport (e.g. to determine the destination). Furthermore, not including certain Header Fields may trigger spam detection to flag the message as spam and/or lead to user experience (UX) issues.</p>
<p id="rfc.section.4.1.3.p.6">For further Data Minimization the value of the Subject Header Field SHOULD be obfuscated. In addition, the value of other Essential Header Fields MAY be obfuscated. Further Header Fields MAY be obfuscated, though simply not adding those to the Outer Message Header SHOULD be prefered over obfuscation. Header Field obfuscation is further specified in <a href="#obfuscation-outer-HF" class="xref">Section 4.1.3.1</a>.</p>
<p id="rfc.section.4.1.3.p.7">Header Fields not obfuscated SHOULD contain the same values as in the Original Message.</p>
<p id="rfc.section.4.1.3.p.8">The MIME Header Section part is the collection of MIME Header Fields describing the following MIME structure as defined in <a href="#RFC2045" class="xref">[RFC2045]</a>. A MIME Header Section part typically includes the following Header Fields:</p>
<p id="rfc.section.4.1.4.p.5">Some of these Header Fields are needed by the Transport (e.g. to determine the destination). Furthermore, not including certain Header Fields may trigger spam detection to flag the message as spam and/or lead to user experience (UX) issues.</p>
<p id="rfc.section.4.1.4.p.6">For further Data Minimization the value of the Subject Header Field SHOULD be obfuscated. In addition, the value of other Essential Header Fields MAY be obfuscated. Further Header Fields MAY be obfuscated, though simply not adding those to the Outer Message Header SHOULD be prefered over obfuscation. Header Field obfuscation is further specified in <a href="#obfuscation-outer-HF" class="xref">Section 4.1.4.1</a>. Header Fields not obfuscated SHOULD contain the same values as in the Original Message.</p>
<p id="rfc.section.4.1.4.p.7">The MIME Header Section part is the collection of MIME Header Fields describing the following MIME structure as defined in <a href="#RFC2045" class="xref">[RFC2045]</a>. A MIME Header Section part typically includes the following Header Fields:</p>
<p></p>
<ul>
@ -783,7 +845,7 @@ signature.
<li>Content-Transfer-Encoding</li>
<li>Content-Disposition</li>
</ul>
<p id="rfc.section.4.1.3.p.10">The following example shows the MIME header of an S&#8203;/&#8203;MIME signed message (using application/pkcs7-mime with SignedData):</p>
<p id="rfc.section.4.1.4.p.9">The following example shows the MIME header of an S&#8203;/&#8203;MIME signed message (using application/pkcs7-mime with SignedData):</p>
<pre>
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=signed-data;
@ -792,7 +854,7 @@ signature.
Content-Disposition: attachment; filename=smime.p7m
</pre>
<p id="rfc.section.4.1.3.p.11">Depending on the scenario, further Header Fields MAY be exposed in the Outer Message Header Section, which is NOT RECOMMENDED unless justified. Such Header Fields may include e.g.:</p>
<p id="rfc.section.4.1.4.p.10">Depending on the scenario, further Header Fields MAY be exposed in the Outer Message Header Section, which is NOT RECOMMENDED unless justified. Such Header Fields may include e.g.:</p>
<p></p>
<ul>
@ -800,59 +862,56 @@ signature.
<li>Reply-To</li>
<li>In-Reply-To</li>
</ul>
<h1 id="rfc.section.4.1.3.1">
<a href="#rfc.section.4.1.3.1">4.1.3.1.</a> <a href="#obfuscation-outer-HF" id="obfuscation-outer-HF">Obfuscation of Outer Message Header Fields</a>
<h1 id="rfc.section.4.1.4.1">
<a href="#rfc.section.4.1.4.1">4.1.4.1.</a> <a href="#obfuscation-outer-HF" id="obfuscation-outer-HF">Obfuscation of Outer Message Header Fields</a>
</h1>
<p id="rfc.section.4.1.3.1.p.1">If the values of the following Outer Message Header Fields are obfuscated, those SHOULD assume the following values:</p>
<p id="rfc.section.4.1.4.1.p.1">If the values of the following Outer Message Header Fields are obfuscated, those SHOULD assume the following values:</p>
<pre>
* Subject: ...
* Message-ID: &lt;new randomly generated Message-ID&gt;
* Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
</pre>
<p id="rfc.section.4.1.3.1.p.2">[[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the same week. ]]</p>
<p id="rfc.section.4.1.3.1.p.3">In certain implementations also the From, To, and/or Cc Header Field MAY be obfucated. Those may be replaced by e.g.</p>
<p id="rfc.section.4.1.4.1.p.2">[[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the same week. ]]</p>
<p id="rfc.section.4.1.4.1.p.3">In certain implementations also the From, To, and/or Cc Header Field MAY be obfucated. Those may be replaced by e.g.</p>
<p></p>
<ul><li>To: Obfuscated <a href="mailto:anonymous@anonymous.invalid">anonymous@anonymous.invalid</a>
</li></ul>
<p id="rfc.section.4.1.3.1.p.5">Such implementations need to ensure that the Transport has access to these Header Fields in clear text and is capable of processing those.</p>
<p id="rfc.section.4.1.3.1.p.6">A use case for obfuscation of all Outer Message Header Fields is mixnet netwerks, i.e. &#8220;onion routing&#8221; for email (e.g.<a href="#pEp.mixnet" class="xref">[pEp.mixnet]</a>).</p>
<p id="rfc.section.4.1.3.1.p.7">Note: It is for further study to what extent Header Field obfuscation (adversely) impacts spam filtering.</p>
<h1 id="rfc.section.4.1.4">
<a href="#rfc.section.4.1.4">4.1.4.</a> <a href="#message-processing" id="message-processing">Message Processing</a>
<p id="rfc.section.4.1.4.1.p.5">Such implementations need to ensure that the Transport has access to these Header Fields in clear text and is capable of processing those.</p>
<p id="rfc.section.4.1.4.1.p.6">A use case for obfuscation of all Outer Message Header Fields is mixnet netwerks, i.e. &#8220;onion routing&#8221; for email (e.g.<a href="#pEp.mixnet" class="xref">[pEp.mixnet]</a>).</p>
<p id="rfc.section.4.1.4.1.p.7">Note: It is for further study to what extent Header Field obfuscation (adversely) impacts spam filtering.</p>
<h1 id="rfc.section.4.1.5">
<a href="#rfc.section.4.1.5">4.1.5.</a> <a href="#message-processing" id="message-processing">Message Processing</a>
</h1>
<p id="rfc.section.4.1.4.p.1">The Following figure depicts the different message representations (OrigM, InnerM, OuterM, RUFM) and which parts those are constructed from:</p>
<p id="rfc.section.4.1.5.p.1">The Following figure depicts the different message representations (OrigM, InnerM, OuterM, RUFM) and which parts those are constructed from:</p>
<pre>
OrigM InnerM Outer(S) OuterM(R) RUFM
&lt;Trans-HF&gt; &gt; &lt;Trans-HF&gt;
From (OrigM) = From
To (OrigM) = To
Cc (OrigM) = Cc
Bcc (OrigM) = Bcc (*) &gt; Bcc
Date (OrigM) = Date
Message-ID = Message-ID
(OrigM)
Subject (new) = Subject
&lt;MIME-HSp&gt; (new) = &lt;MIME-HSp&gt;
PROTECTED: PROTECTED:
&lt;MIME-HS&gt; &gt; &lt;MIME-HS&gt; = &lt;MIME-HS&gt;
(new)
From &gt; From &gt; From = From &gt; From
To &gt; To &gt; To = To &gt; To
Cc (*) &gt; Cc &gt; Cc = Cc &gt; Cc
OrigM InnerM Outer(S) OuterM(R) RUFM
&lt;Trans-HF&gt; &gt; &lt;Trans-HF&gt;
From (OrigM) = From
To (OrigM) = To
Cc (OrigM) = Cc
Bcc (OrigM) = Bcc (*) &gt; Bcc
Date (OrigM) = Date
Message-ID (OrigM)= Message-ID
Subject (new) = Subject
&lt;MIME-HSp&gt; (new) = &lt;MIME-HSp&gt;
PROTECTED: PROTECTED:
&lt;Wrapper&gt; (new) = &lt;Wrapper&gt;
From &gt; From &gt; From = From &gt; From
To &gt; To &gt; To = To &gt; To
Cc (*) &gt; Cc &gt; Cc = Cc &gt; Cc
Bcc (*)
Date &gt; Date &gt; Date = Date &gt; Date
Message-ID &gt; Message-ID &gt; Message-ID = Message-ID &gt; Message-ID
Subject &gt; Subject &gt; Subject = Subject &gt; Subject
&lt;More HF&gt; &gt; &lt;More HF&gt; &gt; &lt;More HF&gt; = &lt;More HF&gt; &gt; &lt;More-HF&gt;
&lt;MIME-HSp&gt; &gt; &lt;MIME-HSp&gt; &gt; &lt;MIME-HSp&gt; = &lt;MIME-HSp&gt; &gt; &lt;MIME-HSp&gt;
&lt;Body&gt; &gt; &lt;Body&gt; &gt; &lt;Body&gt; = &lt;Body&gt; &gt; &lt;Body&gt;
Date &gt; Date &gt; Date = Date &gt; Date
Message-ID &gt; Message-ID &gt; Message-ID = Message-ID &gt; Message-ID
Subject &gt; Subject &gt; Subject = Subject &gt; Subject
&lt;More HF&gt; &gt; &lt;More HF&gt; &gt; &lt;More HF&gt; = &lt;More HF&gt; &gt; &lt;More-HF&gt;
&lt;MIME-HSp&gt; &gt; &lt;MIME-HSp&gt; &gt; &lt;MIME-HSp&gt; = &lt;MIME-HSp&gt; &gt; &lt;MIME-HSp&gt;
&lt;Body&gt; &gt; &lt;Body&gt; &gt; &lt;Body&gt; = &lt;Body&gt; &gt; &lt;Body&gt;
</pre>
<p id="rfc.section.4.1.4.p.2">Legend:</p>
<p id="rfc.section.4.1.5.p.2">Legend:</p>
<p></p>
<ul>
@ -861,61 +920,62 @@ Subject &gt; Subject &gt; Subject = Subject &gt; Subject
<li>InnerM: Inner Message (that protection is applied to)</li>
<li>RUFM: Receiving User Facing Message</li>
<li>More-HF: Additional Header Fields (HF) in the Original Message (OrigM)</li>
<li>MIME-HS: MIME Header Section; with media type (message/RFC822)</li>
<li>MIME-HSp: MIME Header Section part</li>
<li>Wrapper: MIME Header Section; with media type (message/RFC822) to unambigously delimit the inner message from the rest of the message.</li>
<li>MIME-HSp: MIME Header Section part to describe the encryption or signature as per <a href="#RFC8551" class="xref">[RFC8551]</a>
</li>
<li>Trans-HF: Header Fields added in Transit (between sending and receiving side)</li>
<li>&#8217;&gt;&#8217;: taken over / copied from last column</li>
<li>&#8217;=&#8217;: propagates unchanged, unless something unusual (e.g. attack) happens</li>
<li>&#8217;(*)&#8217;: HF is often not present (but also further HF may not be present). If the HF is not present, naturally it can neither be taken over nor propagated.</li>
<li>&#8216;(new)&#8217; / &#8216;(OrigM)&#8217;: HF or MIME-HSp is generated depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.4.1.1</a>, while &#8216;(new)&#8217; / &#8216;(OrigM)&#8217; designate the default.</li>
<li>&#8216;(new)&#8217; / &#8216;(OrigM)&#8217;: HF or MIME-HSp is generated depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.5.1.1</a>, while &#8216;(new)&#8217; / &#8216;(OrigM)&#8217; designate the default.</li>
</ul>
<h1 id="rfc.section.4.1.4.1">
<a href="#rfc.section.4.1.4.1">4.1.4.1.</a> <a href="#sending-side" id="sending-side">Sending Side</a>
<h1 id="rfc.section.4.1.5.1">
<a href="#rfc.section.4.1.5.1">4.1.5.1.</a> <a href="#sending-side" id="sending-side">Sending Side</a>
</h1>
<p id="rfc.section.4.1.4.1.p.1">For a protected message the following steps are applied before a message can be handed over to the Transport:</p>
<h1 id="rfc.section.4.1.4.1.1">
<a href="#rfc.section.4.1.4.1.1">4.1.4.1.1.</a> <a href="#sending-side-step-1" id="sending-side-step-1">Step 1: Decide on Protection Level and Information Disclosure</a>
<p id="rfc.section.4.1.5.1.p.1">For a protected message the following steps are applied before a message is handed over to the Transport:</p>
<h1 id="rfc.section.4.1.5.1.1">
<a href="#rfc.section.4.1.5.1.1">4.1.5.1.1.</a> <a href="#sending-side-step-1" id="sending-side-step-1">Step 1: Decide on Protection Level and Information Disclosure</a>
</h1>
<p id="rfc.section.4.1.4.1.1.p.1">The entity applying protection to a message must decide:</p>
<p id="rfc.section.4.1.5.1.1.p.1">The entity applying protection to a message must decide:</p>
<p></p>
<ul>
<li>Which protection level (signature and/or encryption) is applied to the message? This depends on user request and/or local policy as well as availability of cryptographic keys.</li>
<li>Which Header Fields of the Orignial Message shall be part of the Outer Message Header Section? This typically depends on local policy. By default the Essential Header Fields are part of the Outer Message Header Section (in addition to the MIME Header Section part); cf. <a href="#outer-msg-hf" class="xref">Section 4.1.3</a>.</li>
<li>Which of these Header Fields are to be obfuscated? This depends on local policy and/or specific Privacy requirements of the user. By default only the Subject Header Field is obfuscated; cf. <a href="#obfuscation-outer-HF" class="xref">Section 4.1.3.1</a>.</li>
<li>Which Header Fields of the Orignial Message shall be part of the Outer Message Header Section? This typically depends on local policy. By default the Essential Header Fields are part of the Outer Message Header Section; cf. <a href="#outer-msg-hf" class="xref">Section 4.1.4</a>.</li>
<li>Which of these Header Fields are to be obfuscated? This depends on local policy and/or specific Privacy requirements of the user. By default only the Subject Header Field is obfuscated; cf. <a href="#obfuscation-outer-HF" class="xref">Section 4.1.4.1</a>.</li>
</ul>
<h1 id="rfc.section.4.1.4.1.2">
<a href="#rfc.section.4.1.4.1.2">4.1.4.1.2.</a> <a href="#sending-side-step-2" id="sending-side-step-2">Step 2: Compose the Outer Message Header Section</a>
<h1 id="rfc.section.4.1.5.1.2">
<a href="#rfc.section.4.1.5.1.2">4.1.5.1.2.</a> <a href="#sending-side-step-2" id="sending-side-step-2">Step 2: Compose the Outer Message Header Section</a>
</h1>
<p id="rfc.section.4.1.4.1.2.p.1">Depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.4.1.1</a>, compose the Outer Message Header Section. (Note that this also includes the necessary MIME Header Section part for the following protection layer.)</p>
<p id="rfc.section.4.1.4.1.2.p.2">Outer Header Fields that are not obfuscated SHOULD contain the same values as in the Original Message (except for MIME Header Section part, which depends on the protection level selected in <a href="#sending-side-step-1" class="xref">Section 4.1.4.1.1</a>).</p>
<h1 id="rfc.section.4.1.4.1.3">
<a href="#rfc.section.4.1.4.1.3">4.1.4.1.3.</a> <a href="#sending-side-step-3" id="sending-side-step-3">Step 3: Apply Protection to the Original Message</a>
<p id="rfc.section.4.1.5.1.2.p.1">Depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.5.1.1</a>, compose the Outer Message Header Section. (Note that this also includes the necessary MIME Header Section part for the following protection layer.)</p>
<p id="rfc.section.4.1.5.1.2.p.2">Outer Header Fields that are not obfuscated SHOULD contain the same values as in the Original Message (except for MIME Header Section part, which depends on the protection level selected in <a href="#sending-side-step-1" class="xref">Section 4.1.5.1.1</a>).</p>
<h1 id="rfc.section.4.1.5.1.3">
<a href="#rfc.section.4.1.5.1.3">4.1.5.1.3.</a> <a href="#sending-side-step-3" id="sending-side-step-3">Step 3: Apply Protection to the Original Message</a>
</h1>
<p id="rfc.section.4.1.4.1.3.p.1">Depending on the protection level in selected in <a href="#sending-side-step-1" class="xref">Section 4.1.4.1.1</a> apply signature and/or encryption to the original message (as per <a href="#RFC8551" class="xref">[RFC8551]</a>) and include the result to the message as Outer Message Body.</p>
<p id="rfc.section.4.1.4.1.3.p.2">The resulting (Outer) Message is then typically handed over to the Transport.</p>
<p id="rfc.section.4.1.4.1.3.p.3">[[ TODO: Example ]]</p>
<h1 id="rfc.section.4.1.4.2">
<a href="#rfc.section.4.1.4.2">4.1.4.2.</a> <a href="#receiving-side" id="receiving-side">Receiving Side</a>
<p id="rfc.section.4.1.5.1.3.p.1">Depending on the protection level selected in <a href="#sending-side-step-1" class="xref">Section 4.1.5.1.1</a> apply signature and/or encryption to the original message including the wrapper (as per <a href="#RFC8551" class="xref">[RFC8551]</a>) and put the result to the message as Outer Message Body.</p>
<p id="rfc.section.4.1.5.1.3.p.2">The resulting (Outer) Message is then typically handed over to the Transport.</p>
<p id="rfc.section.4.1.5.1.3.p.3">[[ TODO: Example ]]</p>
<h1 id="rfc.section.4.1.5.2">
<a href="#rfc.section.4.1.5.2">4.1.5.2.</a> <a href="#receiving-side" id="receiving-side">Receiving Side</a>
</h1>
<p id="rfc.section.4.1.4.2.p.1">When a protected message is received the following steps are applied:</p>
<h1 id="rfc.section.4.1.4.2.1">
<a href="#rfc.section.4.1.4.2.1">4.1.4.2.1.</a> <a href="#receiving-side-step-1" id="receiving-side-step-1">Step 1: Decrypt message and/or check signature</a>
<p id="rfc.section.4.1.5.2.p.1">When a protected message is received the following steps are applied:</p>
<h1 id="rfc.section.4.1.5.2.1">
<a href="#rfc.section.4.1.5.2.1">4.1.5.2.1.</a> <a href="#receiving-side-step-1" id="receiving-side-step-1">Step 1: Decrypt message and/or check signature</a>
</h1>
<p id="rfc.section.4.1.4.2.1.p.1">Depending on the protection level the received message is decrypted and/or its signature is checked as per <a href="#RFC8551" class="xref">[RFC8551]</a>.</p>
<h1 id="rfc.section.4.1.4.2.2">
<a href="#rfc.section.4.1.4.2.2">4.1.4.2.2.</a> <a href="#receiving-side-step-2" id="receiving-side-step-2">Step 2: Construct the Receiving User Facing Message</a>
<p id="rfc.section.4.1.5.2.1.p.1">Depending on the protection level the received message is decrypted and/or its signature is checked as per <a href="#RFC8551" class="xref">[RFC8551]</a>.</p>
<h1 id="rfc.section.4.1.5.2.2">
<a href="#rfc.section.4.1.5.2.2">4.1.5.2.2.</a> <a href="#receiving-side-step-2" id="receiving-side-step-2">Step 2: Construct the Receiving User Facing Message</a>
</h1>
<p id="rfc.section.4.1.4.2.2.p.1">The Receiving User Facing Message is constructed as follows:</p>
<p id="rfc.section.4.1.5.2.2.p.1">The Receiving User Facing Message is constructed as follows:</p>
<p></p>
<ul>
<li>The Header Section of the Receiving User Facing Message MUST consist of the Outer Message Header Fields that are not contained in the Inner Message Header Section, and the Inner Message Header Fields (i.e. the Inner Message Header Field MUST always take precedence).</li>
<li>The Body of the Receiving User Facing Message Body MUST be the same as the Inner Message Body.</li>
</ul>
<p id="rfc.section.4.1.4.2.2.p.3">The resulting message is handed over for further processing, which typically involves rendering it to the user.</p>
<p id="rfc.section.4.1.4.2.2.p.4">[[ TODO: Do we need to take special care for HFs, which may appear multiple times, e.g. Received HF? ]]</p>
<p id="rfc.section.4.1.4.2.2.p.5">Note: It is for further study whether and, if yes, how the Outer Message Header Section (as received from the Transport) is preserved for the user.</p>
<p id="rfc.section.4.1.5.2.2.p.3">The resulting message is handed over for further processing, which typically involves rendering it to the user.</p>
<p id="rfc.section.4.1.5.2.2.p.4">[[ TODO: Do we need to take special care for HFs, which may appear multiple times, e.g. Received HF? ]]</p>
<p id="rfc.section.4.1.5.2.2.p.5">Note: It is for further study whether and, if yes, how the Outer Message Header Section (as received from the Transport) is preserved for the user.</p>
<h1 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#backward-compatibility-use-case" id="backward-compatibility-use-case">Backward Compatibility Use Case</a>
</h1>
@ -955,11 +1015,6 @@ Subject &gt; Subject &gt; Subject = Subject &gt; Subject
<a>Freed, N.</a> and <a>N. Borenstein</a>, "<a href="https://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>", RFC 2045, DOI 10.17487/RFC2045, November 1996.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2046">[RFC2046]</b></td>
<td class="top">
<a>Freed, N.</a> and <a>N. Borenstein</a>, "<a href="https://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>", RFC 2046, DOI 10.17487/RFC2046, November 1996.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
<td class="top">
<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
@ -1054,12 +1109,12 @@ Subject &gt; Subject &gt; Subject = Subject &gt; Subject
<p></p>
<ul>
<li>Decide on format of obfuscated HFs, in particular Date HF (<a href="#obfuscation-outer-HF" class="xref">Section 4.1.3.1</a>)</li>
<li>Impact on spam filtering, if HFs are obfuscated (<a href="#obfuscation-outer-HF" class="xref">Section 4.1.3.1</a>)</li>
<li>More examples (e.g. in <a href="#message-processing" class="xref">Section 4.1.4</a>)</li>
<li>Should Outer Message Header Section (as received) be preserved for the user? (<a href="#receiving-side-step-2" class="xref">Section 4.1.4.2.2</a>)</li>
<li>Do we need to take special care of HFs that may appear multiple times, e.g. Received HF? (<a href="#receiving-side-step-2" class="xref">Section 4.1.4.2.2</a>)</li>
<li>Change adding Content-Type header field parameter &#8220;forwarded&#8221; from SHOULD to MUST (<a href="#mime-format" class="xref">Section 4.1.1</a>)?</li>
<li>Decide on format of obfuscated HFs, in particular Date HF (<a href="#obfuscation-outer-HF" class="xref">Section 4.1.4.1</a>)</li>
<li>Impact on spam filtering, if HFs are obfuscated (<a href="#obfuscation-outer-HF" class="xref">Section 4.1.4.1</a>)</li>
<li>More examples (e.g. in <a href="#message-processing" class="xref">Section 4.1.5</a>)</li>
<li>Should Outer Message Header Section (as received) be preserved for the user? (<a href="#receiving-side-step-2" class="xref">Section 4.1.5.2.2</a>)</li>
<li>Do we need to take special care of HFs that may appear multiple times, e.g. Received HF? (<a href="#receiving-side-step-2" class="xref">Section 4.1.5.2.2</a>)</li>
<li>Change adding Content-Type header field parameter &#8220;forwarded&#8221; from SHOULD to MUST (<a href="#wrapper" class="xref">Section 4.1.3</a>)?</li>
<li>Decide on whether or not merge requirements from <a href="#I-D.ietf-lamps-header-protection-requirements" class="xref">[I-D.ietf-lamps-header-protection-requirements]</a> into this document.</li>
<li>Decide what parts of <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a> to merge into this document.</li>
<li>Enhance Introduction and Problem Statement sections</li>


+ 300
- 188
ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200626.txt View File

@ -74,30 +74,31 @@ Table of Contents
2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 6
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Main Case for Header Protection . . . . . . . . . . . 6
3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Main Case for Header Protection . . . . . . . . . . . 7
3.1.2. Backward Compatibility . . . . . . . . . . . . . . . 7
3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 7
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Inner Message Header Fields . . . . . . . . . . . . . 11
4.1.3. Outer Message Header Fields . . . . . . . . . . . . . 11
4.1.4. Message Processing . . . . . . . . . . . . . . . . . 13
4.2. Backward Compatibility Use Case . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Additional information . . . . . . . . . . . . . . . 19
A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 19
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 20
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2. Inner Message Header Fields . . . . . . . . . . . . . 13
4.1.3. Wrapper . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Outer Message Header Fields . . . . . . . . . . . . . 13
4.1.5. Message Processing . . . . . . . . . . . . . . . . . 15
4.2. Backward Compatibility Use Case . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Additional information . . . . . . . . . . . . . . . 21
A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 21
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 22
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
@ -105,7 +106,6 @@ Table of Contents
exist, which allow to assess the authenticity and integrity of the
email headers section or selected header fields (HF) from the domain-
level perspective, specifically DomainKeys Identified Mail (DKIM)
[RFC6376] and Sender Policy Framework (SPF) [RFC7208], and Domain-
@ -114,6 +114,7 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 2]
Internet-Draft Header Protection S/MIME June 2020
[RFC6376] and Sender Policy Framework (SPF) [RFC7208], and Domain-
based Message Authentication, Reporting, and Conformance (DMARC)
[RFC7489]. These protocols, while essential to responding to a range
of attacks on email, do not offer (full) end-to-end protection to the
@ -164,7 +165,6 @@ Internet-Draft Header Protection S/MIME June 2020
Hoeneisen & Melnikov Expires December 28, 2020 [Page 3]
Internet-Draft Header Protection S/MIME June 2020
@ -215,8 +215,8 @@ Internet-Draft Header Protection S/MIME June 2020
payload of a Message. Typically, the Body consists of a
(multipart) MIME [RFC2045] construct.
o MIME Header Section (part): The collection of MIME Header Fields
describing the following MIME structure as defined in [RFC2045].
o MIME Header Fields: Header Fields describing the MIME structure of
its body as defined in [RFC2045].
@ -226,6 +226,12 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 4]
Internet-Draft Header Protection S/MIME June 2020
o MIME Header Section (part): The collection of MIME Header Fields.
"MIME Header Section" refers to a Header Sections that contains
only MIME Header Fields, whereas "MIME Header Section part" refers
to the MIME Header Fields of a Header Section that - in addition
to MIME Header Fields - also contains non-MIME Header Fields.
o Header Protection (HP): cryptographic protection of email Header
Sections (or parts of it) for signatures and/or encryption
@ -237,12 +243,12 @@ Internet-Draft Header Protection S/MIME June 2020
side.
o Inner Message (InnerM): The message to be protected, shortly
before protection measures are applied to on the sending side or
the message shortly after decryption and/or unwrapping the signed
part on the receiving side. Typically the Inner Message is in
clear text. The Inner Message is rather similar as the Original
Message. The Inner Message MUST be the same on the sending and
the receiving side.
before wrapping and protection measures are applied to on the
sending side or the message shortly after decryption and
unwrapping has been applied to on the receiving side respectively.
Typically, the Inner Message is in clear text. The Inner Message
is a subset of (or the same as) the Original Message. The Inner
Message must be the same on the sending and the receiving side.
o Outer Message (OuterM): The Message as handed over to the
Transport or received from the Transport respectively. The Outer
@ -254,7 +260,7 @@ Internet-Draft Header Protection S/MIME June 2020
Section has been merged with the Inner Message Header Section.
o Essential Header Fields (EHF): The Header Fields an Outer Message
Header Section SHOULD contain at least; cf. Section 4.1.3.
Header Section SHOULD contain at least; cf. Section 4.1.4.
o Protected: Protected refers to the parts of a message where
protection measures of any Protection Levels have been applied to.
@ -268,12 +274,6 @@ Internet-Draft Header Protection S/MIME June 2020
o Unprotected Message: A message that no protection measures of any
Protection Levels have been applied to.
o Data Minimization: Data spareness and hiding all technically
concealable information whenever possible.
@ -282,6 +282,9 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 5]
Internet-Draft Header Protection S/MIME June 2020
o Data Minimization: Data spareness and hiding all technically
concealable information whenever possible.
2. Problem Statement
The LAMPS charter contains the following Work Item:
@ -323,12 +326,9 @@ Internet-Draft Header Protection S/MIME June 2020
These use cases apply independently of whether S/MIME, PGP/MIME or
any other technology is used to achieve HP.
3.1. Interactions
3.1.1. Main Case for Header Protection
Both peers (sending and receiving side) fully support Header
Protection as specified in this document; see Section 4.1.
@ -338,6 +338,13 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 6]
Internet-Draft Header Protection S/MIME June 2020
3.1. Interactions
3.1.1. Main Case for Header Protection
Both peers (sending and receiving side) fully support Header
Protection as specified in this document; see Section 4.1.
3.1.2. Backward Compatibility
The sending side fully supports Header protection as specified in
@ -380,13 +387,6 @@ Internet-Draft Header Protection S/MIME June 2020
This specification applies to the protection levels "signature &
encryption" and "signature only" (cf. Section 3.2):
Sending and receiving sides SHOULD implement "signature and
encryption", which is the default to use on the sending side.
Certain implementations MAY decide to send "signature only" messages,
depending on the circumstances and customer requirements. Sending
side MAY and receiving sides SHOULD implement "signature only".
Hoeneisen & Melnikov Expires December 28, 2020 [Page 7]
@ -394,6 +394,13 @@ Hoeneisen & Melnikov Expires December 28, 2020 [Page 7]
Internet-Draft Header Protection S/MIME June 2020
Sending and receiving sides SHOULD implement "signature and
encryption", which is the default to use on the sending side.
Certain implementations MAY decide to send "signature only" messages,
depending on the circumstances and customer requirements. Sending
side MAY and receiving sides SHOULD implement "signature only".
It generally is NOT RECOMMENDED to send a message with protection
level "encryption only". On the other hand, messages with protection
level "encryption only" might arrive at the receiving side. While
@ -413,6 +420,16 @@ Internet-Draft Header Protection S/MIME June 2020
4.1.1. MIME Format
Currently there are two options in discussion:
1. The option according to the current S/MIME specification (cf.
[RFC8551])
2. An alternative option that is based on the former "memory hole"
approach (cf. [I-D.autocrypt-lamps-protected-headers])
4.1.1.1. S/MIME Specification
As per S/MIME version 3.1 and later (cf. [RFC8551]), the sending
client MAY wrap a full MIME message in a message/RFC822 wrapper in
order to apply S/MIME security services to these header fields.
@ -423,17 +440,25 @@ Internet-Draft Header Protection S/MIME June 2020
mailing applications might display the Inner Message as attachment
otherwise.
In the simplest case, a message looks as follows:
The MIME structure of an Email message looks as follows:
Hoeneisen & Melnikov Expires December 28, 2020 [Page 8]
Internet-Draft Header Protection S/MIME June 2020
<Outer Message Header Section (unprotected)>
<Outer Message Body (protected)>
<MIME Header Section>
<MIME Header Section (wrapper)>
<Inner Message Header Section>
<Inner Message Header Section>
<Inner Message Body>
<Inner Message Body>
The following example demonstrates how header section and payload of
@ -441,17 +466,44 @@ Internet-Draft Header Protection S/MIME June 2020
first body part of a multipart/signed message or the signed and/or
encrypted payload of the application/pkcs7-mime body part. Lines
prepended by "O: " are the Outer Message Header Section. Lines
prepended by "I: " are the Inner Message Header Section. Lines
prepended by "W: " are the wrapper (MIME Header Section):
Hoeneisen & Melnikov Expires December 28, 2020 [Page 8]
Internet-Draft Header Protection S/MIME June 2020
prepended by "I: " are the Inner Message Header Section. Lines
prepended by "W: " are the wrapper (MIME Header Section):
Hoeneisen & Melnikov Expires December 28, 2020 [Page 9]
Internet-Draft Header Protection S/MIME June 2020
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
@ -491,73 +543,133 @@ Internet-Draft Header Protection S/MIME June 2020
The Outer Message Header Section is unprotected, while the remainder
(Outer Message Body) is protected. The Outer Message Body consists
of the Inner Message (Header Section and Body).
of the wrapper (MIME Header Section) and the Inner Message (Header
Section and Body).
The wrapper is a simple MIME Header Section with media type "message/
RFC822" containing a Content-Type header field parameter
"forwarded=no" followed by an empty line.
The Inner Message Header Section is the same as (or a subset of) the
Original Message Header Section preceded by a MIME Header
Section with media type "message/RFC822" containing a Content-Type
header field parameter "forwarded=no" (cf. Section 4.1.2).
Original Message Header Section (cf. Section 4.1.2).
The Inner Message Body is the same as the Original Message Body.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 9]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 10]
Internet-Draft Header Protection S/MIME June 2020
The Inner Message Body is the same as the Original Message Body.
The Original Message itself may contain any MIME structure.
The Original Message itself may contain any defined MIME structure.
There may also be an additional MIME layer with Media-Type
There may also be an additional MIME layer with media type
"multipart/mixed" in the Outer Message Body to contain the Inner
Message (as "message/RFC822") along with other MIME part(s).
Message (wrapped in a "message/RFC822") along with other MIME
part(s).
4.1.1.2. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory
4.1.1.1. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory
Hole")
Hole") {#option-ex-memory-hole}
An alternative Option (based on the former autocrypt "Memory Hole"
approach) to be considered, is described in
[I-D.autocrypt-lamps-protected-headers].
That option emphasizes backward compatibility challenges to existing
Mail User Agents (MUAs) that do encryption, but are unaware of Header
Protection as specified herein (see also Section 4.2).
Unlike the option described in Section 4.1.1.1, this option does not
use a "message/RFC822" wrapper to unambigously delimit the Inner
Message.
That option suggests to use the media type "text/plain" to contain
the Inner Message (as opposed to "message/RFC822", cf.
Section 4.1.1). For MUA implementers rendering those messages, that
approach might become problematic implementation-wise once the
Content of "text/plain" needs to be parsed (as media type "text/
plain" is defined as unstructured text).
The MIME structure of an Email message looks as follows:
Regarding MIME type "message/RFC822" [RFC2046] specifies:
<Outer Message Header Section (unprotected)>
Plain text does not provide for or allow formatting commands, font
attribute specifications, processing instructions, interpretation
directives, or content markup. Plain text is seen simply as a
linear sequence of characters, possibly interrupted by line breaks
or page breaks"
<Outer Message Body (protected)>
Existing MIME parsers and libraries and/or MUAs implemented according
to [RFC2046] will need to be changed to implement the option
described in [I-D.autocrypt-lamps-protected-headers], as that option
differs from the current MIME Standard (cf. [RFC2046]).
<Inner Message Header Section>
The impact of using "text/plain", while in fact containing a (subset
of a) "message/RFC822" media type to be parsed, is for further study
concerning MIME standards and real world deployments.
<Inner Message Body>
For further information, the reader is encouraged to consult
[I-D.autocrypt-lamps-protected-headers].
The following example demonstrates how header section and payload of
a protect body part might look like. For example, this will be the
first body part of a multipart/signed message or the signed and/or
encrypted payload of the application/pkcs7-mime body part. Lines
prepended by "O: " are the outer header section. Lines prepended by
"I: " are the inner header section.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 10]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 11]
Internet-Draft Header Protection S/MIME June 2020
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
O: Subject: Meeting at my place
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
O: MIME-Version: 1.0
O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
O: protocol="application/pkcs7-signature";
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
This is a multipart message in MIME format.
--.cbe16d2a-e1a3-4220-b821-38348fc97237
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
I: MIME-Version: 1.0
I: MMHS-Primary-Precedence: 3
I: Subject: Meeting at my place
I: To: somebody@example.net
I: X-Mailer: Isode Harrier Web Server
I: Content-Type: text/plain; charset=us-ascii
This is an important message that I don't want to be modified.
--.cbe16d2a-e1a3-4220-b821-38348fc97237
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature
[[base-64 encoded signature]]
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
The Outer Message Header Section is unprotected, while the remainder
(Outer Message Body) is protected. The Outer Message Body consists
of the Inner Message (Header Section and Body).
The Inner Message Header Section is the same as (or a subset of) the
Original Message Header Section (cf. Section 4.1.2).
The Inner Message Body is the same as the Original Message Body.
The Original Message itself may contain any MIME structure.
There may also be an additional MIME layer with media type
"multipart/mixed" in the Outer Message Body to contain the Inner
Message along with other MIME part(s).
Hoeneisen & Melnikov Expires December 28, 2020 [Page 12]
Internet-Draft Header Protection S/MIME June 2020
@ -575,12 +687,16 @@ Internet-Draft Header Protection S/MIME June 2020
Appendix A.1). Certain MUAs cannot properly decrypt messages with
Bcc recipients. ]]
In additon, the Inner Message Header Section MUST be preceded by a
MIME Header Section with media type "message/RFC822" that SHOULD
contain the Content-Type header field parameter "forwarded=no" as
defined in [I-D.melnikov-iana-reg-forwarded].
4.1.3. Wrapper
The wrapper is a simple MIME Header Section followed by an empty line
preceding the Inner Message (inside the Outer Message Body). The
media type of the wrapper MUST be "message/RFC822" and SHOULD contain
the Content-Type header field parameter "forwarded=no" as defined in
[I-D.melnikov-iana-reg-forwarded]. The wrapper delimits unambigously
the Inner Message from the rest of the message.
4.1.3. Outer Message Header Fields
4.1.4. Outer Message Header Fields
To maximize Privacy, it is strongly RECOMMENDED to follow the
principle of Data Minimization (cf. Section 2.1).
@ -599,25 +715,25 @@ Internet-Draft Header Protection S/MIME June 2020
o Cc (if present in the OrigM)
o Bcc (if present in the OrigM, see also Section 4.1.3 and
o Bcc (if present in the OrigM, see also Section 4.1.2 and
Appendix A.1)
o Date
o Message-ID
o Subject
Some of these Header Fields are needed by the Transport (e.g. to
determine the destination). Furthermore, not including certain
Hoeneisen & Melnikov Expires December 28, 2020 [Page 11]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 13]
Internet-Draft Header Protection S/MIME June 2020
o Subject
Some of these Header Fields are needed by the Transport (e.g. to
determine the destination). Furthermore, not including certain
Header Fields may trigger spam detection to flag the message as spam
and/or lead to user experience (UX) issues.
@ -626,10 +742,8 @@ Internet-Draft Header Protection S/MIME June 2020
Header Fields MAY be obfuscated. Further Header Fields MAY be
obfuscated, though simply not adding those to the Outer Message
Header SHOULD be prefered over obfuscation. Header Field obfuscation
is further specified in Section 4.1.3.1.
Header Fields not obfuscated SHOULD contain the same values as in the
Original Message.
is further specified in Section 4.1.4.1. Header Fields not
obfuscated SHOULD contain the same values as in the Original Message.
The MIME Header Section part is the collection of MIME Header Fields
describing the following MIME structure as defined in [RFC2045]. A
@ -667,14 +781,12 @@ Internet-Draft Header Protection S/MIME June 2020
Hoeneisen & Melnikov Expires December 28, 2020 [Page 12]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 14]
Internet-Draft Header Protection S/MIME June 2020
4.1.3.1. Obfuscation of Outer Message Header Fields
4.1.4.1. Obfuscation of Outer Message Header Fields
If the values of the following Outer Message Header Fields are
obfuscated, those SHOULD assume the following values:
@ -700,7 +812,7 @@ Internet-Draft Header Protection S/MIME June 2020
Note: It is for further study to what extent Header Field obfuscation
(adversely) impacts spam filtering.
4.1.4. Message Processing
4.1.5. Message Processing
The Following figure depicts the different message representations
(OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
@ -725,38 +837,35 @@ Internet-Draft Header Protection S/MIME June 2020
Hoeneisen & Melnikov Expires December 28, 2020 [Page 13]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 15]
Internet-Draft Header Protection S/MIME June 2020
OrigM InnerM Outer(S) OuterM(R) RUFM
<Trans-HF> > <Trans-HF>
From (OrigM) = From
To (OrigM) = To
Cc (OrigM) = Cc
Bcc (OrigM) = Bcc (*) > Bcc
Date (OrigM) = Date
Message-ID = Message-ID
(OrigM)
Subject (new) = Subject
<MIME-HSp> (new) = <MIME-HSp>
OrigM InnerM Outer(S) OuterM(R) RUFM
PROTECTED: PROTECTED:
<MIME-HS> > <MIME-HS> = <MIME-HS>
(new)
<Trans-HF> > <Trans-HF>
From (OrigM) = From
To (OrigM) = To
Cc (OrigM) = Cc
Bcc (OrigM) = Bcc (*) > Bcc
Date (OrigM) = Date
Message-ID (OrigM)= Message-ID
Subject (new) = Subject
<MIME-HSp> (new) = <MIME-HSp>
From > From > From = From > From
To > To > To = To > To
Cc (*) > Cc > Cc = Cc > Cc
PROTECTED: PROTECTED:
<Wrapper> (new) = <Wrapper>
From > From > From = From > From
To > To > To = To > To
Cc (*) > Cc > Cc = Cc > Cc
Bcc (*)
Date > Date > Date = Date > Date
Message-ID > Message-ID > Message-ID = Message-ID > Message-ID
Subject > Subject > Subject = Subject > Subject
<More HF> > <More HF> > <More HF> = <More HF> > <More-HF>
<MIME-HSp> > <MIME-HSp> > <MIME-HSp> = <MIME-HSp> > <MIME-HSp>
<Body> > <Body> > <Body> = <Body> > <Body>
Date > Date > Date = Date > Date
Message-ID > Message-ID > Message-ID = Message-ID > Message-ID
Subject > Subject > Subject = Subject > Subject
<More HF> > <More HF> > <More HF> = <More HF> > <More-HF>
<MIME-HSp> > <MIME-HSp> > <MIME-HSp> = <MIME-HSp> > <MIME-HSp>
<Body> > <Body> > <Body> = <Body> > <Body>
Legend:
@ -774,14 +883,17 @@ Internet-Draft Header Protection S/MIME June 2020
o More-HF: Additional Header Fields (HF) in the Original Message
(OrigM)
o MIME-HS: MIME Header Section; with media type (message/RFC822)
o Wrapper: MIME Header Section; with media type (message/RFC822) to
unambigously delimit the inner message from the rest of the
message.
o MIME-HSp: MIME Header Section part
o MIME-HSp: MIME Header Section part to describe the encryption or
signature as per [RFC8551]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 14]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 16]
Internet-Draft Header Protection S/MIME June 2020
@ -799,15 +911,15 @@ Internet-Draft Header Protection S/MIME June 2020
taken over nor propagated.
o '(new)' / '(OrigM)': HF or MIME-HSp is generated depending on the
decision in Section 4.1.4.1.1, while '(new)' / '(OrigM)' designate
decision in Section 4.1.5.1.1, while '(new)' / '(OrigM)' designate
the default.
4.1.4.1. Sending Side
4.1.5.1. Sending Side
For a protected message the following steps are applied before a
message can be handed over to the Transport:
message is handed over to the Transport:
4.1.4.1.1. Step 1: Decide on Protection Level and Information
4.1.5.1.1. Step 1: Decide on Protection Level and Information
Disclosure
The entity applying protection to a message must decide:
@ -819,56 +931,54 @@ Internet-Draft Header Protection S/MIME June 2020
o Which Header Fields of the Orignial Message shall be part of the
Outer Message Header Section? This typically depends on local
policy. By default the Essential Header Fields are part of the
Outer Message Header Section (in addition to the MIME Header
Section part); cf. Section 4.1.3.
Outer Message Header Section; cf. Section 4.1.4.
o Which of these Header Fields are to be obfuscated? This depends
on local policy and/or specific Privacy requirements of the user.
By default only the Subject Header Field is obfuscated; cf.
Section 4.1.3.1.
Section 4.1.4.1.
4.1.4.1.2. Step 2: Compose the Outer Message Header Section
4.1.5.1.2. Step 2: Compose the Outer Message Header Section
Depending on the decision in Section 4.1.4.1.1, compose the Outer
Depending on the decision in Section 4.1.5.1.1, compose the Outer
Message Header Section. (Note that this also includes the necessary
MIME Header Section part for the following protection layer.)
Outer Header Fields that are not obfuscated SHOULD contain the same
values as in the Original Message (except for MIME Header
Hoeneisen & Melnikov Expires December 28, 2020 [Page 15]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 17]
Internet-Draft Header Protection S/MIME June 2020
Outer Header Fields that are not obfuscated SHOULD contain the same
values as in the Original Message (except for MIME Header
Section part, which depends on the protection level selected in
Section 4.1.4.1.1).
Section 4.1.5.1.1).
4.1.4.1.3. Step 3: Apply Protection to the Original Message
4.1.5.1.3. Step 3: Apply Protection to the Original Message
Depending on the protection level in selected in Section 4.1.4.1.1
apply signature and/or encryption to the original message (as per
[RFC8551]) and include the result to the message as Outer Message
Body.
Depending on the protection level selected in Section 4.1.5.1.1 apply
signature and/or encryption to the original message including the
wrapper (as per [RFC8551]) and put the result to the message as Outer
Message Body.
The resulting (Outer) Message is then typically handed over to the
Transport.
[[ TODO: Example ]]
4.1.4.2. Receiving Side
4.1.5.2. Receiving Side
When a protected message is received the following steps are applied:
4.1.4.2.1. Step 1: Decrypt message and/or check signature
4.1.5.2.1. Step 1: Decrypt message and/or check signature
Depending on the protection level the received message is decrypted
and/or its signature is checked as per [RFC8551].
4.1.4.2.2. Step 2: Construct the Receiving User Facing Message
4.1.5.2.2. Step 2: Construct the Receiving User Facing Message
The Receiving User Facing Message is constructed as follows:
@ -893,7 +1003,9 @@ Internet-Draft Header Protection S/MIME June 2020
Hoeneisen & Melnikov Expires December 28, 2020 [Page 16]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 18]
Internet-Draft Header Protection S/MIME June 2020
@ -949,7 +1061,7 @@ Internet-Draft Header Protection S/MIME June 2020
Hoeneisen & Melnikov Expires December 28, 2020 [Page 17]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 19]
Internet-Draft Header Protection S/MIME June 2020
@ -969,11 +1081,6 @@ Internet-Draft Header Protection S/MIME June 2020
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
@ -1001,20 +1108,20 @@ Internet-Draft Header Protection S/MIME June 2020
melnikov-iana-reg-forwarded-00 (work in progress),
November 2019.
[I-D.pep-email]
Marques, H., "pretty Easy privacy (pEp): Email Formats and
Protocols", draft-marques-pep-email-02 (work in progress),
October 2018.
Hoeneisen & Melnikov Expires December 28, 2020 [Page 18]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 20]
Internet-Draft Header Protection S/MIME June 2020
[I-D.pep-email]
Marques, H., "pretty Easy privacy (pEp): Email Formats and
Protocols", draft-marques-pep-email-02 (work in progress),
October 2018.
[pEp.mixnet]
pEp Foundation, "Mixnet", June 2020,
<https://dev.pep.foundation/Mixnet>.
@ -1058,17 +1165,19 @@ A.1. Stored Variants of Messages with Bcc
fields, which must not include the Bcc header field neither for
signature calculation nor for encryption.
2. The message(s) sent to the recipient addresses in the Bcc header
field, which depends on the implementation:
Hoeneisen & Melnikov Expires December 28, 2020 [Page 19]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 21]
Internet-Draft Header Protection S/MIME June 2020
2. The message(s) sent to the recipient addresses in the Bcc header
field, which depends on the implementation:
a) One message for each recipient in the Bcc header field
separately with a Bcc header field containing only the address of
the recipient it is sent to
@ -1100,24 +1209,27 @@ Appendix C. Open Issues
before publication. ]]
o Decide on format of obfuscated HFs, in particular Date HF
(Section 4.1.3.1)
(Section 4.1.4.1)
o Impact on spam filtering, if HFs are obfuscated (Section 4.1.3.1)
o Impact on spam filtering, if HFs are obfuscated (Section 4.1.4.1)
o More examples (e.g. in Section 4.1.4)
o More examples (e.g. in Section 4.1.5)
o Should Outer Message Header Section (as received) be preserved for
the user? (Section 4.1.4.2.2)
the user? (Section 4.1.5.2.2)
o Do we need to take special care of HFs that may appear multiple
times, e.g. Received HF? (Section 4.1.4.2.2)
times, e.g. Received HF? (Section 4.1.5.2.2)
o Change adding Content-Type header field parameter "forwarded" from
SHOULD to MUST (Section 4.1.1)?
SHOULD to MUST (Section 4.1.3)?
Hoeneisen & Melnikov Expires December 28, 2020 [Page 20]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 22]
Internet-Draft Header Protection S/MIME June 2020
@ -1173,4 +1285,4 @@ Authors' Addresses
Hoeneisen & Melnikov Expires December 28, 2020 [Page 21]
Hoeneisen & Melnikov Expires December 28, 2020 [Page 23]

Loading…
Cancel
Save