From 5f694e8c23579d01b4f9dd3559b8b18bf41bcddd Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 15:11:17 +0100 Subject: [PATCH] clarification: "append" implies "stored at the end of a file." this is not generally true for these two cases. I now realize that this is weird: we're claiming that certificates are "append only". However, the meaning of that term, in OpenPGP is ... not about the location of additions. Rather it just means "we only get to add packets, not remove them". Regardless of packet order. --- book/source/08-signing_components.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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