RFC Errata
Found 5 records.
Status: Verified (3)
RFC 4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", May 2006
Note: This RFC has been obsoleted by RFC 8422
Note: This RFC has been updated by RFC 5246, RFC 7027, RFC 7919
Source of RFC: tls (sec)
Errata ID: 2389
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Note: This RFC has been obsoleted by RFC 8422
Note: This RFC has been updated by RFC 5246, RFC 7027, RFC 7919
Source of RFC: tls (sec)
Errata ID: 2392
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.