RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 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.

Report New Errata



Advanced Search