RFC Errata
Found 55 records.
Status: Verified (5)
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
Source of RFC: openpgp (sec)
Errata ID: 2270
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Shaw
Date Reported: 2010-05-18
Verifier Name: Sean Turner
Date Verified: 2010-07-20
Section 5.2.2 says:
SHA224: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
0x00, 0x04, 0x1C
It should say:
SHA224: 0x30, 0x2d, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
0x00, 0x04, 0x1C
Notes:
The second byte as published in 4880 is 0x31 but should be 0x2d.
Hal Finney noted this once, but I didn't see it entered in as an errata.
Errata ID: 2271
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Shaw
Date Reported: 2010-05-18
Verifier Name: Sean Turner
Date Verified: 2010-07-20
Section 6.5 says:
Input data: 0x14FB9C03D97E Hex: 1 4 F B 9 C | 0 3 D 9 7 E 8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110 6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110 Decimal: 5 15 46 28 0 61 37 62 Output: F P u c A 9 l +
It should say:
Input data: 0x14FB9C03D97E Hex: 1 4 F B 9 C | 0 3 D 9 7 E 8-bit: 00010100 11111011 10011100 | 00000011 11011001 01111110 6-bit: 000101 001111 101110 011100 | 000000 111101 100101 111110 Decimal: 5 15 46 28 0 61 37 62 Output: F P u c A 9 l +
Notes:
This example shows the conversion of 0x14FB9C03D97E into Radix-64. The problem is in the last byte, where '7E' is shown in binary as 11111110. That of course should be 01111110. The error is carried through in the 6-bit rendering of that data where the next-to-last 6-bit group 100111 should actually be 100101. The decimal rendering as well as the output (character) line is correct.
Errata ID: 3298
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2012-07-27
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16
Section 5.2.4 says:
Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked.
It should say:
Primary key revocation signatures (type 0x20) hash only the key being revoked. Subkey revocation signature (type 0x28) hash first the primary key and then the subkey being revoked.
Notes:
This amendment to subkey revocation signatures is intended to align the spec with existing implementations. (it also makes the subkey revocation signatures more symmetric with the subkey binding signatures).
GnuPG (all known versions with subkey support) hashes both keys, as does PGP (tested at version 6.5.8). I'm unaware of any other OpenPGP implementation that actually complies with the spec as written for subkey revocations.
This was apparently noticed (but apparently ignored) back in 2000 (see point 2 of [0]) and was recently discussed again on the IETF list [1].
[0] http://www.mhonarc.org/archive/html/ietf-openpgp/2000-12/msg00001.html
[1] http://www.mhonarc.org/archive/html/ietf-openpgp/2012-07/msg00003.html
Errata ID: 7889
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2024-04-10
Verifier Name: Paul Wouters
Date Verified: 2024-04-21
Section 5.2.3.23 says:
Note that any signature may be revoked, including a certification on some other person's key.
It should say:
Note that any certification may be revoked, including a certification on some other person's key.
Notes:
the only three types of revocation that are specified in OpenPGP are:
0x20: Key revocation signature
The signature is calculated directly on the key being revoked. A
revoked key is not to be used. Only revocation signatures by the
key being revoked, or by an authorized revocation key, should be
considered valid revocation signatures.
0x28: Subkey revocation signature
The signature is calculated directly on the subkey being revoked.
A revoked subkey is not to be used. Only revocation signatures
by the top-level signature key that is bound to this subkey, or
by an authorized revocation key, should be considered valid
revocation signatures.
0x30: Certification revocation signature
This signature revokes an earlier User ID certification signature
(signature class 0x10 through 0x13) or direct-key signature
(0x1F). It should be issued by the same key that issued the
revoked signature or an authorized revocation key. The signature
is computed over the same data as the certificate that it
revokes, and should have a later creation date than that
certificate.
There is no explicit mechanism to revoke a document signature (as opposed to a certification signature), so it makes no sense to claim that "any signature may be revoked".
This was observed by Andrew Gallagher in https://gitlab.com/dkg/openpgp-revocation/-/issues/15, and is still an issue in the successor to RFC 4880, draft-ietf-openpgp-crypto-refresh ☹
Errata ID: 2242
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20
Section 13.1.3. says:
mL = intended length in octets of the encoded message, at least tLen
+ 11, where tLen is the octet length of the DER encoding T of a
certain value computed during the encoding operation
It should say:
emLen = intended length in octets of the encoded message, at least
tLen + 11, where tLen is the octet length of the DER encoding T
of a certain value computed during the encoding operation
Notes:
In the following text it is called emLen.
Changed to editorial.
Status: Reported (1)
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
Source of RFC: openpgp (sec)
Errata ID: 7970
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Huigens
Date Reported: 2024-06-04
Section 13.1.3 says:
2. Using the list in Section 5.2.2, produce an ASN.1 DER value for
the hash function used. Let T be the full hash prefix from
Section 5.2.2, and let tLen be the length in octets of T.
It should say:
2. Using the list in Section 5.2.2, produce an ASN.1 DER value for
the hash function used and the hash digest. Let T be the full
hash prefix from Section 5.2.2, concatenated with the hash
digest H, and let tLen be the length in octets of T.
Notes:
This section is an informational (non-normative) copy of section 9.2 of RFC 3447.
However, it mistakenly omits the hash digest from the value T, and thus unintentionally diverges from RFC 3447.
Technically speaking, this does not affect the rest of RFC 4880 as its other sections refer to RFC 3447 rather than this section, but it is nevertheless incorrect and potentially confusing.
All implementations implement it correctly, however, so accepting this erratum should not lead to any changes in implementations.
Status: Held for Document Update (17)
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
Source of RFC: openpgp (sec)
Errata ID: 2199
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 3.7.2.1. says:
For compatibility, when an S2K specifier is used, the special value 254 or 255 is stored in the position where the hash algorithm octet would have been in the old data structure. This is then followed immediately by a one-octet algorithm identifier, and then by the S2K specifier as encoded above.
It should say:
For compatibility, when an S2K specifier is used, the special value 254 or 255 is stored in the position where the cipher algorithm octet would have been in the old data structure. This is then followed immediately by a one-octet cipher algorithm identifier, and then by the S2K specifier as encoded above.
Notes:
The paragraph before says:
Older versions of PGP just stored a cipher algorithm octet preceding
the secret data or a zero to indicate that the secret data was
unencrypted. The MD5 hash function was always used to convert the
passphrase to a key for the specified cipher algorithm.
Errata ID: 2200
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 3.7.2.1. says:
This last possibility, the cipher algorithm number with an implicit use of MD5 and IDEA, is provided for backward compatibility;
It should say:
This last possibility, the cipher algorithm number with an implicit use of MD5, is provided for backward compatibility;
Notes:
The cipher algorithm is determined by the number. There is no implicit
use of IDEA.
Errata ID: 2206
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 5.1. says:
A Public-Key Encrypted Session Key packet holds the session key used to encrypt a message.
It should say:
A Public-Key Encrypted Session Key (PKESK) packet holds the session key used to encrypt a message.
Notes:
The acronym PKESK is not defined.
Tweaked the suggestion to reword the 1st sentence in 5.1 to define it.
Errata ID: 2208
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 5.2.1. says:
This signature is a statement by a signing subkey, indicating that it is owned by the primary key and subkey.
It should say:
This signature is a statement by a signing subkey, indicating that it is owned by the primary key.
Notes:
The subkey does not own itself.
Errata ID: 2214
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 5.2.3. says:
The concatenation of the data being signed and the signature data from the version number through the hashed subpacket data (inclusive) is hashed. The resulting hash value is what is signed. The left 16 bits of the hash are included in the Signature packet to provide a quick test to reject some invalid signatures. There are two fields consisting of Signature subpackets. The first field is hashed with the rest of the signature data, while the second is unhashed.
It should say:
The concatenation of the data being signed and the signature data from the version number through the hashed subpacket data (inclusive), plus a six-octet trailer (see section 5.2.4) is hashed. The resulting hash value is converted to the signature. The left 16 bits of the hash are included in the Signature packet to provide a quick test to reject some invalid signatures. There are two fields consisting of Signature subpackets. The first field (together with the preceding parts of the signature) is included in the hash, while the second is not.
Notes:
There are six more octets (see 5.2.4.).
The data being signed is signed. The hash value is not signed, but
converted into the signature.
The first field is not hashed (does not contain a hash), but it is
hashincluded. It is not true that the rest of the signature data is used
in the hash. (This formulation is such strange for accuracy.)
Unhashing is the reverse of hashing, which is hopefully unfeasible.
Modified text.
Errata ID: 2216
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 5.2.3.3. says:
Subpackets that appear in a certification self-signature apply to the user name, and subpackets that appear in the subkey self-signature apply to the subkey.
It should say:
Subpackets that appear in a certification self-signature apply to the User ID, and subpackets that appear in the subkey self-signature apply to the subkey.
Notes:
User ID, not user name
Errata ID: 2219
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 5.3. says:
The message is encrypted with a session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet or the Symmetric-Key Encrypted Session Key packet.
It should say:
The message is encrypted with a session key, and the session key is itself encrypted and stored in the Public-Key Encrypted Session Key packet or the Symmetric-Key Encrypted Session Key packet.
Notes:
The word `Public-Key' is missing.
Changed to editorial
Errata ID: 2222
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 5.5.3. says:
Implementations MUST use a string-to-key specifier; the simple hash is for backward compatibility and is deprecated, though implementations MAY continue to use existing private keys in the old format.
It should say:
Implementations MUST generate a string-to-key specifier; the simple hash is for backward compatibility and is deprecated, though implementations MAY continue to use existing private keys in the old format.
Notes:
MUST use and MAY continue to use the opposite is a contradiction.
Changed to editorial.
Errata ID: 2226
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 5.9. says:
These should be converted to native line endings by the receiving
software.
It should say:
These SHOULD be converted to native line endings by the receiving
software.
Notes:
This is a SHOULD of [RFC2119].
Changed to editorial.
Errata ID: 2234
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 6.5. says:
Examples of Radix-64
It should say:
Examples of base64
Notes:
Radix-64 has a checksum, too.
Changed to editorial.
Errata ID: 2235
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 8. says:
If two characters in the sequence are separated by '-', this is shorthand for the full list of ASCII characters between them (e.g., '[0-9]' matches any decimal digit).
It should say:
If two characters in the sequence are separated by '-', this is shorthand for the full list of ASCII characters between them (e.g., '[0-9]' matches any decimal digit). The collation sequence is UTF-8.
Notes:
UTF-8 has the collation sequence of unicode. You probably do not want
to have the system's locale involved.
Maybe a hint on greediness of regex is nessessary, too.
Changed to editorial.
Errata ID: 2236
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 11. says:
11. Packet Composition (the headline)
It should say:
11. Packet Sequence Composition
Notes:
It is about the composition of a sequence of packets, not about the
composition of a packet.
Errata ID: 2238
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 11.1. says:
After the User ID packet or Attribute packet, there may be zero or more Subkey packets.
It should say:
After the sequence with the User ID packets and User Attribute packets, there may be zero or more Subkey packets.
Notes:
The Subkey packets come after all User ID packets and User Attribute
packets.
Changed to editorial.
Errata ID: 2240
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 12.1. says:
In the above diagram, if the binding signature of a subkey has been revoked, the revoked key may be removed, leaving only one key.
It should say:
In the above diagram, if the binding signature of a subkey has been revoked, the revoked key may be removed. Note that this bears the danger of importing the subkey again without the Binding Signature Revocation.
Notes:
If there are more than one subkeys, the removing of one leaves more
than one key. And the warning is missing.
Changed to editorial.
Errata ID: 2243
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 13.9. says:
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and prefixes the plaintext with BS+2 octets of random data, such that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB resynchronization after encrypting those BS+2 octets. Thus, for an algorithm that has a block size of 8 octets (64 bits), the IV is 10 octets long and octets 7 and 8 of the IV are the same as octets 9 and 10. For an algorithm with a block size of 16 octets (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate octets 15 and 16. Those extra two octets are an easy check for a correct key.
It should say:
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and prefixes the plaintext with BS+2 octets of random data, such that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB resynchronization after encrypting those BS+2 octets. Thus, for an algorithm that has a block size of 8 octets (64 bits), the virtual IV is 10 octets long and octets 7 and 8 of the virtual IV are the same as octets 9 and 10. For an algorithm with a block size of 16 octets (128 bits), the virtual IV is 18 octets long, and octets 17 and 18 replicate octets 15 and 16. Those extra two octets are an easy check for a correct key."
Notes:
'IV' is used in a contradicting manner.
Changed to editorial.
From Jon. C.: This is a marvelous re-wording of a confusing process. I really like the “virtual IV” mentioned. However, the suggested change omitted the final sentence, which is the whole reason for the virtual IV. I have restored that sentence.
Errata ID: 5491
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marco Bellaccini
Date Reported: 2018-09-04
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-06-12
Section 6.1 says:
#define CRC24_POLY 0x1864CFBL
It should say:
#define CRC24_POLY 0x864CFBL
Notes:
In the C reference implementation of CRC-24, the generator used does not match the specification in Section 6, though the final masking step avoids a functional difference.
Errata ID: 7545
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Raghu Saxena
Date Reported: 2023-06-16
Held for Document Update by: RFC Editor
Date Held: 2023-06-19
Section 6.2 says:
The format of an Armor Header is that of a key-value pair. A colon
(':' 0x38) and a single space (0x20) separate the key and value.
OpenPGP should consider improperly formatted Armor Headers to be
corruption of the ASCII Armor. Unknown keys should be reported to
the user, but OpenPGP should continue to process the message.
It should say:
The format of an Armor Header is that of a key-value pair. A colon
(':' 0x3A) and a single space (0x20) separate the key and value.
OpenPGP should consider improperly formatted Armor Headers to be
corruption of the ASCII Armor. Unknown keys should be reported to
the user, but OpenPGP should continue to process the message.
Notes:
0x3A is a colon -> ':' , whereas 0x38 is the character for the numeral eight -> '8'
Status: Rejected (32)
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
Source of RFC: openpgp (sec)
Errata ID: 2197
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 3.5. says:
A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC.
It should say:
A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC, ignoring leap seconds.
Notes:
And I did not yet talk about relativity theory.
--VERIFIER NOTES--
The OpenPGP time is an integer denoting UTC time. An implementation is free to display with or without leap seconds just as it might display said time in a time zone.
Errata ID: 2198
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 3.7.1.3. says:
Initially, one or more hash contexts are set up as with the other S2K algorithms, depending on how many octets of key data are needed. Then the salt, followed by the passphrase data, is repeatedly hashed until the number of octets specified by the octet count has been hashed.
It should say:
Initially, one or more hash contexts are set up as with the other S2K algorithms, depending on how many octets of key data are needed. Then the concatenation of salt and passphrase data is repeated sufficiently often and concatenated. The concatenation is truncated to the number of octets specified by the octet count. The truncated concatenation is hashed.
Notes:
Did I get it right? If not, clearify it.
There are a lot of interpretations of the fuzzy instruction.
E.g. it could be repeat{data:=truncate(concatenate(hash(data)))} until
the octet count is exceeded. And it is still unclear weather you have to
count for each hash context separately and weather you have to count the
preloads, too.
--VERIFIER NOTES--
Submitter does not even know if the erratum is correct.
Errata ID: 2201
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 4.2. says:
The first octet of the packet header is called the "Packet Tag". It
determines the format of the header and denotes the packet contents.
The remainder of the packet header is the length of the packet.
...
+---------------+
PTag |7 6 5 4 3 2 1 0|
+---------------+
Bit 7 -- Always one
Bit 6 -- New packet format if set
It should say:
The first octet of the packet header encodes the packet format and
the "Packet Tag". It determines the format of the header and denotes
the packet contents. The remainder of the packet header is the length
of the packet body.
...
+---------------+
|7 6 5 4 3 2 1 0|
+---------------+
Bit 7 -- Always one
Bit 6 -- New packet format if set
Notes:
Only a part of the first octet (depending on the packet format, i.e.
depending on bit 6 of the first octet) is the Packet Tag.
The packet consists of header and body. The encoded length is the length
of the packet body.
--VERIFIER NOTES--
The suggestion is incorrect. The first octet of the header is called the packet tag. The packet tag contains other information besides tag information, but it is nonetheless called (and has always been called) the packet tag.
Errata ID: 2202
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 4.4.1. says:
0 - The packet has a one-octet length. The header is 2 octets long. 1 - The packet has a two-octet length. The header is 3 octets long. 2 - The packet has a four-octet length. The header is 5 octets long.
It should say:
0 - The packet body has a one-octet length. The header is 2 octets
long.
1 - The packet body has a two-octet length. The header is 3 octets
long.
2 - The packet body has a four-octet length. The header is 5 octets
long.
Notes:
The packet consists of header and body. The encoded length is the length
of the packet body.
--VERIFIER NOTES--
The language is clear in the document. The Body Length refers to the length of the body. Colloquially, the document calls this the packet length, but OpenPGP is hardly unique in being a TLV record system in which the length is the length of the value, not of the Tag, Length, and Value.
Errata ID: 2203
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 4.4.2. says:
1. A one-octet Body Length header encodes packet lengths of up to 191
octets.
2. A two-octet Body Length header encodes packet lengths of 192 to
8383 octets.
3. A five-octet Body Length header encodes packet lengths of up to
4,294,967,295 (0xFFFFFFFF) octets in length. (This actually
encodes a four-octet scalar number.)
4. When the length of the packet body is not known in advance by the
issuer, Partial Body Length headers encode a packet of
indeterminate length, effectively making it a stream.
It should say:
1. A one-octet Body Length header encodes packet body lengths of up
to 191 octets.
2. A two-octet Body Length header encodes packet body lengths of 192
to 8383 octets.
3. A five-octet Body Length header encodes packet body lengths of up
to 4,294,967,295 (0xFFFFFFFF) octets in length. (This actually
encodes a four-octet scalar number.)
4. When the length of the packet body is not known in advance by the
issuer, Partial Body Length headers encode a packet of
indeterminate length, effectively making it a stream.
Notes:
The packet consists of header and body. The encoded length is the length
of the packet body.
--VERIFIER NOTES--
The language is clear in the document. The Body Length refers to the length of the body. Colloquially, the document calls this the packet length, but OpenPGP is hardly unique in being a TLV record system in which the length is the length of the value, not of the Tag, Length, and Value.
Errata ID: 2205
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 5.1. says:
The value "m" in the above formulas is derived from the session key as follows. First, the session key is prefixed with a one-octet algorithm identifier that specifies the symmetric encryption algorithm used to encrypt the following Symmetrically Encrypted Data Packet. Then a two-octet checksum is appended, which is equal to the sum of the preceding session key octets, not including the algorithm identifier, modulo 65536. This value is then encoded as described in PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to form the "m" value used in the formulas above. See Section 13.1 of this document for notes on OpenPGP's use of PKCS#1.
It should say:
?
Notes:
That is how to derive m from the session key and the algorithm
identifier.
But how to derive the session key and the algorithm identifier from m?
--VERIFIER NOTES--
Not actionable. No actual erratum.
Errata ID: 2225
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 5.9. says:
If the special name "_CONSOLE" is used, the message is considered to be "for your eyes only".
It should say:
If the special name "_CONSOLE_" is used, the message is considered to be "for your eyes only".
Notes:
If the name is actually "_CONSOLE", you should explicitly mention it.
--VERIFIER NOTES--
Erratum is wrong.
Errata ID: 2228
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 5.13. says:
The plaintext of the data to be encrypted is passed through the SHA-1 hash function, and the result of the hash is appended to the plaintext in a Modification Detection Code packet. The input to the hash function includes the prefix data described above; it includes all of the plaintext, and then also includes two octets of values 0xD3, 0x14. These represent the encoding of a Modification Detection Code packet tag and length field of 20 octets.
It should say:
The concatination of the prefix data descibed above, the plaintext to be encrypted and two octets of values 0xD3, 0x14 (These represent the encoding of a Modification Detection Code packet tag and length field of 20 octets) is passed through the SHA-1 hash function.
Notes:
The text is misleading and contradicting.
--VERIFIER NOTES--
Erratum is incorrect.
Errata ID: 2232
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 6.3. says:
The encoded output stream must be represented in lines of no more than 76 characters each.
It should say:
The encoded output stream MUST be represented in lines in according to the following algorithm. Choose a maximal line width w not greater than 76. Insert after each w characters a line break. If the last = (the beginning of the encoded checksum) is not at the beginning of a line, one line break MAY be inserted before the last =.
Notes:
The old formulation allows lines of different length and even empty
lines.
--VERIFIER NOTES--
The submitter describes legal, correct behavior, and amends the text to disallow it.
Errata ID: 2237
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 11.1. says:
User Attribute packets and User ID packets may be freely intermixed in this section, so long as the signatures that follow them are maintained on the proper User Attribute or User ID packet.
It should say:
User Attribute packets and User ID packets may be freely intermixed in this section, so long as the signatures that follow them are maintained on the proper User Attribute or User ID packet, and as long the first one is a User ID packet.
Notes:
The first one must be a User ID packet and must not be a User Attribute
packet.
--VERIFIER NOTES--
The RFC is correct. It says that they may be freely intermixed, to denote that they may be freely intermixed.
Errata ID: 3725
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kwadronaut
Date Reported: 2013-09-14
Rejected by: Sean Turner
Date Rejected: 2014-01-14
Section 5.2.3.11. says:
Some implementations do not represent the interest of a single user (for example, a key server). Such implementations always trim local certifications from any key they handle.
It should say:
Some implementations do not represent the interest of a single user (for example, a key server). Such implementations MUST always trim local certifications from any key they handle.
Notes:
Inspiration taken from a thread on sks-devel: http://lists.nongnu.org/archive/html/sks-devel/2013-09/msg00022.html
--VERIFIER NOTES--
As agreed by the authors, MUST is unnecessary here.
Errata ID: 2204
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 5.1. says:
The recipient of the message finds a session key that is encrypted to their public key, decrypts the session key, and then uses the session key to decrypt the message.
It should say:
The recipient of the message finds a Public-Key Encrypted Session Key packet that contains the session key encrypted with the recipient's public key, decrypts the session key, and then uses the session key to decrypt the message.
Notes:
There is only one session key, the session key, not a session key.
The recipient is singular.
Encrypted with public key, will be decrypted with secret key. Encrypted
(with the public key) to some cipher.
--VERIFIER NOTES--
The suggestion is more precise, but harder to read.
Errata ID: 2207
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 5.2. says:
Note that if an implementation is creating an encrypted and signed message that is encrypted to a V3 key, it is reasonable to create a V3 signature.
It should say:
Note that if an implementation is creating an encrypted and signed message that is encrypted with a V3 key, it is reasonable to create a V3 signature.
Notes:
Encrypted with a key to some cipher.
--VERIFIER NOTES--
I think we can accept that encrypting implicitly means there’s a cipher involved.
Errata ID: 2209
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 5.2.2. says:
- One-octet length of following hashed material. MUST be 5.
- One-octet signature type.
- Four-octet creation time.
It should say:
- Six-octet with the following three items.
- One-octet length of the remaining two items which are
included in the hash. MUST be 5.
- One-octet signature type.
- Four-octet creation time.
Notes:
It is not the lenght of hashed material, but it is the length of the
next two items, which are included in the hash. And these three items
belong together and have six-octet length.
--VERIFIER NOTES--
Erratum is incorrect.
Errata ID: 2210
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 5.2.2. says:
- Two-octet field holding left 16 bits of signed hash value.
It should say:
- Two-octet field holding the first 16 bits of signed hash
value.
Notes:
left is misleading. It could be remaining (from leave). And there are
cultures where the last letters of a line are on the left side.
The convention is high digit before (not left of) low digit (which may
be odd for Arabs).
--VERIFIER NOTES--
The erratum makes good point that “left” is used where “first” or “high-order” might have been a better term. However, given that we know that we use Network Byte Order, “left” is a reasonable synonym for “first.” The IETF works in English and NBO; the comments about Arabs are well-taken, but pedantic and add no value.
Additionally, a search of other RFCs shows that we are not alone in using “left” to mean “high-order.” While this may be idiomatic rather than well-defined, our research shows it’s an IETF idiom as much as an OpenPGP idiom.
Errata ID: 2211
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 5.2.2. says:
The details of the calculation are different for DSA signatures than for RSA signatures.
It should say:
The details of the calculation are different for DSA signatures from that for RSA signatures.
Notes:
different from, not different than
--VERIFIER NOTES--
Our research shows that this is a matter of opinion -- in US English grammar, the “different than” is acceptable this way. Jon prefers “different from” (the suggested erratum) and David “different than.” Thus our agreed resolution is to reject, as this is debate over usage, not an actual erratum.
Errata ID: 2212
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 5.2.3. says:
- Two-octet field holding the left 16 bits of the signed hash
value.
...
The left 16 bits of the hash are included in the Signature packet to
provide a quick test to reject some invalid signatures.
It should say:
- Two-octet field holding the high 16 bits of the signed hash
value.
...
The high 16 bits (first two octets) of the hash are included in the
Signature packet to provide a quick test to reject some invalid
signatures.
Notes:
Use exactly the sentence from 5.2.2.
left is misleading. It could be remaining (from leave). And there are
cultures where the last letters of a line are on the left side.
The convention is high digit before (not left of) low digit (which may
be odd for Arabs).
--VERIFIER NOTES--
Like errata 2210, but here Constantin corrects to “high” rather than “first.” I don’t believe either is so misleading as to warrant a change.
Errata ID: 2213
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 5.2.3. says:
- Two-octet scalar octet count for following hashed subpacket data.
- Hashed subpacket data set (zero or more subpackets).
- Two-octet scalar octet count for the following unhashed subpacket
data.
- Unhashed subpacket data set (zero or more subpackets).
It should say:
- Two-octet scalar octet count for following hashincluded subpacket
data.
- Hashincluded subpacket data set (zero or more subpackets).
- Two-octet scalar octet count for the following not hashincluded
subpacket data.
- Not hashincluded subpacket data set (zero or more subpackets).
Notes:
The first field does not contain a hash. But it is included in the hash.
Unhashing is the reverse of hashing, which is hopefully unfeasible.
--VERIFIER NOTES--
This is incorrect.
Errata ID: 2215
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 5.2.3.1. says:
An implementation SHOULD ignore any subpacket of a type that it does not recognize. Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error.
It should say:
Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error. An implementation SHOULD ignore any subpacket of a type that it does not recognize.
Notes:
The explanation for recognizing should come before recognizing is used.
--VERIFIER NOTES--
The existing text explains the rule of thumb, and then the exception. The suggestion would be more confusing than the original.
Errata ID: 2217
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 5.2.3.18. says:
Note also that since this is a URI, the key server can actually be a copy of the key retrieved by ftp, http, finger, etc.
It should say:
?
Notes:
Nonsense. The key server is not a copy of a key.
I do not get the point. What should be noted?
Modified to editorial.
--VERIFIER NOTES--
Not actionable. No actual erratum. To answer the question, this text reminds the reader that a URI can refer to a static entity, as well as a query to a server. Yes, this is arguably superfluous, but it is there because of the WG’s rough consensus.
Errata ID: 2218
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 5.2.4. says:
All signatures are formed by producing a hash over the signature data, and then using the resulting hash in the signature algorithm. For binary document signatures (type 0x00), the document data is hashed directly. For text document signatures (type 0x01), the document is canonicalized by converting line endings to <CR><LF>, and the resulting data is hashed. When a signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body of the key packet. (Note that this is an old-style packet header for a key packet with two-octet length.) A subkey binding signature (type 0x18) or primary key binding signature (type 0x19) then hashes the subkey using the same format as the main key (also using 0x99 as the first octet). Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked. A certification signature (type 0x10 through 0x13) hashes the User ID being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the User ID or attribute packet packet, without any header. A V4 certification hashes the constant 0xB4 for User ID certifications or the constant 0xD1 for User Attribute certifications, followed by a four-octet number giving the length of the User ID or User Attribute data, and then the User ID or User Attribute data. When a signature is made over a Signature packet (type 0x50), the hash data starts with the octet 0x88, followed by the four-octet length of the signature, and then the body of the Signature packet. (Note that this is an old-style packet header for a Signature packet with the length-of-length set to zero.) The unhashed subpacket data of the Signature packet being hashed is not included in the hash, and the unhashed subpacket data length value is set to zero. Once the data body is hashed, then a trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by the four-octet signature time. A V4 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data. Thus, the fields hashed are the signature version, the signature type, the public-key algorithm, the hash algorithm, the hashed subpacket length, and the hashed subpacket body. V4 signatures also hash in a final trailer of six octets: the version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet, big-endian number that is the length of the hashed data from the Signature packet (note that this number does not include these final six octets). After all this has been hashed in a single hash context, the resulting hash field is used in the signature algorithm and placed at the end of the Signature packet.
It should say:
All signatures are formed by producing a hash over the signature data, and then using the resulting hash in the signature algorithm. The signature data is the concatenation of a body and a trailer. For binary document signatures (type 0x00), the document data is is the sinature data body. For text document signatures (type 0x01), the document is canonicalized by converting line endings to <CR><LF>, and the resulting data is the sinature data body. When a signature is made over one key, the signature data body is a Public-Key packet (see 5.5.) in the old packet format with two-octet body length (octet 0x99, followed by the two-octet body length, followed by the Public-Key packet body). The signature data body of a subkey binding signature (type 0x18) or of a primary key binding signature (type 0x19) is the concatination of the Public-Key packet of the main key and a Public-Key (not a Public-Subkey packet) packet of the subkey in the format discribed above. The signature data body of a Key Revocation signatures (type 0x20 or 0x28) is the Public-Key packet of the key being revoked in the format described above. The signature data body for a V3 certification signature (type 0x10 through 0x13) is the concatination of the key packet in the format described above and the body of a User ID packet (see 5.11.). The signature data body for a V4 certification signature (type 0x10 through 0x13) is the concatenation of the key packet in the format descibed above, either the constant 0xB4 for User ID certification or the constant 0xD1 for User Attribute certification (User Attribute packets are not a required part of the OpenPGP standard. Except as noted, a User Attribute packet may be used anywhere that a User ID packet may be used. (see 5.12.)), a four-octet number giving the length of the User ID Packet body, and the User ID Packet body. (0xB4 starts an old-style packet header of a User ID packet with one-octet body length and 0xD1 starts the new-style packet header of a User Attribute packet. But the body length is encoded differently.) When a signature is made over a Signature packet (type 0x50), the to signed Signature packet is trimmed by leaving out the not hashincluded subpacket data and setting the not hashincluded subpacket data length to zero. The body of the signature data is the octet 0x88, followed by the four-octet-length of the to be signed Signature packet body, followed by the to be signed Signature packet body. (0x88 starts an old-style packet header of a Signature packet with one-octet body length. But the body length is encoded differently.) The signature data trailer for a V3 signature are five octets of the signature packet body, starting from the signature type field. This data is the signature type followed by the four-octet signature time. The signature data trailer for a V4 signature is the concatenation of a part of the signature packet body starting from the first field, the version number, through the end of the hashincluded subpacket data, one more time the version number (0x04), 0xFF, and a four-octet number of the length of the part included from the signature packet.
Notes:
The original is nearly unintelligible. Key, key packet, key packet body,
etc are confused until a signature hashes the User ID into a hash
context (sic!).
The 0x99 for all public-keys and the differently encoded body lenght for
User ID packets and User Attribute packets is really odd.
Proposal:
A Flag and a Feature for a new encoding of the signature body. Usage of
a the actual new-style packet headers with 0xFF and four-octet body
length.
Changed to editorial.
--VERIFIER NOTES--
As complex as the RFC’s text may be, it’s been through the IETF process including people actually coding to it. I don’t find the change any less complex and might contain errors.
Errata ID: 2220
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 5.5.3. says:
- A Public-Key or Public-Subkey packet, as described above.
It should say:
- A Public-Key or Public-Subkey packet body, as described above.
Notes:
There is no Public-Key packet header in the Secret-Key packet body.
Changed to editorial.
--VERIFIER NOTES--
Similar to Errata 2202 and 2203, it is an idiom of the document to say “packet” when it might be more precise to say “packet body.” It is, however, clear. If there are inconsistencies in this idiom, they’d make reasonable errata.
Errata ID: 2221
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 5.5.3. says:
- If the string-to-key usage octet is zero or 255, then a two-octet
checksum of the plaintext of the algorithm-specific portion (sum
of all octets, mod 65536).
It should say:
- If the string-to-key usage octet is not 254, then a two-octet
checksum of the plaintext of the algorithm-specific portion (sum
of all octets, mod 65536).
Notes:
Without the values values of 1 to 253 the following
Note that for all other values, a two-octet checksum is required.
is not just a note.
Changed to editorial.
--VERIFIER NOTES--
The RFC is correct.
Errata ID: 2223
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 5.5.3. says:
This checksum or hash is encrypted together with the
algorithm-specific fields (if string-to-key usage octet is not
zero).
It should say:
For V4 keys this checksum or hash is encrypted together with the
algorithm-specific fields (if string-to-key usage octet is not
zero).
Notes:
The following text says:
With V3 keys, the checksum is stored in the clear. With V4 keys,
the checksum is encrypted like the algorithm-specific data.
Changed to editorial.
--VERIFIER NOTES--
Text describing V3 keys precedes this text.
Errata ID: 2224
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 5.5.3. says:
Encryption/decryption of the secret data is done in CFB mode using the key created from the passphrase and the Initial Vector from the packet. A different mode is used with V3 keys (which are only RSA) than with other key formats. With V3 keys, the MPI bit count prefix (i.e., the first two octets) is not encrypted. Only the MPI non- prefix data is encrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so that the CFB block boundary is aligned with the start of the MPI data. With V4 keys, a simpler method is used. All secret MPI values are encrypted in CFB mode, including the MPI bitcount prefix.
It should say:
Encryption/decryption of the secret data is done in CFB mode using the key created from the passphrase and the Initial Vector from the packet. A different mode is used with V3 keys (which are only RSA) than with other key formats. With V3 keys, the MPI bit count prefix (i.e., the first two octets) is not encrypted. Only the MPI non- prefix data is encrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so that the CFB block boundary is aligned with the start of the MPI data. With V4 keys, a simpler method is used. All secret MPI values are encrypted in CFB mode, including the MPI bitcount prefix.
Notes:
It is unclear if the Furthermore belongs only to V3 keys.
Changed to editorial.
--VERIFIER NOTES--
Text is in a paragraph describing V3 keys.
Errata ID: 2227
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 5.12. says:
A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder.
It should say:
A User ID packet body consists of UTF-8 text that is intended to represent the name and email address of the key holder. or A User ID packet contains UTF-8 text that is intended to represent the name and email address of the key holder.
Notes:
Yes, it is pedantic. But the packet consists of header and body.
--VERIFIER NOTES--
Similar to errata 2220 etc. It is indeed pedantic as submitter notes.
Errata ID: 2229
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 5.13. says:
Suffice it to say that many people consider properties such as
deniability to be as valuable as integrity.
It should say:
It is sufficient to say that many people consider properties such
as deniability to be as valuable as integrity.
Notes:
Is that an imperative?
--VERIFIER NOTES--
Suggestion isn’t grammatical.
Errata ID: 2230
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 5.14. says:
The Modification Detection Code packet MUST be the last packet in the plaintext data that is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST appear in no other place.
It should say:
The Modification Detection Code packet MUST be the last packet in the plaintext data that is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST NOT appear in any other place.
Notes:
'MUST appear in no other place' postulates an existence in the nowhere.
--VERIFIER NOTES--
On its surface, a good suggestion, but lacks the force of the original.
Errata ID: 2231
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 5.14. says:
A Modification Detection Code packet MUST have a length of 20 octets.
It should say:
A Modification Detection Code packet MUST have a body length of 20 octets.
Notes:
The packet consists of header and body.
--VERIFIER NOTES--
Similar to errata 2220 etc. It is indeed pedantic as submitter notes.
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.
Errata ID: 2239
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 12.1. says:
Entries in square brackets are optional and ellipses indicate
repetition.
...
Primary-Key
[Revocation Self Signature]
[Direct Key Signature...]
User ID [Signature ...]
[User ID [Signature ...] ...]
[User Attribute [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...]
It should say:
Entries in square brackets are optional, vertical bar separates
alternatives, and ellipses indicate repetition.
...
Primary-Key
[Revocation Self Signature]
[Direct Key Signature...]
User ID [Signature ...]
[[User ID [Signature ...] |
[User Attribute [Signature ...]]...]
[[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...]
Notes:
11.1. says:
User Attribute packets and User ID packets may be freely intermixed
in this section, so long as the signatures that follow them are
maintained on the proper User Attribute or User ID packet, and as
long the first one is a User ID packet.
Changed to editorial.
--VERIFIER NOTES--
The RFC is correct. It says that they may be freely intermixed, to denote that they may be freely intermixed.
Errata ID: 2241
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 12.2. says:
The fingerprint of a V3 key is formed by hashing the body (but not the two-octet length) of the MPIs that form the key material (public modulus n, followed by exponent e) with MD5.
It should say:
The fingerprint of a V3 key is formed by hashing the concatenation of the bodies of the MPIs (MPI without two-octet length) that form the key material (public modulus n, followed by exponent e) with MD5.
Notes:
There are two bodies and one hash.
Changed to editorial.
--VERIFIER NOTES--
It could have been:
... by hashing the body (but not the two-octet length) of the two MPIs
^^^
But, it's clear from the parenthetical that there are two MPIs.