4.7 KiB
Advanced material: Signatures
(notation-signature-subpackets)=
Notation signature subpackets
Notation signature subpackets can be used to effectively extend the otherwise limited set of {term}signature subpacket types<OpenPGP Signature Subpacket Type> in OpenPGP with user-defined {term}notations<Notation>. {term}Issuers<Issuer> can use these {term}notations<Notation> to add name-value pairs to an {term}OpenPGP signature<OpenPGP Signature Packet>.
{term}Notation names - strings encoded in UTF-8 - may reside in the "user namespace." This namespace is characterized by a {term}notation tag, followed by a DNS domain name, both in UTF-8 format.
{term}Notations<Notation>, as described earlier, allow for user-defined extensions to the {term}OpenPGP signature subpacket types<OpenPGP Signature Subpacket Type>. A practical and popular application of this functionality is seen in Keyoxide, a decentralized {term}identity verification service. Keyoxide uses {term}notations<Notation> in the ariadne.id namespace. For the details of this {term}implementation<OpenPGP Implementation>, refer to the Keyoxide documentation.
Choosing the hash algorithm for a signature
A central element of signature packets is the hash digest of the input data. Most OpenPGP software supports a set of different hash mechanisms, of which one is chosen for each signature packet (this is one aspect of OpenPGP's cryptographic agility), and used to calculate the hash digest.
Different hash mechanisms offer different trade-offs:
- Hash digest size: Larger hash size tends to correspond with greater strength against cryptanalysis, and hash digests are relatively small: at the time of this writing, typical sizes are 32 to 64 bytes. However, for some use cases - especially where small messages are sent over a bandwidth-limited transport - larger hash sizes may unacceptably increase message size.
- Computational cost: Different hash algorithms may have different computational costs. Some OpenPGP users may prefer to limit this cost, for example on constrained computing environments.
The following sections discuss how the hash algorithm is chosen, based on preferences that are associated with the involved OpenPGP certificates.
Typically: Local determination
Often, signature creation isn't targeted at a specific receiver. Many signatures are issued for an indeterminate set of "anyone who receives the signature."
For example, self-signatures that form a certificate are aimed at everyone who interacts with that certificate. Similarly, when creating a data signature for a software package, this signature is aimed at "anyone who will check the signature," often over a long period of time, easily spanning years.
In such cases, the issuer of that signature chooses the hash algorithm locally, without following preferences of a third party.
With a specific recipient: "Negotiation" based on recipient's preferences
In contrast, when a message is created for a specific recipient, the sender can - and should - choose the hash algorithm for the signature packet based on the recipient's hash algorithm preference.
The recipient's hash algorithm preference is defined in metadata of their certificate, see {ref}preferences-features for more details.
In this workflow, the signed hash digest is created with a hash algorithm that follows the recipient's preferences, and its intersection with the sender's capabilities and preferences.
Signature versions
As described in the RFC, the version of a generated signature packet must conform to the version of the key that issues the signature.
That is:
- OpenPGP version 6 keys must generate version 6 signature packets
- OpenPGP version 4 keys must generate version 4 signature packets
Note that some historical version 3 signature packets may still be relevant for applications that handle old OpenPGP data[^sig-v3]. These version 3 signature packets will have been generated by version 4 keys.
[sig-v3]Version 4 signature packets were introduced in RFC 2440 in 1998, which specifies that applications SHOULD generate v4 signature, however generation of v3 signature packets has remained allowed through RFC 4880.