mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-30 03:22:06 +01:00
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:
parent
5faec16cb8
commit
5f694e8c23
1 changed files with 2 additions and 2 deletions
|
@ -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
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue