vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-09 11:19:41 +02:00
Code Issues Projects Releases Packages Wiki Activity

ch4: merging: process feedback from paul in #121

Browse source
This commit is contained in:
Heiko Schaefer 2023-11-22 18:45:30 +01:00
parent 61ada929e7
commit 113077109b
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 6 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

8
book/source/04-certificates.md
View file

@ -357,8 +357,12 @@ For example, Bob's OpenPGP system may have a local copy of Alice's certificate,
Merging two versions of a certificate involves making decisions about which packets should be kept. The versions of the certificate will typically contain some packets that are identical. No duplicates of the exact same packet should be stored in the merged version of the certificate. Additionally, if the newly obtained copy contains packets that are in fact entirely unrelated to the certificate, those should not be retained (a third party may have included unrelated packets, either by mistake, or with malicious intent).
- How to merge two copies of the same certificate?
- Canonicalization
#### Handling unauthenticated information
For information that *is* related to the certificate, but not bound to it by a self-signature, there is no generally correct approach. The receiving implementation must revolve these cases, possibly in a context-specific manner. Such cases include:
- Third-party certifications. These could be valuable information, where a third party attests that the association of an identity to a certificate is valid. On the other hand, they could also be a type of spam.
- Subpackets in the unhashed area of a signature packet. Again, these could contain information that is useful to the recipient. However, the data could also be either useless, or even misleading/harmful.
(cert-mini)=
### Certificate minimization