From f3da8a4dcda15d60ae17cb9b90cbd67312837962 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 19:16:06 +0100 Subject: [PATCH] Process Wiktor's input --- book/source/04-certificates.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index a50fa62..27be16a 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -352,7 +352,7 @@ However, there are contexts in which it is preferable to only use a subset of th As described above, OpenPGP certificates are effectively [append-only](append-only) data structures. As part of the practical realization of this fact, OpenPGP software needs to *merge* different copies of a certificate. -For example, Bob's OpenPGP system may have a local copy of Alice's certificate, and obtain a different version of Alice's certificate from a keyserver. The goal of the implementation is to add new information about Alice's certificate, if any, to the local copy. Alice may have added a new identity, replaced a subkey with a replacement subkey, or revoked some components of her certificate. Or, Alice may have revoked her certificate, signaling that she doesn't want communication partners to use that certificate anymore. All of these updates could be crucial for Bob to be aware of. +For example, Bob's OpenPGP system may have a local copy of Alice's certificate, and obtain a different version of Alice's certificate from a keyserver. The goal of the implementation is to add new information about Alice's certificate, if any, to the local copy. Alice may have added a new identity, replaced a subkey with a new subkey, or revoked some components of her certificate. Or, Alice may have revoked her certificate, signaling that she doesn't want communication partners to use that certificate anymore. All of these updates could be crucial for Bob to be aware of. 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). @@ -445,16 +445,16 @@ Disadvantages/risks of minimizing certificates: #### Guidelines -1. Don't minimize certificates unless you have a good reason to +1. Don't minimize certificates unless you have a good reason to. 2. When presenting a minimized certificate view, consider when that view needs to be updated. Ideally, minimized certificates are freshly generated, on demand (e.g. the Autocrypt header is constructed while an email is sent or composed) and the client merges all data collected. ### Fingerprints and beyond: "Naming" certificates in user-facing contexts #### Version 4 -With OpenPGP version 4 certificates, it was customary that user-facing software used 20 byte *fingerprints* as an identifier for the certificate. Or alternatively, the shortened 8 byte *Key ID*. Both were represented in hexadecimal format, sometimes with whitespace to group the fingerprint into blocks for easier readability. +With OpenPGP version 4 certificates, it was customary that user-facing software used 20 byte *fingerprints* as an identifier for the certificate. Or alternatively, shortened *Key ID* variants of the fingerprint. Both were represented in hexadecimal format, sometimes with whitespace to group the identifier into blocks for easier readability. -For example, in workflows to accept a certificate for a communication partner, or during third-party certification of an identity, users were shown hexadecimal representations of a fingerprint, and asked to manually verify that the fingerprint corresponds to the expected certificate. +For example, in workflows to accept a certificate for a communication partner, or during third-party certification of an identity, users were shown hexadecimal representations of a fingerprint. Users were asked to manually verify that the fingerprint corresponds to the expected certificate. #### Version 6 @@ -466,7 +466,9 @@ Instead, "mechanical fingerprint transfer and comparison" should be preferred, w However, both Fingerprints and Key IDs may (and usually *must*) be used, programmatically, by software that handles OpenPGP data, to address specific certificates. This is equally true for OpenPGP version 6. -Note that regardless of the OpenPGP version, software that relies on (8 byte) Key IDs should not assume that Key IDs are unique. It is trivial to generate collisions for Key IDs, so applications must be able to handle Key ID collisions gracefully. +Note that regardless of the OpenPGP version, software that relies on 8-byte Key IDs should not assume that Key IDs are unique. It is trivial to generate collisions for 8-byte Key IDs, so applications must be able to handle Key ID collisions gracefully. + +The historical 4-byte "short Key IDs" format should not be used anywhere, anymore (finding collisions in a 32-bit keyspace has been [trivial for a long time](https://evil32.com/)). ### When are certificates valid?