RFC Errata
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.