4.8 KiB
Advanced material: Signatures
(notation-signature-subpackets)=
Notation signature subpackets
Notation signature subpackets can 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." In this namespace, each notation is identified by a {term}notation tag, which is followed by a DNS domain name. Both the notation tag and the domain name are encoded in UTF-8 format.
{term}Notations<Notation> allow for user-defined extensions to the {term}OpenPGP signature subpacket types<OpenPGP Signature Subpacket Type>. A practical and popular example of this functionality is applied 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
The hash digest of the input data is a central element of signature packets in OpenPGP. The hash digest is calculated using a hash mechanism, selected from a diverse set supported by most OpenPGP software. The ability to choose from different hash mechanisms for each signature packet demonstrates OpenPGP's cryptographic agility.
Different hash mechanisms offer different trade-offs:
- Hash digest size: Generally, a larger hash size offers greater resistance against cryptanalysis. At the time of this writing, typical hash digests range from 32 to 64 bytes, which are relatively compact. However, for some use cases - especially when transmitting small messages over limited bandwidth - 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 explain how the hash algorithm is chosen, based on preferences specified in the associated OpenPGP certificates.
Typically: Local determination
Often, signature creation does not target a specific recipient. Instead, many signatures are intended for a broad audience, that is, anyone who receives the signature.
This is common in situations like self-signatures on certificates, which are relevant to all users of that certificate, or signatures on software packages, designed for anyone verifying the package, potentially over several years.
In such cases, the issuer of that signature chooses the hash algorithm locally, based on their own criteria rather than the preferences of any 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. These preferences are specified in the metadata of the recipient's OpenPGP certificate, see {ref}preferences-features for more details.
In this workflow, the signed hash digest is created with a hash algorithm that meets the recipient's preferences as well as the sender's capabilities and preferences.
Conforming to signature packet versions
As described in the RFC, the version of a generated signature packet must conform to the version of the key used to issue it. Specifically:
- OpenPGP version 6 keys must generate version 6 signature packets
- OpenPGP version 4 keys must generate version 4 signature packets
Some version 3 signature packets, while historical, may still be relevant for applications that handle legacy 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 signatures. However, generation of v3 signature packets continued to be permissable as per RFC 4880.