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. --> 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]. --> 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. --> 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]. --> 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]) --> 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] --> 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. --> 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). --> 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. --> 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. --> 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 --> 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... --> 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. --> 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. --> 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. --> 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. b) FYI - We removed the blank columns from Tables 2 and 3. 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). 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. --> 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. --> 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. --> 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. 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". 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. --> 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. 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. --> 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 --> 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). --> 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) 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) Mail User Agent (MUA) --> 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 Method Signature vs. Method signature Non-Structural Header Field vs. non-structural Header Field Outer Header Section vs. outer Header Section user-facing vs. User-Facing 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 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. 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"? 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 --> 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 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. --> Thank you. RFC Editor/ap/kc On May 20, 2025, at 6:17 PM, RFC Editor via auth48archive <auth48archive@rfc-editor.org> wrote: *****IMPORTANT***** Updated 2025/05/20 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9788.xml https://www.rfc-editor.org/authors/rfc9788.html https://www.rfc-editor.org/authors/rfc9788.pdf https://www.rfc-editor.org/authors/rfc9788.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9788-diff.html https://www.rfc-editor.org/authors/rfc9788-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9788-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9788 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9788 (draft-ietf-lamps-header-protection-25) Title : Header Protection for Cryptographically Protected E-mail Author(s) : D. Gillmor, B. Hoeneisen, A. Melnikov WG Chair(s) : Russ Housley, Tim Hollebeek Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
