Fundamental Elliptic Curve Cryptography Algorithms
Note: This ballot was opened for revision 04 and is now closed.
(Tim Polk) Yes
(Sean Turner) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
Comment (2010-07-15 for -** No value found for 'p.get_dochistory.rev' **)
This text from the Introduction could be a little clearer: Its intent is to provide the Internet community with a summary of the basic algorithms that predate any specialized or optimized algorithms, which can be used as a normative specification. Is this document intended for use as a normative specification or is it intended to provide pointers to other documents that can be used as normative specifications?
(Adrian Farrel) No Objection
(Russ Housley) No Objection
Comment (2010-07-14 for -** No value found for 'p.get_dochistory.rev' **)
Section 3.3.1 (Discriminant) includes: > > For each elliptic curve group, the discriminant - 16*(4*a^3 + 27*b^2) > must be nonzero modulo p [S1986]; ... > I agree with the observation by Vijay Gurbani in the Gen-ART Review on 14-July-2010 that the hyphen can be misread as a minus sign. I suggest replacing placing "16*(4*a^3 + 27*b^2)" in commas. Section 3.3.2 (Security) begins: > > Security is highly dependent on the choice of these parameters. This > section gives normative guidance on acceptable choices. See also > Section 10 for informative guidance. > This use of "normative" in an Information RFC is unusual. I suggest the section be renamed and the rewording or removal of this paragraph. I propose "Choosing Secure ECC Parameters" as a useful section name. In section 9: s/May, 1994/May 1994/