A Signature packet describes a binding between some public key and some data.
The most common signatures are a signature of a file or a block of text and a signature that is a certification of a User ID.¶
Three versions of Signature packets are defined.
Version 3 provides basic signature information, while versions 4 and 6 provide an expandable format with subpackets that can specify more information about the signature.¶
For historical reasons, versions 1, 2, and 5 of the Signature packet are unspecified.
Any new Signature packet version should be registered in the registry established in Section 10.3.2.2.¶
The body of a version 4 or version 6 Signature packet contains:¶
-
A 1-octet version number.
This is 4 for version 4 signatures and 6 for version 6 signatures.¶
-
A 1-octet Signature Type ID.¶
-
A 1-octet public key algorithm.¶
-
A 1-octet hash algorithm.¶
-
A scalar octet count for the hashed subpacket data that follows this field. For a version 4 signature, this is a 2-octet field.
For a version 6 signature, this is a 4-octet field.
Note that this is the length in octets of all of the hashed subpackets; an implementation's pointer incremented by this number will skip over the hashed subpackets.¶
-
A hashed subpacket data set (zero or more subpackets).¶
-
A scalar octet count for the unhashed subpacket data that follows this field.
For a version 4 signature, this is a 2-octet field.
For a version 6 signature, this is a 4-octet field.
Note that this is the length in octets of all of the unhashed subpackets; an implementation's pointer incremented by this number will skip over the unhashed subpackets.¶
-
An unhashed subpacket data set (zero or more subpackets).¶
-
A 2-octet field holding the left 16 bits of the signed hash value.¶
-
Only for version 6 signatures, a variable-length field containing:¶
-
A 1-octet salt size. The value MUST match the value defined for the hash algorithm as specified in Table 23.¶
-
The salt, which is a random value of the specified size.¶
-
One or more MPIs comprising the signature.
This portion is algorithm specific.¶
With RSA signatures, the hash value is encoded using PKCS#1 encoding type EMSA-PKCS1-v1_5, as described in Section 9.2 of [RFC8017] (see also Section 12.1.3).
This requires inserting the hash value as an octet string into an ASN.1 structure.
The object identifier (OID) for the hash algorithm itself is also included in the structure; see the OIDs in Table 24.¶
A version 3 signature MUST NOT be created and MUST NOT be used with the Elliptic Curve Digital Signature Algorithm (ECDSA).¶
A DSA signature MUST use a hash algorithm with a digest size of at least the number of bits of q, the group generated by the DSA key's generator value.¶
If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q.
This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm.¶
An ECDSA signature MUST use a hash algorithm with a digest size of at least the curve's "fsize" value (see Section 9.2), except in the case of NIST P-521, for which at least a 512-bit hash algorithm MUST be used.¶
A version 3 signature MUST NOT be created and MUST NOT be used with EdDSALegacy.¶
An EdDSALegacy signature MUST use a hash algorithm with a digest size of at least the curve's "fsize" value (see Section 9.2).
A verifying implementation MUST reject any EdDSALegacy signature that uses a hash algorithm with a smaller digest size.¶
The two MPIs for Ed25519Legacy represent the octet strings R and S of the Edwards-curve Digital Signature Algorithm (EdDSA) described in [RFC8032].¶
-
MPI of an EC point R, represented as a (non-prefixed) native (little-endian) octet string up to 32 octets.¶
-
MPI of EdDSA value S, also in (non-prefixed) native (little-endian) format with a length up to 32 octets.¶
Ed25519Legacy MUST NOT be used in Signature packets version 6 or above.¶
For more details, see Section 12.7.¶
A version 3 signature MUST NOT be created and MUST NOT be used with Ed25519.¶
An Ed25519 signature MUST use a hash algorithm with a digest size of at least 256 bits.
A verifying implementation MUST reject any Ed25519 signature that uses a hash algorithm with a smaller digest size.¶
For more details, see Section 12.7.¶
A version 3 signature MUST NOT be created and MUST NOT be used with Ed448.¶
An Ed448 signature MUST use a hash algorithm with a digest size of at least 512 bits.
A verifying implementation MUST reject any Ed448 signature that uses a hash algorithm with a smaller digest size.¶
The concatenation of the data being signed, the signature data from the version number through the hashed subpacket data (inclusive), and (for signature versions later than 3) a 6-octet trailer (see Section 5.2.4) is hashed. The resulting hash value is what is signed. The high 16 bits (first two octets) of the hash are included in the Signature packet to provide a way to reject some invalid signatures without performing a signature verification. When verifying a version 6 signature, an implementation MUST reject the signature if these octets do not match the first two octets of the computed hash.¶
There are two fields consisting of Signature subpackets.
The first field is hashed with the rest of the signature data, while the second is not hashed into the signature. The second set of subpackets (the "unhashed section") is not cryptographically protected by the signature and should include only advisory information. See Section 13.13 for more information.¶
The differences between a version 4 and version 6 signature are two-fold: first, a version 6 signature increases the width of the fields that indicate the size of the hashed and unhashed subpackets, making it possible to include significantly more data in subpackets.
Second, the hash is salted with random data (see Section 13.2).¶
The algorithms for converting the hash function result to a signature are described in Section 5.2.4.¶
A subpacket data set consists of zero or more Signature subpackets.
In Signature packets, the subpacket data set is preceded by a 2-octet (for version 4 signatures) or 4-octet (for version 6 signatures) scalar count of the length in octets of all the subpackets.
A pointer incremented by this number will skip over the subpacket data set.¶
Each subpacket consists of a subpacket header and a body.
The header consists of:¶
- The encoded subpacket length (1, 2, or 5 octets).¶
- The encoded Subpacket Type ID (1 octet).¶
- The subpacket-specific data.¶
The subpacket length field covers the encoded Subpacket Type ID and the subpacket-specific data, and it does not include the subpacket length field itself. It is encoded similarly to a 1-octet, 2-octet, or 5-octet OpenPGP format packet header. The encoded subpacket length can be decoded as follows:¶
if the 1st octet < 192, then
lengthOfLength = 1
subpacketLen = 1st_octet
if the 1st octet >= 192 and < 255, then
lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then
lengthOfLength = 5
subpacket length = [4-octet scalar starting at 2nd_octet]
¶
Bit 7 of the encoded Subpacket Type ID is the "critical" bit.
If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating implementation, the evaluator SHOULD consider the signature to be in error.¶
An implementation SHOULD ignore any non-critical subpacket of a type that it does not recognize.¶
An evaluator may "recognize" a subpacket but not implement it.
The purpose of the critical bit is to allow the signer to tell an evaluator that it would prefer a new, unknown feature to generate an error rather than being ignored.¶
The other bits of the encoded Subpacket Type ID (i.e., bits 6-0) contain the Subpacket Type ID.¶
The following signature subpackets are defined:¶
Implementations SHOULD implement the four preferred algorithm subpackets (11, 21, 22, and 39), as well as the "Features" (30) and "Reason for Revocation" (29) subpackets.
To avoid surreptitious forwarding (see Section 13.12), implementations SHOULD also implement the "Intended Recipients Fingerprint" (35) subpacket.
Note that if an implementation chooses not to implement some of the preferences subpackets, it MUST default to the mandatory-to-implement algorithms to ensure interoperability.
An encrypting implementation that does not implement the "Features" (30) subpacket SHOULD select the type of encrypted data format based on the versions of the recipient keys or external inference (see Section 13.7 for more details).¶
A number of subpackets are currently defined for OpenPGP signatures.
Some subpackets apply to the signature itself and some are attributes of the key.
Subpackets that are found on a self-signature are placed on a certification made by the key itself.
Note that a key may have more than one User ID and thus may have more than one self-signature and differing subpackets.¶
A subpacket may be found in either the hashed or the unhashed subpacket sections of a signature. If a subpacket is not hashed, then the information in it cannot be considered definitive because it is not covered by the cryptographic signature. See Section 13.13 for more discussion about hashed and unhashed subpackets.¶
It is certainly possible for a signature to contain conflicting information in subpackets.
For example, a signature may contain multiple copies of a preference or multiple expiration times. In most cases, an implementation SHOULD use the last subpacket in the hashed section of the signature, but it MAY use any conflict resolution scheme that makes more sense. Please note that conflict resolution is intentionally left to the implementer; most conflicts are simply syntax errors, and the ambiguous language here allows a receiver to be generous in what they accept, while putting pressure on a creator to be stingy in what they generate.¶
Some apparent conflicts may actually make sense. For example, suppose a keyholder has a version 3 key and a version 4 key that share the same RSA key material. Either of these keys can verify a signature created by the other, and it may be reasonable for a signature to contain an Issuer Key ID subpacket (Section 5.2.3.12) for each key, as a way of explicitly tying those keys to the signature.¶
A self-signature is a binding signature made by the key to which the signature refers. There are three types of self-signatures: the certification signatures (Type IDs 0x10-0x13), the Direct Key signature (Type ID 0x1F), and the Subkey Binding signature (Type ID 0x18). A cryptographically valid self-signature should be accepted from any primary key, regardless of what Key Flags (Section 5.2.3.29) apply to the primary key.
In particular, a primary key does not need to have 0x01 set in the first octet of the Key Flags order to make a valid self-signature.¶
For certification self-signatures, each User ID MAY have a self-signature and thus different subpackets in those self-signatures.
For Subkey Binding signatures, each subkey MUST have a self-signature.
Subpackets that appear in a certification self-signature apply to the User ID, and subpackets that appear in the subkey self-signature apply to the subkey.
Lastly, subpackets on the Direct Key signature apply to the entire key.¶
An implementation should interpret a self-signature's preference subpackets as narrowly as possible.
For example, suppose a key has two user names, Alice and Bob.
Suppose that Alice prefers the AEAD ciphersuite AES-256 with OCB, and Bob prefers Camellia-256 with GCM. If the implementation locates this key via Alice's name, then the preferred AEAD ciphersuite is AES-256 with OCB; if the implementation locates the key via Bob's name, then the preferred algorithm is Camellia-256 with GCM.
If the key is located by Key ID, the algorithm of the Primary User ID of the key provides the preferred AEAD ciphersuite.¶
Revoking a self-signature or allowing it to expire has a semantic meaning that varies with the signature type.
Revoking the self-signature on a User ID effectively retires that user name.
The self-signature is a statement, "My name X is tied to my signing key K", and it is corroborated by other users' certifications.
If another user revokes their certification, they are effectively saying that they no longer believe that name and that key are tied together.
Similarly, if the users themselves revoke their self-signature, then the users no longer go by that name, no longer have that email address, etc.
Revoking a binding signature effectively retires that subkey. Revoking a Direct Key signature cancels that signature.
Please see Section 5.2.3.31 for more relevant details.¶
Since a self-signature contains important information about the key's use, an implementation SHOULD allow the user to rewrite the self-signature and important information in it, such as preferences and key expiration.¶
When an implementation imports a secret key, it SHOULD verify that the key's internal self-signatures do not advertise features or algorithms that the implementation doesn't support.
If an implementation observes such a mismatch, it SHOULD warn the user and offer to create new self-signatures that advertise the actual set of features and algorithms supported by the implementation.¶
An implementation that encounters multiple self-signatures on the same object MUST select the most recent valid self-signature and ignore all other self-signatures.¶
By convention, a version 4 key stores information about the primary Public Key (key flags, key expiration, etc.) and the Transferable Public Key as a whole (features, algorithm preferences, etc.) in a User ID self-signature of type 0x10 or 0x13. To use a version 4 key,
some implementations require at least one User ID with a valid self-signature to be present.
For this reason, it is RECOMMENDED to include at least one User ID with a self-signature in version 4 keys.¶
For version 6 keys, it is RECOMMENDED to store information about the primary Public Key as well as the Transferable Public Key as a whole (key flags, key expiration, features, algorithm preferences, etc.) in a Direct Key signature (Type ID 0x1F) over the Public Key, instead of placing that information in a User ID self-signature.
An implementation MUST ensure that a valid Direct Key signature is present before using a version 6 key.
This prevents certain attacks where an adversary strips a self-signature specifying a Key Expiration Time or certain preferences.¶
An implementation SHOULD NOT require a User ID self-signature to be present in order to consume or use a key, unless the particular use is contingent on the keyholder identifying themselves with the textual label in the User ID.
For example, when refreshing a key to learn about changes in expiration, advertised features, algorithm preferences, revocation, subkey rotation, and so forth, there is no need to require a User ID self-signature. On the other hand, when verifying a signature over an email message, an implementation MAY choose to only accept a signature from a key that has a valid self-signature over a User ID that matches the message's From: header, as a way to avoid a signature transplant attack.¶
(4-octet time field)¶
The time the signature was made.¶
This subpacket MUST be present in the hashed area.¶
When generating this subpacket, it SHOULD be marked as critical.¶
(8-octet Key ID)¶
The OpenPGP Key ID of the key issuing the signature.
If the version of that key is greater than 4, this subpacket MUST NOT be included in the signature.
For these keys, consider the Issuer Fingerprint subpacket (Section 5.2.3.35) instead.¶
Note: in previous versions of this specification, this subpacket was simply known as the "Issuer" subpacket.¶
(4-octet time field)¶
The validity period of the key.
This is the number of seconds after the key creation time that the key expires.
For a direct or certification self-signature, the key creation time is that of the primary key.
For a Subkey Binding signature, the key creation time is that of the subkey.
If this is not present or has a value of zero, the key never expires.
This is found only on a self-signature.¶
When an implementation generates this subpacket, it SHOULD be marked as critical.¶
(array of 1-octet values)¶
A series of Symmetric Cipher Algorithm IDs indicating how the keyholder prefers to receive the version 1 Symmetrically Encrypted and Integrity Protected Data packet (Section 5.13.1).
The subpacket body is an ordered list of octets with the most preferred listed first.
It is assumed that only the algorithms listed are supported by the recipient's implementation.
Algorithm IDs are defined in Section 9.3.
This is only found on a self-signature.¶
When generating a v2 SEIPD packet, this preference list is not relevant.
See Section 5.2.3.15 instead.¶
(array of pairs of octets indicating Symmetric Cipher and AEAD algorithms)¶
A series of paired algorithm IDs indicating how the keyholder prefers to receive the version 2 Symmetrically Encrypted and Integrity Protected Data packet (Section 5.13.2).
Each pair of octets indicates a combination of a symmetric cipher and an AEAD mode that the keyholder prefers to use.
The Symmetric Cipher Algorithm ID precedes the AEAD algorithm ID in each pair.
The subpacket body is an ordered list of pairs of octets with the most preferred algorithm combination listed first.¶
It is assumed that only the combinations of algorithms listed are supported by the recipient's implementation, with the exception of the mandatory-to-implement combination of AES-128 and OCB.
If AES-128 and OCB are not found in the subpacket, it is implicitly listed at the end.¶
AEAD algorithm IDs are listed in Section 9.6.
Symmetric Cipher Algorithm IDs are listed in Section 9.3.¶
For example, a subpacket containing the six octets¶
indicates that the keyholder prefers to receive v2 SEIPD using AES-256 with OCB, then AES-256 with GCM, then Camellia-256 with OCB, and finally the implicit AES-128 with OCB.¶
Note that support for the version 2 Symmetrically Encrypted and Integrity Protected Data packet (Section 5.13.2) in general is indicated by a Features Flag (Section 5.2.3.32).¶
This subpacket is only found on a self-signature.¶
When generating a v1 SEIPD packet, this preference list is not relevant.
See Section 5.2.3.14 instead.¶
(array of 1-octet values)¶
Message digest algorithm IDs that indicate which algorithms the keyholder prefers to receive.
Like the Preferred AEAD Ciphersuites, the list is ordered.
Algorithm IDs are defined in Section 9.5.
This is only found on a self-signature.¶
(array of 1-octet values)¶
Compression algorithm IDs that indicate which algorithms the keyholder prefers to use.
Like the Preferred AEAD Ciphersuites, the list is ordered.
Algorithm IDs are defined in Section 9.4.
A zero, or the absence of this subpacket, denotes that uncompressed data is preferred; the keyholder's implementation might have no compression support available.
This is only found on a self-signature.¶
(4-octet time field)¶
The validity period of the signature.
This is the number of seconds after the Signature Creation Time that the signature expires.
If this is not present or has a value of zero, it never expires.¶
When an implementation generates this subpacket, it SHOULD be marked as critical.¶
(1 octet of exportability, 0 for not, 1 for exportable)¶
This subpacket denotes whether a certification signature is "exportable"; it is intended for use by users other than the signature's issuer.
The packet body contains a Boolean flag indicating whether the signature is exportable.
If this packet is not present, the certification is exportable; it is equivalent to a flag containing a 1.¶
Non-exportable, or "local", certifications are signatures made by a user to mark a key as valid within that user's implementation only.¶
Thus, when an implementation prepares a user's copy of a key for transport to another user (this is the process of "exporting" the key), any local certification signatures are deleted from the key.¶
The receiver of a transported key "imports" it and likewise trims any local certifications. In normal operation, there won't be any local certifications, assuming the import is performed on an exported key. However, there are instances where this can reasonably happen.
For example, if an implementation allows keys to be imported from a key database in addition to an exported key, then this situation can arise.¶
Some implementations do not represent the interest of a single user (for example, a key server).
Such implementations always trim local certifications from any key they handle.¶
When an implementation generates this subpacket and denotes the signature as non-exportable, the subpacket MUST be marked as critical.¶
(1 octet of revocability, 0 for not, 1 for revocable)¶
A Signature's revocability status. The packet body contains a Boolean flag indicating whether the signature is revocable. Signatures that are not revocable ignore any later Revocation Signatures. They represent the signer's commitment that its signature cannot be revoked for the life of its key.
If this packet is not present, the signature is revocable.¶
(1 octet "level" (depth), 1 octet of trust amount)¶
The signer asserts that the key is not only valid but also trustworthy at the specified level. Level 0 has the same meaning as an ordinary validity signature.
Level 1 means that the signed key is asserted to be a valid trusted introducer, with the 2nd octet of the body specifying the degree of trust.
Level 2 means that the signed key is asserted to be trusted to issue level 1 Trust Signatures; that is, the signed key is a "meta introducer".
Generally, a level n Trust Signature asserts that a key is trusted to issue level n-1 Trust Signatures.
The trust amount is in a range from 0-255, interpreted such that values less than 120 indicate partial trust and values of 120 or greater indicate complete trust.
Implementations SHOULD emit values of 60 for partial trust and 120 for complete trust.¶
(null-terminated UTF-8 encoded Regular Expression)¶
Used in conjunction with Trust Signature packets (of level > 0) to limit the scope of trust that is extended.
Only signatures by the target key on User IDs that match the Regular Expression in the body of this packet have trust extended by the Trust Signature subpacket.
The Regular Expression uses the same syntax as Henry Spencer's "almost public domain" Regular Expression [REGEX] package.
A description of the syntax is found in Section 8.
The Regular Expression matches (or does not match) a sequence of UTF-8-encoded Unicode characters from User IDs.
The expression itself is also written with UTF-8 characters.¶
For historical reasons, this subpacket includes a null character (an octet with value zero) after the Regular Expression.
When an implementation parses a Regular Expression subpacket, it MUST remove this octet; if it is not present, it MUST reject the subpacket (i.e., ignore the subpacket if it's non-critical and reject the signature if it's critical).
When an implementation generates a Regular Expression subpacket, it MUST include the null terminator.¶
When generating this subpacket, it SHOULD be marked as critical.¶
(1 octet of class, 1 octet of public key algorithm ID, 20 octets of version 4 fingerprint)¶
This mechanism is deprecated.
Applications MUST NOT generate such a subpacket.¶
An application that wants the functionality of delegating revocation can use an escrowed Revocation Signature.
See Section 13.9 for more details.¶
The remainder of this section describes how some implementations attempt to interpret this deprecated subpacket.¶
This packet was intended to authorize the specified key to issue Revocation Signatures for this key. The class octet must have bit 0x80 set.
If bit 0x40 is set, it means the revocation information is sensitive.
Other bits are for future expansion to other kinds of authorizations.
This is only found on a Direct Key self-signature (Type ID 0x1F).
The use on other types of self-signatures is unspecified.¶
If the "sensitive" flag is set, the keyholder feels this subpacket contains private trust information that describes a real-world sensitive relationship.
If this flag is set, implementations SHOULD NOT export this signature to other users except in cases where the data needs to be available, i.e., when the signature is being sent to the designated revoker or when it is accompanied by a Revocation Signature from that revoker.
Note that it may be appropriate to isolate this subpacket within a separate signature so that it is not combined with other subpackets that need to be exported.¶
(4 octets of flags, 2 octets of name length (M), 2 octets of value length (N), M octets of name data, N octets of value data)¶
This subpacket describes a "notation" on the signature that the issuer wishes to make.
The notation has a name and a value, each of which are strings of octets.
There may be more than one notation in a signature.
Notations can be used for any extension the issuer of the signature cares to make.
The "flags" field holds 4 octets of flags.¶
All undefined flags MUST be zero.
Defined flags are as follows:¶
Notation names are arbitrary strings encoded in UTF-8.
They reside in two namespaces: the IETF namespace and the user namespace.¶
The IETF namespace is registered with IANA.
These names MUST NOT contain the "@" character (0x40).
This is a tag for the user namespace.¶
This registry is initially empty.¶
Names in the user namespace consist of a UTF-8 string tag followed by "@", followed by a DNS domain name.
Note that the tag MUST NOT contain an "@" character.
For example, the "sample" tag used by Example Corporation could be "sample@example.com".¶
Names in a user space are owned and controlled by the owners of that domain.
Obviously, it's bad form to create a new name in a DNS space that you don't own.¶
Since the user namespace is in the form of an email address, implementers MAY wish to arrange for that address to reach a person who can be consulted about the use of the named tag.
Note that due to UTF-8 encoding, not all valid user space name tags are valid email addresses.¶
If there is a critical notation, the criticality applies to that specific notation and not to notations in general.¶
(N octets of flags)¶
This is a list of 1-bit flags that indicates preferences that the keyholder has about how the key is handled on a key server.
All undefined flags MUST be zero.¶
This is found only on a self-signature.¶
(String)¶
This is a URI of a key server that the keyholder prefers be used for updates.
Note that keys with multiple User IDs can have a Preferred Key Server for each User ID.
Note also that since this is a URI, the key server can actually be a copy of the key retrieved by https, ftp, http, etc.¶
(1 octet, Boolean)¶
This is a flag in a User ID's self-signature that states whether this User ID is the main User ID for this key.
It is reasonable for an implementation to resolve ambiguities in preferences, for example, by referring to the Primary User ID.
If this flag is absent, its value is zero.
If more than one User ID in a key is marked as primary, the implementation may resolve the ambiguity in any way it sees fit, but it is RECOMMENDED that priority be given to the User ID with the most recent self-signature.¶
When appearing on a self-signature on a User ID packet, this subpacket applies only to User ID packets.
When appearing on a self-signature on a User Attribute packet, this subpacket applies only to User Attribute packets. That is, there are two different and independent "primaries" -- one for User IDs and one for User Attributes.¶
(String)¶
This subpacket contains a URI of a document that describes the policy under which the signature was issued.¶
(N octets of flags)¶
This subpacket contains a list of binary flags that hold information about a key.
It is a string of octets, and an implementation MUST NOT assume a fixed size, so that it can grow over time. If a list is shorter than an implementation expects, the unstated flags are considered to be zero. The defined flags are as follows:¶
Table 9:
OpenPGP Key Flags Registry
| Flag |
Definition |
| 0x01... |
This key may be used to make User ID certifications (Signature Type IDs 0x10-0x13) or Direct Key signatures (Signature Type ID 0x1F) over other keys. |
| 0x02... |
This key may be used to sign data. |
| 0x04... |
This key may be used to encrypt communications. |
| 0x08... |
This key may be used to encrypt storage. |
| 0x10... |
The private component of this key may have been split by a secret-sharing mechanism. |
| 0x20... |
This key may be used for authentication. |
| 0x80... |
The private component of this key may be in the possession of more than one person. |
| 0x0004... |
Reserved (ADSK) |
| 0x0008... |
Reserved (timestamping) |
Usage notes:¶
The flags in this packet may appear in self-signatures or in certification signatures. They mean different things depending on who is making the statement. For example, a certification signature that has the "sign data" flag is stating that the certification is for that use. On the other hand, the "communications encryption" flag in a self-signature is stating a preference that a given key be used for communications. However, note that determining what is "communications" and what is "storage" is a thorny issue. This decision is left wholly up to the implementation; the authors of this document do not claim any special wisdom on the issue and realize that accepted opinion may change.¶
The "split key" (0x10) and "group key" (0x80) flags are placed on a self-signature only; they are meaningless on a certification signature.
They SHOULD be placed only on a Direct Key signature (Type ID 0x1F) or a Subkey Binding signature (Type ID 0x18), one that refers to the key the flag applies to.¶
When an implementation generates this subpacket, it SHOULD be marked as critical.¶
(String)¶
This subpacket allows a keyholder to state which User ID is responsible for the signing.
Many keyholders use a single key for different purposes, such as business communications as well as personal communications.
This subpacket allows such a keyholder to state which of their roles is making a signature.¶
This subpacket is not appropriate to use to refer to a User Attribute packet.¶
(1 octet of revocation code, N octets of reason string)¶
This subpacket is used only in Key Revocation and Certification Revocation signatures.
It describes the reason why the key or certification was revoked.¶
The first octet contains a machine-readable code that denotes the reason for the revocation:¶
Table 10:
OpenPGP Reason for Revocation (Revocation Octet) Registry
| Code |
Reason |
| 0 |
No reason specified (Key Revocation or Certification Revocation signatures) |
| 1 |
Key is superseded (Key Revocation signatures) |
| 2 |
Key material has been compromised (Key Revocation signatures) |
| 3 |
Key is retired and no longer used (Key Revocation signatures) |
| 32 |
User ID information is no longer valid (Certification Revocation signatures) |
| 100-110 |
Private Use |
Following the revocation code is a string of octets that gives information about the Reason for Revocation in human-readable form (UTF-8).
The string may be null (of zero length).
The length of the subpacket is the length of the reason string plus one.
An implementation SHOULD implement this subpacket, include it in all Revocation Signatures, and interpret revocations appropriately.
There are important semantic differences between the reasons, and there are thus important reasons for revoking signatures.¶
If a key has been revoked because of a compromise, all signatures created by that key are suspect. However, if it was merely superseded or retired, old signatures are still valid. If the revoked signature is the self-signature for certifying a User ID, a revocation denotes that that user name is no longer in use.
Such a signature revocation SHOULD include a Reason for Revocation subpacket containing code 32.¶
Note that any certification may be revoked, including a certification on some other person's key. There are many good reasons for revoking a certification signature, such as the case where the keyholder leaves the employ of a business with an email address. A revoked certification is no longer a part of validity calculations.¶
(N octets of flags)¶
The Features subpacket denotes which advanced OpenPGP features a user's implementation supports. This is so that as features are added to OpenPGP that cannot be backward compatible, a user can state that they can use that feature. The flags are single bits that indicate that a given feature is supported.¶
This subpacket is similar to a preferences subpacket and only appears in a self-signature.¶
An implementation SHOULD NOT use a feature listed when sending to a user who does not state that they can use it, unless the implementation can infer support for the feature from another implementation-dependent mechanism.¶
Defined features are as follows:¶
First octet:¶
If an implementation implements any of the defined features, it SHOULD implement the Features subpacket, too.¶
See Section 13.7 for details about how to use the Features subpacket when generating encryption data.¶
(1 octet public key algorithm, 1 octet hash algorithm, N octets hash)¶
This subpacket identifies a specific target signature to which a signature refers.
For Revocation Signatures, this subpacket provides explicit designation of which signature is being revoked. For a Third-Party Confirmation or Timestamp signature, this designates what signature is signed.
All arguments are an identifier of that target signature.¶
The N octets of hash data MUST be the size of the signature's hash. For example, a target signature with a SHA-1 hash MUST have 20 octets of hash data.¶
(1 Signature packet body)¶
This subpacket contains a complete Signature packet body as specified in Section 5.2.
It is useful when one signature needs to refer to, or be incorporated in, another signature.¶
(1 octet key version number, N octets of fingerprint)¶
The OpenPGP Key fingerprint of the key issuing the signature.
This subpacket SHOULD be included in all signatures.
If the version of the issuing key is 4 and an Issuer Key ID subpacket (Section 5.2.3.12) is also included in the signature, the Key ID of the Issuer Key ID subpacket MUST match the low 64 bits of the fingerprint.¶
Note that the length N of the fingerprint for a version 4 key is 20 octets; for a version 6 key, N is 32.
Since the version of the signature is bound to the version of the key, the version octet here MUST match the version of the signature.
If the version octet does not match the signature version, the receiving implementation MUST treat it as a malformed signature (see Section 5.2.5).¶
(1 octet key version number, N octets of fingerprint)¶
The OpenPGP Key fingerprint of the intended recipient primary key.
If one or more subpackets of this type are included in a signature, it SHOULD be considered valid only in an encrypted context, where the key it was encrypted to is one of the indicated primary keys or one of their subkeys. This can be used to prevent forwarding a signature outside of its intended, encrypted context (see Section 13.12).¶
Note that the length N of the fingerprint for a version 4 key is 20 octets; for a version 6 key, N is 32.¶
An implementation SHOULD generate this subpacket when creating a signed and encrypted message.¶
When generating this subpacket in a version 6 signature, it SHOULD be marked as critical.¶