RFC 4880, "OpenPGP Message Format", November 2007

Note: This RFC has been obsoleted by RFC 9580

Note: This RFC has been updated by RFC 5581

Errata ID: 2233
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 6.4. says:

   In Radix-64 data, characters other than those in the table, line
   breaks, and other white space probably indicate a transmission error,
   about which a warning message or even a message rejection might be
   appropriate under some circumstances.  Decoding software must ignore
   all white space.

   Because it is used only for padding at the end of the data, the
   occurrence of any "=" characters may be taken as evidence that the
   end of the data has been reached (without truncation in transit).  No
   such assurance is possible, however, when the number of octets
   transmitted was a multiple of three and no "=" characters are
   present.

It should say:

   In Radix-64 data, characters other than those in the table, line
   breaks earlier than defined by the first line's length without
   following '=' or '-', line breaks at the beginning of a line, and
   other white space probably indicate a transmission error, about which
   a warning message or even a message rejection might be appropriate
   under some circumstances.  After that check, decoding software must
   ignore all white space.

   The boundary between encoded data and encoded checksum is before the
   last '=' of a sequence of one, two or three '='.

Notes:

Might reject and must ignore is a contradiction.
There is always at least one '=', i.e. the beginning of the encoded
checksum.

Changed to editorial.
--VERIFIER NOTES--
There is no contradiction. The implementation must ignore all whitespace, and must reject all bogus ‘=’ characters.

Report New Errata