RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (1)

RFC 5480, "Elliptic Curve Cryptography Subject Public Key Information", March 2009

Note: This RFC has been updated by RFC 8813

Source of RFC: pkix (sec)

Errata ID: 6670
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Corey Bonnell
Date Reported: 2021-08-31
Verifier Name: Benjamin Kaduk
Date Verified: 2021-09-01

Section 3 says:

   If the keyUsage extension is present in a certificate that indicates
   id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following
   values MUST NOT be present:

     digitalSignature;
     nonRepudiation;
     keyTransport;
     keyCertSign; and
     cRLSign.

It should say:

   If the keyUsage extension is present in a certificate that indicates
   id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following
   values MUST NOT be present:

     digitalSignature;
     nonRepudiation;
     keyEncipherment;
     keyCertSign; and
     cRLSign.

Notes:

"keyTransport" KU bit name does not exist; I believe "keyEncipherment" is intended here instead.

While RFC 8813 makes it clear that "keyEncipherment" and "dataEncipherment" are prohibited, I'm marking this erratum as "Technical" due the reference to a non-existent bit name.

Status: Reported (1)

RFC 5480, "Elliptic Curve Cryptography Subject Public Key Information", March 2009

Note: This RFC has been updated by RFC 8813

Source of RFC: pkix (sec)

Errata ID: 4170
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Annie Yousar
Date Reported: 2014-11-11

Section 4 says:

   ---------+----------+------------+-----------
   256      | 512      | SHA-512    | secp521r1
   ---------+----------+------------+-----------

It should say:

   ---------+----------+------------+-----------
   256      | 512+     | SHA-512    | secp521r1
   ---------+----------+------------+-----------

Notes:

The first table in section 4 (p. 9) provides the right text. The corresponding line in the table on p. 10 is the wrong one. In fact the key size is exactly 521 and not only 512+. Therefore 512+ in both tables could also be replaced by 521.

Status: Held for Document Update (2)

RFC 5480, "Elliptic Curve Cryptography Subject Public Key Information", March 2009

Note: This RFC has been updated by RFC 8813

Source of RFC: pkix (sec)

Errata ID: 1727
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2009-03-16
Held for Document Update by: Pasi Eronen

Section 2.1.1, pg.5 says:

|     o specifiedCurve, which is of type SpecifiedECDomain type (defined
        in [X9.62]), allows all of the elliptic curve domain parameters
        to be explicitly specified.  [...]

It should say:

|     o specifiedCurve, which is of type SpecifiedECDomain (defined
        in [X9.62]), allows all of the elliptic curve domain parameters
        to be explicitly specified.  [...]

Notes:

Location: last bullet in Section 2.1.1.
Rationale: inadvertant replication of "type"

Errata ID: 1728
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2009-03-16
Held for Document Update by: Pasi Eronen

Section 2.1.1.1 says:

   The namedCurve field in ECParameters uses object identifiers to name
   well-known curves.  This document publishes curve identifiers for the
   fifteen NIST-recommended curves [FIPS186-3].  Other documents can
|  publish other name curve identifiers.  The NIST-named curves are:

It should say:

   The namedCurve field in ECParameters uses object identifiers to name
   well-known curves.  This document publishes curve identifiers for the
   fifteen NIST-recommended curves [FIPS186-3].  Other documents can
|  publish other named curve identifiers.  The NIST named curves are:
                     ^                             ^

Notes:

Location: first paragraph of 2.1.1.1
Rationale:
a) typo: s/name curve/named curve/
b) extraneous hyphen (inserted in final publication processing)
changes semantics in an unfortunate manner; "NIST-named curves"
could be misunderstood as indicating that NIST had named these
'Named Curves'; "NIST-recommended named curves" might have been a
valid alternative but would have incurred too much word repetition.

Report New Errata



Advanced Search