mirror of
https://codeberg.org/openpgp/notes.git
synced 2025-09-10 11:49:40 +02:00
53 lines
4.8 KiB
Markdown
53 lines
4.8 KiB
Markdown
<!--
|
||
SPDX-FileCopyrightText: 2023 The "Notes on OpenPGP" project
|
||
SPDX-License-Identifier: CC-BY-SA-4.0
|
||
-->
|
||
|
||
# Advanced material: Signatures
|
||
|
||
(notation-signature-subpackets)=
|
||
## Notation signature subpackets
|
||
|
||
[Notation signature subpackets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#notation-data) 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](https://docs.keyoxide.org/wiki/ariadne-identity/).
|
||
|
||
## 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*](https://en.wikipedia.org/wiki/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](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-hash-algorithm-preferences). 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.
|
||
|
||
## Signature versions
|
||
|
||
As described in the [RFC](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-packet-type-id-2), 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](https://datatracker.ietf.org/doc/html/rfc2440#section-5.2) in 1998, which specifies that applications SHOULD generate v4 signature, however generation of v3 signature packets has remained allowed through [RFC 4880](https://www.rfc-editor.org/rfc/rfc4880.html#section-5.2).
|