Clarifications for Elliptic Curve Cryptography Subject Public Key Information
RFC 8813
Yes
No Objection
Note: This ballot was opened for revision 00 and is now closed.
Roman Danyliw Yes
Alvaro Retana No Objection
Warren Kumari No Objection
Thanks to Tim for the OpsDir review, and Sean for addressing it.
Éric Vyncke No Objection
Ultra short document :-) Anyway, a minor comment: what is the location of the text updating the section 3 of RFC 5480? Should it go at the end of the existing section 3 (my guess)? Or at the beginning ? or somewhere in the middle ? Should it replace completely or partially the existing section 3? -éric PS: I know that my comment is mostly larger than the update itself ;-)
(Alexey Melnikov; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
If further clarifications can be made based on the latest email from the Gen-ART reviewer, that would be good.
(Barry Leiba; former steering group member) No Objection
Thanks for a nice, super-short and to-the-point document. I hate to pick on anything here, but: then the following values also MUST NOT be present: Do you mean "MUST NOT also be present"? The "also" seems misplaced where it is, and it made me wonder if I misunderstood. An alternative fix would be to simply remove "also".
(Benjamin Kaduk; former steering group member) No Objection
I'm somewhat amenable to the genart reviewer's concerns that we are implicitly asserting restrictions in RFC 5480 usage by describing the algorithms defined by 5480 as "key agreement algorithms"; RFC 5480 does not seem to use that terminology to refer to id-ecPublicKey. Section 1 Cryptography. As part of these semantics, it defines what combinations are permissible for the values of the key usage extensions [RFC5280]. [RFC5480] specifies 7 of the 9 values; it nit: IMO, "key usage extensions" would mean both keyUsage and extendedKeyUsage, but this document considers only the identified bits in the original keyUsage extension, and thus the singular "extension" would be more appropriate. Section 4 What are the considerations that apply to implementations that follow RFC 5480 but not this document, e.g., existing implementations that allow keyEncipherment and/or dataEncipherment? Specifically, if we are forbidding their usage, is it because there are vulnerabilities to doing so? It seems like we should mention them here.
(Deborah Brungard; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection