vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-09 11:19:41 +02:00
Code Issues Projects Releases Packages Wiki Activity

Merge branch 'heiko-ch6' into draft

Browse source
This commit is contained in:
Heiko Schaefer 2023-12-10 21:48:27 +01:00
commit c9f263e769
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 39 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

49
book/source/06-signatures.md
View file

@ -66,6 +66,11 @@ As outlined above, an {term}`OpenPGP signature<OpenPGP Signature Packet>` is a c
Structure of an {term}`OpenPGP signature packet`
```
The input data packets differ between specific signature types. Also see {numref}`fig-signature-types`. For example:
- for a [*binary data signature*](data_signature_types), the input data packet is a *literal data packet*, while
- for a [*subkey binding signature*](bind_subkey), the input data packets consist of a primary and a subkey packet.
### Creating an OpenPGP signature packet
Creating an {term}`OpenPGP signature packet` involves encoding a statement about a specific set of data within the {term}`packet`.
@ -155,18 +160,42 @@ For specific guidelines on which {term}`subpackets<OpenPGP Signature Subpacket>`
{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](https://docs.keyoxide.org/wiki/ariadne-identity/).
### "Negotiating" signature hash algorithm based on recipients preference subpackets
### Choosing the hash algorithm for a signature
```{admonition} TODO
:class: warning
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.
investigate, discuss: GnuPG uses preference packets for the User ID that was addressed while sequoia completely omits User ID preferences and either uses Direct Key Sigs or (I think) primary User ID.
```
Different hash mechanisms offer different trade-offs:
### Explore viability of having multiple signatures, e.g. v4+v6?
- *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.
```{admonition} TODO
:class: warning
The following sections discuss how the hash algorithm is chosen, based on preferences that are associated with the involved OpenPGP certificates.
C-R 5.2. says: An implementation MUST generate a version 6 signature when signing with a version 6 key. An implementation MUST generate a version 4 signature when signing with a version 4 key.
```
#### 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](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-hash-algorithm-preferences).
The recipient's hash algorithm preference is defined in metadata of their certificate, see {ref}`algo-pref` 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](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).