Hi Bernie, This is a friendly reminder that we await your review and approval of the updated files. Once we receive your approval, we will move this document forward in the publication process.
— FILES (please refresh) — https://www.rfc-editor.org/authors/rfc9788.xml https://www.rfc-editor.org/authors/rfc9788.txt https://www.rfc-editor.org/authors/rfc9788.html https://www.rfc-editor.org/authors/rfc9788.pdf https://www.rfc-editor.org/authors/rfc9788-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9788-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9788-auth48rfcdiff.html (AUTH48 changes side by side) https://www.rfc-editor.org/authors/rfc9788-lastdiff.html (last version to this one) https://www.rfc-editor.org/authors/rfc9788-lastrfcdiff.html (rfcdiff between last version and this) Please see the AUTH48 status page for this document here: https://www.rfc-editor.org/auth48/rfc9788 Thank you, RFC Editor/ap > On Jul 30, 2025, at 11:21 AM, Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > > Hi Roman, > > Thank you for the follow up. Your approval has been noted: > https://www.rfc-editor.org/auth48/rfc9788 > > Best regards, > RFC Editor/ap > >> On Jul 30, 2025, at 10:33 AM, Roman Danyliw <r...@cert.org> wrote: >> >> Hi Alanna! >> >> Having heard no objections to the new normative language per >> https://mailarchive.ietf.org/arch/msg/spasm/qDR0QqnPphZhTJGcN-zVuNwu8rc/, I >> approve the changes to this document. >> >> Roman >> >> -----Original Message----- >> From: Roman Danyliw >> Sent: Thursday, July 17, 2025 1:09 PM >> To: Alanna Paloma <apal...@staff.rfc-editor.org> >> Cc: Daniel Kahn Gillmor <d...@fifthhorseman.net>; Bernie Hoeneisen >> <ber...@ietf.hoeneisen.ch>; Alexey Melnikov <alexey.melni...@isode.com>; >> rfc-edi...@rfc-editor.org; lamps-...@ietf.org; lamps-cha...@ietf.org; Russ >> Housley <hous...@vigilsec.com>; auth48archive <auth48archive@rfc-editor.org> >> Subject: RE: [AD] AUTH48: RFC-to-be 9788 >> <draft-ietf-lamps-header-protection-25> for your review >> >> For situational awareness, I've reached out to the LAMPS WG to confirm there >> are no objections to the introduction of new normative language with the >> keywords in Section 10.*. I'll respond on Tuesday, July 29 with the way >> ahead after this call for input closes. >> >> Roman >> >> -----Original Message----- >> From: Alanna Paloma <apal...@staff.rfc-editor.org> >> Sent: Wednesday, July 16, 2025 3:07 PM >> To: Roman Danyliw <r...@cert.org> >> Cc: Daniel Kahn Gillmor <d...@fifthhorseman.net>; Bernie Hoeneisen >> <ber...@ietf.hoeneisen.ch>; Alexey Melnikov <alexey.melni...@isode.com>; >> rfc-edi...@rfc-editor.org; lamps-...@ietf.org; lamps-cha...@ietf.org; Russ >> Housley <hous...@vigilsec.com>; auth48archive <auth48archive@rfc-editor.org> >> Subject: Re: [AD] AUTH48: RFC-to-be 9788 >> <draft-ietf-lamps-header-protection-25> for your review >> >> Warning: External Sender - do not click links or open attachments unless you >> recognize the sender and know the content is safe. >> >> >> Hi Roman, >> >> Apologies for that! The link should be working now. >> >> https://www.rfc-editor.org/authors/rfc9788-ad-diff.html >> >> RFC Editor/ap >> >>> On Jul 16, 2025, at 10:49 AM, Roman Danyliw <r...@cert.org> wrote: >>> >>> Hi! >>> >>> I was trying to review the diff but >>> https://www.rfc-editor.org/authors/rfc9788-ad-diff.html returned a 404 >>> error? Should I look elsewhere, or is there a glitch? >>> >>> Roman >>> >>> -----Original Message----- >>> From: Alanna Paloma <apal...@staff.rfc-editor.org> >>> Sent: Wednesday, July 16, 2025 1:07 PM >>> To: Roman Danyliw <r...@cert.org>; Daniel Kahn Gillmor >>> <d...@fifthhorseman.net>; Bernie Hoeneisen <ber...@ietf.hoeneisen.ch>; >>> Alexey Melnikov <alexey.melni...@isode.com> >>> Cc: rfc-edi...@rfc-editor.org; lamps-...@ietf.org; >>> lamps-cha...@ietf.org; Russ Housley <hous...@vigilsec.com>; >>> auth48archive <auth48archive@rfc-editor.org> >>> Subject: Re: [AD] AUTH48: RFC-to-be 9788 >>> <draft-ietf-lamps-header-protection-25> for your review >>> >>> Warning: External Sender - do not click links or open attachments unless >>> you recognize the sender and know the content is safe. >>> >>> >>> Hi Authors and Roman*, >>> >>> *Roman - As the AD, please review and approve the following changes: >>> - Section 1.2: added text >>> - Section 1.4: added text >>> - Section 4.2: updated text >>> - Section 5.2.1: deleted text >>> - Section 6.1: updated text (including removal of keyword “MUST”) >>> - Section 6.1.1: added section with new text >>> - Section 6.1.2: added and updated text >>> - Section 7.1: added text >>> - Section 10.1: updated text >>> - Section 10.2: added keywords “MUST” and “MUST NOT” >>> - Section 10.3: added keywords “SHOULD” and “MUST” >>> - Section 10.4: added text >>> >>> See this diff file for the changes: >>> https://www.rfc-editor.org/authors/rfc9788-ad-diff.html >>> >>> >>> Authors - Thank you for your reply. We have updated the files as requested. >>> >>>> 1) In Section 1.1 ("Update to RFC 8551"), the rendered plain text >>>> version of the document appears to split "message/rfc822" across two >>>> lines, with the line break coming immediately after the "/" (U+002F >>>> SOLIDUS). The authors would prefer it if there was no line break in >>>> that string, but we don't know how to coax that behavior out of the >>>> XML input format. (there is no problem in the HTML output, but the >>>> PDF output may also have the same problem) Can you help us fix this? >>> >>> ) We have fixed this issue. >>> >>>> 2) In the course of the review, we realized that the document uses >>>> the terms "send" and "compose" somewhat interchangably, and likewise >>>> also "receive" and "render" somewhat interchangeably. While we >>>> think the XML included here is understandable as-is, we think it >>>> might be cleaner to try to use use "compose" more regularly for the >>>> message generation side and "render" more regularly for the message >>>> interpretation side. We have prepared an additional update to the >>>> XML that applies this change, but it's a fairly large change >>>> size-wise, since "send" and "receive" are relatively common words in >>>> the document. If you think our using "compose" and "render" more >>>> consistently throughout the document (instead of "send" and >>>> "receive") is worthwhile, please let us know. I can send you a >>>> version of the XML with that change applied as well. If you're OK >>>> with it as-is, we can live with it as-is too. >>> >>> ) As the text seems understandable and clear enough to readers as-is, we >>> defer to your preference if you would like “send”/“compose” and >>> “receive”/“render” to be made more consistent throughout the document. >>> Since you already made those updates in another XML file, we can easily >>> update the other document files to match if you do choose to make these >>> changes. >>> >>>> 3) Finally, the MIME structure diagram misalignment in PDF that we >>>> are wrestling with in RFC-to-be 9787 also appears to apply to this draft. >>>> With the recent changes to xml2rfc >>>> (https://github.com/ietf-tools/xml2rfc/pull/1261) i think we can >>>> resolve this by switching to an entirely BOX DRAWINGS approach, as >>>> with 9787. Let us know if that's your preference, or if you'd rather >>>> we do something else with those diagrams. >>> >>> ) As DKG’s PR to add Noto Sans Mono >>> (https://github.com/ietf-tools/xml2rfc/pull/1261) has been merged into >>> main, we are awaiting the next release of xml2rfc, which will likely be >>> later this week. To be consistent with 9787, please send us and updated XML >>> with BOX DRAWINGS. >>> >>> --- >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9788.xml >>> https://www.rfc-editor.org/authors/rfc9788.txt >>> https://www.rfc-editor.org/authors/rfc9788.html >>> https://www.rfc-editor.org/authors/rfc9788.pdf >>> >>> The relevant diff files have been posted here: >>> https://www.rfc-editor.org/authors/rfc9788-diff.html (comprehensive >>> diff) https://www.rfc-editor.org/authors/rfc9788-auth48diff.html >>> (AUTH48 changes) >>> https://www.rfc-editor.org/authors/rfc9788-auth48rfcdiff.html (AUTH48 >>> changes side by side) >>> https://www.rfc-editor.org/authors/rfc9788-lastdiff.html (last version >>> to this one) >>> https://www.rfc-editor.org/authors/rfc9788-lastrfcdiff.html (rfcdiff >>> between last version and this) >>> >>> We will await the updated XML file as well as approvals from Bernie and >>> *Roman. >>> >>> Please see the AUTH48 status page for this document here: >>> https://www.rfc-editor.org/auth48/rfc9788 >>> >>> Thank you, >>> RFC Editor/ap >>> >>>> On Jul 15, 2025, at 1:14 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net> >>>> wrote: >>>> >>>> Hi RFC Editors, all-- >>>> >>>> Attached is the updated XML that contains resolutions to all the >>>> issues that Bernie raised in his AUTH48 review. >>>> >>>> Bernie and Alexey and myself jointly considered the points he raised, >>>> and workshopped these fixes. We have consensus among the authors >>>> that they are all net improvements to the document, though we are >>>> happy to get feedback from the RFC Editor or the responsible AD (Hi, >>>> Roman!) if you'd prefer something different. >>>> >>>> This list is more numerous than most AUTH48 review changes i've >>>> participated in, but hopefully they're not too problematic. >>>> >>>> # Substantial Changes >>>> >>>> While the overwhelming majority of the changes are editorial or >>>> clarifications, there are a few places where cleanup resulted in >>>> edits that have some minor substantive changes. Please let us know >>>> if any of these are a problem. They are: >>>> >>>> ## Security Guidance on Applying the `hp` Parameter >>>> >>>> Section 10.2 ("Avoid Cryptographic Summary Confusion from the hp >>>> Parameter") has been tightened up to use bcp14 MUST where before it >>>> said >>>> (non-bcp14) "should", effectively requiring the composer to correctly >>>> set `hp="clear"` or `hp="cipher"` depending on whether they are >>>> encrypting or merely signing an end-to-end protected message. This >>>> is necessary for message recipients to be able to reason about the >>>> incoming message in the face of transport agents who might apply >>>> encryption in transit. >>>> >>>> ## Security Guidance on Escaping Legacy Display Elements >>>> >>>> Section 10.3 ("Caution About Composing with Legacy Display Elements") >>>> has been tightened up to use BCP 14 language (MUSTs and SHOULDs) >>>> where before it was looser and more descriptive. This is necessary >>>> because avoiding these steps can create significant security issues, >>>> particularly when replying to a message with a potentially malicious >>>> Subject. >>>> >>>> ## Pseudocode Cleanup >>>> >>>> The two pseudocode algorithms ReferenceHCP and Compose have been >>>> given subtle, mutually reinforcing improvements. The end result of >>>> the changes to the pseudocode is no change at all to the messages >>>> produced by their application. But the cleanup allows Compose to be >>>> simpler and ReferenceHCP to be more explicit about handling different >>>> contexts in which it might be invoked. >>>> >>>> ## IANA Update >>>> >>>> The text describing `hcp_shy` in the IANA table has been improved for >>>> clarity -- this is an editorial cleanup, but we wanted to flag it >>>> specifically as it probably needs to be passed along to IANA. >>>> >>>> # Questions for RFC Editor >>>> >>>> Finally, we have a few questions for the RFC editor about the draft >>>> itself: >>>> >>>> 1) In Section 1.1 ("Update to RFC 8551"), the rendered plain text >>>> version of the document appears to split "message/rfc822" across two >>>> lines, with the line break coming immediately after the "/" (U+002F >>>> SOLIDUS). The authors would prefer it if there was no line break in >>>> that string, but we don't know how to coax that behavior out of the >>>> XML input format. (there is no problem in the HTML output, but the >>>> PDF output may also have the same problem) Can you help us fix this? >>>> >>>> 2) In the course of the review, we realized that the document uses >>>> the terms "send" and "compose" somewhat interchangably, and likewise >>>> also "receive" and "render" somewhat interchangeably. While we >>>> think the XML included here is understandable as-is, we think it >>>> might be cleaner to try to use use "compose" more regularly for the >>>> message generation side and "render" more regularly for the message >>>> interpretation side. We have prepared an additional update to the >>>> XML that applies this change, but it's a fairly large change >>>> size-wise, since "send" and "receive" are relatively common words in >>>> the document. If you think our using "compose" and "render" more >>>> consistently throughout the document (instead of "send" and >>>> "receive") is worthwhile, please let us know. I can send you a >>>> version of the XML with that change applied as well. If you're OK >>>> with it as-is, we can live with it as-is too. >>>> >>>> 3) Finally, the MIME structure diagram misalignment in PDF that we >>>> are wrestling with in RFC-to-be 9787 also appears to apply to this draft. >>>> With the recent changes to xml2rfc >>>> (https://github.com/ietf-tools/xml2rfc/pull/1261) i think we can >>>> resolve this by switching to an entirely BOX DRAWINGS approach, as >>>> with 9787. Let us know if that's your preference, or if you'd rather >>>> we do something else with those diagrams. >>>> >>>> On behalf of the authors, >>>> >>>> --dkg >>>> >>>> >>>> On Thu 2025-07-10 21:55:43 +0200, Bernie Hoeneisen wrote: >>>>> The authors are working together on several issues I run into during >>>>> my >>>>> AUTH48 review. After all issues are resolved, DKG will send you a >>>>> new XML version. This is expected to happen sometime next week. >>>> >>>> <rfc9788.xml> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
