RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (3)

RFC 4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", May 2006

Source of RFC: tls (sec)

Errata ID: 2389

Status: Verified
Type: Technical

Reported By: Juho Vähä-Herttua
Date Reported: 2010-07-23
Verifier Name: Sean Turner
Date Verified: 2011-03-26

Section 5.4 says:

   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.

It should say:

   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.

Errata ID: 3652

Status: Verified
Type: Editorial

Reported By: Peter Dettman
Date Reported: 2013-06-13
Verifier Name: Sean Turner
Date Verified: 2013-08-14

Section 5.4 says:

ECBasisType basis;
select (basis) {
    case ec_trinomial:
        opaque  k <1..2^8-1>;
    case ec_pentanomial:
        opaque  k1 <1..2^8-1>;
        opaque  k2 <1..2^8-1>;
        opaque  k3 <1..2^8-1>;
};

It should say:

ECBasisType basis;
select (basis) {
    case ec_basis_trinomial:
        opaque  k <1..2^8-1>;
    case ec_basis_pentanomial:
        opaque  k1 <1..2^8-1>;
        opaque  k2 <1..2^8-1>;
        opaque  k3 <1..2^8-1>;
};

Notes:

ECBasisType is earlier introduced as:
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;

The cases of the select statement should spell the enum elements correctly.

{spt} Related to: http://www.rfc-editor.org/errata_search.php?eid=2389

Errata ID: 4783

Status: Verified
Type: Editorial

Reported By: Florent Tatard
Date Reported: 2016-08-19
Verifier Name: Kathleen Moriarty
Date Verified: 2016-08-24

Section 5.7 says:

Actions of the sender:

   The client selects an ephemeral ECDH public key corresponding to the
   parameters it received from the server according to the ECKAS-DH1
   scheme from IEEE 1363 [6].  It conveys this information to the client
   in the ClientKeyExchange message using the format defined above.

It should say:

Actions of the sender:

   The client selects an ephemeral ECDH public key corresponding to the
   parameters it received from the server according to the ECKAS-DH1
   scheme from IEEE 1363 [6].  It conveys this information to the server
   in the ClientKeyExchange message using the format defined above.

Notes:

The client conveys data to the server, not itself.

Status: Held for Document Update (2)

RFC 4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", May 2006

Source of RFC: tls (sec)

Errata ID: 2392

Status: Held for Document Update
Type: Editorial

Reported By: Brian Smith
Date Reported: 2010-07-23
Held for Document Update by: Sean Turner

Section 5.2 says:

The server's Supported Point Formats Extension has the same structure
as the client's Supported Point Formats Extension (see
Section 5.1.2).  Items in elliptic_curve_list here are ordered
according to the server's preference (favorite choice first).  Note
that the server may include items that were not found in the client's
list (e.g., the server may prefer to receive points in compressed
format even when a client cannot parse this format: the same client
may nevertheless be capable of outputting points in compressed
format).

It should say:

The server's Supported Point Formats Extension has the same structure
as the client's Supported Point Formats Extension (see
Section 5.1.2).  Items in ec_point_format_list here are ordered
according to the server's preference (favorite choice first).  Note
that the server may include items that were not found in the client's
list (e.g., the server may prefer to receive points in compressed
format even when a client cannot parse this format: the same client
may nevertheless be capable of outputting points in compressed
format).

Notes:

ec_point_format_list is the field in the Supported Point Formats Extension. elliptic_curve_list is the field in the Supported Elliptic Curves Extension.

Errata ID: 4633

Status: Held for Document Update
Type: Editorial

Reported By: Kurt Roeckx
Date Reported: 2016-03-02
Held for Document Update by: Stephen Farrell
Date Held: 2016-09-12

Section 5.1.1 says:

        struct {
            NamedCurve elliptic_curve_list<1..2^16-1>
        } EllipticCurveList;

It should say:

        struct {
            NamedCurve elliptic_curve_list<2..2^16-1>
        } EllipticCurveList;

Notes:

The count is in bytes, not items.

Report New Errata



Search RFCs
Advanced Search
×