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
