>> Drop support for SHA1 entirely. It's beginning to look >> cryptographically very dubious, and is being dropped by pretty much >> everyone else. Even if the attacks against it don't affect the way >> it's used in DKIM it seems unwise to suggest it be used at all. At the >> very least it seems a poor "marketing" move to include an algorithm >> that's been dropped by most everyone else as insecure before this spec >> is finalized. >> >> "Verifiers MUST support rsa-sha256 and MAY support rsa-sha1. >> Signers SHOULD sign using rsa-sha256 and SHOULD NOT sign using rsa- >> sha1." might provide enough wiggle room to allow existing code time to >> migrate away from SHA1.
Seeing that the message I received this suggestion in, is signed by the mipassoc.org server with an rsa-sha1 key, I find this suggestion curious. Dropping support altogether for SHA1 might indeed alienate many currently installed systems. I'd opt for "Verifiers MUST support rsa-sha256 and MUST support rsa-sha1", whilst keeping the SHOULD/SHOULD NOT emphasis as described above, in order to eventually have every signer use rsa-sha256. To optimise is okay, but to start dropping/alienating currently installed base is something I'd consider unwise at this point in time. Kind regards, -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
