vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-23 08:02:05 +01:00
Code Issues Projects Releases Packages Wiki Activity

Merge pull request 'ch7: edits by tammi plus text by heiko' (#117) from tammi-heiko-ch7 into draft

Browse source 
Reviewed-on: https://codeberg.org/openpgp/notes/pulls/117
This commit is contained in:
heiko 2023-11-16 16:26:02 +00:00
commit 8db1df2a91
1 changed files with 53 additions and 56 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

109
book/source/07-signing_data.md
View file

@ -6,92 +6,97 @@ SPDX-License-Identifier: CC-BY-SA-4.0
(signing_data)= (signing_data)=
# Signatures over data # Signatures over data
A *data signature* guarantees the authenticity (and implicitly also the integrity) of some data. Typical use cases for data signatures in OpenPGP are signatures for software packages or emails. In OpenPGP, a *data signature* guarantees the authenticity and, implicitly, the integrity of certain data. Typical use cases of data signatures include the authentication of software packages and emails.
When we say "authenticity," here, we mean that the signature guarantees that whoever controls the signing key material has issued the signature. "Authenticity" in this context means that the data signature was issued by the entity controlling the signing key material. However,
it does not automatically signal if the expected party indeed controls the signer certificate. OpenPGP does offer mechanisms for *strong authentication*, connecting certificates to specific identities. This verifies that the intended communication partner is indeed associated with the cryptographic identity behind the signature[^sign-auth].
It is a separate question if the party we expect indeed controls the signer certificate. OpenPGP does offer mechanisms for *strong authentication* of the connection between certificates and identities. So, if necessary, we can also verify that our intended communication partner really uses the cryptographic identity that issued the signature[^sign-auth]. [^sign-auth]: Other signing solutions, like [signify](https://flak.tedunangst.com/post/signify), focus on pure signing without strong authentication of the signer's identity.
[^sign-auth]: Other signing solutions, such as [signify](https://flak.tedunangst.com/post/signify), typically only offer a solution for pure signing, without offering a mechanism for strong authentication of the identity of the signer. Data signatures can only be issued by component keys with the *signing* [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags).
Data signatures can only be issued by component keys that carry the *signing* [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags). Note that data signatures are distinct from {ref}`component_signatures_chapter`, which are used to form and maintain certificates, as well as to certify identities on certificates.
Note that signatures over data are distinct from {ref}`component_signatures_chapter`, which are used to attach metadata or subkeys to a certificate.
(data_signature_types)=
## Signature types ## Signature types
Data signatures use one of two OpenPGP [signature types](signature_types): OpenPGP data signatures use one of two [signature types](signature_types):
- "Signature of a binary document" (*Binary Signature*, type ID `0x00`): A universal signature type for binary data. Binary signatures are typically used for files or data streams. - [**Binary signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-binary) (type ID `0x00`): This is the standard signature type for binary data and is typically used for files or data streams. Binary signatures are calculated over the data without any modifications or transformations.
Binary signatures are calculated over the data "as is", without performing any transformations. - [**Text signature**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-of-a-canonical-te) (type ID `0x01`): Used for textual data, such as email bodies. When calculating a text signature, the data is first normalized by converting line endings into a canonical form (`<CR><LF>`). This approach mitigates issues caused by platform-specific text encodings. This is especially important for detached and cleartext signatures, where the message file might undergo re-encoding between the creation and verification of the signature.
- "Signature of a canonical text document" (*Text Signature*, type ID `0x01`): Used for textual data, such as email bodies. When calculating a text signature, the data is first normalized by converting line endings into a canonical form (`<CR><LF>`). The normalization mitigates issues caused by platform-specific text encodings, for example with detached signatures, where the message file may get re-encoded between signature generation and validation.
Data signatures are generated by hashing the message content, plus the metadata in the signature packet, and calculating a cryptographic signature over that hash. The resulting cryptographic signature is stored in an OpenPGP signature packet. Data signatures are generated by hashing the message content along with the metadata in the OpenPGP signature packet, and calculating a cryptographic signature over that hash. The resulting cryptographic signature is stored in the signature packet.
Data signature packets can be used in three different forms. We'll discuss these in the following section. Data signature packets manifest in three distinct forms, which will be detailed in the subsequent section.
## Forms of OpenPGP data signatures ## Forms of OpenPGP data signatures
OpenPGP signatures over data can be used in three different forms[^sign-modes-gpg]: OpenPGP data signatures can be applied in three distinct forms[^sign-modes-gpg]:
- *Detached*: The signature is a standalone artifact, separate from the signed data. - **Detached**: The OpenPGP signature exists as a separate entity, independent of the signed data.
- *Inline*: The original data and the signature over the data are collectively stored in an OpenPGP container. - **Inline**: Both the original data and its corresponding OpenPGP signature are encapsulated within an OpenPGP container.
- *Cleartext signature*: A message in text format and a signature over this message are stored in a combined text-format, which leaves the original message in a human-readable representation. - **Cleartext signature**: A plaintext message and its OpenPGP signature coexist in a combined text format, preserving the readability of the original message.
[^sign-modes-gpg]: These three signature forms correspond with GnuPG's `--detach-sign`, `--sign` and `--clear-sign` modes. [^sign-modes-gpg]: These three forms of signature application align with GnuPG's `--detach-sign`, `--sign`, and `--clearsign` command options.
### Detached signatures ### Detached signatures
A detached signature is produced by calculating an OpenPGP signature over the signed data. The original data is left as is, while the OpenPGP signature is stored as a standalone file. A detached signature can be distributed alongside or independent of the original data. The authenticity and integrity of the original data file can be verified using the detached signature file. A detached signature is produced by calculating an OpenPGP signature over the data intended for signing. The original data remains unchanged, and the OpenPGP signature is stored as a standalone file. A detached signature file can be distributed alongside or independent of the original data. The authenticity and integrity of the original data file can be verified by using the detached signature file.
This signature format is especially useful for signing software releases and other files that must not be modified by the signing process. This signature format is especially useful for signing software releases and other files where it is imperative that the content remains unaltered during the signing process.
### Inline signatures ### Inline signatures
An inline signature joins the signed data and a signature over this data into one combined OpenPGP message. An inline signature joins the signed data and its corresponding data signature into a single OpenPGP message.
This method is usually used with signed and/or encrypted emails. Most software that supports OpenPGP for encrypted and/or signed messages uses inline-signatures. This method is commonly used for signing or encrypting emails. Most email software capable of handling OpenPGP communications typically uses inline signatures.
#### Structure #### Structure
An inline-signed OpenPGP message consists of three segments: An inline-signed OpenPGP message consists of three segments:
- One or more [One-Pass Signature packets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig), 1. [**One-pass signature packets**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig): These one or more packets precede the signed data and enable signature computation in one pass.
- the original data, wrapped in a [Literal Data packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit),
- the corresponding Data Signature packets. 2. [**Literal data packet**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit): This contains the original data (e.g., the body of a message), without additional interpretation or conversion.
3. **Data signature packets**: These contain the cryptographic signature corresponding to the original data.
#### Creation #### Creation
To produce an inline signature, the signer processes the entirety of the data by reading from an input file and writing into am output OpenPGP message file. The signer calculates a cryptographic signature over the course of this process. Therefore, an efficient signer can only emit the resulting data signature packet at the end of this process, and thus store it at the end of the data stream. To produce an inline signature, the signer processes the entirety of the data by reading from an input file and writing into an output OpenPGP message file. As the data is processed, the signer simultaneously calculates a cryptographic signature. This procedure results in the appending of a data signature packet to the output OpenPGP message file, where it can be efficiently stored.
On the other hand, an efficient verifying application needs to know how to process the literal data before reading it. This is the purpose of the so-called One-Pass Signature packets in the first segment of inline-signed messages. One-Pass Signature packets contain the fingerprint of the signing key, as well as the hash algorithm used to calculate the hash digest for the signature. For efficient verification, an application must understand how to handle the literal data prior to its reading. This requirement is addressed by the one-pass signature packets located at the beginning of inline-signed messages. These packets include essential information such as the fingerprint of the signing key and the hash algorithm used for computing the signature's hash digest. This setup enables the verifier to process the data correctly and efficiently.
```{admonition} TODO ```{admonition} TODO
:class: warning :class: warning
Is the signer keyid/fingerprint in the OPS important for the verifier to be able to verify the signature efficiently? Or is it (only?) there to be hashed and signed, along with the literal data? Is the signer keyid/fingerprint in the OPS important for the verifier to be able to verify the signature efficiently? Or is it (only?) there to be hashed and signed, along with the literal data?
Realization: It's probably useful to know the fingerprints right away, to first go find the public key material, before calculating the hash of a huge file.
``` ```
#### Verification #### Verification
This structure allows verifying applications to verify inline-signed messages in *one pass*: Inline-signed messages enable efficient verification in *one pass*, structured as follows:
- The One-Pass Signature packets initiate the verification process, 1. **Initiation with one-pass signature packets**: These packets begin the verification process. They include the signer's key ID/fingerprint, essential for identifying the appropriate public key for signature validation.
- the literal data can then be processed (which means: it gets hashed),
- the signature packets at the end of the message can be verified against the hash digest that the previous step calculated.
Note that the final step of verifying the cryptographic signature requires access to the signer's public key material. This public key material is not included in the signed message. The verifier must obtain the signer's public key data out-of-band (e.g. by obtaining the signer's certificate from a key server). 2. **Processing the literal data packet**: This step involves hashing the literal data, preparing it for signature verification.
3. **Verifying signature packets**: Located at the end of the message, these packets are checked against the previously calculated hash digest.
Important to note, the signer's public key, critical for the final verification step, is not embedded in the message. Verifiers must acquire this key externally (e.g., from a key server) to authenticate the signature successfully.
### Cleartext signatures ### Cleartext signatures
The *Cleartext Signature Framework* (CSF) is an OpenPGP mechanism that combines two goals: The *Cleartext Signature Framework* (CSF) in OpenPGP accomplishes two primary objectives:
- It leaves the message in clear text format, so that it can be viewed directly by a human in a program that knows nothing about OpenPGP. - maintaining the message in a human-readable cleartext format, accessible without OpenPGP-specific software
- At the same time, it adds an OpenPGP signature that allows verification of that message by users whose software supports OpenPGP. - incorporating an OpenPGP signature for authentication by users with OpenPGP-compatible software
#### Example #### Example
In {numref}`cleartext` we inspect an example of a cleartext signature in detail. Let's have a brief look at this example, here, to get a sense of what a cleartext signature looks like: The following is a detailed example of a {numref}`cleartext` signature:
```text ```text
-----BEGIN PGP SIGNED MESSAGE----- -----BEGIN PGP SIGNED MESSAGE-----
@ -108,42 +113,34 @@ r13/eqMN8kfCDw==
-----END PGP SIGNATURE----- -----END PGP SIGNATURE-----
``` ```
The cleartext signature consists of two blocks, which contain the message and a signature, respectively. In this case, the message consists of the text "hello world". This signature consists of two parts: a message ("hello world") and an ASCII-armored OpenPGP signature. The message is immediately comprehensible to a human reader, while the signature block allows for the message's authenticity verification via OpenPGP software.
Notice that this message is readable by a human reader, without requiring additional software tools, as long as the reader understands which elements to ignore. #### Use case
The message is followed by a block that contains an ASCII-armored OpenPGP signature for the message. Using this signature, OpenPGP software can verify the authenticity of the message in the first block. Clear text signatures combine the advantages of both detached and inline signatures:
#### Use-case - **Self-contained format**: Cleartext signatures enable the message and its signature to be stored as a single file.
One use-case for cleartext signatures is: Asking someone to sign some piece of data. The person who is asked to sign the data can easily inspect it with simple commandline tools, such as `cat`, and verify that they agree with the data they are asked to sign. - **Human readability**: The message within a cleartext signature remains accessible in a plain text format. This eliminates the need for specialized software to read the message content.
```{admonition} TODO These features are particularly beneficial in scenarios where signed messages are managed semi-manually and where existing system infrastructure offers limited or no native support for OpenPGP in the workflow[^arch-certifications].
:class: warning
(Ask David for details:) [^arch-certifications]: An illustrative example is the workflow adopted by Arch Linux to certify User IDs of new packagers. This process relies on [cleartext signed statements from existing packagers](https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/blob/master/.gitlab/issue_templates/New%20Packager%20Key.md?ref_type=heads&plain=1#L33-46). These signed statements are stored as attachments in an issue tracking system for later inspection. The advantage of this approach lies in the convenience of having the message and signature in a single file, which simplifies manual handling. Based on the vouches in these cleartext signed messages and an [email confirmation from the new packager](https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/verify-a-packager-key), the main key operators can issue OpenPGP third-party certifications.
We use this for example to verify User ID and primary key of Arch Linux packagers before signing the User IDs on their keys with the main signing keys and to verify the data claims when introducing new packagers (i.e. already established packagers vouch for the data of a new packager).
```
#### Text transformations for cleartext signatures #### Text transformations for cleartext signatures
```{admonition} TODO The cleartext signature framework includes specific text normalization procedures to ensure the integrity and clarity of the message:
:class: warning
explain text transformations for cleartext signatures (LF->CRLF and additional escaping) _ **Escaping dashes**: The framework implements a method of [dash-escaped text](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-dash-escaped-text) within the message. Dash-escaping ensures that the parser correctly distinguishes between the armor headers, which are part of the signature's structure, and any lines in the message that happen to start with a dash.
```
- **Normalization of line endings**: Consistent with the approach for any other [text signature](data_signature_types), a cleartext signature is calculated on the text with normalized line endings (`<CR><LF>`). This ensures that the signature remains valid regardless of the text format of the receiving implementation.
#### Pitfalls #### Pitfalls
Cleartext signatures are popular and have useful applications. Despite their widespread adoption, cleartext signatures have their limitations and are sometimes viewed as a "legacy method"[^csf-gnupg]. The RFC details the [pitfalls of cleartext signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-issues-with-the-cleartext-s), such as incompatibility with semantically meaningful whitespace, challenges with large messages, and security vulnerabilities related to misleading Hash header manipulations. Given these issues, safer alternatives like inline and detached signature forms are advised.
At the same time, they are considered a "legacy method"[^csf-gnupg] by some.
[^csf-gnupg]: https://lists.gnupg.org/pipermail/gnupg-devel/2023-November/035428.html [^csf-gnupg]: https://lists.gnupg.org/pipermail/gnupg-devel/2023-November/035428.html
The RFC points out a number of specific [pitfalls of cleartext signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-issues-with-the-cleartext-s), and how to avoid them. It advises that in many cases, the inline and detached signature forms are preferable.
## Advanced topics ## Advanced topics
### Nesting of one-pass signatures ### Nesting of one-pass signatures