Please join the [email protected] mailing list if you are interested in this work.
Begin forwarded message: > From: The IESG <[email protected]> > Date: 28 April 2017 at 17:13:42 BST > To: "IETF-Announce" <[email protected]> > Cc: [email protected], [email protected], The IESG <[email protected]> > Subject: WG Action: Formed DKIM Crypto Update (dcrup) > > A new IETF WG has been formed in the Applications and Real-Time Area. For > additional information, please contact the Area Directors or the WG > Chairs. > > DKIM Crypto Update (dcrup) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > Rich Salz <[email protected]> > Murray Kucherawy <[email protected]> > > Assigned Area Director: > Alexey Melnikov <[email protected]> > > Applications and Real-Time Area Directors: > Adam Roach <[email protected]> > Ben Campbell <[email protected]> > Alexey Melnikov <[email protected]> > > Technical advisors: > Eric Rescorla <[email protected]> > > Mailing list: > Address: [email protected] > 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. > > DCRUP will consider three types of changes to DKIM: additional signing > algorithms such as those based on elliptic curves, changes to key > strength advice and requirements, 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: > Oct 2017 - Agree what algorithms and key formats to add or deprecate > Dec 2017 - Submit WG draft to IESG as Proposed Standard
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
