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
