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
