As threatened, albeit kind of late, here's plan for how to rotate to a new algorithm.
We note that every Arc-Seal and Arc-Message-Signature header has an a= tag that identifies the hash and signing algorithms used. (In sec 5.1.1.1 it just says hash, which is wrong.) Every DKIM key record has k= tag that says what signing algorithm the key is for. That should mean that we could publish several key records for several algorithms at the same domain and selector, except that RFC 6376 sec 3.6.2.2 says you can't. I think that's a bug in 6376, but we can fix that later. We relax the language saying that there can only be one Arc-Seal and one Arc-Message-Signature header for each i= value to say that there can be a group but they can only differ in the a=algorithm, s=selector, b=signature, and for A-M-S the bh=hash if the algorithms have different hashes. The group is valid if the recipient can verify at least one of them. The Arc-Seal signature covers all of the A-S and A-M-S headers, even ones it can't verify, and the header says cv=pass if it could verify at least one of the headers in each group. (Even if you can't verify a new algorithm, maybe the next system can.) To avoid infinite regress, we leave the instructions in 5.1.1.3 alone, so when adding new A-S headers, they're added as a group and the signatures are computed as through the b= in all of the headers in the newly added group were empty. I don't think this will add a lot of code, and it provides a straightforward upgrade path. When a system is upgraded to support a new algorithm, it starts adding headers for both the old and new algorithm. This potentially adds an extra A-S and A-M-S header at each level, but it's just linear, not exponential. When checking signatures, verifiers should try the new algorithm first in each group with multiple headers (it's a lot faster), and if so it need not check any others. Receivers can see from the ARC headers on their incoming mail how much of the mail has new signatures in addition to the old ones and who's adding them. Eventually there'll be enough new signatures that we can nudge the people still using only old ones and eventually only use the new ones. One minor weakness is that the A-S signature signs the headers in a group in whatever order they're in, and if a later system reorders them, the signature will break. We could address that by allowing sequence numbers like i=n.m where the m only affects the order in which they're signed, but I doubt it's worth it. It's hard to imagine a mail system that would only reorder the headers and not also break the signatures in other ways. R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
