Ballot for draft-ietf-curdle-rsa-sha2
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Thanks for addressing the SecDir review comments. https://mailarchive.ietf.org/arch/msg/secdir/ObNBH1VK1aPmdid3StYKLooa4Ls
Section 3.2: The signature field, if present, encodes a signature using an algorithm name that MUST match the SSH authentication request - either "rsa-sha2-256", or "rsa-sha2-512". It might be that I'm not familiar enough with SSH to know what recipients do when receiving unexpected values and the the proper behavior here would be obvious to implementors. If that's not the case, I would think that additional text here telling recipients what to do in the case of a mismatch would be helpful. The reference [EXT-INFO] needs to be normative rather than informative, as it is part of a normative behavior described in this document. Both section 1 and Section 5.1 describe NIST recommendations regarding key length, while not endorsing them (normatively or otherwise). This strikes me as notable, given that the NIST recommendations regarding SHA-1 seem to form part of the rationale for its replacement. Is the lack of endorsing NIST-recommended key lengths intentional? Nits: RFC6979 is in the references section, but does not appear to be referenced. One of the lines in the Acknowledgements section is too long.
There are a few outstanding comments from the Gen-ART review: https://datatracker.ietf.org/doc/review-ietf-curdle-rsa-sha2-10-genart-lc-housley-2017-09-01/ I personally do not have strong feelings about the title and the text in Section 3.1 but the review comments should be resolved by the author/WG.
[EXT-INFO] needs to be a normative reference, since it's part of a SHOULD level normative requirement.