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

Reply via email to