no objection to these changes.
On Mon, 16 Jun 2025, Daniel Kahn Gillmor wrote:
Hi folks--
On Wed 2025-06-11 18:28:34 -0400, Daniel Kahn Gillmor wrote:
I wanted to address this question about artwork and sourcecode elements
of RFC-to-be-9788:
I haven't heard back from the RFC editor about this cleanup of artwork
and sourcecode, so i haven't sent a followup concerning the
remaining large question about the test vectors.
In preparation for the test vector cleanup, i am sending one additional
update to the xml, which cleans up some of the terminology. Some of
these cleanups revert minor changes that the RFC editor made recently,
which i'll describe in a bit more detail interleaved with changes inline
below. (feel free to ignore those justifications if you're OK with the
updates!)
I'm attaching the cumulatively updated xml file to this message.
I will follow up with fixes/corrections to the test vectors, but i
wanted to separate out these fixes.
OK, here is commentary on some of the more subtle changes:
OLD:
As an example, an MUA that obscures the <tt>Subject</tt> Header Field
by replacing it with the literal string "<tt>[...]</tt>" hides all
Cc'ed recipients and does not offer confidentiality to any other
Header Fields that would be represented as (in pseudocode):
NEW:
As an example, an MUA that obscures the <tt>Subject</tt> Header Field
by replacing it with the literal string "<tt>[...]</tt>", hides all
<tt>Cc</tt>'ed recipients, and does not offer confidentiality to any
other Header Fields would be represented as (in pseudocode):
This example is an MUA that is doing a list of three things, not an MUA
characterized by the first thing it does.
OLD:
printable 7-bit, clean ASCII characters
NEW:
printable 7-bit clean ASCII characters
"7-bit clean" is a single qualifier. it would be "unclean" if bit 8
were non-zero. it is not "7-bit, clean" If you'd prefer to write it
"7-bit-clean", that's also fine. "printable" is itself a distinct
qualifier, which further subsets "7-bit clean" ASCII characters from the
unprintable "7-bit clean" ASCII characters.
OLD:
The receiving MUA will render the message Body, render a selected
subset of Header Fields, and provide a summary of the cryptographic
properties of the message (as described in <xref section="3"
sectionFormat="of" target="RFC9787"/>).
NEW:
The receiving MUA will render the message Body, render a selected
subset of Header Fields, and (as described in <xref section="3"
sectionFormat="of" target="RFC9787"/>) provide a summary of the
cryptographic properties of the message.
Section 3 of RFC 9787-to-be only describes the Cryptographic Summary;
the "OLD" variant of the sentence made it look like that section would
describe the rendering steps as well.
OLD:
Add an additional trailing newline after the resultant text, and
prepend the entire list to the Body of the <tt>text/plain</tt> part.
NEW:
Add an additional trailing newline after the resultant text, and
prepend the entire list to the content of the <tt>text/plain</tt>
part.
(and several similar changes) the RFC Editor has done a good thing by
clearly defining (and capitalizing) Body to refer to the part of an
email message that follows the Header Section. While this is very
similar to an individual MIME part, a MIME part isn't an entire message
on its own, especially in this context. In particular, the MIME part is
a subset of the Body, but it is not itself a Body. So, i've avoided
using the term Body in places where it looks like it might refer to
anything other than the body of a message as a whole.
OLD:
This mitigates against an attack where Mallory gets a copy of an
encrypted message from Alice to Bob and then relays the message to
Bob
NEW:
This mitigates against an attack where Mallory gets a copy of an
encrypted message from Alice to Bob and then replays the message to
Bob
I've changed "relays" back to "replays", as discussed in this e-mail
thread.
OLD:
Specific examples of Header Fields that are meaningful to the user are
commonly added by the transport agents that appear below.
NEW:
Specific examples of Header Fields that are meaningful to the user and
are commonly added by MTAs appear below.
The list is a list of Header Fields that have these properties, not a
list of transport agents. Also, use the established initialism.
OLD:
At some point, when the majority of MUA clients can generate
cryptographically protected messages with Header Protection, it should
be possible to deprecate any cryptographically protected message that
does not have Header Protection.
NEW:
At some point, when the majority of MUA clients that can generate
cryptographically protected messages can do so with Header Protection,
it should be possible to deprecate any cryptographically protected
message that does not have Header Protection.
We don't care about MUAs that don't generate cryptograhically protected
messages at all when we're thinking about how to evolve the
cryptographic e2e email ecosystem. We can enforce Header Protection
for e2e e-mail long before we enforce e2e e-mail itself.
OLD:
If the <tt>From</tt> Header Field was treated like any other protected
Header Field by the receiving MUA, this scheme would enable sender
address spoofing.
NEW:
If the <tt>From</tt> Header Field were treated like any other
protected Header Field by the receiving MUA, this scheme would enable
sender address spoofing.
The use of the subjunctive mood indicates a counterfactual here.
OLD:
Autocrypt Protected Headers
NEW:
"draft-autocrypt" Protected Headers
This reverts a change by the RFC editor: participants in the Autocrypt
project (https://autocrypt.org) (including myself) produced the
referenced draft, but never proceeded to standardization with it, due to
problems discovered on some MUAs. It is not a part of the formal
Autocrypt recommendation, and it would be inappropriate to call this
approach "Autocrypt Protected Headers".
Hope this is helpful! I'll send along the test vector updates shortly.
Regards,
--dkg
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
