Subject: [TLS] [Technical Errata Reported] RFC4492 (2389)

From: RFC Errata System <[email-masked]>
Date: Fri, 23 Jul 2010 01:32:43 -0700 (PDT)

The following errata report has been submitted for RFC4492,
"Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4492&eid=2389

--------------------------------------
Type: Technical
Reported by: Juho Vähä-Herttua <[email-masked]>

Section: 5.4

Original Text
-------------
   point:   This is the byte string representation of an elliptic curve
      point following the conversion routine in Section 4.3.6 of ANSI
      X9.62 [7].  This byte string may represent an elliptic curve point
      in uncompressed or compressed format; it MUST conform to what the
      client has requested through a Supported Point Formats Extension
      if this extension was used.

        enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;

   ec_basis_trinomial:   Indicates representation of a characteristic-2
      field using a trinomial basis.

   ec_basis_pentanomial:   Indicates representation of a
      characteristic-2 field using a pentanomial basis.

Corrected Text
--------------
   point:   This is the byte string representation of an elliptic curve
      point following the conversion routine in Section 4.3.6 of ANSI
      X9.62 [7].  This byte string may represent an elliptic curve point
      in uncompressed or compressed format; it MUST conform to what the
      client has requested through a Supported Point Formats Extension
      if this extension was used.

        enum {
            ec_basis_trinomial(1), ec_basis_pentanomial(2),
            (255)
        } ECBasisType;

   ec_basis_trinomial:   Indicates representation of a characteristic-2
      field using a trinomial basis.

   ec_basis_pentanomial:   Indicates representation of a
      characteristic-2 field using a pentanomial basis.

Notes
-----
The ECBasisType enumeration is submitted as part of the ECParameters structure and therefore needs numerical values. It is common to assign numerical values starting from 1 to enums and maximum value of 255 should be enough, since currently there are only two known basis types and it is unlikely to change in the near future.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4492 (draft-ietf-tls-ecc-12)
--------------------------------------
Title               : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
Publication Date    : May 2006
Author(s)           : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller
Category            : INFORMATIONAL
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 23 Jul 2010 11:28:02 +0200

On Jul 23, 2010, at 10:32 AM, RFC Errata System wrote:

> The ECBasisType enumeration is submitted as part of the ECParameters  
> structure and therefore needs numerical values. It is common to  
> assign numerical values starting from 1 to enums and maximum value  
> of 255 should be enough, since currently there are only two known  
> basis types and it is unlikely to change in the near future.

Thanks, Juho.  Yes, the RFC text is wrong in not assigning enum values  
here, and the values that you suggest (1 and 2, with extra value 255  
to clearly state the intended width) are the ones that the  
specification would have used.

Using enum values 0 and 1 would have been equally possible, but this  
RFC tends to avoid value 0, except when specifying point compression  
in ECPointFormat, where 0 denotes the special "no compression"  
default.  For ECBasisType, there's no similar special default.

The implementations I'm aware of so far only provide named curves,  
i.e. ECBasisType is never actually encoded on the wire.  If anyone  
knows an existing implementation supporting explicit characteristic-2  
curves, I'd be glad to hear how it handles this issue -- I'd expect it  
would be using the enum values 1 and 2 as suggested here, but in case  
0 and 1 are in actual use somewhere, we'd have to think about  
maintaining compatibility.

Bodo

> Title               : Elliptic Curve Cryptography (ECC) Cipher  
> Suites for Transport Layer Security (TLS)