From b049915e500911a497f78f426b951118b1b7bd2b Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 16 Nov 2023 17:27:04 +0100 Subject: [PATCH] ch4: edit "minimization" for flow, clarity, terminology --- book/source/04-certificates.md | 60 ++++++++++++++++++++-------------- 1 file changed, 35 insertions(+), 25 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index a223954..e5eab68 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -329,55 +329,65 @@ write ### Certificate minimization -Certificate minimization is a practice of presenting partial view of a certificate by filtering out selected components. +Certificate minimization is the practice of presenting a partial view of a certificate by filtering out some of its components. -Stripping some components has several benefits: - - since everyone can append data to other certificates by certifying User IDs this in the worst case can lead to ["certificate flooding"](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) which inflates the target certificate to the point that the consumer software rejects the certificate completely, - - in some contexts it's clear that the entire certificate is not necessary to facilitate some workflows, for example e-mail clients require only encryption, signing and certifying component keys and they don't need authentication subkeys that are used for SSH connections, - - sometimes the certificate grows naturally so big that the user software [has problems handing it](https://www.reddit.com/r/GnuPG/comments/bp23p4/my_key_is_too_large/). +Filtering out some elements of a certificate can have different benefits: + +- For some workflows it's clear that the full certificate is not required. For example, email clients only need encryption, signing and certification component keys. They don't need authentication subkeys, which are used for SSH connections. +- In some contexts, data can be added to certificates by third parties, e.g. by adding third-party User ID certifications on some key servers. In the worst case this can lead to ["certificate flooding"](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) which inflates the target certificate to a point where consumer software rejects the certificate completely. Filtering out elements can mitigate this. +- Sometimes, a certificate organically grows so big that the user software [has problems handing it](https://www.reddit.com/r/GnuPG/comments/bp23p4/my_key_is_too_large/). #### Implementations -GnuPG is [stripping signatures on key import](https://dev.gnupg.org/T4607#127792). +GnuPG [strips some signatures on key import](https://dev.gnupg.org/T4607#127792). -Besides that GnuPG also offers two ways of cert minimization, described [in their manual](https://www.gnupg.org/documentation/manuals/gnupg-devel/OpenPGP-Key-Management.html) as: +In addition, GnuPG offers two explicit methods for certificate minimization, described [in the GnuPG manual](https://www.gnupg.org/documentation/manuals/gnupg-devel/OpenPGP-Key-Management.html) as: -> - clean -> Compact (by removing all signatures except the selfsig) any user ID that is no longer usable (e.g. revoked, or expired). Then, remove any signatures that are not usable by the trust calculations. Specifically, this removes any signature that does not validate, any signature that is superseded by a later signature, revoked signatures, and signatures issued by keys that are not present on the keyring. -> - minimize -> Make the key as small as possible. This removes all signatures from each user ID except for the most recent self-signature. +*clean* +: *Compact (by removing all signatures except the selfsig) any user ID that is no longer usable (e.g. revoked, or expired). Then, remove any signatures that are not usable by the trust calculations. Specifically, this removes any signature that does not validate, any signature that is superseded by a later signature, revoked signatures, and signatures issued by keys that are not present on the keyring.* -`clean` removes signatures from keys that are not present in current keyring as well as stale data while `minimize` removes signatures that are not needed at the point when the command is executed. +*minimize* +: *Make the key as small as possible. This removes all signatures from each user ID except for the most recent self-signature.* -Some libraries, such as Sequoia, depend on old self-signatures as they construct a view of the certificate in the past, when the signature was allegedly created. This can cause problems with signature verification as [reported in rpm-sequoia ticket](https://github.com/rpm-software-management/rpm-sequoia/issues/50#issuecomment-1689642607) where Sequoia ultimately would revert back to GnuPG-specific approach. +`clean` removes third-party signatures by certificates that are not present in current keyring, as well as other stale data. `minimize` removes superseded signatures that are not needed at the point when the command is executed. + +#### Limitations that can result from stripping historical self-signatures + +Some implementations, such as Sequoia, prefer to rely on the full historical set of self-signatures to construct a view of the certificate over time. This way, signatures can be verified at different reference times. In this model, removing superseded self-signatures can cause problems with the validation of historical signature. + +An example for the tension between minimization and nuanced verification of the [temporal validity](temporal-validity) of signatures can be seen in the case of [rpm-sequoia](https://github.com/rpm-software-management/rpm-sequoia/issues/50#issuecomment-1689642607). To handle the limited availability of historical self-signatures on certificates in the wild, the rpm-sequoia implementation was adjusted to accept self-signatures that predate the existing self-signature for the signing key. #### Autocrypt/WKD minimization -E-mail clients depend only on a limited subset of components of the certificate, thus it's possible to construct a smaller key that will be easier to transfer buy mail user-agents. +Email clients depend only on a limited subset of the components of certificates. Thus, it's possible to use a smaller view of that certificate, which is easier to transfer by mail user-agents. -For example the following fragment drops any subkey that is not usable at the time of export. Additionally all Authentication subkeys are stripped since they do not have any use for e-mail: +For example the following fragment drops any subkey that is not usable at the time of export. Additionally, all *authentication* subkeys are stripped since they do not have any use for email: ```sh -gpg --export-options export-minimal,export-clean,no-export-attributes --export-filter keep-uid=mbox=wiktor@metacode.biz --export-filter 'drop-subkey=expired -t || revoked -t || usage =~ a' --export wiktor@metacode.biz +gpg --export-options export-minimal,export-clean,no-export-attributes \ + --export-filter keep-uid=mbox=wiktor@metacode.biz \ + --export-filter 'drop-subkey=expired -t || revoked -t || usage =~ a' \ + --export wiktor@metacode.biz ``` -At the time of writing this exported key has exactly 3771 bytes which is significantly smaller from a full key which weights 152322 bytes. The minimization made the key 40 times smaller which may be important in some contexts (e.g. e-mail headers). +At the time of writing, the resulting filtered exported certificate comprises 3771 bytes. This is significantly smaller than the full certificate, which comprises 152322 bytes. The minimization made the certificate 40x smaller, which can be important in some contexts (e.g. when embedding the certificate in email headers). -Note that in some contexts it's not clear if minimization brings more benefit than harm. Consider ProtonMail client which fetches OpenPGP certificates via WKD automatically when composing a message. It needs only subkeys. But if the same key is fetched as part of automatic signature verification then stripping certifications and leaving only subkeys would prevent the client from performing Web of Trust calculations and authenticating the certificate. +Note that in some contexts it's not clear if minimization brings more benefit than harm. Consider the ProtonMail client, which fetches OpenPGP certificates via WKD automatically when composing a message. It needs only subkeys. But if the same key is fetched as part of automatic signature verification then stripping certifications and leaving only subkeys would prevent the client from performing Web of Trust calculations and authenticating the certificate. #### Pitfalls of minimization -Disadvantages of minimized certificates: - - does not present full view on how the certificate evolved, - - as other certificates are collected, the certifications that were previously unusable become usable again, minimization prevents this mechanism, - - removing keys unusable by the minimizing implementation may mean the receiver will not see them even if *they* support them, - - refreshing keys from keyservers will inflate the key again since OpenPGP certificates are append-only structures, - - carelessly stripping all invalid components may make the key unusable. Some libraries, such as [anonaddy-sequoia](https://gitlab.com/willbrowning/anonaddy-sequoia/-/blob/master/src/sequoia.rs?ref_type=heads#L125) strip all unusable encryption subkeys unless it leaves the key with no encryption subkeys. In this case at least one subkey is left. Even though it may be expired it presents a better UX for the end-user who probably is still in possesion of the private key for decryption. +Disadvantages/risks of minimizing certificates: + +- Does not present full view of how the certificate (and the validity of its components) evolved over time. +- As other certificates are collected, third-party certifications that were previously unusable may become usable again. Dropping third-party certifications as a part of minimization prevents this mechanism. +- Removing component keys that the minimizing implementation can't use means that the receiver does not receive a copy of those, even if *the receiver* supports them. +- Refreshing certificates from key servers may inflate the certificate again, since OpenPGP certificates tend to act as [append-only structures](append-only). +- Carelessly stripping all invalid components may make the certificate unusable. Some libraries, such as [anonaddy-sequoia](https://gitlab.com/willbrowning/anonaddy-sequoia/-/blob/master/src/sequoia.rs?ref_type=heads#L125) strip unusable encryption subkeys. However, at least one subkey is retained, even if all encryption subkeys are unusable. Even though this may leave only an expired encryption subkey in the certificate, this presents a better UX for the end-user who probably is still in possession of the private key for decryption. #### Guidelines 1. Don't minimize certificates unless you have a good reason to -2. If presenting minimzied certificate view consider when it needs updates. In the best case the certificate would be minimized on demand (e.g. Autocrypt header constructed when the e-mail is sent or composed) and the client would merge all data collected. +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. ### "Naming" a certificate in user-facing contexts - fingerprints and beyond