Ballot for charter-ietf-dcrup
Yes
No Objection
Note: This ballot was opened for revision 01-00 and is now closed.
Ballot question: "Is this charter ready for external review? Is this charter ready for approval without external review?"
Editorial comments only: 1: Original: 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. This sentence is really long, and I got lost in it. It says that there are 4 changes, but the wording makes it hard to figure out which they are. Proposed (semi-colons to separate from the "such as"). Or, perhaps make this bullets instead?: 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. 2: "It will limit itself to existing implemented algorithms and key forms." The "it will limit itself" sounds odd in a charter; I'd suggest "It will be limited to..." or something similar (otherwise it sounds like this is an internal decision)
I think I addressed comments from Warren and Spencer.
I'm fine skipping the external review.
I'm glad to see this work going forward and am also fine with skipping external review.
I'm fine with doing this, without external review. I'm a Yes for this one, but Alexey needs to be a Yes before it's approved, of course. But definitely the right thing to do. I did see 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 I may be unaware of a well-known term of art, but I'm guessing "context transport security" is missing "of" (so, "context of transport security")? less severe. Still, the community wishes to discourage its continued use in the DKIM context.
Looks fine to me. Have no strong feelings about external review.