@ -800,7 +800,7 @@ Internet-Draft Header Protection S/MIME June 2020
same week. ]]
In certain implementations also the From, To, and/or Cc Header Field
MAY be obfucated. Those may be replaced by e.g.
MAY be obfucated. [KRB: "obfuscated". Please fix all instances.] Those may be replaced by e.g.
o To: Obfuscated anonymous@anonymous.invalid [1]
@ -808,10 +808,10 @@ Internet-Draft Header Protection S/MIME June 2020
these Header Fields in clear text and is capable of processing those.
A use case for obfuscation of all Outer Message Header Fields is
mixnet netwerks, i.e. "onion routing" for email (e.g.[pEp.mixnet]).
mixnet netwerks [KRB: "networks". Please fix all instances.], i.e. "onion routing" for email (e.g.[pEp.mixnet]).
Note: It is for further study to what extent Header Field obfuscation
(adversely) impacts spam filtering.
(adversely) impacts spam filtering. [KRB: suggest "Further studies of the impact that Header Field obfuscation has on spam filtering are needed." If adversely is in parentheses, it implies that some impacts may be positive. Not sure if that's the intent of your statement, here.]
4.1.5. Receiving User Facing Message Header Fields
@ -892,6 +892,8 @@ Internet-Draft Header Protection S/MIME June 2020
o MIME-HSp: MIME Header Section part to describe the encryption or
signature as per [RFC8551]
[KRB: You may wish to consider putting this before the example diagram.]
Hoeneisen & Melnikov Expires December 30, 2020 [Page 16]
@ -928,7 +930,7 @@ Internet-Draft Header Protection S/MIME June 2020
the message? This depends on user request and/or local policy as
well as availability of cryptographic keys.
o Which Header Fields of the Orignial Message shall be part of the
o Which Header Fields of the Orignial [KRB: "Original". Please fix all instances.] 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. Section 4.1.4.
@ -960,9 +962,9 @@ Internet-Draft Header Protection S/MIME June 2020
4.1.7.3. Step 3: Apply Protection to the Original Message
Depending on the Protection Level selected in Section 4.1.7.1 apply
signature and/or encryption to the Original Message including the
wrapper (as per [RFC8551]) and set the result to the message as Outer
Depending on the Protection Level selected in Section 4.1.7.1 [KRB: add comma here] apply
signature and/or encryption to the Original Message [KRB: add comma here] including the
wrapper (as per [RFC8551]) [KRB: add comma here] and set the result to the message as Outer
Message Body.
The resulting (Outer) Message is then typically handed over to the
@ -972,11 +974,11 @@ Internet-Draft Header Protection S/MIME June 2020
4.1.8. Receiving Side Message Processing
When a protected message is received the following steps are applied:
When a protected message is received [KRB: add comma here] the following steps are applied:
Depending on the protection level the received message is decrypted
Depending on the protection level [KRB: add comma here] the received message is decrypted
and/or its signature is checked as per [RFC8551].
4.1.8.2. Step 2: Construct the Receiving User Facing Message
@ -985,23 +987,23 @@ Internet-Draft Header Protection S/MIME June 2020
Section 4.1.5.
The resulting message is handed over for further processing, which
typically involves rendering it to the user.
typically involves rendering it to [KRB: "to" -> "for"] the user.
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.
for the user. [KRB: suggest "Further study is needed to determine whether or not the Outer Message Header Section as received from the Transport is preserved for the user, and if so, how this is to be achieved."]
4.2. Backward Compatibility Use Case
[I-D.autocrypt-lamps-protected-headers] describes a possibility to
[I-D.autocrypt-lamps-protected-headers] describes a possibility [KRB: suggest "possible way"] to
achieve backward compatibility with existing S/MIME (and PGP/MIME)
implementations unaware of this specification (Legacy Display). It
implementations unaware of this specification (Legacy Display). [KRB: This reads really awkwardly. Suggest "created prior to this specification"] It
mainly focuses on email clients that do not render emails using
header protection (nicely) and may confuse the user. While this has
header protection (nicely) [KRB: What do you mean by "nicely"? Do you mean that they do not render these particular emails in a user-friendly manner?] and may confuse the user. While this has
been observed occasionally in PGP/MIME (cf. [RFC3156]), the extent
of this problem with S/MIME implementations is still unclear. (Note:
At this time, none of the samples in
[I-D.autocrypt-lamps-protected-headers] applies header protection as
[I-D.autocrypt-lamps-protected-headers] applies[KRB: "apply"] header protection as
@ -1015,13 +1017,13 @@ Internet-Draft Header Protection S/MIME June 2020
Type "message/RFC822".)
Should serious backward compatibility issues with rendering at the
receiver reveal, the Legacy Display format described in
receiver reveal [KRB: "be discovered"], the Legacy Display format described in
[I-D.autocrypt-lamps-protected-headers] may serve as a basis to
mitigate those (backward compatibility use case).
mitigate those (backward compatibility use case) [KRB: Not sure why the parenthetical is here. I'd just end the sentence with "...as a basis to mitigate those issues."].
Another variant of backward compatibility has been implemented by pEp
[I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has
implemented this for PGP/MIME (but not yet S/MIME).
implemented this for PGP/MIME (but not yet S/MIME) [KRB: This parenthetical should be a regular part of the sentence, i.e., not in parentheses. Add a comma after PGP/MIME.].
5. Security Considerations
@ -1146,7 +1148,7 @@ Internet-Draft Header Protection S/MIME June 2020
[1] mailto:anonymous@anonymous.invalid
Appendix A. Additional information
Appendix A. Additional information [KRB: I've noticed in these lists, you're not ending with a period. Periods should still be used.]
A.1. Stored Variants of Messages with Bcc
@ -1161,16 +1163,16 @@ A.1. Stored Variants of Messages with Bcc
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
separately [KRB: add comma here] with a Bcc header field containing only the address of
the recipient it is sent to [KRB: add period here]
b) The same message for each recipient in the Bcc header field
with a Bcc header field containing an indication such as
"Undisclosed recipients" (but no addressees)
"Undisclosed recipients" (but no addressees) [KRB: Again, not sure why this last part is in parentheses. Get rid of those, add a comma after recipients, and add period at the end of the sentence.]
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)
identical to 1. / cf. above) [KRB: add period here]
@ -1181,11 +1183,11 @@ Internet-Draft Header Protection S/MIME June 2020
3. The message stored in the 'Sent'-Folder of the sender, which
usually contains the Bcc unchanged from the original message,
i.e. with all recipient addresses.
i.e. [KRB: add comma here] with all recipient addresses.
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
The most privacy preserving [KRB: add the word "method"] is to standardize 2a, as in the other
cases (2b and 2c) [KRB: add comma here] information about hidden recipients is revealed via
keys. In any case [KRB: add comma here] the message has to be cloned and adjusted
