RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (2)

RFC 8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", August 2018

Note: This RFC has been updated by RFC 8996

Source of RFC: tls (sec)

Errata ID: 5703
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Theinen
Date Reported: 2019-04-23
Verifier Name: Benjamin Kaduk
Date Verified: 2019-05-01

Section 5.10. says: 

All RSA signatures must be generated and verified according to
   Section 7.2 of [RFC8017].

It should say:

All RSA signatures must be generated and verified according to
   Section 8.2 of [RFC8017].

Notes:

Section 7.2 of RFC 8017 describes the RSAES-PKCS1-v1_5 encryption scheme. Section 8.2 of RFC 8017 describes the RSASSA-PKCS1-v1_5 signature scheme. The original text contradicts the natural expectation and is probably wrong. If it was intended, there should have been a thorough explanation (like in the well-known case of IKEv1 using the encryption scheme for signing).

Errata ID: 6002
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rich Salz
Date Reported: 2020-03-02
Verifier Name: Benjamin Kaduk
Date Verified: 2020-03-05

Section 9 says: 

   IANA has assigned two values in the "TLS SignatureAlgorithm" registry
   for ed25519 (7) and ed448 (8) with this document as reference.  This
   keeps compatibility with TLS 1.3.

It should say:

   IANA has assigned two values in the "TLS SignatureAlgorithm" registry
   for ed25519 (7) and ed448 (8) with DTLS-OK set to "Y" and this document
   as reference.  This keeps compatibility with TLS 1.3.

Notes:

IANA had consulted with Yoav, one of the authors (and a TLS registry expert), who explicitly told them to use DTLS-OK of "Y", but this clarification was not reflected in the final RFC. This also matches the text in the subsequent paragraph.

Status: Held for Document Update (2)

RFC 8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", August 2018

Note: This RFC has been updated by RFC 8996

Source of RFC: tls (sec)

Errata ID: 5466
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masato Gosui
Date Reported: 2018-08-17
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-08-17

Section 5.3 says: 

   Actions of the sender:

   The server constructs an appropriate certificate chain and conveys it
   to the client in the Certificate message.  If the client has used a
   Supported Elliptic Curves Extension, the public key in the server's
   certificate MUST respect the client's choice of elliptic curves.  A
   server that cannot satisfy this requirement MUST NOT choose an ECC
   cipher suite in its ServerHello message.)

It should say:

   Actions of the sender:

   The server constructs an appropriate certificate chain and conveys it
   to the client in the Certificate message.  If the client has used a
   Supported Elliptic Curves Extension, the public key in the server's
   certificate MUST respect the client's choice of elliptic curves.  A
   server that cannot satisfy this requirement MUST NOT choose an ECC
   cipher suite in its ServerHello message.

Notes:

This removes the spurious closing parenthesis of the last sentence of the "Actions of the sender" paragraph.

Errata ID: 5468
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masato Gosui
Date Reported: 2018-08-17
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17

Section 5.4 says: 

   namedCurve: Specifies a recommended set of elliptic curve domain

It should say:

   namedcurve: Specifies a recommended set of elliptic curve domain

Notes:

This fixes mismatched names of the variable "namedcurve" in the "Structure of this message" paragraph.

Report New Errata



Advanced Search