RFC Errata
Found 5 records.
Status: Verified (4)
RFC 4880, "OpenPGP Message Format", November 2007
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: 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 updated by RFC 5581
Source of RFC: openpgp (sec)
Errata ID: 7889
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2024-04-10
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 ☹