RFC Errata
Found 4 records.
Status: Verified (3)
RFC 4648, "The Base16, Base32, and Base64 Data Encodings", October 2006
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 2837
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2011-06-15
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-16
Section 16.2 says:
http://zgp.org/pipermail/p2p-hackers/2001-September/000315.html
It should say:
http://zgp.org/pipermail/p2p-hackers/2001-September/000316.html
Notes:
The same "off by one" issue was already present in RFC 3548 (obsoleted by RFC 4648). The archived article 315 has another author. Articles 316 and 319 are from the author noted in the RFCs, belong to a discussion of "web-safe base64" formats (incl. hex. + base32 alternatives), and specify the relevant base64 modification:
316 is shorter than 319, and nearer to the erroneous 315, so that was likely the intended article.
Errata ID: 5855
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Barclay
Date Reported: 2019-09-06
Verifier Name: Orie Steele
Date Verified: 2024-04-01
Section 10. says:
10. Test Vectors BASE64("") = "" BASE64("f") = "Zg==" ...
Notes:
TL;DR: Test Vectors section should specify the character encoding (ASCII/UTF-8) of the _character_ sequences used to represent input-data _octet_ sequences.
The input to a Base 64/-32/-16 encoding operation is sequence of _octets_.
However, the test vector expressions use sequences of _characters_ to represent input _octet_ sequences.
That's a type mismatch (characters where octets are needed), and although it's pretty obvious that the strings were meant to represent octet sequences, there's no mention the the intended character encoding isn't, say, EBCDIC.
Some possible fixes:
1) The text should specify the character encoding (ASCII/UTF-8) to be used to interpret the character sequences as input octet sequences.
2) The input octet sequences should be represented with a more direct (encoding-independent) representation of octets (e.g., "0x48, 0x69".).
Errata ID: 7514
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zachary Collier
Date Reported: 2023-05-09
Verifier Name: RFC Editor
Date Verified: 2023-05-09
Section 3.5 says:
If this property do not hold [...]
It should say:
If this property does not hold [...]
Notes:
The verb "do" in the clause "If this property do not hold" is incorrect. The correct verb is "does," as the subject "this property" is singular.
Status: Reported (1)
RFC 4648, "The Base16, Base32, and Base64 Data Encodings", October 2006
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 4889
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Umberto Rustichelli
Date Reported: 2016-12-14
Section 6 says:
When fewer than 40 input bits are available in an input group, bits with value zero are added (on the right) to form an integral number of 5-bit groups.
It should say:
When fewer than 40 input bits are available in an input group, bits with value zero are added (on the right) to form an integral number of 8-bit groups.
Notes:
8-bit instead of 5-bit.
What follows the correction clearly shows that the final input group must be 8, 16, 24, 32 or 40 bit long, that is, a multiple of 8, not of 5.
Also examples of commonly-used Base32 encoders/decoders seem to show this behaviour.
Also, I would not say "When fewer than 40 input bits are available in an input group" but rather "When fewer than 40 input bits are available in the final input group", to better clarify and not to change the subject ambiguously, unless this is intentionally applicable to any input lot.