Browse Source

added remark regarding Bcc (appendix)

master
Bernie Hoeneisen 2 years ago
parent
commit
54335017be
2 changed files with 13 additions and 12 deletions
  1. +2
    -1
      ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628.html
  2. +11
    -11
      ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628.txt

+ 2
- 1
ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628.html View File

@ -903,7 +903,7 @@ signature.
<a href="#rfc.section.4.1.5.2">4.1.5.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.5.2.p.1">Depending on the decision in <a href="#sending-side-step-1" class="xref">Section 4.1.5.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.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</a>).</p>
<p id="rfc.section.4.1.5.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</a>).</p>
<h1 id="rfc.section.4.1.5.3">
<a href="#rfc.section.4.1.5.3">4.1.5.3.</a> <a href="#sending-side-step-3" id="sending-side-step-3">Step 3: Apply Protection to the Original Message</a>
</h1>
@ -1103,6 +1103,7 @@ Subject &gt; Subject &gt; Subject = Subject &gt; Subject
<li>The message(s) sent to the recipient addresses in the Bcc header field, which depends on the implementation: <br><br> 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 <br><br> b) The same message for each recipient in the Bcc header field with a Bcc header field containing an indication such as &#8220;Undisclosed recipients&#8221; (but no addressees) <br><br> c) The same message for each recipient in the Bcc header field which does not include a Bcc header field (this message is identical to 1. / cf. above)</li>
<li>The message stored in the &#8216;Sent&#8217;-Folder of the sender, which usually contains the Bcc unchanged from the original message, i.e. with all recipient addresses.</li>
</ol>
<p id="rfc.section.A.1.p.3">The most privacy preserving is to standardize 2a, as in the other cases (2b and 2c) information about hidden recipients is revealed via keys. In any case the message has to be cloned and adjusted depending on the recipient.</p>
<h1 id="rfc.appendix.B">
<a href="#rfc.appendix.B">Appendix B.</a> <a href="#document-changelog" id="document-changelog">Document Changelog</a>
</h1>


+ 11
- 11
ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628.txt View File

@ -848,7 +848,7 @@ Internet-Draft Header Protection S/MIME June 2020
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
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.5.1).
@ -1178,6 +1178,11 @@ Hoeneisen & Melnikov Expires December 30, 2020 [Page 21]
Internet-Draft Header Protection S/MIME June 2020
The most privacy preserving is to standardize 2a, as in the other
cases (2b and 2c) information about hidden recipients is revealed via
keys. In any case the message has to be cloned and adjusted
depending on the recipient.
Appendix B. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]]
@ -1221,11 +1226,6 @@ Appendix C. Open Issues
o Enhance Introduction and Problem Statement sections
o Decide on whether or not specification for more legacy HP
requirements should be added to this document
o Improve definitions in Section 3.2
@ -1234,6 +1234,11 @@ Hoeneisen & Melnikov Expires December 30, 2020 [Page 22]
Internet-Draft Header Protection S/MIME June 2020
o Decide on whether or not specification for more legacy HP
requirements should be added to this document
o Improve definitions in Section 3.2
o Privacy Considerations Section 6
o Security Considerations Section 5
@ -1274,11 +1279,6 @@ Authors' Addresses


Loading…
Cancel
Save