move example minimization to a footnote, supplement main text with a more general paragraph

This commit is contained in:
Heiko Schaefer 2023-12-04 00:00:34 +01:00
parent f142aa73e2
commit 68b9d2b04d
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB

View file

@ -475,20 +475,22 @@ Note that it's not generally clear if minimization brings more benefit than harm
For example, we might consider minimizing a certificate for distribution via WKD, with the use-case of email in mind.
The following fragment processes an example certificate. It drops any subkey that is not valid at the time of export (because of revocation or expiration). Additionally, authentication subkeys are stripped, since they are irrelevant for email:
Many certificates can be significantly pruned if the only goal of distributing them is to enable encryption and signature verification. For such cases, many components can be dropped, including invalid subkeys and their binding signatures, authentication subkeys, shadowed self-signatures, and third-party certifications. With many real-world certificates, the space savings of such a minimization are significant[^space-example].
```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
```
Such minimization might be appropriate and convenient to enable encrypted communication with a ProtonMail client, which automatically fetches OpenPGP certificates via WKD while composing a message. The ProtonMail use case requires only component keys, not third-party certifications, and it doesn't require historical component keys or self-signatures.
At the time of writing, the original certificate consists of 152322 bytes of data. The filtered variant consists of only 3771 bytes, which is 40x smaller. In some contexts, there are hard constraints on size, and minimization is unavoidable, e.g., when embedding certificate data in email headers.
However, in a different context, the same certificate might be fetched to verify the authenticity of a signature. In that case, third-party certifications may be crucial for the client. Stripping them could prevent the client from performing Web of Trust calculations and authenticating the signature.
The above minimization might be convenient when interacting with a ProtonMail client, which fetches OpenPGP certificates via WKD automatically, while composing a message. The ProtonMail use case requires only component keys, not third-party certifications, and it doesn't require historical component keys or self-signatures.
[^space-example]: The following fragment processes an example certificate. It drops any subkey that is not valid at the time of export (because of revocation or expiration), and any third-party certifications. Additionally, authentication subkeys are stripped, since they are irrelevant for email:
However, in a different context, the same certificate might be fetched to verify the authenticity of a signature. In that case, third-party certifications are crucial for the client. Stripping them could prevent the client from performing Web of Trust calculations and authenticating the signature.
```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
```
At the time of writing, the original certificate consists of 152322 bytes of data. The filtered variant consists of only 3771 bytes, which is 40x smaller. In some contexts, there are hard constraints on size, and minimization is unavoidable, e.g., when embedding certificate data in email headers.
#### Pitfalls of minimization