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.
This commit is contained in:
Heiko Schaefer 2023-11-25 15:11:17 +01:00
parent 5faec16cb8
commit 5f694e8c23
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB

View file

@ -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: 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.) - [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)= (bind_subkey)=
### Binding subkeys to a certificate ### Binding subkeys to a certificate
@ -131,7 +131,7 @@ Take for instance, the User ID `Alice Adams <alice@example.org>`. 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. 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 ```{figure} diag/user_id_certification.png