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

edits to commit 7e339903fc

Browse source
This commit is contained in:
Tammi L. Coles 2023-12-04 11:49:19 +00:00
parent 6bc0ddddd9
commit a20aaba4d3
1 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
book/source/08-signing_components.md
View file

@ -72,7 +72,7 @@ Self-signatures play a crucial role in forming and managing the structure of Ope
Internally, an OpenPGP certificate is essentially a series of packets strung sequentially. When a certificate is stored in a file format known as a [transferable public key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-transferable-public-keys), packets can be easily added or removed.
To safeguard against unauthorized addition or alteration of components, OpenPGP uses cryptographic signatures. These validate that all components, such as subkeys or [identity components](identity_components), were linked to the OpenPGP certificate by its owner, using the primary key. While anyone can still store unrelated elements to a certificate dataset, OpenPGP implementations will reject them if they lack a valid cryptographic connection with the certificate.
To safeguard against unauthorized additions or alterations of components, OpenPGP uses cryptographic signatures. These validate that all components, such as subkeys or [identity components](identity_components), were linked to the OpenPGP certificate by its owner, using the primary key. While anyone can still store unrelated elements to a certificate dataset, OpenPGP implementations will reject them if they lack a valid cryptographic connection with the certificate.
```{note}
Conversely, omissions of packets by third parties can easily occur when handling an OpenPGP certificate dataset. This could pose a challenge, for example, when an attacker deliberately omits revocation packets. Without access to an alternative, complete certificate source, recipients might not detect these omissions.
@ -115,7 +115,7 @@ Binding subkeys that possess the *signing* key flag to a certificate represents
That is, to bind a signing-capable subkey to a primary key, it is insufficient that the "primary key wants to be associated with the subkey." The subkey must explicitly signal that it "wants to be associated with the primary key."
This mutual binding is crucial for security. Without it, an individual (e.g., Alice) could falsely claim a connection to another person's (e.g., Bob's) signing subkey.
As a consequence, Alice could claim to have issued signatures which were in fact issued by Bob.
Alice could thus claim to have issued signatures which were actually issued by Bob.
To prevent such scenarios, where an attacker might wrongfully "adopt" a victim's signing subkey, a dual-layer of signatures is used:
- the [subkey binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-subkey-binding) (type ID `0x18`), which is issued by the certificate's primary key