On Wed, 29 Jul 2026, Wei Chuang wrote:
wiggle room on how to interpret multiple signatures. It only mandates PERMAIL if all signatures fail in a DKIM2 signature header field. My read is that it is up to local policy whether to "AND" multiple signatures, or to "OR" them. This helps with the the ramp up of a new algorithm ...
I don't see how that would work. If there's two signatures, you only understand one of them, and your policy is 'AND' what do you do? Either you fail the message, or your policy isn't really 'AND'. The only policy that makes sense is 'OR'.
I realize this sounds condescending, but it is not a good idea to provide security options where the users don't understand the implications. While it might seem that using AND is obviously "more secure", in reality the only scenarios where it helps are implausible. One of the algorithms is cryptographically insecure, people don't know about it, and spammers are dumb so they put both a valid fake insecure signature and an invalid fake secure one on the message, rather than just the fake insecure one which will pass. A much more likely scenario is the one above where it just makes key rotation harder.
As I said a few messages back, if people really really want a belt and suspenders scheme where both conventional ed25519 and PQ ML-DSA-44 need to pass, we can do that by adding a "combo" signing algorithm where the key is the two keys concatenated, the signature is the two signatures, and it only passes if they both do. The TLS working group is planning to do that as an option for PQ SSL certificates. It would not be hard to do in DKIM2, but I do not think it is worth it.
R's, John _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
