mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-30 03:22:06 +01:00
Improve on original text: "Elements" encompass both "components" and "signatures." Regarding malicious addition, we care about both.
Additionally, "typically" reads confusingly weak to me, erring on the side of "maybe too strong" with "will" seems better.
This commit is contained in:
parent
97e413a3dd
commit
5faec16cb8
1 changed files with 1 additions and 1 deletions
|
@ -70,7 +70,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.
|
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 additions, OpenPGP uses cryptographic signatures. These validate that any additions, such as subkeys or [identity components](identity_components), were made by the owner of the OpenPGP certificate using its primary key. While anyone can still store unrelated subkeys and identity components to a certificate dataset, OpenPGP implementations typically reject components lacking a valid cryptographic connection with the certificate.
|
To safeguard against unauthorized additions, OpenPGP uses cryptographic signatures. These validate that any additions, such as subkeys or [identity components](identity_components), were made by the owner of the OpenPGP certificate using its 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}
|
```{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.
|
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.
|
||||||
|
|
Loading…
Reference in a new issue