On Wed, Jun 18, 2025, at 21:08, Steffen Nurpmeso wrote: > [email protected] wrote in > <175028097011.643508.1606149502766119820@dt-datatracker-75bbdb9cc5-qvb4t>: > ... > | Title: A method for describing changes made to an email > | Author: Bron Gondwana > | Name: draft-gondwana-dkim2-modification-alegbra-02.txt > | Pages: 6 > | Dates: 2025-06-18 > > I thought it makes sense to make it very clear how different the > approaches are. > > Here it seems to be the desire to be able to recreate messages > entirely. > > For ACDC instead the DKIM-normalized data is used to create the > differences: verifiers and signers have to create this > representation anyway, and you can, after applying the difference, > more or less immediately verify the signature of elder data. > To me this seems ok since even the new RFC 5321bis will state > something around > Real mail security lies only in end-to-end methods involving the > message bodies, such as those that use digital signatures > and whereas i admire DKIM, that will not change. > Using the normalized data is sufficient to create a visual > approximation, shall the user ask for it. > And it is, in particular, sufficient to use all the elder header > data -- thus, if a user says "ietf-dkim is a mailing-list, and > please always show me the From: of the "original" sender, not the > mailing-list mitigated variant", then this is still possible. > > For me these two (and a half) goals are the only that count, i do > not believe in actual use cases for anything else. So (1) > cryptographic verification (simplemost), (2) possible display of > elder header data, ((3) visual approximation for allowing user > decisions on which modifications are allowed).
Yes, calculating the diff on the normalised form is certainly a valid option, and having that convert back to the previous message's normalised form. That's pretty much what I'm trying to do but not insisting on the normalising step. I'd be happy to add the normalisation requirement. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
