mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-22 23:52:05 +01:00
make second-pass edits to ch7
This commit is contained in:
parent
d47d9fdd53
commit
7ed65cc02c
1 changed files with 5 additions and 5 deletions
|
@ -6,7 +6,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0
|
|||
(signing_data)=
|
||||
# Signatures over data
|
||||
|
||||
In OpenPGP, a *data signature* guarantees the authenticity and, implicitly, the integrity of certain data. Typical use cases include the authentication of software packages and 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.
|
||||
|
||||
"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].
|
||||
|
@ -23,7 +23,7 @@ Note that data signatures are distinct from {ref}`component_signatures_chapter`,
|
|||
OpenPGP data signatures use one of two [signature types](signature_types):
|
||||
|
||||
- [**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.
|
||||
- [**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 mitigates issues caused by platform-specific text encodings, which is important for detached and cleartext signatures where the message file might be re-encoded between signature creation and verification.
|
||||
- [**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.
|
||||
|
||||
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.
|
||||
|
||||
|
@ -33,7 +33,7 @@ Data signature packets manifest in three distinct forms, which will be detailed
|
|||
|
||||
OpenPGP data signatures can be applied in three distinct forms[^sign-modes-gpg]:
|
||||
|
||||
- **Detached**: The OpenPGP signature exists as a separate entity, independent from the signed data.
|
||||
- **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 container.
|
||||
- **Cleartext signature**: A plaintext message and its OpenPGP signature coexist in a combined text format, preserving the readability of the original message.
|
||||
|
||||
|
@ -63,7 +63,7 @@ An inline-signed OpenPGP message consists of three segments:
|
|||
|
||||
#### Creation
|
||||
|
||||
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 a data signature packet being appended to the output OpenPGP message file, where it can be efficiently stored.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
@ -96,7 +96,7 @@ The *Cleartext Signature Framework* (CSF) in OpenPGP accomplishes two primary ob
|
|||
|
||||
#### Example
|
||||
|
||||
Below is a detailed example of a {numref}`cleartext` signature:
|
||||
The following is a detailed example of a {numref}`cleartext` signature:
|
||||
|
||||
```text
|
||||
-----BEGIN PGP SIGNED MESSAGE-----
|
||||
|
|
Loading…
Reference in a new issue