RFC 4880, "OpenPGP Message Format", November 2007

Note: This RFC has been updated by RFC 5581

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.

Report New Errata