diff --git a/book/source/08-signing_components.md b/book/source/08-signing_components.md index 0c09153..0d404a5 100644 --- a/book/source/08-signing_components.md +++ b/book/source/08-signing_components.md @@ -79,7 +79,7 @@ Conversely, omissions of packets by third parties can easily occur when handling However, there are legitimate instances in which third parties add "unbound" packets (i.e., not signed by the certificate's owner) to a certificate: - [Third-party certifications](third_party_cert) are often stored within the packet data of the certificate to which they are related. This is a standard practice that provides convenience for users by allowing easy access to all relevant certifications. (See {ref}`cert-flooding` for discussion of a related pitfall.) -- OpenPGP software may locally append [unbound identity data](unbound_user_ids) to a certificate. +- OpenPGP software may locally add [unbound identity data](unbound_user_ids) to a certificate. (bind_subkey)= ### Binding subkeys to a certificate @@ -131,7 +131,7 @@ Take for instance, the User ID `Alice Adams `. To link this U There are four types of *certifying self-signature*. The most commonly used type for binding User IDs is the [positive certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-positive-cert) (type ID `0x13`). Alternatively, types `0x10`, `0x11` or `0x12` might be used. This binding signature must be issued by the primary key. -The certifying self-signature packet – calculated over the primary key, User ID, and metadata of the signature packet – is then appended to the certificate, directly following the User ID packet. +The certifying self-signature packet – calculated over the primary key, User ID, and metadata of the signature packet – is then added to the certificate, directly following the User ID packet. ```{figure} diag/user_id_certification.png