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

Attempt at clarification, triggered by Paul's feedback in #121

Browse source
This commit is contained in:
Heiko Schaefer 2023-11-22 20:37:41 +01:00
parent f428ed956f
commit daaf172cca
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 13 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -422,11 +422,17 @@ To deal with this reality, the rpm-sequoia implementation was adjusted to accept
The Autocrypt Level 1 specification defines a specific [minimal format for OpenPGP certificates](https://autocrypt.org/level1.html#openpgp-based-key-data) that are distributed by the autocrypt mechanism.
#### Autocrypt/WKD minimization
One goal of the Autocrypt mechanism is to distribute certificates widely. To this end, Autocrypt sends certificates in mail headers, where smaller size is greatly preferable.
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.
Basic encrypted email functionality requires only a small subset of the recipient's certificate, so small certificate size is feasible.
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:
#### Minimization for email
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:
```sh
gpg --export-options export-minimal,export-clean,no-export-attributes \
@ -435,9 +441,11 @@ gpg --export-options export-minimal,export-clean,no-export-attributes \
--export wiktor@metacode.biz
```
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).
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.
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.
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.
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.
#### Pitfalls of minimization