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

[Bodo Moeller <[e-mail]>]

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

>
> 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 <[e-mail]>
>
> 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.

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



>
> 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