Hi,
As promised, below I am sending the first bath of change requests (more to
follow). Most of these changes are about the explicit destinction "Header
Field" and "Header Section" as requested in the Terms section of this
RFC-to-be. Hope I caught all relevant instances...
Alexey/DKG: Please review all instances, in particular those which I
requested explicitely in a square bracket note!
Furthermore I have a question regarding a minor issue:
- Is it correct, that in the IANA registration section this RFC-to-be has
no square brackets and a space betweeen "RFC" and its number, while
referred RFC do? (In IANA registry, both are external references?) Or
is this simply a typical case that is handled with by IANA in a standard
process?
Example (in section 12.2):
| Content-Type | | MIME | | [RFC4021] and RFC 9788 |
Have a nice weekend!
Best,
Bernie
--
http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology
-------------------------------------------------------------------------
* Section 1.3.
OLD:
Users generally do not understand the distinction between message body and
message header.
NEW:
Ordinary Users generally do not understand the distinction between email
message Body and Header Section.
* Section 1.3.1
OLD:
In some cases, like when a user-visible header like the Subject is
cryptographically hidden, a Legacy MUA will not be able to render or reply
to the message exactly the same way as a conformant MUA would.
NEW:
In some cases, like when a user-visible Header Field like the Subject is
cryptographically hidden, a Legacy MUA will not be able to render or reply
to the message exactly the same way as a conformant MUA would.
* Section 1.4
[not sure, DKG/Alexey to verify]
OLD:
Though not strictly email, similar protections have been in use on Usenet
for the signing and verification of message headers for years.
NEW:
Though not strictly email, similar protections have been in use on Usenet
for the signing and verification of message Header Fields for years.
* Section 3.1
OLD:
This function takes a non-structural Header Field identified by name with
the initial value val_in as arguments and returns a replacement header
value val_out.
NEW:
This function takes a non-structural Header Field identified by name with
the initial value val_in as arguments and returns a replacement Header
Field value val_out.
* Section 4.3.1
[DKG to verify]
OLD:
Abort, v is not a valid value for header h.
NEW:
Abort, v is not a valid value for Header Field h.
* Section 4.7
OLD:
Or the message might be displayed outside of its current thread if the MUA
loses access to a removed References or In-Reply-To header.
NEW:
Or the message might be displayed outside of its current thread if the MUA
loses access to a removed References or In-Reply-To Header Field.
* Section 4.10.2
[DKG, Alexey: Would Header Section (end of the sentence) be more
appropriate?]
OLD:
That is, infer Header Field confidentiality based on the unprotected
headers.
NEW:
That is, infer Header Field confidentiality based on the unprotected
Header Fields.
* 5.2.1
[DKG to verify]
OLD:
Adjust bodypart by inserting a Legacy Display Element header list ldlist
into its content and adding a Content-Type parameter hp-legacy-display
with value 1 (see Section 5.2.2 for text/plain and Section 5.2.3 for
text/html).
NEW:
Adjust bodypart by inserting a Legacy Display Element Header Field list
ldlist into its content and adding a Content-Type parameter
hp-legacy-display with value 1 (see Section 5.2.2 for text/plain and
Section 5.2.3 for text/html).
--
OLD:
If refmsg is not null, respond is not null, and refmsg itself is encrypted
with header protection:
NEW:
If refmsg is not null, respond is not null, and refmsg itself is encrypted
with Header Protection:
* Section 6.1
OLD:
If the Header Field's value is changed by the HCP, then it is applied to
the outside header.
NEW:
If the Header Field's value is changed by the HCP, then it is applied to
the outer Header Section
---
OLD:
If that value is itself different than the protected value, then it is
applied to the outside header. If the value is the same as the protected
value, then it is simply copied to the outside header directly.
NEW:
If that value is itself different than the protected value, then it is
applied to the outer Header Section. If the value is the same as the
protected value, then it is simply copied to the outer Header Section
directly.
* Section 6.1.1
OLD:
The respond function takes a list of headers from a referenced message as
input and generates a list of initial candidate message Header Field names
and values that are used to populate the message composition interface.
NEW:
The respond function takes a list of Header Fields from a referenced
message as input and generates a list of initial candidate message Header
Field names and values that are used to populate the message composition
interface.
* Section 10
OLD:
In addition, these underlying security considerations are now also
applicable to the contents of the message header, not just the message
body.
NEW:
In addition, these underlying security considerations are now also
applicable to the contents of the message Header Section, not just the
message Body.
* Section 10.3
OLD:
Likewise, if the header value was originally encoded per [RFC2047], it
should be decoded first to a standard string and re-encoded using the
charset appropriate to the target part.
NEW:
Likewise, if the Header Field value was originally encoded per [RFC2047],
it should be decoded first to a standard string and re-encoded using the
charset appropriate to the target part.
---
OLD:
When including a Legacy Display Element in a text/html part (see Section
5.2.3), any material in the header values should be explicitly HTML
escaped to avoid being rendered as part of the HTML. At a minimum, the
characters <, >, and & should be escaped to <, >, and &,
respectively (for example, see [HTML-ESCAPES]). If unescaped characters
from removed or obscured header values end up in the Legacy Display
Element, a receiving MUA that follows the guidance in Section 4.5.3.3
might fail to identify the boundaries of the Legacy Display Element,
cutting out more than it should or leaving remnants visible. And a Legacy
MUA parsing such a message might misrender the entire HTML stream,
depending on the content of the removed or obscured header values.
NEW:
When including a Legacy Display Element in a text/html part (see Section
5.2.3), any material in the Header Field values should be explicitly HTML
escaped to avoid being rendered as part of the HTML. At a minimum, the
characters <, >, and & should be escaped to <, >, and &,
respectively (for example, see [HTML-ESCAPES]). If unescaped characters
from removed or obscured Header Field values end up in the Legacy Display
Element, a receiving MUA that follows the guidance in Section 4.5.3.3
might fail to identify the boundaries of the Legacy Display Element,
cutting out more than it should or leaving remnants visible. And a Legacy
MUA parsing such a message might misrender the entire HTML stream,
depending on the content of the removed or obscured Header Field values.
Section 10.4
[DKG, Alexey: Would Header Section (7th word in NEW sentence) be more
appropriate?]
OLD:
For example, the standard MIME headers of the Cryptographic Payload of a
message are often a predictable sequence of bytes, even without Header
Protection, when they only include the Structural Header Fields
MIME-Version and Content-Type.
NEW:
For example, the standard MIME Header Fields of the Cryptographic Payload
of a message are often a predictable sequence of bytes, even without
Header Protection, when they only include the Structural Header Fields
MIME-Version and Content-Type.
---
OLD:
Including protected Header Fields as defined in this document increases
the amount of known plaintext. Since some of those headers in a reply will
be derived from the message being replied to, this also creates a
potential risk for chosen-plaintext attacks, in addition to
known-plaintext attacks.
NEW:
Including protected Header Fields as defined in this document increases
the amount of known plaintext. Since some of those Header Fields in a
reply will be derived from the message being replied to, this also creates
a potential risk for chosen-plaintext attacks, in addition to
known-plaintext attacks.
* Section 11.2.1
OLD:
The MUA may have an idiosyncratic way of generating a Message-ID header,
which could embed the choice of MUA, time zone, hostname, or other subtle
information to a knowledgeable recipient.
NEW:
The MUA may have an idiosyncratic way of generating a Message-ID Header
Field, which could embed the choice of MUA, time zone, hostname, or other
subtle information to a knowledgeable recipient.
* Section 11.2.3
OLD:
In another example, if the HCP modifies the Date header to mask out
high-resolution timestamps (e.g., rounding to the most recent hour), some
information about the date of delivery will still be attached to the
email.
NEW:
In another example, if the HCP modifies the Date Header Field to mask out
high-resolution timestamps (e.g., rounding to the most recent hour), some
information about the date of delivery will still be attached to the
email.
* Section 13
The referereced documents [PEP-EMAIL] and [PEP-GENERAL] have just been
updated with changes relevant to this document. Please use update version
numbers (-03) and dates (22. May 2025).
* Appendix D2
OLD:
Note that because Alice's MUA is aware of Header Protection, it knows what
the correct Subject header is, even though it was obscured. It also knows
to avoid including the Legacy Display Element in the quoted/attributed
text that it includes in the draft reply.
NEW:
Note that because Alice's MUA is aware of Header Protection, it knows what
the correct Subject Header Field is, even though it was obscured. It also
knows to avoid including the Legacy Display Element in the
quoted/attributed text that it includes in the draft reply.
* Appendix D2.2
OLD:
Note that all headers except Subject are the same.
NEW:
Note that all Header Fields except Subject are the same.
* Appendix F3 (and ToC)
OLD
F.3. Protected Email Headers
NEW:
F.3. Autocrypt Protected Headers
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
