This is not a comment that requires addressing.  It is more of an opinion:

While this is a complex topic, the authors have done a fantastic job to make it clear and understandable.  Protected email (signed or signed and encrypted) is sadly a pretty niche idea, let alone protecting the headers that go with it.  I would love for this to change, maybe the e2e email guidance draft and this draft will help.

Thanks for this document. I hope the length of it does not deter people from implementing it properly by skimming it (as in, I wish it had been shorter)

I just have a few comments/nits:

        Such a Legacy Display Element need not be rendered to the user
        of an MUA that implements this specification, because the MUA
        already knows the correct Header Field information, and can
        render it to the user in the appropriate part of the MUA's user
        interface rather than in the body of the message.

"need not" is not 2119 language. Since the legacy display element can
be forged, should this not be a MUST NOT be rendered on non-legacy clients?

        If a non-structural Header Field name Z is present in Header
        Section of the Cryptographic Payload, but doesn't appear in an
        HP-Outer Header Field value at all, then the sender is effectively
        asserting that every instance of Z was made confidential

Should this say something that thus, if a Header Field name Z is present
in the outer Header Section, that it means it is forged and/or added by
an MTA, not the MUA? And maybe MUST NOT be rendered in any way?
(section 4 states this somewhat)

        If the signature fails validation, the MUA lowers the affected
        state to unprotected or encrypted-only without warning the user,
        as specified by Section 3.1 of [I-D.ietf-lamps-e2e-mail-guidance].

I wonder why a signature failure is not a "warn the user" event?
It is not the same as "unprotected", but this document tells people to treat
it as such?

Section 4.4.2: why not MUSTs instead of SHOULDs ?

        The algorithm returns a MIME object that is ready to be injected
        into the mail system.

mail message instead of mail system?


[I-D.ietf-openpgp-crypto-refresh-13] needs to be updated to RFC 9580

Section 10:

Why shouldn't a MUA always alert with a big warning when there is a From
mismatch in any way (inner, outer, HP-outer) ? Or could it display something
like "Paul Forged Wouters <paul@nohats.ca> on behave of someone_else@foo.com"

Section 12.2 could be written much shorter - the target audience is IANA
after all and they are experts in what they do :P



NITS:

Some combination terms are partially bolded, eg "SPECIFICATION REQUIRED".

Thanks for working on this specification.