This is an interesting issue. Perhaps we need another ticket just to discuss how to handle signature transition. My first thought is that it will be more effective to announce support for ed25519 in the report header, rather than in each message result. Another possibility is for a recipient to indicate support for new signatures in the DMARC policy record.
Any report recipient will have difficulty knowing how to extrapolate from a single result or even a single report to a general rule. John has observed that the RUA report does not even indicate the target domain(s) being reported. I would think this data inadequacy should be a priority for correction. For any multi-server configuration, knowing that one IP supports the new signatures does not mean that all servers do so. The challenge becomes knowing whether the domain is fully transitioned, and we don't even know the domain being evaluated. I suspect that a day will come when a research presents evidence that the old signatures can no longer be trusted. At that point, PCI DSS or GDPR will require us to quickly deprecate the old signatures, and compliant systems will simply ignore the RSA signatures. At that point, transition planning is simplified. Dual signatures also create some challenges for ARC. I don't think an ARC Set can reasonably include signatures under both algorithms. Doug Foster On Mon, Jan 25, 2021 at 12:10 AM Дилян Палаузов <[email protected]> wrote: > Hello, > > lets say a site signs an email with both rsa and ed25519 algorithms. This > site wants to know, whether the recipient can validate the ed25519 > signatures, so that in the future rsa signing for that receiving site can > be skipped (or errors in the ed25519 implementation fixed). > > For this to work the receiving site must put in the report information > about each aligned dkim signature, saying which public key-name was used. > > Greetings > Дилян > > On January 25, 2021 2:25:13 AM GMT+02:00, "Brotman, Alex" <Alex_Brotman= > [email protected]> wrote: >> >> Hello folks, >> >> Some time ago, an issue[1] was brought to the list where which DKIM(s) being >> reported is not clear in RFC7489 [2]. There was a short discussion, though >> no clear resolution before conversation trailed off. It seems like there >> were points that may need to be discussed. One was whether the reporting >> SHOULD report all signatures, regardless of alignment or validity, or >> perhaps just the one that aligns (if there is one). There was also another >> question if there should be a limit to the number of signatures reported so >> that it remains sane. >> >> We'd like to try to get this resolved within about two weeks. Thank you for >> your feedback. >> >> 1: https://mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/ >> 2: https://tools.ietf.org/html/rfc7489#section-7.2 >> >> -- >> Alex Brotman >> Sr. Engineer, Anti-Abuse & Messaging Policy >> Comcast >> ------------------------------ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> >> _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
