Dear RFC Editor et al.
Inline you can find my answers to your questions. Sometimes I am tagging
my co-authors to have a closer look at the issue in question.
cheers
Bernie
On Tue, 20 May 2025, rfc-edi...@rfc-editor.org wrote:
Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
The following come to my mind (list incomplete):
- Header Protection
- Header Confidentiality Policy
- HCP
- cryptographic email
- email encryption
- encryption
- encrypt
- signature
- sign
- S/MIME
- PGP/MIME
- Legacy Display
- Legacy Display Element
- MIME
- Privacy
2) <!--[rfced] FYI - In the following sentence, we have updated "page 5"
to "Section 2". Please review and let us know of any objections.
Original:
In some cases, some mail user agents cannot render message/rfc822
message subparts at all, in violation of baseline MIME requirements
as defined on page 5 of [RFC2049].
Current:
In some cases, some mail user agents cannot render message/rfc822
message subparts at all, which is in violation of baseline MIME
requirements as defined in Section 2 of [RFC2049].
-->
Should not be an issue. If Alexey agrees, I am fine with this too.
3) <!--[rfced] Should "highest" be added to this sentence to describe the
"extent possible"?
Original:
This document aims for backward compatibility with Legacy MUAs to the
extent possible.
Perhaps:
This document aims for backward compatibility with Legacy MUAs to the
highest extent possible.
-->
I suggest to not to change this (i.e. go with Original), unless my
co-authors really want to.
4) <!--[rfced] To reflect how their usage is described in RFC 8126, we
have updated "key words" to "policies" and "SPECIFICATION
REQUIRED" and "IETF REVIEW" to "Specification Required" and "IETF
Review", respectively (i.e., we capitalized only the first letter
of each word and removed <bcp14> tags around "REQUIRED" in the
XML). Note that all occurrences of these terms have been made
lowercase.
Additionally, may we move this text from the "Requirements Language"
section to the "Terms" section as the first paragraph since these
terms are not key words?
One example
Original:
The key words "SPECIFICATION REQUIRED" and "IETF REVIEW" that appear
in this document when used to describe namespace allocation are to be
interpreted as described in [RFC8126].
Current:
The policies "Specification Required" and "IETF Review" that appear
in this document when used to describe namespace allocation are to be
interpreted as described in [RFC8126].
-->
No objection. Looks sensible to match the new policies.
5) <!--[rfced] To match use in RFC 3156 and the companion document, we
updated the expansion of "PGP/MIME" in the Abstract and Terms
section as follows. Please let us know of any objections.
Original (Abstract):
The Header Protection scheme defined here is also applicable to
messages with PGP/MIME cryptographic protections.
Current:
The Header Protection scheme defined here is also applicable to
messages with PGP/MIME (Pretty Good Privacy with MIME) cryptographic
protections.
...
Original (Section 1.7):
* PGP/MIME: MIME Security with OpenPGP (see [RFC3156])
Current:
* PGP/MIME: Pretty Good Privacy with MIME (see [RFC3156])
-->
No objection.
6) <!--[rfced] FYI - We have moved this text to the end of the Terms section
since
it does not match the definition list formatting of the other terms listed.
Please let us know of any objections.
Original:
* Cryptographic Layer, Cryptographic Payload, Cryptographic
Envelope, Cryptographic Summary, Structural Header Fields, Main
Body Part, User-Facing Header Fields, and MUA are all used as
defined in [I-D.ietf-lamps-e2e-mail-guidance]
Current:
Additionally, Cryptographic Layer, Cryptographic Payload, Cryptographic
Envelope, Cryptographic Summary, Structural Header Fields, Main
Body Part, User-Facing Header Fields, and MUA are all used as
defined in [I-D.ietf-lamps-e2e-mail-guidance]
-->
No objection
7) <!--[rfced] For clarity and consistency, may we update the phrasing of
"Legacy receiving MUA" and "modern receiving clients" as follows?
Original:
The message generation guidance aims to minimize negative
interactions with any Legacy receiving MUA while providing
actionable cryptographic properties for modern receiving
clients.
Perhaps:
The message generation guidance aims to minimize negative
interactions with any Legacy MUA recipient while providing
actionable cryptographic properties for modern client
recipients.
-->
See other mail sent earlier today (in response to Alexey's comments)
8) <!--[rfced] May we update "non-encrypted" to "unencrypted"?
Original:
A sending implementation MUST NOT produce a Cryptographic Payload
with parameter hp="cipher" for a non-encrypted message (that is,
where none of the Cryptographic Layers in the Cryptographic Envelope
of the message provide encryption).
Perhaps:
A sending implementation MUST NOT produce a Cryptographic Payload
with parameter hp="cipher" for an unencrypted message (that is,
where none of the Cryptographic Layers in the Cryptographic Envelope
of the message provide encryption).
-->
No objection.
@DKG?
9) <!--[rfced] To improve readability, we have updated "at all" to "completely"
and reworded the sentence below. Please review and let us know of any
objections.
Original:
The receiving MUA MUST avoid rendering the identified Legacy Display
Elements to the user at all, since it is aware of Header Protection
and can render the actual protected Header Fields.
Current:
The receiving MUA MUST completely avoid rendering the identified Legacy
Display Elements to the user, since it is aware of Header Protection
and can render the actual protected Header Fields.
-->
No objection.
10) <!--[rfced] To make this sentence more concise, may we remove "of the part"?
Original:
* Discard the leading lines of the body of the part up to and
including the first entirely blank line.
Perhaps:
* Discard the leading lines of the body up to and including the
first entirely blank line.
-->
In support of Alexey's suggestions (cf. email from Alexey on May 21):
* Discard the leading lines of the body part up to and
including the first entirely blank line.
11) <!--[rfced] The <artwork> in Sections 5.2.2 and 5.2.3 includes the
following attributes: charset=UTF-8 and hp-legacy-display=1.
Should quotes appear around the "UTF-8" and "1" values in these
instances per other use in the document? And should "UTF-8" be made
lowercase for consistency, or are the lowercase instances different?
Current:
Content-Type: text/plain; charset=UTF-8 vs.
Content-Type: text/plain; charset="utf-8"
Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; vs.
Content-Type: text/plain; charset=UTF-8; hp-legacy-display=1
-->
In support of Alexey's suggestions (cf. email from Alexey on May 21).
12) <!--[rfced] As "Main Body Part" is a term used throughout the document, may
we
update this sentence as shown below?
Original:
The purpose of injecting a Legacy Display Element into each Main Body
MIME part is to enable rendering of otherwise obscured Header Fields
in Legacy MUAs that are capable of message decryption...
Perhaps:
The purpose of injecting a Legacy Display Element into each MIME Main
Body Part is to enable rendering of otherwise obscured Header Fields
in Legacy MUAs that are capable of message decryption...
-->
See other mail (in response to Alexey's comments)
13) <!--[rfced] Is a "mail transport system" the same thing as a "mail transport
agent"? If so, may we update this sentence to use "mail transport agents"
for consistency with the rest of the document?
Original:
In the future, some mail transport systems may accept and deliver
messages with even less publicly visible metadata.
Perhaps:
In the future, some mail transport agents may accept and deliver
messages with even less publicly visible metadata.
-->
In support of Alexey's concerns (cf. email from Alexey on May 21).
14) <!--[rfced] To improve readability, may we update the phrasing of "may not
expect to be injected by their MUA" as follows?
Original:
This can be
especially problematic for Header Fields that are not user-facing,
which the sender may not expect to be injected by their MUA.
Perhaps:
This can be
especially problematic for Header Fields that are not user-facing;
the sender may not expect these Header Fields to be injected by their MUA.
-->
Maybe replace "these" by "such" in your suggestion:
This can be
especially problematic for Header Fields that are not user-facing;
the sender may not expect such Header Fields to be injected by their MUA.
@DKG?
15) <!--[rfced] May we update "genericize" to "generalize"?
Original:
So even if an
ambitious HCP opts to remove the human-readable part from any From
Header Field, and to standardize/genericize the local part of the
From address, the domain will still leak.
Perhaps:
So even if an
ambitious HCP opts to remove the human-readable part from any From
Header Field, and to standardize/generalize the local part of the
From address, the domain will still leak.
-->
No opinion.
@DKG?
16) <!--[rfced] We have included some specific questions about the IANA
text below. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further updates are needed.
a) In Section 12.1, does the "Author/Change Controller" information
only apply to the "HP-Outer" registration? If so, may we update the
text below to reflect "this entry" (instead of "these two entries")
as shown in option A? Or if it also applies to the "Content-Type"
registration, may we move it to the end of Section 12.2 and update
the text as shown in option B?
Original:
The Author/Change Controller of these two entries (Section 4.5 of
[RFC3864]) should be the IETF itself.
Perhaps A:
The Author/Change Controller (Section 4.5 of [RFC3864]) for this
entry is the IETF itself.
Perhaps B:
The Author/Change Controller (Section 4.5 of [RFC3864])
for the HP-Outer and Content-Type Header Field name
registrations is the IETF itself.
To me Option A appears to be the better. (History: At some ealier stage we
had two Header Fields for registration, thus this is most likley a
leftover.)
Furthermore, I suggest to remove the word "itself".
@DKG @Alexey ?
b) FYI - We removed the blank columns from Tables 2 and 3.
Maybe add a note that the columns XX and YY were empty and therefore not
shown in the table, so that the unsavy reader is not confused.
We also removed Table 4 (in Section 12.2) as one table is sufficient to
show the addition of this document as a reference to the "Permanent
Message Header Field Names" registry (see Table 3).
No objection to the removal of Table 4.
However, I suggest the following change:
OLD:
Consequently, this document has been added as a reference for
Content-Type in the "Permanent Message Header Field Names" registry as
shown below.
NEW:
Consequently, IANA has added this document as a reference for
Content-Type in the "Permanent Message Header Field Names" registry as
shown below.
c) We shortened the title of Section 12.2 as the hp and
hp-legacy-display parameters are mentioned in the introductory
sentence. Please let us know of any objections.
Original:
12.2 Update Reference for Content-Type Header Field due to
hp and hp-legacy-display Parameters
Current:
12.2 Reference Update for the Content-Type Header Field
d) FYI - In Section 12.3, we ordered the notes to match the order
in the IANA registry <https://www.iana.org/assignments/mail-parameters/>;
please let us know of any objections.
-->
No objection.
Note: More findings on IANA Registration sections in my earlier emails
today.
17) <!--[rfced] What does "the draft" refer to in the sentence below?
Should this be updated to "the draft message"? Note that there are
other occurrences like the example listed below that are used throughout
the appendices of this document.
Original:
It uses the Header Protection scheme from the draft.
Perhaps:
It uses the Header Protection scheme from the draft message.
-->
I guess you are refering to the occurances in Appendix C.
To my understanding those refer to this document (RFC-to-be 9788).
@DKG?
Note: This text is also part of the autogenerated testvectors (i.e. those
in the grey boxes) in Appedix C, which MUST NOT be changed. This is due to
signature and encryption, i.e. signature and decryption will fail for
those using the test vectors, if edited. (If we wanted to change this, DKG
would need to reproduce the test vectors.)
18) <!--[rfced] FYI - We alphabetized the names listed in the Acknowledgements
section. We believe that was the intent as only two were out of order. Let us
know if you prefer the original order.
-->
Alphabethical order is indeed our policy.
(My mistake, the two were out of order. ;-) )
19) <!-- [rfced] We have some questions/comments regarding artwork and
sourcecode:
a) Please review each artwork element and let us know if any should be marked
as sourcecode (or another element) instead.
How can we find out which artwork element is marked with what?
b) Some artwork elements are marked as type "ascii-art" while others are
not. Please review and let us know if there are any artwork elements you would
like to have marked as "ascii-art".
The only artworks I am aware of are the 3 figures in Appendix D.
c) Since the sourcecode type "text/x-hcp" is not part of the list at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>,
may we update to sourcecode type "pseudocode"? Note that it is also
acceptable to leave the "type" attribute not set.
-->
No opinion.
@DKG?
20) <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is
output
in fixed-width font. In the txt output, there are no changes to the font,
and the quotation marks have been removed.
In the html and pdf outputs, the text enclosed in <em> is output in
italics. In the txt output, the text enclosed in <em> appears with an
underscore before and after.
Please review carefully and let us know if the output is acceptable or if any
updates are needed.
Which sections are affected?
Additionally, we note variances with <tt>, for example, Bcc'ed vs.
<tt>Bcc</tt>'ed. Please review let us know if any updates are needed
for consistency.
-->
Which sections are affected?
21) <!--[rfced] We note that the figures in the sections and appendices
listed below are either misaligned slightly and/or have broken
lines in the PDF output (the html and txt outputs display correctly).
To avoid this issue, please let us know if replacing/redrawing
the non-ASCII characters with ASCII characters is possible
(this is commonly done for structure in YANG trees; see
Section 5 of RFC 9731 as an example). Or if you have a
different solution for a fix, please let us know.
Misaligned:
Section 1.9
Section 4.5.1
Section 4.5.2
Section 4.10.1
Appendices C.3.1-C.3.8
Broken Lines :
Appendix C.1.3
Appendix C.1.5
Appendix C.1.6
Appendix C.1.7
Appendix C.1.8
Appendix C.2.2
Appendix C.2.3
Appendix C.2.4
Appendix C.2.5
Appendix C.2.6
Appendices C.3.9-C.3.17
-->
Would such a change only affect the PDF version?
22) <!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
I am not aware of such notes.
@DKG @Alexey?
23) <!--[rfced] Acronyms
a) FYI - We have added an expansion for the following abbreviation
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
man in the middle (MITM)
nothing found that required changes.
b) For the following terms, both the expansion and the acronym are
used throughout the document. Would you like to use the expansion
upon the first mention and the acronym for the rest of the document
for consistency as recommended in the Web Portion of the Style Guide
<https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>?
Header Confidentiality Policy (HCP)
As this is not a widely used term, at certain places that expansion makes
sense, at other places it can be abbreviated.
What do you think @DKG ?
Mail User Agent (MUA)
Makes sense to me, though no occurance of the expansion found (except the
first one)
24) <!--[rfced] Terminology
a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how
they may be made consistent.
Legacy Message vs. Legacy message
"Legacy Message" is part of "Message", which is defined in section 1.7
(Terms).
I suggest to replace all instances of "message" with "Message" as this
is a defined term in Section 1.7 (Terms)
Method Signature vs. Method signature
"Method signature" appears more sensible to me.
@DKG?
Non-Structural Header Field vs. non-structural Header Field
We define "Structural Header Field" in section 1.7 (Terms) refering to
RFC-to-be 9787. However, Non-Structural Header Field is not explicitely
defined in neither of the documents. Therfore, I suggest:
1) Use "Non-Structural Header Field" throughout the document
2) Add a brief definition for "Non-Structural Header Field" to RFC-to-be
9787, e.g. "Header Field that is not a Structural Header Field" (or alike).
3) add a definition for "Non-Structural Header Field" to Section 1.7 (as
reference to RFC 9787 similar as existing for "Structural Header Field").
@DKG, @Alexey?
Outer Header Section vs. outer Header Section
We use this quite ofter without Defining it properly. Therefore, I
suggest:
1) Use "Outer Header Section" throughout the document
2) Add a definition to section 1.7, e.g. "The unprotected Header Section
that MTAs and MUAs unaware of Header Protection treat as the Header
Section of the Message." (or alike)
@DKG @Alexey?
user-facing vs. User-Facing
Suggest to replace all instances with "User-Facing" as this is a defined
term in Section 1.7 (Terms)
b) As the following terminology appears to be used inconsistently
throughout the document, may we update to use the form on the right?
header protection > Header Protection
Suggest to replace all instances with "Header Protection" as this is a
defined term in Section 1.7 (Terms)
Exceptions: The automatically generated test-vectors (grey boxes in
Appendix C, HTML version), which MUST NOT be changed.
c) In this document, "Header Field" is consistently uppercase; however, it
appears
as "header field" (consistently lowercase) in the companion document as well as
in
RFCs 2045, 3864, 4021, 5322, and 8551. Please let us know if you would like to
make
this term lowercase to match the companion document and referenced RFCs or if
you
would like to leave it as is, which is also acceptable. Note that this document
uses "Header Field" about 451 times and "Header Section" about 42 times.
Keep "Header Field" and "Header Section" throughout the document as these
are defined terms in Section 1.7 (Terms).
d) Please review instances of the term "NULL" used in this document.
Should they instead be "NUL" (that is, referring to the specific
ASCII control code), "null character", or just "null"?
I am not aware that we use "NUL" or "null character" in relation with
ASCII.
@DKG?
Just found a nit:
* Section 5.2.1
OLD:
c. If newval is not null):
NEW:
c. If newval is not null:
e) FYI - We updated the document to reflect the forms on the right for
consistency with the RFC Series and companion document. Please let us
know of any objections.
e-mail -> email
electronic email -> email
-->
No objection
25) <!--[rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether the following should be updated:
- dummy
- man in the middle
- whitespace
supporting Alexey, see other mail (in response to Alexey's comments)
In addition, please consider whether "traditional" should be updated for
clarity.
While the NIST website
<https://web.archive.org/web/20250203031433/https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf>
indicates that this term is potentially biased, it is also ambiguous.
"Traditional" is a subjective term, as it is not the same for everyone.
-->
I do not see a real problem with traditional. What would be the
alternatives? ("legacy" does not work well, as this may create
ambiguities within the document.)
More on consistent use of terms:
* Suggest to replace instances of "body" by "Body", as this is a defined
term in Section 1.7 (Terms). Exceptions: HTML tags and if part of test
vector in appendix C
* Appendix C1
[ Cryptographic Summary ]
OLD:
An MUA implementer can use these messages to verify that the reported
cryptographic summary of the message indicates no header protection.
NEW:
An MUA implementer can use these Messages to verify that the reported
Cryptographic Summary of the Message indicates no Header Protection.
* Section 5.1
[ Structural Header Fields ]
OLD:
As a well-formed MIME tree, origbody already has structural Header
Fields (Content-*) present.
NEW:
As a well-formed MIME tree, origbody already has Structural Header Fields
(Content-*) present.
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
