Skip to main content

Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol
draft-ietf-curdle-ssh-ed25519-ed448-11

Yes

(Alexey Melnikov)
(Barry Leiba)
(Benjamin Kaduk)

No Objection

(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)

Note: This ballot was opened for revision 09 and is now closed.

Roman Danyliw
No Objection
Comment (2019-08-06 for -09) Sent
A few editorial nits:

** References in Section 3 – 7, 10 to [RFC4251], [RFC4253] and [RFC8032] are showing up in the format “[RFC#], Section x.x [RFC#]”.  For example, “[RFC4253], Section 6.6 [RFC4253]”.  It should likely only be “Section x.x [RFC#]”.

** Section 8.  Typo.  s/the the/the/

** Section 8.  Typo and making it be “an example”, not “the example”.  s/the SSHFP Resource Record for  the Ed448 public key with SHA-256 fingerprint would be example be /The SSHFP Resource Record for a Ed448 public key with a SHA-256 fingerprint would, for example, be/
Warren Kumari
No Objection
Comment (2019-08-07 for -09) Not sent
As mentioned in email to OpsDir, thanks to Sheng & the authors for addressing comments.
Éric Vyncke
No Objection
Comment (2019-08-06 for -09) Sent
Thank you for this short document. I have one COMMENT and a couple of NITs though (minor and trivial to fix)

=== COMMENT ===

--- Section 2.1 ---
Please use RFC 8174 boilerplate.

=== NIT ===
The "Ed25519" is capitalized in section 1 and all uppercase in section 7. 

Section 8 would benefit for editorial review regarding the use of ':' and starting sentence with a capitalized word.
Alexey Melnikov Former IESG member
Yes
Yes (for -09) Not sent

                            
Barry Leiba Former IESG member
(was No Objection) Yes
Yes (for -09) Not sent

                            
Benjamin Kaduk Former IESG member
Yes
Yes (for -09) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2019-08-06 for -09) Sent
It would be nice if this document briefly noted somewhere what the security properties are of Ed25519 and Ed448, or otherwise give some indication for why supporting these algorithms is a good thing.

In Section 2.1, please use the RFC 8174 boilerplate.
Alvaro Retana Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-08-02 for -09) Sent
I think this document should update RFC4253.
Suresh Krishnan Former IESG member
No Objection
No Objection (2019-08-06 for -09) Sent
* Section 5

"Signatures are generated according to the procedure in [RFC8032], Section 5.2.6 [RFC8032]."

Shouldn’t this also include Section 5.1.6 of [RFC8032] to generate the signature using Ed25519?