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] In order to expand "PGP" (and to match the companion document), we included "(Pretty Good Privacy with MIME)" as follows per RFC 3156. Please let us know of any objections. Original: E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME ([RFC3156]) cryptographic standards can provide integrity, authentication and confidentiality to MIME ([RFC4289]) e-mail messages. Current: End-to-end email security using S/MIME [RFC8551] and PGP/MIME (Pretty Good Privacy with MIME) [RFC3156] cryptographic standards can provide integrity, authentication, and confidentiality to MIME [RFC4289] email messages. --> 3) <!--[rfced] FYI - To clarify the citation, we updated the sentence below as follows. Please let us know of any objections. Original: For example, [EFAIL]'s "Direct Exfiltration" attack leaks cleartext due to an attack that splices existing ciphertext into a new message, which is then handled optimistically (and wrongly) by many mail user agents. Current: For example, as described in [EFAIL], the "Direct Exfiltration" attack leaks cleartext due to an attack that splices existing ciphertext into a new message, which is then handled optimistically (and wrongly) by many mail user agents. --> 4) <!--[rfced] Would you like to move the 2119 key words paragraph under "Terminology" (Section 1.1) or move the paragraph under its own section (which would be named "Requirements Language" and would become Section 1.1)? Please let us know your preference. --> 5) <!--[rfced] Since the list of header fields in Section 1.1.2 contains more than five fields, may we update "only a handful" to "only a small amount" or other for conciseness? Original: Of all the header fields that an e-mail message may contain, only a handful are typically presented directly to the user. Perhaps: Of all the header fields that an email message may contain, only a small amount are typically presented directly to the user. --> 6) <!--[rfced] Should the following parenthetical paragraph 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). Original: (It is of course possible that a message forwarded as a MIME attachment could have its own cryptographic status while still being a message subpart; but that status should be distinct from the status of the enclosing message.) --> 7) <!--[rfced] For consistency with the previous sentence, may we update "end-to-end crypto" to "end-to-end cryptographic protection"? Original: When adding end-to-end cryptographic protection to an e-mail endpoint, care should be taken not to negate any of the distinct features of e-mail as a whole. If these features are violated to provide end-to-end crypto, the user may just as well choose one of the other systems that don't have the drawbacks that e-mail has. Perhaps: When adding end-to-end cryptographic protection to an email endpoint, care should be taken not to negate any of the distinct features of email as a whole. If these features are violated to provide end-to-end cryptographic protection, the user may just as well choose one of the other systems that don't have the drawbacks that email has. --> 8) <!--[rfced] May we rephrase the following text for readability as shown below? Original: Care should be taken that enabling cryptography in an MUA does not inadvertently limit the ability of the user to interact with correspondents who use legacy or non-cryptographic MUAs. Perhaps: Care should be taken when enabling cryptography in an MUA so that the MUA does not inadvertently limit the ability of the user to interact with correspondents who use legacy or non-cryptographic MUAs. --> 9) <!--[rfced] Should "as of 2024" perhaps be updated to "as of 2025"? Original: By analogy, when the user of an MUA first enables end-to-end cryptographic protection, it's likely that they will want to see which messages _have_ protection (that is, the security indicators amenable to a conformant MUA as of 2024 are most likely to be comparable to those of a pre-2018 web browser). --> 10) <!--[rfced] To clarify the text, may we update "usable experience" to "user experience"? Original: It is out of scope for this document to define expectations about protections for any given message, but an implementer who cares about usable experience should be deliberate and judicious about the expectations their interface assumes that the user has in a given context. Perhaps: It is out of scope for this document to define expectations about protections for any given message, but an implementer who cares about user experience should be deliberate and judicious about the expectations their interface assumes that the user has in a given context. --> 11) <!--[rfced] Please clarify the use of the RFC 2119/8174 terminology in the following sentences. Is the intention that "MUST NOT" should be used after the "and" in both sentences? Original: Furthermore, when decrypting an Errant Cryptographic Layer, the MUA MUST treat the decrypted cleartext as a distinct MIME subtree, and not attempt to merge or splice it together with any other part of the message. ... During message rendering, if a conformant MUA attempts decryption of such a non-MIME encrypted section of an e-mail, it MUST synthesize a separate MIME part to contain only the decrypted data, and not attempt to merge or splice that part together with any other part of the message. Perhaps: Furthermore, when decrypting an Errant Cryptographic Layer, the MUA MUST treat the decrypted cleartext as a distinct MIME subtree, and it MUST NOT attempt to merge or splice it together with any other part of the message. ... During message rendering, if a conformant MUA attempts decryption of such a non-MIME encrypted section of an email, it MUST synthesize a separate MIME part to contain only the decrypted data, and it MUST NOT attempt to merge or splice that part together with any other part of the message. --> 12) <!--[rfced] We are having some difficulty understanding how "within the content of a MIME part" relates to the rest of the sentence. How may we clarify the text? Original: For example so-called "PGP Inline" messages typically contain base64-encoded ("ASCII- armored", see Section 6 of [I-D.ietf-openpgp-crypto-refresh-13]) ciphertext, or within the content of a MIME part. Perhaps For example, so-called "PGP Inline" messages typically contain base64-encoded ("ASCII-armored", see Section 6 of [RFC9580]) ciphertext or are within the content of a MIME part. --> 13) <!--[rfced] To improve readability, may we remove "at all" and rephrase the sentences to use "fully"? Original: When encountering what appears to be encrypted data not at a MIME boundary, a conformant MUA MAY decline to decrypt the data at all. ... The receiving MUA MAY decline to decrypt such a message at all. Perhaps: When encountering what appears to be encrypted data not at a MIME boundary, a conformant MUA MAY fully decline to decrypt the data. ... The receiving MUA MAY fully decline to decrypt such a message. --> 14) <!-- [rfced] We note that there are no instances of "Content-Type: message/global" in RFC 5355. Please review and let us know if/how this citation should be updated. Original: An incoming e-mail message may include an attached forwarded message, typically as a MIME subpart with Content-Type: message/rfc822 ([RFC5322]) or Content-Type: message/global ([RFC5355]). --> 15) <!--[rfced] We note that both "conformant rendering MUA" and "conformant composing MUA" are used in the document. Should this phrasing be made consistent? Original: A conformant rendering MUA MUST NOT conflate the cryptographic protections of the forwarded message with the cryptographic protections of the incoming message. ... A conformant rendering MUA MAY render a Cryptographic Summary of the protections afforded to the forwarded message by its own Cryptographic Envelope... ... a conformant composing MUA should consider that multiple parts might be rendered as the Main Body Part when the message is ultimately viewed. --> 16) <!--[rfced] To improve readability, may we update "prefer" to "choose"? Original: An MUA MAY offer the user a mechanism to prefer a particular MIME type within multipart/alternative instead of the last renderable child. Perhaps: An MUA MAY offer the user a mechanism to choose a particular MIME type within multipart/alternative instead of the last renderable child. --> 17) <!--[rfced] To clarify "to avoid possible cross-protocol key misuse", may we update this sentence as follows? Original: A conformant MUA that generates S/MIME certificates for the user MUST generate distinct S/MIME certificates: one for encryption and another for signing, to avoid possible cross-protocol key misuse. Perhaps: A conformant MUA that generates S/MIME certificates for the user MUST also generate distinct S/MIME certificates to avoid possible cross-protocol key misuse: one for encryption and another for signing. --> 18) <!--[rfced] May we expand "certs" to "certificates" in the text below? Original: ...and intermediate certification authority certificates that permit chaining from the end entity certs to widely-accepted trust anchors. ... A future version of this document may describe in more detail how these incoming certs should be handled. ... Such discussion should address privacy concerns: what information leaks to whom when checking peer cert revocations? --> 19) <!--[rfced] May we expand "sysadmin" to "system administrator"? Original: For example, a user who trusts their system administrator not to compromise their MUA may accept secret key material generated by the sysadmin, but probably should not accept secret key material generated by an unaffiliated online web service. Perhaps: For example, a user who trusts their system administrator not to compromise their MUA may accept secret key material generated by the system administrator but probably should not accept secret key material generated by an unaffiliated online web service. --> 20) <!--[rfced] The way that "usable" appears in the sentence below reads awkwardly. May we update it to "efficient" to improve clarity? Original: An MUA that takes active steps to fix any of these problems before they arise is even more usable than just warning, but guidance on how to do active certificate maintenance is beyond scope for this current document (see Appendix A.4.3). Perhaps: An MUA that takes active steps to fix any of these problems before they arise is even more efficient than one that just issues warnings, but guidance on how to do active certificate maintenance is beyond the scope for this current document (see Appendix A.4.3). --> 21) <!--[rfced] May we clarify "simple language" as follows? Original: If the MUA does find any of these issues and chooses to warn the user, it should use one aggregate warning with simple language that the certificates might not be acceptable for other people, and recommend a course of action that the user can take to remedy the problem. Perhaps: If the MUA does find any of these issues and chooses to warn the user, it should use one aggregate warning with simple language that describes how the certificates might not be acceptable for other people and recommend a course of action that the user can take to remedy the problem. --> 22) <!--[rfced] Please clarify if the cryptographic transformation needs to be reapplied "in any attempt to resend the message" as shown below. Original: Furthermore, any attempt to re-send the message needs to also re-apply the cryptographic transformation before sending, or else the message contents will leak upon re-send. Perhaps: Furthermore, in any attempt to resend the message, the cryptographic transformation needs to be reapplied before sending or else the message contents will leak upon resend. --> 23) <!--[rfced] Should this list item be phrased as a question to match the other list items in Section 9.4? Original: * Section 3.6.3 of [RFC5322] describes a set of choices about whether (and how) to populate the Bcc field explicitly on Bcc'ed copies of the message, and in the copy stored in the sender's Sent folder. Perhaps: * Should the Bcc field be populated explicitly on Bcc'ed copies of the message and in the copy stored in the sender's Sent folder? See Section 3.6.3 of [RFC5322] for a set of choices. --> 24) <!-- [rfced] References a) FYI - We have updated this reference to match the information at the provided URL. Please review and let us know if further updates are needed. Original: [AUTOCRYPT] Breitmoser, V., Krekel, H., and D. K. Gillmor, "Autocrypt - Convenient End-to-End Encryption for E-Mail", July 2018, <https://autocrypt.org/>. Current: [AUTOCRYPT] Autocrypt Team, "Autocrypt - Convenient End-to-End Encryption for E-Mail", <https://autocrypt.org/>. b) FYI - We have updated the URL of this reference to point the conference paper rather than the EFAIL homepage. Please review and let us know of any objections. Original: [EFAIL] Poddebniak, D., Dresen, C., Müller, J., Ising, F., Schinzel, S., Friedberger, S., Somorovsky, J., and J. Schwenk, "Efail: breaking S/MIME and OpenPGP email encryption using exfiltration channels", August 2018, <https://efail.de>. Current: [EFAIL] Poddebniak, D., Dresen, C., Müller, J., Ising, F., Schinzel, S., Friedberger, S., Somorovsky, J., and J. Schwenk, "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", Proceedings of the 27th USENIX Security Symposium (USENIX Security 18), pp. 549-566, August 2018, <https://www.usenix.org/conference/usenixsecurity18/ presentation/poddebniak>. c) FYI - We have updated the URL of this reference to point the conference paper rather than the DROWN Attack homepage. Please review and let us know of any objections. Original: [DROWN] Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N., Dankel, M., Steube, J., Valenta, L., Adrian, D., Halderman, J. A., Dukhovni, V., Käsper, E., Cohney, S., Engels, S., Paar, C., and Y. Shavitt, "DROWN: Breaking TLS using SSLv2", March 2016, <https://drownattack.com/>. Current: [DROWN] Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N., Dankel, M., Steube, J., Valenta, L., Adrian, D., Halderman, J. A., Dukhovni, V., Käsper, E., Cohney, S., Engels, S., Paar, C., and Y. Shavitt, "DROWN: Breaking TLS using SSLv2", Proceedings of the 25th USENIX Security Symposium (USENIX Security 16), pp. 689-706, August 2016, <https://drownattack.com/drown-attack-paper.pdf>. --> 25) <!--[rfced] FYI - To conform with the RFC Series, we have removed the Document History section from this document. --> 26) <!-- [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 let us know if any updates are needed for consistency. --> 27) <!--[rfced] We note that the figures in the sections listed below are either misaligned 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. Sections: 4.1.1.1 4.1.2.1 4.1.2.2 6.2.1.1 (second structure) 7.3 (both structures) --> 28) <!-- [rfced] Abbreviations a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Automatic Certificate Management Environment (ACME) Authenticated Encryption with Associated Data (AEAD) certification authority (CA) Cipher Block Chaining (CBC) Cipher FeedBack (CFB) DomainKeys Identified Mail (DKIM) Elliptic Curve (EC) JSON Meta Application Protocol (JMAP) Lightweight Directory Access Protocol (LDAP) Message Authentication Code (MAC) Pretty Good Privacy (PGP) Post Office Protocol (POP) Web Key Directory (WKD) b) How should "SPKI" be expanded? As "Simple Public Key Infrastructure", "SubjectPublicKeyInfo", "Subject Public Key Info", or something else? --> 29) <!--[rfced] Terminology a) We note that there is mixed usage of the following terminology throughout the document. May we update to use the form on the right for consistency? cryptographic envelope > Cryptographic Envelope cryptographic payload > Cryptographic Payload errant Cryptographic Layer vs. errant cryptographic layer > Errant Cryptographic Layer header protection > Header Protection b) 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. Encrypted But Unverified vs. Encrypted but Unverified Public Key vs. public key Unprotected vs. unprotected Encrypted Message vs. encrypted message Signed Message vs. signed message (Note: "unprotected message" is used throughout) Structural Header Fields vs. structural header fields User-Facing Header Fields vs. "user-facing" header field vs. user-facing header field c) FYI - We updated this document to reflect the forms on the right for consistency with the companion document and the RFC Series. Please let us know of any objections. e-mail -> email smartcards -> smart cards d) May we update "mail user agent" to "Mail User Agent (MUA)" on the first mention (in the Abstract) and use "MUA" thereafter (as recommended in the Web Portion of the Style Guide <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)? Additionally, may we make the following update for conciseness? Original: * _MUA_ is short for Mail User Agent; an e-mail client. Perhaps: * The _Mail User Agent (MUA)_ is an email client. --> 30) <!-- [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. In addition, please consider whether "tradition" should be updated for clarity. While the NIST website <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/ nist-technical-series-publications-author-instructions#table1> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. --> Thank you. RFC Editor/ap/kc On May 20, 2025, at 6:06 PM, rfc-edi...@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/rfc9787.xml https://www.rfc-editor.org/authors/rfc9787.html https://www.rfc-editor.org/authors/rfc9787.pdf https://www.rfc-editor.org/authors/rfc9787.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9787-diff.html https://www.rfc-editor.org/authors/rfc9787-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9787-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9787 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9787 (draft-ietf-lamps-e2e-mail-guidance-17) Title : Guidance on End-to-End E-mail Security 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
