On Mon, Mar 31, 2025 at 12:32 PM John Levine <jo...@taugh.com> wrote:
> It appears that Wei Chuang <wei...@google.com> said: > >To sign a message, the signer must find the maximum instance tag "i=n", > >denoted as M. To add a new DKIM2-Signature, first verify that there isn't > >any to be defined in the future indication that the message "left" DKIM2. > ... > > I have a few questions that might greatly simplify the process. > > Most (all?) non-trace headers are defined to occur only once, like From: > and Subject: > I think this could work also and agree it would shorten the list of header fields that have to be oversigned. This list of non-trace headers with one or zero header fields is defined in RFC5322 section 3.6 <https://datatracker.ietf.org/doc/html/rfc5322#section-3.6>, but the list to be verified by DKIM2 should be explicitly specified assuming this feature is to be adopted. > > How about we say that if a signer or verifier sees more than one of them, > stop > and the result is failure, no oversigning needed. > > The only trace header I think it's likely we'll sign is the previous DKIM2 > signatures > which is easy enough, just sign them in order up through the current one. > I suppose > there's the Resent-blah: trace headers, but since we're signing the > envelope > recipient already, do we care? > There's also other optional DKIM2 headers: DKIM2-Delta-Header, DKIM2-Delta-Body and DKIM2-Authentication-Result as well. Presumably the Resent fields should be signed for like the other Originator and Destination fields even if they don't have a DKIM2 validation purpose. If so, the Resent fields should be oversigned. -Wei > > R's, > John > >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org