Skip to main content

Fundamental Elliptic Curve Cryptography Algorithms
draft-mcgrew-fundamental-ecc-04

Yes

(Sean Turner)
(Tim Polk)

No Objection

(Adrian Farrel)
(Alexey Melnikov)
(Dan Romascanu)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Robert Sparks)
(Ron Bonica)
(Stewart Bryant)

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

Sean Turner Former IESG member
Yes
Yes () Unknown

                            
Tim Polk Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Peter Saint-Andre Former IESG member
No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection (2010-07-15) Unknown
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?
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2010-07-14) Unknown
  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/
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown