I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-os-ietf-sshfp-ecdsa-sha2-04.txt Reviewer: Francis Dupont Review Date: 20111210 IETF LC End Date: 20120103 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: not a real issue but I am not convinced there is a real crypto reason to give up SHA-1. At the first view the attack against SSHFP is a pre-image one, but: - I leave the question to cryptographers of the security directorate - there are many not-crypto reasons to move from SHA-1 to SHA-256 Nits/editorial comments: - I'd like to get only the SHA-256 name and no variants, in particular no SHA256 (my idea is to always use the same name) - IMHO the 'OpenSSH' format is just the PEM format - IMHO the multi-line fingerprint in text RRs must be enclosed by parenthesis to be correctly parsed - 1 page 3: the abbrev RR should be introduced as soon as the term 'resource record' is used - 1 page 3: ; and -> ; - 3.2.1 page 4: this is the MUST I am not convinced by the justification (BTW I suggest to fix the justification if it is too wrong, and to keep the MUST) - 7 page 7: software implementations -> implementations - 7 page 8: BTW I like the disclaimer: ... Regardless of whether or not the attacks on SHA-1 will affect SSHFP, it is believed (at the time of this writing) that SHA- 256 is the better choice for use in SSHFP records. - 8.2 page 9: Di!erential -> Differential - Author's Address: CZ -> Czech Republic Regards francis.dup...@fdupont.fr _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
