Signature packets (type 2) bind user IDs and subkeys to a key, revoke them, and sign data. Much of what a key file says, such as what a key may be used for and when it expires, is in the subpackets of its self-signatures. Numbers are big-endian; this page follows RFC 9580 section 5.2 (Tables 4–10) and the IANA OpenPGP registries.
Signature packet
| Field | Version 4 | Version 6 |
|---|---|---|
| Version | 1 byte: 4 | 1 byte: 6 |
| Signature type | 1 byte; see types | Same |
| Public key algorithm | 1 byte | Same |
| Hash algorithm | 1 byte | Same |
| Hashed subpackets | 2-byte length, then subpackets | 4-byte length, then subpackets |
| Unhashed subpackets | 2-byte length, then subpackets | 4-byte length, then subpackets |
| Hash prefix | 2 bytes: the left 16 bits of the signed hash | Same; a verifier must reject the signature if they do not match |
| Salt | – | 1-byte size, which must match the hash algorithm (16 for SHA2-256, 32 for SHA2-512, …), then the random salt |
| Signature | Algorithm-specific: one MPI for RSA, two (r, s) for DSA and ECDSA, 64 bytes for Ed25519, 114 for Ed448 | Same |
What is hashed is the signed data, then the signature from the version through the hashed subpackets, then a 6-byte trailer (section 5.2.3.6). Hashed subpackets are covered by the signature; unhashed ones are not protected and should hold only advisory information. Version 3 signatures (a 5-byte hashed part: type and creation time, then an 8-byte key ID) must not be created with ECDSA, EdDSA, Ed25519 or Ed448.
Signature types
| Type | Meaning |
|---|---|
0x00 | Signature of a binary document |
0x01 | Signature of a canonical text document (CR LF line endings) |
0x02 | Standalone signature, of its own subpackets (as over an empty document) |
0x10 | Generic certification of a user ID and key: no claim about how well the identity was checked. RFC 9580: most implementations make their key signatures this type. |
0x11 | Persona certification (no checking of identity) |
0x12 | Casual certification (some checking) |
0x13 | Positive certification (substantial checking) |
0x18 | Subkey binding, by the primary key. Binding a signing subkey requires an embedded 0x19. |
0x19 | Primary key binding, by a signing subkey over the primary key and subkey |
0x1F | Direct key signature, over the key itself (for key flags and similar) |
0x20 | Key revocation |
0x28 | Subkey revocation |
0x30 | Certification revocation |
0x40 | Timestamp signature |
0x50 | Third-party confirmation |
0xFF | Reserved |
All other values are unassigned.
Subpackets
Each subpacket is a length (one, two or five bytes, as for packet lengths but without partial lengths; it counts the type byte and the data), a type byte and the data. Bit 7 of the type byte marks the subpacket critical: an evaluator that meets an unknown critical subpacket should consider the signature in error, and should ignore unknown non-critical ones (section 5.2.3.7).
| Type | Subpacket | Data |
|---|---|---|
| 0, 1 | Reserved | – |
| 2 | Signature creation time | 4-byte time |
| 3 | Signature expiration time | 4-byte seconds after creation; 0 never |
| 4 | Exportable certification | 1 byte: 0 local only |
| 5 | Trust signature | Level and amount |
| 6 | Regular expression | Zero-terminated expression limiting a trust signature |
| 7 | Revocable | 1 byte: 0 cannot be revoked |
| 8 | Reserved | – |
| 9 | Key expiration time | 4-byte seconds after key creation; 0 never |
| 10 | Placeholder for backward compatibility | – |
| 11 | Preferred symmetric ciphers for v1 SEIPD | List of cipher IDs |
| 12 | Revocation key (deprecated) | Class, algorithm and fingerprint of a key allowed to revoke this one |
| 13–15 | Reserved | – |
| 16 | Issuer key ID | 8-byte key ID of the signer |
| 17–19 | Reserved | – |
| 20 | Notation data | 4 flag bytes (0x80000000: human-readable), name length, value length, name, value |
| 21 | Preferred hash algorithms | List of hash IDs |
| 22 | Preferred compression algorithms | List of compression IDs |
| 23 | Key server preferences | Flags; 0x80 no-modify |
| 24 | Preferred key server | URI |
| 25 | Primary user ID | 1 byte: non-zero for the primary user ID |
| 26 | Policy URI | URI |
| 27 | Key flags | See key flags |
| 28 | Signer’s user ID | The user ID the signer signs as |
| 29 | Reason for revocation | Reason code and text; see reasons |
| 30 | Features | Flags: 0x01 version 1 SEIPD supported, 0x08 version 2 SEIPD supported; 0x02, 0x04 reserved |
| 31 | Signature target | Algorithms and hash of the signature this one refers to |
| 32 | Embedded signature | A whole signature packet body (the primary key binding) |
| 33 | Issuer fingerprint | Key version byte and the signer’s fingerprint |
| 34 | Reserved | – |
| 35 | Intended recipient fingerprint | Key version and fingerprint of an intended recipient |
| 36 | Not listed in RFC 9580 Table 5 | – |
| 37 | Reserved (attested certifications) | – |
| 38 | Reserved (key block) | – |
| 39 | Preferred AEAD ciphersuites | Pairs of cipher and AEAD mode IDs |
| 40–99, 111–127 | Not listed | – |
| 100–110 | Private or experimental | – |
Key flags
| Bit (first byte) | The key may… |
|---|---|
0x01 | Make user ID certifications (0x10–0x13) or direct key signatures (0x1F) over other keys |
0x02 | Sign data |
0x04 | Encrypt communications |
0x08 | Encrypt storage |
0x10 | Be split by a secret-sharing mechanism (its private part) |
0x20 | Authenticate |
0x80 | Be in the possession of more than one person |
In the second byte, 0x04 and 0x08 are reserved (for ADSK
and timestamping). The list may be any length; missing flags are zero, and the
subpacket should be marked critical. The split-key (0x10) and group-key
(0x80) flags belong only on self-signatures (section 5.2.3.29).
Reasons for revocation
| Code | Reason |
|---|---|
| 0 | No reason specified (key or certification revocations) |
| 1 | Key is superseded (key revocations) |
| 2 | Key material has been compromised (key revocations) |
| 3 | Key is retired and no longer used (key revocations) |
| 32 | User ID information is no longer valid (certification revocations) |
| 100–110 | Private use |