Perhaps the issue is that two similar but different things are being conflated here.
Is DKIM2 a new protocol? I think the answer to this is clearly yes. We are defining a new interaction between systems. Does the DKIM2 protocol need to be implemented as a new header field, or can it reuse DKIM-Signature? The current view is that it needs to be separate, but it is acknowledged that this decision needs to be justified. Adding additional tags is certainly not a justification for needing a new header. Verifiers do not need to know about all tags present in the signature header in order to do signature verification. Changing the meaning of DKIM1's tags could be a reason, though it's a fairly weak one. Proposals from the meeting were changing h= to not need to list mandatory headers, and removing the need for c= by mandating a single canonicalization method (relaxed/relaxed, or maybe relaxed/simple). Even if there is an entirely new header, these decisions should be evaluated. Simplicity for adoption is a potentially stronger reason. DKIM2 is expected to produce signatures in situations that are not be producing them today. By having a completely separate header, it is much easier to ensure that these additional signatures do not disrupt existing flows because signing systems can do whatever they do for DKIM1 and add DKIM2 in parallel. Extra DKIM signatures are not likely to be a problem in flows where the message is delivered unmodified, but in modifying flows there may be differences in how the message is treated. On Sat, Mar 22, 2025, 6:49 p.m. Steffen Nurpmeso <stef...@sdaoden.eu> wrote: > Dear Michael Thomas. > > Michael Thomas wrote in > <80a3e172-3a1c-471a-b72b-3c07b4dd8...@mtcc.com>: > ... > |Again, why? Especially if the receiver knows whether it's base DKIM vs > |upgraded DKIM via some explicit signaling with the tags from the sender? > |If they are just unknown tags, it will verify and even if the receiver > |is upgrade-savvy it would just look like a normal STD76 signature. > > Since *noone* ever brought that up, i do it myself. > (If still not /dev/null'ed.) > > It cannot be that easy, because the entire email infrastructure is > totally messed up. By the IETF. Mostly DMARC, though. Noone > cares for ARC, really. But DKIM. But 99% DMARC, say. > > The reason is that > > MITIGATIONS > > are active, everywhere. This means that, more often than not, > either "elder" DKIM signatures are simply thrown away, or renamed > to, for example, X-Mailman-Original-DKIM-Signature. > Depends on what is rewritten, and if, etc etc. > > And this in turn means that it is IMPOSSIBLE to create valid > DKIMv1 chains, "except for a single hop message". > > That ship has sailed. > The damage was done many years ago. > You need to add something new. > > Having said that. It can be absolutely identical to DKIMv1 except > for the name of the header as such. > > For, i think, the last time, and i well understand that many > comments around here shoot against me by bringing snippets of the > arguments of the ACDC draft in favour of something else, however > technically sound that can be (cough, cough), anyone who looks > will find that the technical approach of the ACDC thing is easily > done, and is capable to do anything of DKIMv2, but more elegant, > and with lesser effort. And scalable, just as is SMTP. > > Greetings, > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
