Fundamental Elliptic Curve Cryptography Algorithms
RFC 6090

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' **)
No email
send info
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' **)
No email
send info
  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/

Alexey Melnikov No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection