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

[Sean Turner <[e-mail]>]

On 7/23/10 5:28 AM, Bodo Moeller wrote:
> 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

Bodo,

Finally getting around to this.  The question is whether the enum values 
are converted to external representation.  If they are not then it's 
okay that they're not there as 4.5 of TLS says:

   For enumerateds that are never converted to external representation,
   the numerical information may be omitted.

Are they converted?

There are two other places where enums aren't given values:

   enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;

and

   enum { implicit, explicit } PublicValueEncoding;

Should these also be changed?

spt

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