RFC 4880, "OpenPGP Message Format", November 2007

Note: This RFC has been updated by RFC 5581

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.

Report New Errata