On Sat, Mar 22, 2025 at 3:23 PM Michael Thomas <m...@mtcc.com> wrote:
> TL;DR: I still don't see anything that precludes this as a DKIM update. > I see it as a package of changes that provide the capabilities sought by the charter. That "package" might be a whole new thing, or it could be a suite of new tags on the old thing. I think there's a strong, but not yet complete, argument in favor of this being a new thing that can't be achieved simply with new tags. The abstract idea I'm relying on here is that a STD 76 signature needs to fail in certain new cases. But we can't make it fail if all it does is ignore new tags. The conditional signatures work is the best example I can remember: We needed a way to say "this signature from $DOMAIN1 is only valid in the presence of another valid signature from $DOMAIN2". There was a tag proposed to carry that semantic. But a STD 76 verifier that doesn't know about the new tag will still pass the signature even if there's no valid $DOMAIN2 signature present, and we don't want that. The only way to actually prevent the false positive is (a) v=2, (b) a totally new header field, or (c) some convoluted monkeying with canonicalizations, which might also be a full protocol change anyway. There's a separate argument about "v=2" vs. a new header field name that I poked at in some other reply. I understand the preference some (Dave?) have for the latter, but there sure seems to be a lot of opportunity for code reuse if you go the former route. The other major factor that has me thinking that this is a new thing is that we are, in at least two spots, reaching across the 5321-5322 barrier. That's a pretty significant change. That this new thing needs to understand the envelope and MX selection logic doesn't seem like a simple extension to me. Anyway, it seems a lot like what DKIM2 is up to will wander into this space. It remains to be seen whether it's possible to do this purely incrementally, and so I think the consensus is comfortable starting from the assumption that this will ultimately be a new thing, not just new tags, and then trying to work our way backwards. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
