The DKIM Crypto Update (dcrup) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. DKIM Crypto Update (dcrup) ----------------------------------------------------------------------- Current status: Active WG Chairs: Rich Salz <rsalz@akamai.com> Murray Kucherawy <superuser@gmail.com> Assigned Area Director: Alexey Melnikov <aamelnikov@fastmail.fm> Applications and Real-Time Area Directors: Adam Roach <adam@nostrum.com> Ben Campbell <ben@nostrum.com> Alexey Melnikov <aamelnikov@fastmail.fm> Technical advisors: Eric Rescorla <ekr@rtfm.com> Mailing list: Address: dcrup@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/dcrup Archive: https://mailarchive.ietf.org/arch/browse/dcrup/ Group page: https://datatracker.ietf.org/group/dcrup/ Charter: https://datatracker.ietf.org/doc/charter-ietf-dcrup/ The DKIM Crypto Update (DCRUP) Working Group is chartered to update DomainKeys Identified Mail (DKIM, RFC 6376) to handle more modern cryptographic algorithms and key sizes. DKIM (RFC 6376) signatures include a tag that identifies the hash algorithm and signing algorithm used in the signature. The only current algorithm is RSA, with advice that signing keys should be between 1024 and 2048 bits. While 1024 bit signatures are common, longer signatures are not because bugs in DNS provisioning software prevent publishing longer keys as DNS TXT records. DKIM also currently supports use of SHA1 coupled with RSA. SHA1 has been formally deprecated due to weakness especially when used in the context transport security, though the risk of a successful preimage attack is less severe. Still, the community wishes to discourage its continued use in the DKIM context. DCRUP will consider four types of changes to DKIM: additional signing algorithms such as those based on elliptic curves, changes to key strength advice and requirements, deprecating the use of SHA1, and new public key forms, such as putting the public key in the signature and a hash of the key in the DNS to bypass bugs in DNS provisioning software that prevent publishing longer keys as DNS TXT records. It will limit itself to existing implemented algorithms and key forms. Other changes to DKIM, such as new message canonicalization schemes, are out of scope. The WG will as far as possible avoid changes incompatible with deployed DKIM signers and verifiers. Milestones:
