7. Signatures over data¶
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.
“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[1].
Data signatures can only be issued by component keys with the signing key flag.
Note that data signatures are distinct from Signatures on components, which are used to form and maintain certificates, as well as to certify identities on certificates.
7.1. Signature types¶
OpenPGP data signatures use one of two signature types:
Binary signature (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.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>
). 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.
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 signatures manifest in three distinct forms, which will be detailed in the subsequent section.
7.2. Forms of OpenPGP data signatures¶
OpenPGP data signatures can be applied in three distinct forms[2]:
Detached: The OpenPGP signature exists as a separate entity, independent of the signed data.
Inline: Both the original data and its corresponding OpenPGP signature are encapsulated within an OpenPGP message.
Cleartext signature: A plain text message and its OpenPGP signature coexist in a combined text format, preserving the readability of the original message.
7.3. Detached signatures¶
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 separately, e.g. 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 where it is imperative that the content remains unaltered during the signing process.
7.4. Inline signatures¶
An inline signature joins the signed data and its corresponding data signature into a single OpenPGP message.
This method is commonly used for signing or encrypting emails. Most email software capable of handling OpenPGP communications typically uses inline signatures.
For more details and internals, see Internals of inline signed messages.
7.5. Cleartext signatures¶
The Cleartext Signature Framework (CSF) in OpenPGP accomplishes two primary objectives:
maintaining the message in a human-readable cleartext format, accessible without OpenPGP-specific software
incorporating an OpenPGP signature for authentication by users with OpenPGP-compatible software
7.5.1. Example¶
The following is a detailed example of a Section 28.3 signature:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
hello world
-----BEGIN PGP SIGNATURE-----
wpgGARsKAAAAKQWCZT0vBCIhBtB7JOyRoU3SQKwtU+bIqeBUlJpBIi6nOFdu0Zyu
o9yZAAAAANqgIHAzoRTzu/7Zuxc8Izf4r3/qSCmBfDqWzTXqmVtsSBSHACka3qbN
eehqu8H6S0UK8V7yHbpVhExu9Hu72jWEzU/B0h9MR5gDhJPoWurx8YfyXBDsRS4y
r13/eqMN8kfCDw==
=Ks9w
-----END PGP SIGNATURE-----
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.
7.5.2. Use case¶
Cleartext signatures combine the advantages of both detached and inline signatures:
Self-contained format: Cleartext signatures enable the message and its signature to be stored as a single file.
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.
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[3].
7.5.3. Text transformations for cleartext signatures¶
The cleartext signature framework includes specific text normalization procedures to ensure the integrity and clarity of the message:
Escaping dashes: The framework implements a method of 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, 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.
7.5.4. Pitfalls¶
Despite their widespread adoption, cleartext signatures have their limitations and are sometimes viewed as a “legacy method”[4]. The RFC details the pitfalls of cleartext signatures, 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.