RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (4)

RFC 4880, "OpenPGP Message Format", November 2007

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.

Report New Errata