RFC Errata
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: 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.