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>
