On 1/29/25 9:05 PM, Murray S. Kucherawy wrote:
On Wed, Jan 29, 2025 at 8:45 PM Jim Fenton <fen...@bluepopcorn.net> wrote:
I’m a little unclear on the need to fully describe the “mutation”
that might be applied by an intermediary. Even if fully described,
you need to have some trust of the intermediary to accept the
mutation, because otherwise you don’t know that the mutation
doesn’t contain harmful/unwanted content (barring some magic AI
thing perhaps).
If you do have trust of the intermediary to only sign messages
where they have verified the DKIM signature of the message
received by the intermediary, shouldn’t the intermediary’s
signature on the modified message should be sufficient? I thought
this was effectively what ARC is doing, although I have quibbles
about how ARC does it.
I think there's a difference between a general mechanism that can
describe any mutation, and a fixed set of known mutations we can all
agree are well understood and generally harmless (Subject tags, small
footers, etc.). The former approach does indeed mean the verifier has
to decide if the mutation is acceptable, which I think is a difficult
problem.
Of course that's exactly what l= and z= provide, and an MLM can always
resign the message. The advantage of some new diff-like thing is that it
can be more comprehensive. The advantage of l= z= is that originating
domain owns its destiny and doesn't have to rely on MLM's to be
upgraded. However, given my experiments in the past, the diff-like thing
probably needs to be more than just allowing for footers if you want to
catch most/all of the mutations that can happen. I really regret not
having written a paper on that.
But I'm content to leave that discussion to the WG rather than the
charter.
I do think it's a valid discussion point to understand why this has
bubbled up to the top. I know there's been talk about this off and on
for quite a while, but it's never seemed very serious. That makes me
curious why it is now.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
