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

[Sean Turner <[e-mail]>]

On 2/24/11 6:20 AM, Bodo Moeller wrote:
> On Wed, Feb 23, 2011 at 8:37 PM, Juho Vähä-Herttua <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>      >> 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.
>
>
>
>      > 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?
>
>
>
>     The first "other place" is actually exactly the enum which was
>     originally reported. The ECBasisType indeed is converted to external
>     representation as can be seen in RFC 4492 section 5.4. struct
>     ECParameters below the case explicit_char2. PublicValueEncoding
>     instead is gotten from ClientCertificateType message and doesn't
>     have external representation. As said in RFC 4492 section 5.7:
>
>     (This is "explicit"  in ECC cipher suites except when the client
>     uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication
>     mechanism.)
>
>     The other two enums (KeyExchangeAlgorithm and SignatureAlgorithm)
>     that aren't given values depend on cipher suite and don't need
>     external representation. However, without the external
>     representation of ECBasisType it is impossible for the parser to
>     know if it should only parse "k" or "k1, k2 and k3" from the struct
>     and it will fail, hence the errata.
>
>     Hope this helps, and feel free to correct me if necessary. I wasn't
>     sure who the question was asked since the email was addressed to
>     Bodo, but thought to clarify anyway.
>
>
> Yes, thanks.
>
> Just to avoid any confusion, let me clarify the context of my previous
> statement that "ECBasisType is never actually encoded on the wire": this
> was referring to my knowledge about *existing implementations*; it's
> clear from the specification that you need to encode ECBasisType on the
> wire if you support explicitly specified characteristic-2 curves for
> ECDHE ciphersuites.

So hearing no objections I'm going to mark this errata as verified.

spt